On October 26, 2012, I will deliver a presentation at the Lean Kanban Netherlands 2012 conference, about Enhanced Risk Management in Kanban via the Theory of Constraints. The presentation will show how cross-pollination by two different schools of thought — Kanban and Theory of Constraints — can give rise to innovative ways to manage projects, to enhance risk management, and to continuously improve your software processes.
Kanban is relatively new on the software methodology scenario, but it has enjoyed rapid success, and most software practitioners have heard about it. The same is not true with regards to the Theory of Constraint, which is often disregarded, ignored or misunderstood by software practitioners.
In the recent post, Theory of Constraints and Software Engineering, I introduced the Theory of Constraints (TOC), and I described how Throughput Accounting (TA) can be used to make management and investment decisions about software projects. In this post I will continue exploring TOC, in order to describe some foundational knowledge that is necessary to understand my approach to combining Kanban and TOC.
This foundational knowledge is about how TOC deals with:
- Schedule Management
- Buffer Management
- Risk Management
- Root Cause Analysis
- People Factors
- Continuous Improvement
In this post I will cover schedule management. The other components will be covered in future posts. An overview of these components of TOC is illustrated in the following mind map, which will guide our exploration of these concepts. We will refer back to this illustration several times.
Critical Chain Project Management
To begin with, we will take a look at TOC’s Critical Chain Project Management (CCPM).
CCPM’s claim to fame is its Scheduling Technique. Though let’s make this clear immediately: The scheduling technique of CCPM will not be used with Kanban. We examine it here, only because it is important to know about it in order to appreciate what will we will bring over to Kanban: namely the Buffer Management techniques of CCPM (but more about that later).
Critical Chain Project Management and Critical Path Method
Critical Chain Project Management (CCPM) is naturally compared to the traditional Critical Path Method (CP) and its scheduling technique, as it comes from a similar origin. Both work with a Project Network; both aim at planning and setting the schedule of work.
In a traditional setting, CCPM offers distinct advantages over CP for scheduling because of the unique concept of the Critical Chain (CC).
The Critical Chain
The Critical Chain (CC) was first described in [GOLDRATT-1997]. Scheduling starts of with a project network, just like CP. Within that project network, the CC is identified. The CC is defined by [SULLIVAN-2012] as:
The longest sequence of dependent events through a project network considering both task and resource dependencies in completing the project. The critical chain is the constraint of a project.
Unlike traditional CP scheduling, attention is given to resource dependencies. In fact, without dependencies, they are the same:
If no resource contention exists, then the critical chain would be identical to the critical path.
CCPM considers project planning with a wider perspective, and identifies the project’s overall constraint (the CC); this is possible by considering with greater care how resource availability impacts the flow of work through the project network. Then, CCPM tackles the CC as any other constraints, by using TOC’s other tools.
The Flaws in Ordinary Estimation
For most people coming from CP, the most surprising part of CCPM is how estimation is handled. [LEACH-2004] observes how project estimates are done in a traditional setting.
[A common error is to] attempt to account for individual task common-cause variation by adding contingency time into each estimate.
In simpler terms: ever little task estimation gets padded with some “safety margin.” Notably, the main reason why this happens is because of the psychological aspects that are involved, and not because of factual evidence:
People estimating task times for a project usually do so believing that the project manager wants ’low-risk’ task times, perhaps a probability of 80% to 95% probability of completing within the task-duration estimate or less. […] this estimate is two or more times the 50% probable estimate. In most project environments, people feel good if they complete a task by the due date and feel bad if they overrun the due date. This reinforces their attempts to estimate high-probability completion times.
Extreme Scheduling in Critical Chain Project Management
CCPM has a radical approach to estimation: CCPM slashes any individual task time estimates by 50%. At first, this might seem arbitrary and insane; but the intent is to recognize that when individual task time estimates are stated, then: “Actual individual task performance times include common-cause variation.”
By just cutting in half any individual estimate, the intent is to prevent inflating the single estimates because of the psychological reasons.
The Single Project Buffer in Critical Chain Project Management
So if all safety margins are taken out of the estimates, how can we deal with contingencies? By understanding variation, a simple solution is found: all contingency is taken out of the individual task estimates, and concentrated in a single Project Buffer at the end of the schedule.
(In this discussion a project buffer represents time. Note that in TOC’s there are other kinds of buffers too. Feeding buffers are time buffers allocated when activity lines converge. Capital buffers are reserve funds for contingencies. Inventory buffers are unreleased work to be released when projects go better. All these kinds of buffers are ignored in the present discussion; but keep in mind that they do exist, and enable even better project management than what is described hereafter.)
As we will see, a single project buffer at the end of a project is the main tool to manage risk in CCPM. Comparing the CCPM schedule to a traditional CP schedule, the difference can be illustrated as follows:
All “padding” in the individual estimates is lumped together at the end of the project network, and then slashed in half. (The three colored zones — in green, yellow and red — of the buffer, will be explained later.)
Buffer Sizing in Critical Chain Project Management
In reality, in advanced applications of CCPM, the project buffer must be “appropriately sized” — The “slashing in half” just mentioned above, is just a gross simplification, used primarily to render evident the main difference with CP.
In CCPM, determining the size of the buffer is of critical importance; and it can be sized in many ways. For example:
[GEEKIE-2006] reviews seven common methods.
[FALLAH-2010] uses uncertainty for sizing the buffer.
[COX-2010] describes dynamic buffer sizing, where the size of the buffer is changed dynamically during the due course of the project.
While the sizing of the buffer is absolutely critical, it is also out of scope of and inconsequential to the present discussion. Again, what really matters is the approach that the single project buffer enables in terms of risk management.
Therefore we will leave out how to determine the buffer size as a technical detail. What matters is that there is only one buffer, and that it is placed at the end of the schedule — no matter how you’ve determined its size.
It is the interpretation and the management of this buffer that is of interest.
Statistics Support
How can a single appropriately size buffer be superior to individual task padding? [LEACH-2004] explains the reason for this through statistics:
While attempting to protect the completion date of each task in a project, each task has to include its own allowance for uncertainty. These allowances add up down the path. When we take these allowance out of each task and put them at the end of the path, they add up to the square root of the sum of the squares of the amount removed from each task; a much smaller total amount.
- Note:
Additionally, the Central Limit Theorem also plays its role. Again, according to Leach: "The distribution of samples from a variety of independent distributions tend toward a normal distribution. A normal distribution is a symmetrical distribution. It does not have the long tail to the right that many individual task distributions may have. This means that concentrating contingency at the end of a path reduces the likelihood that it will be overrun by a large amount."
Advantages of the Single Project Buffer in Critical Chain Project Management
Now, all this talk about buffer sizing and statistics might sound a bit way to theoretical to be of any practice. So, instead, let us see what concrete advantages there are.
Concentrating all contingency in a single and appropriately sized project buffer at the end of the schedule gives two significant advantages.
The first obvious advantage of CCPM is a shorter overall plan. This derives from the extreme scheduling practice of CCPM, that “slashes all estimates in half”. This is also what CCPM is most known and famous for, especially when compared to CP.
The second advantage is about how this enables risk management. This is what is of interest in our case, and what we will examine in more detail shortly.
It is this second advantage that gives CCPM the real edge over CP. CCPM is more powerful than CP because of the risk management technique it enables. This is a capability that is entirely missing in CP.
Ironically, CP advocates who criticize CCPM often fail to recognize this additional — and very important trait — simply because they don’t have anything equivalent in their own familiar method.
For the same reason, CCPM is often dismissed, because it is only seen a more complicated alternative to CP, and not as something quite different. Its real strengths go unnoticed: those strengths pertain to how we can deal with risk, even combined with other approaches (Kanban, for instance, as we will see).
##Critical Chain Project Management and Agile/Lean Approaches Appear to Be Incompatible
Many other concepts of TOC support project and risk management; but just as traditional CP advocates dismiss CCPM because of lack of understanding, we have a similar situation in the Agile/Lean camp.
Often TOC is dismissed as inappropriate in contemporary software development approaches (like Agile/Lean); but more often than not the dismissal is due to not truly understanding what TOC has to offer as a whole in this area.
Naturally, traditional project management is associated with scheduling techniques (like the CP method) that certainly do not suite Agile/Lean approaches. Even CCPM shares this limitation. The point is, however, that TOC’s contribution to sound project management is not limited to CCPM scheduling alone — there is much more that provides additional value.
A Common Misunderstanding about CCPM
Notably, [POPPENDIECK-2007] criticized CCPM specifically stating:
[The problem] lies in the assumption that all of the activities needed to complete development should be known in advance […] At a high level, the Critical Chain project buffer may make sense, but at a detailed level, it is an accommodation to the past. […] A master in the Theory of Constraints would recognize this as a natural result of the application of the Theory of Constraints, scrutinize the accommodation embedded in the Critical Chain approach, and develop the new rules to use now that the constraint has been removed.
So if we were that master in the Theory of Constraints, what would we do? Considering the CCPM as the constraint, and removing it entirely, as suggested by the Popendiecks, seems unwarranted.
While the CCPM scheduling method might indeed be an “accommodation to the past”, what this critique ignores entirely is the other essential part of CCPM: the buffer management techniques that are an integral part of TOC in general, and of CCPM in particular (in the context of project management). By ignoring this, the critique also ignores what TOC can provide in terms of early risk detection and identification. If fact, this capability has gone completely unnoticed by all agile/lean authors who have criticized CCPM.
The Critical Chain Always Exists
In CCPM the Critical Chain is the constraint of a project. One key insight here is the following: no matter what kind of software process or methodology is employed (from Waterfall to Scrum, from cowboy-coding to Kanban, and anything in between), at the end of the project all work must have traversed a “project network” of tasks executed by resources.
While the debate might linger and twist around the question about how much of this project network should be defined up-front (like Waterfall), compartmentalized in sprints (Scrum), discovered as you go with the flow (Kanban), or whatever the method of choice is, this undeniable fact remains: To get to the final delivery, the project network must be traversed, and therein the Critical Chain is still the constraint limiting the project’s capability to deliver, no matter what methodology is used.
At the end of the day, any project that is delivered has traversed its own Critical Chain.
TOC teaches us to identify, protect and elevate the constraint; in CCPM the constraint (i.e. the critical chain), is protected and managed by constantly monitoring the project buffer.
Therefore, going back to the critique by the Poppendiecks: what if the CCPM scheduling method were not used at all; yet we still reckon that there is an overall Critical Chain that limits the whole system’s capability? Can we possibly learn anything else from TOC? In particular, what can we learn if we focus on that buffer at the end of the schedule, rather than on the schedule itself? What can we learn from CCPM’s buffer management techniques?
We will answer these questions in the next posts.