IS 556 Enterprise Project Management 1IS 556 -Spring 2008 Lecture 2 Apr 7, 2008 //48

Topic Critical Chain Project Management Other Frameworks Leach - Chapter 2 2IS 556 -Spring 2008Lecture 2 Apr 7, 2008 //48

IS 556 -Spring Multiple Perspectives on Project System Execute projects effectively & TQM Continually improve every PROCESS Theory of Constraints Identifies system constraints Works to improve throughput Lecture 2 Apr 7, 2008 //48

IS 556 -Spring PMBOK  Project Management Book of Knowledge  Framework that defines the areas that require management attention knowledge areas 2. 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 Lecture 2 Apr 7, 2008 //48

IS 556 -Spring PMBOK and Critical Chain  Of the 9 knowledge areas, CCPM impacts the following ones in bold. 1. Integration 2. Scope 3. Time 4. Cost 5. Quality 6. Human Resources 7. Communications 8. Risk (no common-cause special-cause differentiation) 9. Procurement Lecture 2 Apr 7, 2008 //48

IS 556 -Spring 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 1. What to change 2. What to change to 3. How to cause the change  5 focusing steps provide the steps to implement the improvement process 1. Identify the constraint 2. Exploit the constraint 3. Subordinate everything else to the constraint 4. Elevate the constraint 5. Do NOT let inertia prevent further improvement Lecture 2 Apr 7, 2008 //48

IS 556 -Spring TOC – system o/p limited by constraint Lecture 2 Apr 7, 2008 //48

IS 556 -Spring 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 Lecture 2 Apr 7, 2008 //48

IS 556 -Spring Change Management  Necessary to implement the degree of behavior change necessary to achieve the results promised by CCPM. Lecture 2 Apr 7, 2008 //48

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

IS 556 -Spring Defining the PM System The black-box view of the PM System which processes Inputs to produce Outputs that satisfy the system goal When you look at the PM System this way it becomes obvious that the undesired effects are a direct result of what we are 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. Lecture 2 Apr 7, 2008 //48

IS 556 -Spring Identifying the Dilemma (PM Constraint)  Goal of projects is to get done fast. Why? 1. Pouring money into project from inception 2. 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. Lecture 2 Apr 7, 2008 //48

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

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

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

IS 556 -Spring Critical Chain longest path after resource leveling The critical chain consists of both the time and the person (resource) constraint. Lecture 2 Apr 7, 2008 //48

IS 556 -Spring 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 contingency which leads to the EVAPORATING CLOUD for this dilemma. Lecture 2 Apr 7, 2008 //48

IS 556 -Spring st 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 Lecture 2 Apr 7, 2008 //48

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

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

IS 556 -Spring Typical Work Pattern Yet, if this is true then why do most PM literature recommend the use of the early-start schedule. The team knows that there’s slack. HMMMM Can you guess what really happens? Lecture 2 Apr 7, 2008 //48

IS 556 -Spring 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 3 rd conflict. Lecture 2 Apr 7, 2008 //48

IS 556 -Spring rd Conflict – The Multitasking Conflict Multitasking delays all projects. Also justifies using longer task times in future plans Lecture 2 Apr 7, 2008 //48

IS 556 -Spring 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 1 st – 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!! 2 ND – REDUCED LIKELIHOOD OF A LARGE OVERRUN Lecture 2 Apr 7, 2008 //48

IS 556 -Spring Contingency (Buffers) at end of Project The key part of the solution is to use “average” task completion times in the plan and to add an aggregated buffer at the end of the plan for overall project contingency. Lecture 2 Apr 7, 2008 //48

Homework Hmwk wk 2 on COL 26IS 556 -Spring 2008Lecture 2 Apr 7, 2008 //48

IS 556 -Spring Hmwk wk2 – Due Session 3  In Leach text section Rewards are discussed. Based on what Leach says and any other sources you have, answer the following questions with its label. 1. Name and describe one common reward/punishment used by project managers on individuals. 2. What project member behavior rewards from having that reward/punishment. 3. 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 Lecture 2 Apr 7, 2008 //48

IS 556 -Spring Next Session  Chapters 4-6 of Leach Lecture 2 Apr 7, 2008 //48