The Critical Chain Difference: Taming Uncertainty in the Multi-Project Environment

ARTICLE INDEX The Critical Chain Difference: Taming Uncertainty in the MultiProject Environment The Five Focusing Steps of TOC The Critical Chain Method The Critical Ratio The Multi-Project Solution Some Critical Chain Results All Pages

Page 1 of 6

DOWNLOAD THIS WHITEPAPER AS A PDF

Two major issues surrounding the management of multiple projects are resource planning and management of uncertainty. Traditional methods may be able to deal with the issue of resource planning, but provide no simple answer to the management of uncertainty in execution. Critical Chain project management, with its buffer management method, gives the multi-project manager a high degree of visibility, focus and control over the specific tasks across a multitude of projects that require his or her attention.

In this paper you will gain an understanding of the meaning of: the Critical Chain, buffer management, the pacing resource, the Critical Ratio and how they all fit together to provide a simple, elegant and commonsense solution to managing complexity. The Nature of Uncertainty and Complexity

It is a fact of life that in all of our endeavours, nothing is more certain than uncertainty itself. In the area of project management this might manifest itself in a variety of forms:

Vendor performance is unreliable The effort required to complete tasks is not fully known The time to complete even well known tasks can vary The delivery of needed tools, material and equipment is uncertain The availability of the appropriately skilled people cannot be guaranteed. When this uncertainty is combined with the way we run our organisations, usually based on functional responsibility for specific activities, such as design, purchasing, operations, distribution, marketing and sales, then the complexity of managing multiple projects becomes overwhelming.

Figure 1: The challenge of managing multiple projects, through functional resource management, is made more complex under the influence of uncertainty.

The Five Focusing Steps of TOC

The Theory of Constraints (TOC), of which Critical Chain Multi Project Management (CCMPM) is a part, is a method for continuous improvement in organisational productivity. It is an accepted law of TOC that any system has within it a constraint. If that were not so, the system would produce an infinite amount of output. Put more simply, a constraint is anything that prevents the system from achieving more of its goal. In the language of project management, a constraint is anything that prevents projects from approaching zero lead-times. In order to improve the performance of a system or project it is useful to adopt the Five Focusing Steps of TOC: Identify the constraint Exploit the constraint Subordinate to the constraint Elevate the constraint Do not allow Inertia to become the constraint return to step 1

Identify the constraint In the Single Project Environment What prevents the single project coming in within zero lead-time is the longest set of dependent events through the project, taking both task precedence and resource availability into account. This is defined as the Critical Chain. What about the Critical Path? The definition of the Critical Path deals only with the issue of task precedence. Unless one is operating in an environment of infinite resources, the duration of a project is almost always extended by resource contention - different tasks competing for the same resources. The definition of the Critical Chain takes resource availability into account. In the Multi-Project Environment

When projects are added into an enterprise project pipeline, the resource or group of resources which are most utilised relative to the capacity available will govern the rate of the pipeline. CCMPM calls this ratedetermining resource the pacing resource. Exploit the constraint The term exploit is not intended for use in the pejorative sense, but rather as the means by which the most can be squeezed from the rate-determining resources within the project network. In the case of the single project, one would seek to understand how parallel engineering, interrogation of the validity of precedence dependencies and integrity of task duration estimates can be scrutinised, to develop the shortest possible plan for project completion. When dealing with multiple projects, if the enterprise can only deliver at the rate of its most critically constrained resource, then surely common sense dictates that such a resource should be treated differently to all others? The CCMPM treatment of how this works will be dealt with later in this paper. Subordinate to the constraint If it is accepted that the throughput of any system is governed by a constraint, then it follows that the nonconstraints will not be fully utilised. In project language this is seen in all paths that are not the Critical Chain and is responsible for the creation of slack or float. The implications of having non-constrained resources on a project, however goes to the heart of the mode of operation of most enterprises, whether or not they have formal project disciplines in place. Efficient utilisation of resources is the means by which most managers govern their projects, in a neverending quest to eliminate waste. But what use is it to optimise utilisation of a resource in the name of efficiency when it adds no value to the duration of the project? How can the standard equation linking activity to value be broken? How do all levels within the enterprise become comfortable with the idea that when there is nothing to do, the best thing to do is nothing? What measurement system should be put in place to change behaviour from optimising task completion to optimising project completion? And finally, what signals should all project participants get to ensure that they are aligned in their efforts to continuously do what is right to reduce the lead time of their project? The behaviour required to gain the best performance on the Critical Chain demands that the resources not on the Critical Chain subordinate to the demands of the Critical Chain. Subordinate means ensuring that the Critical Chain is not held up, even if it means their own non-critical chain tasks take longer or are disturbed. So while the non-critical chain resources may appear to be doing what is not best for themselves, they are doing what is best for the project as a whole. In the multi-project environment, this would mean subordinating to the requirements of the pacing resource. Elevate the constraint

Once all efforts have been made to squeeze an individual projects duration down to as close to zero as prudent planning will allow, it is time to elevate the constrained resource. This is usually a strategic step and would require the addition of resources to improve the throughput of either the project or enterprise pipeline. Avoid Inertia to become the constraint return to step 1 Once again, common sense dictates that if there is always a constraint in a system, constraints will not disappear with the elevation step, they will simply appear elsewhere. It is important when considering and implementing the elevation step to determine where the new constraint will appear, and if this is where you want it to be. If all systems have constraints, then there really are only two choices either you manage the constraints, or they manage you. Understanding this proposition allows the enterprise to select where it wants its constraint (also known as its control point or throttle) to be and thus control its own process of ongoing improvement. The Critical Chain Method The Critical Chain method is unique in the way in which it treats and measures variability within a project and across projects, so that the effects of that variability are minimised, performance is optimised and reliability is improved. Before simply accepting such a claim, it is necessary to understand how variation drives behaviours under current modes of operation and how introducing the concept of buffers and buffer management can modify these behaviours. Figure 2: Tasks with added safety Figure 2 shows a typical project network with the green solid bars representing a 50% confidence level estimate of task duration and the associated empty bars representing the padding required to take each estimate up to a 90% confidence level. Most project participants, used to the idea of being measured on task completion (local optimisation), and not knowing where trouble will strike, tend to provide as much protection for their tasks as they can reasonably get away with, so they pad their estimates. In this way, they can be seen not to be the cause of delays to the progress of the entire project. Padding of estimates causes the following problems: Projects appear to be longer than necessary Work will expand to fill the time available (Parkinsons Law) Work will be postponed to the last minute (Students syndrome) as the time allocated to complete the task exceeds the actual effort required to complete it Furthermore, with padding in every task, by definition there will be time available to do other things, or to multitask within the project, across projects or in day-to-day activities.

This multi-tasking significantly increases the risk of not being available to work on what is in the best interest of the project/s when it is really required. An added negative effect of multitasking is that many more tasks are opened than is necessary, resulting in high levels of work in process. This creates a difficult environment for the project manager to control. The Critical Chain method addresses the issue of task duration estimating by calling for all tasks to be estimated to only their 50% confidence level. In practical terms this means asking the question: If all the resources you required to do your task were available to you, and you were not interrupted by any other work, what is your best guess as to how long your task would take? The balance of the contingency that would take the estimate to 90% confidence is not lost. Instead it is rolled up and put at the disposal of the project manager, out of the hands of the task manager. This aggregate contingency is referred to as a buffer. Figures 3-5 show the transition from a Critical Path schedule, through to a Critical Chain schedule (resource levelling), and finally on to a Critical Chain schedule with buffers. There is only one of each resource type A, B, C and D. While the overall project duration remains similar, by using the rules of buffer management, the likelihood that the project will be delivered within the quoted time frame is significantly enhanced. How is this possible? In the first instance, by reducing all tasks down to their 50% confidence level (P50 value), there is little time to indulge in Parkinson Law or Students Syndrome behaviour. The requirement to protect the accuracy of initial estimates is eliminated as task managers are expected to complete on time in only half of all cases. The focus can move from task conformance to project performance. Emphasis is placed on what needs to be done to keep the flow of the project moving.

Figure 3: The Critical Path in Red

Figure 4: The Critical Chain in red

Figure 5: The Critical Chain with Buffers As it is the Critical Chain that determines the overall duration of the project, any increase in the length of this chain will, by definition, cause a delay in the project. What we must endeavour to do is protect the customer of the project from negative variation along the critical chain, and protect the critical chain from negative variation along the non-critical chains, or feeding chains. Any task might be delayed, but it would be very unusual for all tasks to be delayed. Some tasks might even finish early. We thus require a shock absorber mechanism to signal when chains are in danger and use this signal as a means of prioritising the

allocation of resources. The buffers fulfil this function. The consumption of buffers can be seen graphically in figures 6 and 7, below.

Figure 6: Task completion and buffer penetration after day 2

Figure 7: Task completion and buffer penetration after Day 3 In this instance, the status date is represented by the dotted line. The Critical Chain is represented by the tasks shaded red. The Project Buffer (PB) has been penetrated (indicated by the yellow shading) and the feeding buffer (FB) has also been penetrated. Task 1 is the most critical to work on, because a delay here causes immediate PB penetration. The role of the resource on Task 4 (of the feeding chain) is to subordinate to the requirements of Task 1 (on the critical chain), even though its own feeding buffer has been penetrated due to late start of work. A further delay on Task 4 will not cause any delay to the duration of the project itself until the entire feeding buffer is consumed.

The Critical Ratio What happens when the schedule networks are significantly more complex than the one shown above and many chains have buffers penetrated? How do we determine what the prioritisation mechanism is for allocation of resources? The way that this is done is to introduce the concept of the Critical Ratio. This number identifies for the project manager which task is the single most important task to be worked on at any particular point in time. It is calculated by dividing the percentage of completed chain by the percentage of buffer consumed by that chain. Thus, if a particular chain is 50% completed and its buffer is 50% consumed, there is no reason for alarm or management attention. However, if 90% of the buffer is consumed but only 10% of the chain it supports is complete then it should be the focus of significant attention as it is acting to block the flow of work through the whole project and will jeopardise due date completion. This Critical Ratio, or buffer burn rate, forms the foundation stone of managing uncertainty. Within the multi-project environment it is the means by which the project or program manager and functional boss gain visibility and control over the multitude of tasks coursing through the organisations pipeline. The Critical Ratio provides a clear and objective measurement system to determine which resources subordinate to what on any given day.

The Critical Ratio can be mapped daily on a trend (or fever) chart, as in figure 8. Ideally, the Critical Ratio should trend within the area of the trend chart shaded yellow, meaning that work on the longest chain is being completed at a commensurate rate with consumption of the project buffer. Figures 9 and 10 use the same data as mentioned earlier to show how this Critical Ratio is calculated and graphed.

Figure 8: The trend chart (or fever chart )

Figure 9: The trend chart shows that the rate of completion of the longest chain is falling behind consumption of the project buffer. The project seems to have stalled at the first task on the critical chain, despite a good start. This indicates action must be taken now to subordinate to the penetrating task Task 1 of the critical chain.

Figure 10: The trend chart shows the Critical Ratio is moving towards a healthier trend, however, the buffer recovery plan must be continued: subordinating non-constraint resources to the currently penetrating task and the resource performing it.

The Multi-Project Solution In most enterprises there is a bank of ideas or projects waiting to kick off (section 1 of figure 11), but it is beyond the enterprises capacity to have all of them active concurrently. If the organisation wishes to execute more of these ideas, the projects will either have to be done faster a greater velocity across the pipeline or a bigger pipeline will have to be built that is, more resource capacity added. It is the job of senior executives to analyse the demands of the business, resource it according to organisational constraints and decide what is going to be done (section 2 of figure 11).

Figure 11: Portfolio Selection The TOC multi-project approach to managing the enterprise once these decisions have been made is as follows: First, the Critical Chain is identified in each individual project the shortest path through the project network, taking both task and resource dependency into account (see figures 4 and 5). This ensures that

each project has the best possible chance of finishing in the shortest possible lead-time. However the critical chain is not enough what of the interdependencies across projects that share the same resource? To manage these interdependencies, it is best to take a strategic view and identify the resource that governs the pace of the entire pipeline. Clearly, this must be the resource that is most loaded relative to all others the constraint of the pipeline (section 3 of figure 11). Software can help to identify this but, in most enterprises, people already know who the pacing resource is by virtue of his/her specialist knowledge, strategic insight and the heavy demand on his/her time.

Figure 12: Pipelining to the capacity of the constraint resource Once the pacing resource has been identified (or selected), resources are gated or released into the pipeline according to the prioritisation of the portfolio and the capacity of the pacing resource (section 4 of figure 11). In other words, the load is leveled across the projects in accordance with the availability of the pacing resource. Why do we not level all tasks for all resources within the pipeline? The level of noise or inherent variability in the processes would make such an exercise futile when it comes to project execution. A much better mechanism to determine when and where a resource should be deployed on any given day is to observe the buffers and their associated Critical Ratios as the projects proceed within the pipeline. This mechanism allows both the project manager and the resource manager (functional supervisor) to have the same view of prioritisation. Clearly the project with the highest priority gets the resource if the Critical Ratio is the same. The demon of uncertainty is tamed by the power of commonsense.

Some Critical Chain Results

Company US Airforce, Warner Robins Air Logistics Center, C17 Production Line US Marine Corps Logistics Base, Barstow CA US Naval Aviation Depot, Cherry Point

Result Snapshot 25% increase in throughput, 40% overtime reduction, 33% cycle time reduction 50% reduction in cycle time 26% reduction in cycle time, 50% increase in deliveries per year $9M saved in 1st year, 50% reduction in overtime, 30% increase in on time delivery, costs down 33%

US Naval Shipyard, Pearl Harbour

US Air Force Operational Test and Evaluation Center Delta Air Lines Inc. Erikson Air-Crane

30% reduction in cycle times, 30% improvement in resource efficiency; 88% on time delivery 20% increase in project completions per month. 26% reduction in cycle times 40% improvement in on time delivery