View
214
Download
0
Category
Tags:
Preview:
Citation preview
Topic
Critical Chain Project Management Other FrameworksLeach - Chapter 2
2IS 556 -Spring 2008 Lecture 2 Apr 7, 2008 //48
IS 556 -Spring 2008 3
Multiple Perspectives on Project System
Executeprojectseffectively
& TQM
Continually improve every PROCESSTheory of Constraints
Identifies system constraintsWorks to improve throughput
Lecture 2 Apr 7, 2008 //48
IS 556 -Spring 2008 4
PMBOK Project Management Book of Knowledge Framework that defines the areas that
require management attention.1. 9 knowledge areas2. 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 2008 5
PMBOK and Critical Chain Of the 9 knowledge areas, CCPM impacts the
following ones in bold.1. Integration2. Scope3. Time4. Cost5. Quality6. Human Resources7. Communications8. Risk
(no common-cause special-cause differentiation)9. Procurement
Lecture 2 Apr 7, 2008 //48
IS 556 -Spring 2008 6
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 change2. What to change to3. How to cause the change
5 focusing steps provide the steps to implement the improvement process
1. Identify the constraint2. Exploit the constraint3. Subordinate everything else to the constraint4. Elevate the constraint5. Do NOT let inertia prevent further improvement
Lecture 2 Apr 7, 2008 //48
IS 556 -Spring 2008 8
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 2008 9
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 2008 10
IS 556 -Spring 2008 11
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 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.
Lecture 2 Apr 7, 2008 //48
IS 556 -Spring 2008 12
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 2008 13
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.
Lecture 2 Apr 7, 2008 //48
IS 556 -Spring 2008 14
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
Lecture 2 Apr 7, 2008 //48
IS 556 -Spring 2008 15
CPM- Resource Leveled Schedule
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.
Resource leveling –rescheduling activities so resource limits not exceeded
Lecture 2 Apr 7, 2008 //48
IS 556 -Spring 2008 16
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 2008 17
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.
Lecture 2 Apr 7, 2008 //48
IS 556 -Spring 2008 18
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
Lecture 2 Apr 7, 2008 //48
IS 556 -Spring 2008 19
Several Syndromes in Action Murphy’s Law
1. What can go wrong, will go wrong, does go wrong
Parkinson’s Law1. Work expands to fill the time scheduled.
Student’s Syndrome1. No matter how much time committed to project,
effort expands as urgency increases.
This leads to the 2nd conflict
Lecture 2 Apr 7, 2008 //48
IS 556 -Spring 2008 20
2nd 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 2008 21
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?
Lecture 2 Apr 7, 2008 //48
IS 556 -Spring 2008 22
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.
Lecture 2 Apr 7, 2008 //48
IS 556 -Spring 2008 23
3rd 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 2008 24
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
Lecture 2 Apr 7, 2008 //48
IS 556 -Spring 2008 25
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.
Lecture 2 Apr 7, 2008 //48
IS 556 -Spring 2008 27
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.
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
Recommended