The critical chain is the constraint for a single project. What is the constraint of an enter- prise that performs multiple projects? How do you put the critical chains of multiple projects together in a way that identifies the con- straint of the enterprise to produce projects that meet the three necessary conditions and do it in a way that allows focus on increasing the project throughput of the enterprise?
What is it that constrains the enterprise from completing more projects or completing the existing projects more quickly?
Consider a more familiar reference envi- ronment with which most people are famil- iar: mowing a lawn. Consider the amount of grass cut as the counterpart to completed projects. What happens when the grass is too
183 Contents
7.1 Identifying the multiproject constraint 7.2 Exploiting the multiproject constraint 7.3 Features of multiproject critical chains
7.4 Introducing new projects to the enterprise
7.5 Summary
7
long or when you try to push the lawnmower too fast? It bogs down and often stalls.
The same thing happens if too many projects are pushed into a multi- project environment without considering the capability of the constraint to perform the projects. If you push too many projects into the system, it will bog down and stall. People will work hard, but projects will take a long time to complete (the engine is stalled much of the time), and a lot of management effort goes into restarting the engine and cleaning out the debris. It will seem as if there are never enough of the key resources necessary to complete the projects.
With the lawnmower, you use the feedback from the system to adjust the rate of processing. You listen and slow down the lawnmower as the engine begins to slow down. Or you raise the cutting height, so you match the processing rate to the feed of the work.
Figure 7.1 illustrates a critical path multiproject scenario. The colors in the bars represent resources. Using conventional low-risk activity esti- mates and considering three-project multitasking, each activity duration is 90 days. In most organizations, the managers of the three projects would rarely work together. Each would work with the managers of the resources to try to get the resources they needed. In this worst- case example, all the resource needs overlap. If there is only one of each resource, each project has to schedule assuming one-third of the resources time to work on its project. That situation is called the fractional head count.
I have made a point of asking groups of project managers (many of whom belong to the Project Management Institute, including certi- fied project management professionals), “How many of you routinely resource-level your project plans?” (Resource loading means identifying the resources needed for each task; resource leveling is removing the con- flicts in which demand exceeds supply.) My unofficial survey indicates that only about 5% of project managers routinely resource-level their plans. In other words, the situation is usually worse than I assumed above: They do not even know where the overlaps occur. I then ask them,
“Why not?” Most need some prodding, but usually the answer is one of two things: (1) It is not worth it, because management will change every- thing anyhow, or (2) it makes the schedule too long. Finally, I ask how many of them have infinite resources at their disposal. So far, none has infinite resources.
theenterprisemultiprojectcriticalchainplan185 ID Task name Duration
1 Activity 1 90 days 2 Activity 2 90 days 3 Activity 3 90 days 4 Activity 4 90 days 5 Activity 5 90 days 6
7 Activity 1 90 days 8 Activity 2 90 days 9 Activity 3 90 days 10 Activity 4 90 days 11 Activity 5 90 days 12
13 Activity 1 90 days 14 Activity 2 90 days 15 Activity 3 90 days 16 Activity 4 90 days 17 Activity 5 90 days
T M F T S W S T M F T S W S T M F T S W S T
Dec 14, '97 Feb 8, '98 Apr 5, '98 May 31, '98 Jul 26, '98 Sep 20, '98 Nov 15, '98 Jan 10, '99 Mar 7, '99 May 2, '99
Red
Red
Red
Blue
Yellow
Blue
Yellow
Blue
Yellow
Green
Green
Green
Black
Black
Black
Figure 7.1 Three projects in a multiproject environment.
Some companies do check resource availability across all projects.
They then argue to increase resources. That is moving to the elevate stage of TOC, before completing the identify, exploit, and subordinate steps—a very expensive strategy.
Considering that and the Figure 7.1 project, assuming these projects are all the same, the resources have to be divided among the three proj- ects; even if you have only one resource of each type. Thus, either the project plans assume this multitasking, or the projects are not going to complete on time due to the necessity for multitasking. Evidently, one of the resources is the capacity constraint of the system.
You first have to identify the company capacity constraint resource.
That is most often a certain type of person, but it may be a physical or even a policy constraint. The company constraint resource becomes the drum for scheduling multiple projects. The terminology comes from Dr.
Goldratt’s production methodology, in which the drum sets the beat for the entire factory. In our example, the drum set the beat for all the com- pany projects. Think of the drummer on a galleon. What happens if even one rower gets out of beat?
The project system becomes a pull system because the drum schedule determines the sequencing of projects. You pull projects forward in time if the drum completes project work early. You delay subsequent projects when the drum is late. For that reason, projects in a multiproject environ- ment also require buffers to protect the drum, to ensure that they never starve the capacity constraint for work. You also must schedule the proj- ects to ensure that they are ready to use the drum resource, should it become available early.
Figure 7.2 illustrates the CCPM method. Compared to the previous critical path case, you reduce each activity time to 15 days to eliminate the three-times multitasking and to use 50% probable duration estimates.
You identify the resource supplying activities 2 and 3 as the capacity con- straint resource. You exploit the resource by synchronizing the projects using that resource as the drum. You subordinate to the resource by add- ing capacity buffers between the projects. The capacity buffers ensure that the capacity constraint resource is available for the subsequent project.
Figure 7.2 shows the CCPM plan completing the three projects (including the project buffer) near the end of August 1998. It shows the first two projects completing even earlier. Compare that to the critical chain multiproject plans of Figure 7.1, all of which are scheduled to
theenterprisemultiprojectcriticalchainplan187 ID Task name
19 Activity 1 20 Activity 2 21 Activity 3 22 Activity 4 23 CCFB 24 Activity 5 25 Project buffer 27 Capacity buffer 29 Activity 1 30 Activity 2 31 Activity 3 32 Activity 4 33 CCFB 34 Activity 5 35 Project buffer 37 Capacity buffer 39 Activity 1 40 Activity 2 41 Activity 3 42 Activity 4 43 CCFB 44 Activity 5 45 Project buffer
Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep
Figure 7.2 CCPM multiple project plan reduces project duration and increases project throughput.
complete in May of 1999. Based on what you have learned for single proj- ects, you can expect the CCPM projects to be early. Based on global project experience, you should expect the critical path projects to be late, for even these extended schedules.
Note that synchronizing the projects this way eliminates resource contention for all resources, not just the drum resource. That happens in the example because the projects are identical. While most multiproject environments do not have identical projects, synchronizing projects to the drum usually eliminates some, if not all, resource contention.
Resource manager prioritization of resources according to the penetra- tion of project buffers resolves remaining resource contentions.
This is a major simplification compared to attempts to micromanage a whole enterprise, which never work. By now, you should understand why this is a hopeless exercise. All the activity durations are estimates.
None of the activities should take the exact amount of time planned. Any schedule produced for all resources across all projects is fiction. It is only one possibility out of millions of possible combinations of project status and resource availability. Instead, the critical chain process uses buffer management to dynamically allocate resources. CCPM allows for such variation with the resource buffers and feeding buffers within each project. This process also includes the ability to absorb the natural variation in the buffers. It is a real-world control system.
TOC leads to an understanding that all resources other than the con- straint must have excess capacity. Those upstream of the constraint resource must have excess capacity to ensure that the constraint resource is never starved for work, which would waste its capacity. In a project, that means we have to buffer to ensure that we provide the constraint resource with the input it needs. Resources downstream of the con- straint must have more capacity than the constraint to deal with fluctua- tions in their own output and that of resources between themselves and the constraint resource. They must ensure that they always deliver the constraint resource-processing rate to the completion of the project(s). In a project, that is the concern of the project, not of the constraint resource.
While projects theoretically can have resource demands in any order, there tends to be a similarity in the order within a company, based on the type of projects they operate. For example, many projects will have a design phase, procurement phase, construction phase, and initial operation phase. Thus, the sequence of demands on resources tends to be
similar, although the usage may vary substantially from project to project.
The general idea carried over from manufacturing is that the further a resource is from the constraint resource in the plan sequence, the more excess capacity and/or the larger buffer it needs to not affect the overall lead time.