IS 556 Enterprise Project Management

IS 556 Enterprise Project Management IS 556 -Spring 2008

Topic Critical Chain Project Management Other FrameworksLeach - Chapter 2 IS 556 -Spring 2008

Multiple Perspectives on Project System & TQM Executeprojects effectively Continually improve every PROCESS Theory of Constraints Identifies system constraintsWorks to improve throughput IS 556 -Spring 2008

PMBOK • Project Management Book of Knowledge • Framework that defines the areas that require management attention. • 9 knowledge areas • 5 types of processes • It does not tell what areas need more attention than others under what circumstances – so there’s a tremendous amount of managerial attention spent on items that may not need it IS 556 -Spring 2008

PMBOK and Critical Chain • Of the 9 knowledge areas, CCPM impacts the following ones in bold. • Integration • Scope • Time • Cost • Quality • Human Resources • Communications • Risk (no common-cause special-cause differentiation) • Procurement IS 556 -Spring 2008

TOC – Theory of Constraints • Looks at individual project tasks logically as the operation of a system for producing the result or output of the tasks. • Determines • What to change • What to change to • How to cause the change • 5 focusing steps provide the steps to implement the improvement process • Identify the constraint • Exploit the constraint • Subordinate everything else to the constraint • Elevate the constraint • Do NOT let inertia prevent further improvement IS 556 -Spring 2008

TOC – system o/p limited by constraint IS 556 -Spring 2008

TOC – Theory of Constraints • Must first identify the system constraint (core conflict) leading to the undesired effects of present project system (or current theory). Core conflict identifies what to change. • TOC leads to a new system design or “what to change-to IS 556 -Spring 2008

Change Management • Necessary to implement the degree of behavior change necessary to achieve the results promised by CCPM. IS 556 -Spring 2008

Topic Critical Chain Project Management Direction the Solution Should Take Leach - Chapter 3 IS 556 -Spring 2008

Defining the PM System When you look at the PM System this way it becomes obvious that the undesired effects area direct result of what weare doing. Thus, we need to look to see if there’s a underlying conflict or dilemma common to projects. So, we must find the dilemma. The black-box view of the PM System which processes Inputs to produce Outputs that satisfy the system goal IS 556 -Spring 2008

Identifying the Dilemma (PM Constraint) • Goal of projects is to get done fast. Why? • Pouring money into project from inception • Getting benefits out of project only on completion • Most projects plan their schedules using the critical path method which has been around for over 40 years. IS 556 -Spring 2008

Critical Path Method (CPM) Schedule Note: we have 2 people (resources) working on project -- #1 startsworking on tasks 1,3, 5 at same time. Because resources are splittingactivities and the dependencies make completion almost impossible. IS 556 -Spring 2008

CPM Actual Task Performance Note that date is now Sept 13th – over a month later. Because all3 beginning tasks of #1 are done simultaneously, each takes 3 timeslonger because each duration on original assumed 100% commitment IS 556 -Spring 2008

CPM- Resource Leveled Schedule Resource leveling –rescheduling activities so resource limits not exceeded The software had only tasks 5 and 6 in the critical path – becausethe Critical Path is NOT determined after resource leveling. The CP isdefined as having no slack because it is the longest path to completion. IS 556 -Spring 2008

Critical Chain longest path after resource leveling The critical chain consists of both the time and the person (resource)constraint. IS 556 -Spring 2008

Exploit the Constraint • To have a successful project, every task on the critical path completes on schedule. • To do that, we must plan every task to include a contingency (difference between a 50% probable estimate and a 90% probable estimate) because of the uncertainty present. • Therefore, every task estimate will include this contingency but it is buried in the task estimate. • But, that leads to reallllllly long estimates so the PM cuts out what is assumed to be contingencywhich leads to the EVAPORATING CLOUD for this dilemma. IS 556 -Spring 2008

1st Conflict Task Time Conflict 3 typical reasons given for projects overruns-1- group responsible for the late part of the project was sloppy -2- people always underestimate how long it will take -3- management set arbitrary dates IS 556 -Spring 2008

Several Syndromes in Action • Murphy’s Law • What can go wrong, will go wrong, does go wrong • Parkinson’s Law • Work expands to fill the time scheduled. • Student’s Syndrome • No matter how much time committed to project, effort expands as urgency increases. • This leads to the 2nd conflict IS 556 -Spring 2008

2nd Conflict “Successful Completion Rewards” The answer is to do extra checks and “improve the quality” of the task I am doing. IS 556 -Spring 2008

Typical Work Pattern Yet, if this is true then why do most PM literature recommend the useof the early-start schedule. The team knows that there’s slack. HMMMMCan you guess what really happens? IS 556 -Spring 2008

Multitasking • So, everyone starts projects as the earliest possible date leading to working on several tasks simultaneously • So if you start 3 tasks at the same time and each task takes 1 week then, at best the three tasks will all take 3 weeks to complete. This assumes that there is no time lost for task switching. • This leads to the 3rd conflict. IS 556 -Spring 2008

3rd Conflict – The Multitasking Conflict Multitasking delays all projects. Also justifies using longer task times in future plans IS 556 -Spring 2008

Resolving Core Conflict • Because you cannot make predictions about a single instance of a statistical events, concentrate the uncertainty for many tasks of a project at end of the project. • Concentrate contingency in the buffer leads to 2 bonuses • 1st – SHORTER PLAN because when we take out the task buffers and put at the end of the path, they add up to the square root of the sum of the squares of the amount removed --- some tasks overrun, some tasks underrun, the distribution of the sum is not as large as the sum of the individual variations because some cancel out!! • 2ND – REDUCED LIKELIHOOD OF A LARGE OVERRUN IS 556 -Spring 2008

Contingency (Buffers) at end of Project The key part of the solution is to use “average” task completiontimes in the plan and to add an aggregated buffer at the end of the plan for overall project contingency. IS 556 -Spring 2008

Homework Hmwk wk 2 on COL IS 556 -Spring 2008

Hmwk wk2 – Due Session 3 • In Leach text section 2.5.3 Rewards are discussed. Based on what Leach says and any other sources you have, answer the following questions with its label. • Name and describe one common reward/punishment used by project managers on individuals. • What project member behavior rewards from having that reward/punishment. • In your opinion, how successful is the reward/punishment at keeping the entire project on schedule. In other words, is the project schedule really affected by the use of that reward/punishment? Why? • Ideal length – 1.0 page for all 3 answers IS 556 -Spring 2008

Next Session • Chapters 4-6 of Leach IS 556 -Spring 2008

IS 556 Enterprise Project Management