A Critical Chain Schedule
(A Better "Wrong Answer"
Looking for information on concepts he was anticipating on a PM certification exam, George wrote:
|>I would like help in explaining the approach and principles behind:
>Since I can't draw the example, I'll try to describe it.
>The network is an AOA diagram and the events are not numbered.
|>A = 7
>B = 3
>C = 6
>D = 8
>E = 5
>F = 6
>G = 2
>H = 4
>I = 7
>J = 3
>K = 7
>L = 2
>M = 8
>N = 3
|>Start (A = 7)
>Start (C = 6)
>Start (D = 8)
>Start (F = 6)
>Paths: Start to A to B to G to L to N
> Start to D to E to G to L to N
> Start to D to H to L to N
> Start to D to I to N
> Start to D to J to M to N
> Start to C to G to L to N
> Start to F to K to M to N
>CP = Start to F to K to M to N = 24
I would probably fail the test. I don't care about early/late start/finishes or slack, since associating dates with a schedule leads to the effect known as Parkinson's Law, and I won't have ANY chance of bringing in the project sooner than planned, and have to be real, real lucky (or real, real heroic) to bring it in when planned.
Here's my shot at drawing a Gantt-like picture of George's starting project in text:
| | |
DDDDDDDD__EEEEE | |
| | |
Note that I'm starting with everthing as late as possible; everything potentially critical, but my longest chain of tasks coincides with George's critical path. I'm going to assume that these tasks are all performed by different resources, i.e., that no resource leveling is needed to make this a feasible schedule. I'm also going to assume that this project's task estimates are realistic estimates, i.e., that there is a 90% confidence of finishing each of them in the noted time. That 90% confidence takes into account both the usual project environment, rife with distractions and interruptions, and the considerable variability associated with doing anything. If I were to take a big risk on any of these tasks, i.e., take on a 50% confidence level of getting any task done in the time projected, the times would be cut in about half. (I know, I know. This is an assumption that won't apply in 100% of the cases, but you would be surprised how often it is valid.)
If that's the case, I would build my schedule in the following manner:
First, I'd take the safety (the difference between the aggressive and "realistic" estimates) out of the tasks.
| | |
OK, I can't comfortably expect the project to be any shorter than this, even if everything goes right in the tasks. Due to the vagaries of cutting odd-length durations in half, I also now have a choice of two longest paths; the one that matches George's original FKMN and one that travels the DJMN path. And they're both 12 days long. I'll arbitrarily choose one to focus on; George's FKMN. By choosing it as the set of tasks I would like to protect, let me now call it the project's critical chain to distinguish it from the other potential critical path.
Note that even in George's original, there was minimal slack in the DJMN path. If Murphy's Law touched any of those tasks, we've got a new critical path.
So we've got a 12-day project that no one in their right mind would commit to. Especially because I've got all the feeding paths as late as possible. If anything goes wrong with them they'll lengthen the critical chain. So we should start them earlier. But there are all kinds of risks and costs of starting things as early as possible, so let's compromise and take half of the safety we removed and use it to buffer the critical chain from the feeding tasks. I can get away with half due to the fact that early tasks will offset late tasks if they're not due-date driven and if the receiving resources can pick up their inputs on a timely basis (Yes -- there are some things that will have to change in the management culture that are beyond the scope of this article, but they may be well worth dealing with to achieve shorter project delivery times and better reliability of project promises.) We'll insert feeding buffers to absorb the variability associated with the feeding path tasks (indicated in the schedule by lower case f's).
| | |
What I've done with these feeding buffers is assure that the critical chain tasks don't have to wait for work to be done by non-critical chain tasks. One little anomaly shows up here. Nore that the D task is the first task in the schedule, although the critical chain starts with the F task. That's because the feeding chains DJ and DEGL require the insertion of protection in the form of feeding buffers to avoid what would have happened in a critical path methodology -- the changing of the critical path throughout the project. Sometimes these feeding buffers might cause gaps to appear in the critical chain as well -- that's OK too, for the same reason. I don't want what I consider critical to change, because then the system of buffering would change, and because I use the buffers to gauge the health of the project, I want to avoid rescheduling and restructuring the project.
Now we're almost there. What about the variability of the critical chain itself? If the M task, for example, runs into our friend, Murphy, then all bets are off. So we need to protect the promise of the project - the due date from variability in critical chain. Guess how. Yes, it's a buffer between the critical chain and the project due date, calculated similarly to the feeding buffers, since if some tasks come in early, they'll offset the late ones. Called the Project Buffer, I'll indicate it on the schedule with lower case p's.
| | |
OK -- that's the critical chain schedule for George's problem. Note that we gained 2 days, an 8% improvement in SCHEDULED project leadtime. I emphasize "scheduled" because in execution, this project has a substantially reduced risk of missing that date because the safety, now in the form of buffers protecting the whole project, won't be wasted to Parkinson's Law as it is commonly done in milestone schedules based on realistic, relatively safe task times. It is also easier to manage in execution, because I have a clear indication of the health of the project in the buffers.
What I've shown here are SOME of the basics of Critical Chain Scheduling and Buffer Management, an approach to project management that comes from the Theory of Constraints. (What is a critical chain if not the constraint of a project that prevents it from being delivered in a shorter time?) The schedule process is the easy piece. There are requirements on management and a few more details I left out that are necessary for this to work, but those that are making it work are finding that the reduced risk that regularly leads to reduced delivered leadtimes (even beyond the reduced schedule) are woth the changes in policies, measurements, and behaviors.
Oh yeah -- George's questions...
>1. Activity D has a latest start time of ___ weeks and a latest finish
>time of ____ weeks?
>The answer is 2,10
The "answer" in this schedule is a start time of day one (whoops -- I've been talking days where George uses weeks) and the answer to latest finish is a realistic "who knows?" Actually, with buffer management techniques used, maybe day 7 or 8. The point is I don't care about any scheduled finish date for tasks. The only date that counts is the date you promise the final deliverable.
>2. What is the Slack time in activity G?
>The answer is 4
George's critical path type schedule would have slack. The critical chain has buffers. Slack is the random mathematical outcome of the project network. Buffers are designed -- sized and placed -- to protect what's necessary to protect; the due date and the critical chain.
>3. Activity L has an early start time of ____ weeks and an early finish
>time of ___ weeks?
>The answer is 15,17
The answer to both is "I have no idea." because in reality, I have no idea how long tasks A, B, C, D, E, G, or H will take, and I refuse to try to predict things that I can't predict when the prediction doesn't matter.
>Thanks in advance for your help and time.
You're welcome. It probably wasn't what you were looking for and it won't help you pass PMI certification today, but my guess is that it will help you pass it if you take it in a few years.
|Computers are useless. They can only give you answers. - Pablo Picasso
The source of this page is a posting made by Frank Patrick to one of a variety of online discussion forums, most likely an e-mail discussion list. It's tone and style may be informal, occasionally provocative, and sometimes, even impertinent. There may even be typos until an opportunity arises to clean them up for more formal presentation. Despite these minor shortcomings of style, the content is worth sharing.
Discuss Critical Chain - An email-based discussion group
Frequently Asked Questions about Critical Chain-based project Management
Top 10 Sources of Project Failure -- A list you probably won't see on Letterman.
FP's Postings - others like this page on a variety of topics
Unconstrained Thinking - a collection of more polished mutterings and musings, written as a column for APICS chapter newsleters
Check Out the Following Links for More About the TOC Approach to Project Management:
Critical Chain and Risk Management - Protecting Project Value from Uncertainty -- Project management is the practice of turning uncertain events into certain promises. If so, then project management is an extended excersie in risk management. The core concepts underlying Critical Chain-based project management directly support risk management and are described in this paper, expanded from one presented at PMI's 2001 National Symposium.
Getting Out From Between Parkinson's Rock and Murphy's Hard Place -- This first link will bring up a paper based on a poster presentation originally given at the 1998 New Jersey PMI Chapter's annual symposium, honored with a "best of the show" award by attendees, and later turned into an article published in PMI's PM Network magazine.
Program Management -- Turning Many Projects into Few Priorities with TOC -- This link will lead to a paper on the key attributes of a TOC Multi-Project Management environment. (Most projects are performed by resources shared with other projects. It can be deadly to ignore the resulting interactions, no matter how well you manage single projects.) This paper was originally presented at PMI's Global Symposium in Philadelphia in October of 1999 and is included in the proceedings of that conference. Audio tapes of the presentation are also available from PMI.
Project Portfolio Management - The First Cut is the Kindest Cut - One of the common problems faced by project-oriented organizations is having too many projects relative to their capacity. Therefore, one of the first things that needs to be done is to determine what can be done is to determine what should be done . . . and what should not be done . . .
Consumption of Effort and Conservation of Energy for Project Success -- This link will lead to an essay on the necessity for managing protective capacity in multi-project environments to get the most organizational throughput from the efforts of project resources.
Critical Chain Basics
The Sooner You Start, The Later You Finish
Multitasking Multiplies Lead Time