Critical path, or chain, or both?
by Tammo T. Wilkens, PMP
Alot of excitement is being generated about the use of the theory of constraints (TOC) and critical chain project management (CCPM). I can't help but wonder if there is any substance to this hot topic. The basic principles of CCPM are available through the proper application of critical path method (CPM) scheduling with resource loading and leveling. The use of feeding buffers unnecessarily complicates the scheduling picture while it constrains the normal scheduling calculations and hides the criticality of activities. I'll try to illustrate these points and help those who are looking for the Holy Grail software to assist in CCPM to recognize that they already have it at their elbows.
I'm often asked: “Do you know of any software that will do critical chain?” My answer is always, “Yes, I have been using it since the late ’70s.” This surprises most people because they think that critical chain is something new, “invented” by Dr. Eliyahu Goldratt. The methods proposed by Goldratt are, in fact, typical stuff that project managers have been using for years. It just hasn't been defined in the same terminology as commonly used to describe the TOC and CCPM. Nonetheless, Goldratt has done a fine job of focusing our attention on what we should be doing.
The problem I have with all this excitement about critical chain is that the ordinary tools of CPM software can easily be used to implement the methods of CCPM. For a very brief but effective summary of TOC and CCPM, refer to “Operational Measurements for Product Development Organizations—Part 2,” Tony Rizzo's article in the December 1999 PM Network. The key points of TOC and CCPM are that resources will drive your critical path more than the logic of how the work should be done, and buffers should be used to protect the project finish and the feeders of critical path activities.
There are several parts to the issue. The first part is that each project needs to be managed to achieve its goal and not the goals of other projects. Another part is that most projects depend on shared resources that are part of an enterprise resource pool. The third part is that the tool is only a tool; it requires the skilled hands of a human being to make it work.
Tammo T. Wilkens, PMP, PE, a senior consultant at Primavera, has spent the last 20 years in the project management field, managing projects within budget and schedule, developing systems for applying earned value techniques, and teaching project management courses at the University of Washington. His teachings include topics such as earned value, CPM calculations, resource leveling, and work breakdown structure design.
Managing Projects to Their Goals. To manage a project to its goal, the team needs to define the work to be done (scope), determine how long each task will take (schedule), establish the sequence of the work so that the code testing is not planned before it is written (logic), and identify the resources needed to get the work done (resources). Traditional resource-loaded CPM schedules cover all pieces of this project plan. The problem that most projects face is that the resources required may not be available when needed, thereby causing critical tasks to be delayed until the resources are available.
Now let's look at how CCPM attempts to address this problem and compare that to the way it has been done by traditional CPM methods. In his book, Critical Chain, Goldratt goes into some length when discussing task duration estimating pitfalls. I consider estimating methodology, whether aggressive or conservative, a matter of management philosophy. However, for the purpose of this discussion, let's assume that the task durations have been “properly” established. Whether the duration estimates are conservative or aggressive is not the issue here. That will merely determine how long the project will require, CCPM or otherwise.
The “buffer” is the tool that CCPM employs both to protect the project finish and to help keep the critical path from being impacted by feeding paths. I feel that buffers are not required as separate entities in traditional CPM scheduling. The buffers can be simply expressed as float. A project buffer at the end of the project can serve to keep the finish date of the project displayed as a fixed date, and in that manner serves a valid purpose. Alternately, the project Total Float can be viewed as the buffer. In the latter case, the project completion date will vary slightly with each update cycle as actual progress is recorded. I find this acceptable for internal project team use. For publication to outside stakeholders, it is often easier to show the fixed finish date and adjust the project buffer as needed to reflect the impact of the periodic update. With proper management, this buffer will shrink and expand. (See “The Human Element” below.)
Feeding buffers are another story altogether, simply because they are a pain in the neck to manage in anything but very small projects. As work is replanned to incorporate scope changes and workaround plans, the buffers need to be relocated and adjusted. This is totally unnecessary when the user simply looks at the schedule Total Float and Free Float. If specific feeding paths need to be identified, then the user can simply adds a code to the task in most scheduling software, identifying it as a feeding task. This is a lot easier than actually creating and maintaining a buffer. The Total Float on all paths, critical or not, indicates the amount of buffer time available on that path. The advantage of this is that the focus of the buffer is visible on all tasks in that branch of logic, not just the buffer task. Furthermore, adding buffer tasks reduces all Total Floats to zero if the buffers take up the total slack time in their feeding path. This reduces the visibility of any schedule problems that might exist, as shown in Exhibit 1, which illustrates this point with two projects: Activities A through H and R through Z, respectively. By adding the buffer (FB), the Total Float and the Free Float have been reduced.
A much-neglected feature of CPM schedules is Free Float, defined as the amount of time within which a task finish can delay without impacting the early start date of any one of its successor tasks. What this tells all participants of the project team is that the Free Float is all the slack time that they have. If they delay beyond it, then they will impact the scheduling of resources on the successor tasks. Note that Activity H in Exhibit 1 has two days of Free Float. I use this to let task managers manage their own work within the constraint of not impacting others. This is very effective in keeping the project on schedule, since bottom-line management is at the level of the work being done.
To eliminate the resource conflicts in Exhibit 1, we can simply let the computer apply the resource-leveling algorithm to produce the result shown in Exhibit 2. Notice that Activities F and H have less Total Float now, but there is no effect on the upper project finish (Activity C). If we use a feeding buffer, as shown in the lower part of Exhibit 1, and then do the resource leveling, we get the result shown in the lower part of Exhibit 2. Note that the project finish (Activity T) is pushed out, and the feeding buffer duration needs to be shortened by two days to bring it back. Why bother?
By using normal CPM scheduling tools, the need for feeding buffers is eliminated, and the use of a project buffer is as easy as adding one activity to the project. This gives the schedule much more freedom to help in the resource planning than adding a lot of constraining buffers.
Managing Resources in the Enterprise. When a schedule is used only to manage the sequence of the work, then the availability of resources will probably create severe impacts on project completion. In an enterprise environment, resource management is essential unless resources can be mobilized “instantly,” since they are shared across projects. Let's look at resource management from the project perspective and the program perspective.
Within a single project, there can easily be contention for the same resource(s). I have found that the best solution in such a case is to use CPM to establish a resource-leveled schedule. By avoiding feeding buffers and entering only essential constraints within the project schedule, the resource-leveling algorithm can work to your best advantage. The priority of access to limited resources can be established using either Total Float, manually determined priority, or both. In this manner, the sequence of work won't be violated, and yet, more important projects or tasks can be identified to the leveling algorithm with a priority value. If project priority is not an issue, then Total Float alone is a good arbitrator for allocating resources to tasks.
Using logic ties to schedule activities so that they have access to critical resources is self-defeating because, in all but the very simplest schedules, it is simply too complex to make the right choices without violating the workflow logic. If the CPM schedule is merely a bunch of tasks listed with constraint dates that have been determined manually, then there is no CPM schedule, and this discussion is not applicable. In such a case, CCPM won't work any better than a spreadsheet.
When multiple projects, or programs, are considered, the problem has not changed; it merely becomes more complex. With enterprise project management software, the resource pool is considered shared across all projects. In such cases, the same principles described earlier hold true. Activities still need to follow the logic of the work sequence, the critical path for each project is still determined by the longest path through that project's network, and resource leveling can still be applied across all projects.
Reader Service Number 096
CCPM advocates suggest that projects should be staggered to allow proper planning of the “drum resource,” that is, the critical resource. While this may be possible in simple schedules and where only one or two resources are critical, it becomes a nightmare to determine how to stagger projects in the real world of complexity. Furthermore, manually staggering may work if the project priorities are defined and if the sequence of work remains the same throughout the project. However, if there are schedule impacts on any of the projects, the staggering may have a detrimental effect on the resource plan.
To illustrate, Exhibit 3 shows two projects, with Activities P1A through P1F and P2A through P2F, respectively. Activities P1E and P2E employ a critical, limited resource. If resource leveling is done across the enterprise, then the result is as shown in Exhibit 4: Project 1 stays on time, and Project 2 is delayed by two days. If the projects are staggered, as shown in Exhibit 5, then the problem with the resource limit is also avoided, but Project 2 is delayed five days. And, without a detailed analysis, it is not known if the staggering created another resource conflict because now Activities P1B, P1E, P2A, and P2D are in parallel.
That's not the worst of it. Now, suppose Activity P1D finishes five days later than planned. It will push Project 1 and Project 2 out along with it or else reintroduce the resource conflict. On the other hand, if another resource leveling is done, then Activity P2E would start on its original start date, as shown in Exhibit 3, and Activity P1E would be delayed by Activity P1D. That would eliminate the resource conflict and cause only a two-day delay in Project P1, while Project P2 would finish on time.
The Human Element. What about the human element of project management? I have found on most of my projects that the impacts of reality on a project make the best plans very suspect, unless they are understood in the light of constant change. What this means is that schedules—whether CPM, CCPM, PERT, or any other methodology used—are only tools to guide the project manager and the rest of the project team in the execution of their work. Constant review and brainstorming to overcome impacts on the schedule are required to keep the project on track.
A few anecdotes from my own experience help illustrate the point. When I assumed the project manager position on an $80 million wood-burning power plant, I found that the scope and schedule had been set in our proposal: project completion in 24 months. However, at that time, we had already spent six months negotiating the terms of the contract without a notice to proceed. We kept the completion date fixed at the original proposed time.
The first thing I did was cut another two months off the schedule as our target completion date. You see, there was an early completion bonus to be earned if we finished one month early, and I wanted a one-month project buffer. We reworked our schedule, adjusted our work methodology accordingly, and managed to that schedule. When Construction complained that Engineering's piping drawings were too late and not in sequence with the planned construction process, I had Construction and Engineering sit down at the same table to work out a plan that was acceptable to both parties. When the boiler manufacturer told us that he was sending our boiler drum (a critical path item) to another project and that our drum would be three months late, I sat down with the boiler people to work out a better schedule. We adjusted our construction schedule slightly to compensate for the compromise date. Another critical path item, the steam turbine, was to come from Japan. The vendor faced stiff penalties for late delivery in that contract, but we constantly monitored and kept in touch with him to assess his progress. We negotiated an earlier shipping schedule to allow for any weather impacts on the cross-Pacific shipment and paper delays with Customs. Despite these actual and potential “hits” on the project schedule, the project completed one month early and earned both schedule and performance bonuses.
When I worked as project control manager for the Los Angeles North Hollywood subway segment, we were facing problems with different soil conditions in the tunnel excavation. This threatened to delay the project by months. Rather than accept that, I assembled the Construction and Engineering consultants' staffs to brainstorm ideas for reworking the schedule to keep the project completion as planned. The bottom line is that the project was still planned for completion on the original date set five years earlier!
THE POINT OF ALL THIS is that the tool will not manage the job for you. It takes constant analysis and replanning to get the job done. By making use of CPM software the way that it was intended to be used, you have a well tested, proven methodology at your disposal. You can even use it to employ CCPM. However, I feel that there is nothing gained by adding time and resource buffers to the schedule. Just manage the “buffers” you already have: float and resource leveling.
If you reread Tony Rizzo's earlier-mentioned December PM Network article, try substituting the words “Project Buffer” with the words “Total Float,” the words “Feeding Buffer” with “Free Float” and the use of “staggering projects” with “resource leveling.” You will gain good insight into how CCPM can be used with existing software, and this will let you manage projects to achieve the project goal. It will also let you do that in an enterprise with shared resources. And, you can do this while keeping focused on the human element of project management. ■
Reader Service Number 043
PM Network July 2000