Critical Chain Project

Management

BCS Nottingham & Derby

Winter School 2006
Steven Wray, BA, MBA, MBCS, C Eng

Phone: 07951 727 490

e-mail: steve@wrayassociates.com
web: www.wrayassociates.com
 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 ?
 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 ?
 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: 0.920 = 12%

For 50 tasks, the Probability of all on time is: 0.950 = 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 25 -

50% 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
Plan C: Approach the problem in a different way

We can reduce variability, but we cannot

eliminate it, because it is inherent to the nature
of a Project

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 depends on both A and B
Each task uses a different resource

Task A 10 d

Task C 10 d

Task B 10 d

Project Time required - 20 d

 Scarcity of Resources
Task C depends on both A and B,
Both A and B need exclusive use of the same resource

Task A 10 d

Resource conflict Task C 10 d

Task B 10 d

Project Time required - 30 d

 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
 Completion Buffer

Task A Completion Buffer

Task C

Task B

Committed end date

 In Practice
Task A

Task C

Task B

Project duration held constant

Task A Completion Buffer

Task C

Task B

The buffer is 25-33% of

chain length
 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

 Feeding Buffers

Task A Completion Buffer

Task C

Task B

FB

Task D
 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

B
At day 5, task A has 8 days
remaining (of 10) - Completion
Buffer is eroded by 3 days

Task D is completed - no effect

D 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
0%
Completion Buffer Remaining

100 %

100 % Critical Chain Remaining 0%

 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 reliable on time in full to budget delivery performance

Identification of Critical Chain and Feeding Chains Focus

Buffers 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

 Multi-Project Pipelines

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
 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

Which is the Pacing Resource ?

How many Products can we deal with in a 50 day quarter ?
 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

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
 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
 Product 793 Spec Design Test plan /
Schedule Manual

Pacing Resource RB Design RB Design RB Design RB

Schedule 792 793 794

Product 794 Spec Design Test plan /

Schedule Manual
 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
0% 3
Completion Buffer Remaining

100 %

100 % Critical Chain Remaining 0%

 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 0-88427-153-6

"Critical Chain Project Management" by Lawrence P

Leach ISBN 1-58053-903-3

"Enterprise-Focused Management" by Ted Hutchin

ISBN 0-72772-979-9
Questions ?