Critical Chain Project Management BCS Nottingham & Derby Winter School 2006

Steven Wray, BA, MBA, MBCS, C Eng Phone: web:

What makes a Project ? One end-point At least two tasks, linked by dependency Significant inherent unpredictability in how long the tasks will take.

What do we want from Project Management ?

Reliable on time in full to budget delivery performance More revenue, more Profit, happy customers A stable plan More Productive use of resources Simple, objective measures of Project progress Shorter meetings, better informed stakeholders - less waste, more productivity Simple, objective measures of Project health status Shorter meetings, better informed stakeholders - less waste, more productivity Clear signals for when corrective action is - and is not - necessary Better directed recovery efforts - less waste, more productivity Direction for ongoing improvement efforts The future brings more revenue, more profit, happier customers than the present

What is our normal experience from today's way of Project Management ?

Reliable on time in full to budget delivery performance ? Or A continuous struggle with time, cost and scope ? A stable plan Or Repeated rescheduling ? Simple, objective measures of Project progress ? Or Clarity at the start and end, thick fog in between ? Simple, objective measures of Project health status ? Or Subjective assessments compounded by human factors ? Clear signals for when corrective action is - and is not - necessary ? Or Intervening too much too early, and too little too late ? Direction for ongoing improvement efforts ? Or"We'll improve our methods when things get better"

'Normal' Practice in the planning phase We identify the tasks in the Project and specify the resources needed for each one We allocate to each task sufficient time that we are confident will allow it to be completed with those resources. That is, the time the task should take on average, plus some contingency to give us the confidence we seek We apply task dependencies, and work out the longest path of tasks in the Project The time along this path is the time-line of the Project

Normal practice in the execution phase As long as every task completes on time (within its contingency), its successors will be started on time As soon as any task finishes late (outside its contingency), its successors will start late, and this normally means they will finish late In order to rescue a Project which shows any lateness, we have to squeeze the remaining tasks in the Project Typically we have to compromise on time, cost or scope and reschedule

The Estimating Dilemma If I allow more time for every task in the plan, each task is less likely to be late, but the Project end date will be later... If I allow less time, the end date will be earlier, but the Project is more likely to overrun BUT I have to deliver the Project on time

How long should we allow in the plan for a task ? Some staff work more quickly than others Sometimes staff are distracted or interrupted Sometimes necessary resources are delayed Some staff are risk-averse in their commitments Some organisations reinforce risk-aversion

How long do we allow in the plan for a task ? The average time the task ought to take an average performer who focuses on it PLUS The time we expect to be spent on distractions PLUS A contingency time to take account of: The spread between average and low performers Our uncertainty in the average time Our uncertainty in the time for distractions How risk-averse we are or have to be

Some simple maths If we set our estimates so that we are 90% sure that any one task will be completed on time If we have 20 tasks in our Project The Probability that all the tasks will be on time is: = 12% For 50 tasks, the Probability of all on time is: = 1%

Emphasising Doing things by the text-book, with 20 tasks, each of which we are 90% sure will complete on time, we have an 88% probability of being late for the Project With 50 tasks, its a lot worse: its a 99% probability of being late for the Project

What if we change our estimating to a 95% confidence level ? NB This will inflate the time for every task maybe by % because we will need more contingency For 20 tasks the probability of being late is now 64% (was 88%) For 50 tasks we are late now 92% (was 99%) We have very much extended our Project time-line, and increased our chances of success from 12% to 36% for the small Project, and from 1% to 8% for the large Project

Surely, there's a better way... Plan A - invest our energy in reducing the extent of the variability: -Allowing longer in Project planning stage for preparing estimates -Training staff in estimating -Use of formal estimating methods -Measuring progress (CSC tools) and feeding results back into estimating practice -More detailed specifications -Less flexibility over changes to specifications -Training the staff better in their job content -Using individual performance measures to identify poor performers -Keeping projects short (c 6 months), breaking larger undertakings into several short Projects Doing this can help, but doesn't solve the problem

Plan B - Coping behaviours Project Managers fight to be assigned the most viable Projects Project Managers fight for the best staff Project Managers fight to keep the Project scope down Project Managers exploit changes in scope to unduly extend timelines and budgets Project Managers sandbag Project plans to create headroom Project Managers quit long Projects well before the delivery date Project Managers disregard targets they know to be impossible Staff work double shifts in the final weeks / months Dumping the blame elsewhere Doing these may help the individual, but not the organisation

We can reduce variability, but we cannot eliminate it, because it is inherent to the nature of a Project Plan C: Approach the problem in a different way We must manage the variability that remains

How we handle variability in Critical Chain We do not build in any contingency at the Task level We move all the contingency to the Project level - we call this the Completion Buffer Individual Tasks can now be late without affecting the completion date of the Project The Project due date is protected as long as the accumulated lateness along any one chain is less than the completion buffer

What difference does this make to our probability of being late ? Under 'normal' practice, if any task is later than its contingency allows, we have a problem Under Critical Chain, we only have a problem if the total lateness exceeds the total contingency This second condition is much less likely than the first [ Law of averages / Central limit theorem] and increasingly so as the number of tasks increases

The Completion Buffer A Buffer is a block of time which protects a deliverable from being affected by delays upstream. The Completion Buffer protects the Project completion date Over the course of the Project we expect our buffers to be used up, in proportion to progress made

Scarcity of Resources In putting together the plan, we must take into account scarcity of resources In particular, if two tasks want exclusive use of the same resource, at the same time, they have to be staggered This affects the plan in a similar way to the task dependencies

Scarcity of Resources Task C – 10 d Task B – 10 d Task A – 10 d Project Time required - 20 d Task C depends on both A and B Each task uses a different resource

Scarcity of Resources Task C – 10 d Task B – 10 d Task A – 10 d Task C depends on both A and B, Both A and B need exclusive use of the same resource Project Time required - 30 d Resource conflict

The Critical Chain We identify the longest chain of dependent tasks by resource through the Project - this is the Critical Chain, at the end we place the Completion Buffer The time taken to complete the Project is the time taken to complete the Critical Chain Any delay in the Critical Chain delays the Project completion

Task C Task B Task A Completion Buffer Committed end date

Task C Task B Task A In Practice Task C Task A Completion Buffer The buffer is 25-33% of chain length Project duration held constant Task B

Feeding Chains All the other chains of tasks we call Feeding Chains, because each one at some point feeds into the Critical Chain Every task in the Project is part of either the Critical Chain or a Feeding Chain

Feeding Buffers We must not allow anything to delay the Critical Chain We must protect the critical chain from being delayed by lateness in the Feeding Chains We start the feeding chains a little early, and insert a block of time to decouple the Critical Chain from each Feeding Chain We call these blocks of time Feeding Buffers

Task C Task B Task A Task D Completion Buffer Feeding Buffers FB

Planning Phase Summary There is no contingency at task level The Project due date is protected by the a block of time called the Completion Buffer The Critical Chain is the longest chain of tasks through the Project All other chains of tasks are Feeding Chains We place Feeding Buffers to decouple the Critical Chain from the feeding chains

Execution phase.... We have a great plan - what can happen in execution ?

Critical Chain in the Execution phase.... No multi-tasking - when someone starts a task they stick to it until it's completed

Bad Multi-tasking Whenever I put down one task and pick up another, I lose productive time How much time is lost switching depends on how deep or shallow the task in hand is Putting a stop to multi-tasking in effect creates extra capacity

More Bad Multi-tasking If we have two people, each available 50% to our Project, and they have to work together, they are effectively 25% available If we have four such people, it's effectively 6%, so we'll wait on average 8 working days to get them together for half a day Real-life case: Ten team leaders, each on 50% availability: Out of two Project meetings held, 3 came to both, 5 to one or the other, 2 to neither

Very Bad Multi-tasking When someone stops doing a task on the Critical Chain, and starts doing something else, they are delaying the entire Project

Critical Chain in the Execution phase.... No multi-tasking - when someone starts a task they stick to it until it's completed We begin each task as soon as resource is available and prerequisite tasks are complete The timings in the plan are for planning, not a commitment on execution

Critical Chain in the Execution phase.... No multi-tasking - when someone starts a task they stick to it until it's completed We begin each task as soon as resource is available and prerequisite tasks are complete We finish each task as soon as we can Early finishes on Critical Chain tasks bring forward the whole Project Early finishes on Feeding Chains increase the protection of the Critical Chain Sometimes we call these three together 'Roadrunner' style

Summarising Practical differences... Planning phase: –The Project is analysed into the Critical Chain and Feeding Chains –Contingency is aggregated into a Completion Buffer protecting the Project end-date, and Feeding Buffers protecting the Critical Chain Execution Phase –No Multi-tasking –Early finish / allowing early start of following tasks –Subordination to the Critical Chain

Measures and Management How do we know how the Project is doing ?

Measures and Management Making less progress than planned will eat into the Completion buffer Making more progress than planned will add to the Completion buffer C B D A At day 5, task A has 8 days remaining (of 10) - Completion Buffer is eroded by 3 days Task D is completed - no effect on Completion Buffer

Measures and Management Question 1: How many days work until the Project is completed ? Answer = the number of days left on the Critical Chain It is the time on the Critical Chain that determines the time required to complete the Project

Measures and Management Question 2: How certain are we about the answer to Question 1 ? Answer = the proportion of the Completion Buffer that we have left, compared to the proportion of the Critical Chain still to do The Completion Buffer protects the end date. The less (more) it is eroded, the less (more) the end date is at risk

Corrective Action We compare the percentage of the Completion Buffer Remaining (%CBR) with the percentage of the Critical Chain Remaining (%CCR) We set trigger points for corrective action, for example: When the ratio %CBR / %CCR is 1or more, Project status is GREEN - Watch When %CBR / %CCR is between 1 and 2/3, Project status is AMBER - Prepare a recovery plan When %CBR / %CCR is less than 2/3, Project status is RED - Implement recovery plan

Measures in 2-D 100 % 0 % Critical Chain Remaining Completion Buffer Remaining

Don't overreact to buffer erosion We expect our buffer to be used up over the course of the Project Our date is not threatened if the buffer is used up in proportion to progress –If we have 2/3 of the completion buffer left and only 1/3 of the Project to do we are doing fine Our date is threatened if the buffer is used up disproportionately –If we have 2/3 of the Project still to do but have only 1/3 of the completion buffer left we have a problem

Measures Summary We have simple, objective measure of Project progress We have a simple, objective measure of Project health status We have a simple rule for triggering - and not triggering - corrective action We can redefine the Project progress meeting as the Buffer Management Meeting

Buffer Management Meeting Attendees: Project Manager, Project Sponsor / Owner, Task Managers, Resource Managers Agenda: 1.Reminder of what tasks are on the Critical Chain. 2.Review Project status ( % Critical Chain outstanding). 3.Review Completion buffer status (Red, Amber, Green). If necessary, initiate corrective actions. 4.Review Feeding buffers status (Red, Amber, Green). If necessary, initiate corrective actions. 5.Review tasks in progress to ensure earliest completion in full. 6.Review tasks not started to ensure earliest start where appropriate.

Using Buffer Management to drive ongoing improvement Buffer Management measures are fact-based and objective Buffer Management meetings highlight buffer erosion / Project delays Preventing the causes of delay will speed up your Projects Your process of ongoing improvement is simply to eliminate the causes of delay by following up on the issues highlighted in Buffer Management meetings As your Projects run faster and more reliably, continue to eliminate more and more causes of delay

How Does Critical Chain help our Project Management ? Aggregated contingency and 'Roadrunner' style Effective due-date protection and extra effective capacity More r eliable on time in full to budget delivery performance Identification of Critical Chain and Feeding Chains Focus B uffers Flexibility A stable plan Buffer measures Objectivity and clarity Better focused meetings, better directed recovery efforts, better informed stakeholders, less waste and more productivity Less encouragement of 'coping behaviours Buffer Management Focus for ongoing improvement efforts

Without CCPM If the plan is not based on the Critical Chain, it may be infeasible If the Critical Chain is not known, the Project Manager cannot focus on it Without contingency the plan is not robust If contingency is all in the task estimates, it's still not robust its just longer, and there is no sense of urgency Without feeding buffers, an early completion will not help the end date, because the next task has to wait for its other prerequisites With multi-tasking and interruptions > 25% capacity is wasted Interruptions on Critical or Feeding Chains delay Project Completion Measures are backward-looking or misdirect attention Improvement processes lack focus

Multi-Project Pipelines The Goal is to maximise Project throughput over some timeframe The constraint is one of the resources available The pipeline can be overcommitted Resources can be used on the wrong Project Projects can delay one another

Starting point is that each Project has a fully defined CCPM plan, and We have a defined set of global resources Assumption that one of the resource constraints dominates the others over the timeframe (Pacing Resource) Execute a single pipeline plan which is feasible and robust Multi-Project Pipelines

Example Which is the Pacing Resource ? How many Products can we deal with in a 50 day quarter ? We run the engineering department of a manufacturing company making custom products Each product ordered is a new variation on a few standard designs Typically, for each product ordered, we spend 5 days on the specification, 10 days on the design, 2 days on the test plan, and 3 days on the manual We have 2 people who do specifications, 3 who do designs, one test planner and one manual-writer

Example Specification: 2 x 50 = 100/5 gives 20 products Design: 3 x 50 = 150, 150/10 gives 15 products Test Plans: 1 x 50 / 2 = 25 products Manuals: 1 x 50 /3 = 17 products Design = Pacing Resource We run the engineering department of a manufacturing company making custom products Each product ordered is a new variation on a few standard designs Typically, for each product ordered, we spend 5 days on the specification, 10 days on the design, 2 days on the test plan, and 3 days on the manual We have 2 people who do specifications, 3 who do designs, one test planner and one manual-writer

Example We run the engineering department of a manufacturing company making custom products Each product ordered is a new variation on a few standard designs Typically, for each product ordered, we spend 5 days on the specification, 10 days on the design, 2 days on the test plan, and 3 days on the manual We have 2 people who do specifications, 3 who do designs, one test planner and one manual-writer What is the consequence if: The test planner is off for two weeks ? One of the designers is off for two weeks ? The documentation task for a product overruns by 50% ? The design task for a product overruns by 50% ? The specification task for a product overruns by 50% ?

Answers Loss of output on the pacing resource has a permanent, pervasive effect Loss of output on the other resources has a temporary, local effect We need to protect the Pacing Resource

Planning the Pipeline Stagger Projects on the Pacing Resource Buffer the Pacing Resource A feasible and robust due-date for each Project

Priorities in the pipeline In order of net profit per hour of time on Pacing Resource In sequence of strategic priority Committed Projects first, then new Projects Look at the effects of different sequences

Pacing Resource Schedule Product 793 Schedule Product 794 Schedule RB Design 792 Design 793 Design 794 Spec Test plan / Manual Design Spec Test plan / Manual Design

Execution Phase Hierarchy of subordination: Never interrupt the Pacing Resource Only interrupt a Critical Chain task to start the Pacing Resource Only interrupt a Feeding Chain task for a Critical Chain task

Measures in 2-D 100 % 0 % Critical Chain Remaining Completion Buffer Remaining

Buffer Management Management team (Project Managers, Resource Managers) looks at: Pacing Resource schedule Resource Buffer status Critical Chains vs Completion Buffers picture Resources: best resources allocated to most important Projects ? Pacing Resource tasks in Progress - early completions ? Pacing Resource tasks due to start - early starts ? Record buffer erosion to focus improvement effort

Summary - Multi- Project Start with all Projects fully-defined in CCPM Identify Pacing Resource Load the pipeline by staggering Projects on the Pacing resource Buffer the Pacing Resource Apply hierarchy of subordination Manage by Buffer Management Use Buffer Management to drive improvement

Without CCPM If we haven't identified the Pacing Resource: –our pipeline may be infeasible –we will waste capacity Without a resource buffer, the pipeline won't be robust Without good measures, management is unfocused or wrongly focused Without Buffer Management, improvement is unfocused

In Practice The logic of CCPM works Many success stories: A50, Lucent, Phillips, US Navy Implementation is not a trivial undertaking As CCPM brings Projects under control, the constraint moves to management Aggressive reductions in cycle time are both possible and necessary

Books "Critical Chain" by Eli Goldratt "Critical Chain Project Management" by Lawrence P Leach ISBN "Enterprise-Focused Management" by Ted Hutchin ISBN

Questions ?