Critical Chain: A Business Novel (21 page)

In order to not leave the true critical path exposed, we must formally change the critical path. Why? Because if we don't do it, the critical path will not be protected. Is it really the case? Now I see it.

Confidently, I ask the class, "What assumption do we make when we claim that if we don't formally change the critical path it will be exposed?"

They don't answer, so I ask again, "Are the original critical path and the true critical path very different from each other?"

"No," Ruth answers. "As a matter of fact, from the point where the two merge until the end of the project, they are the same. I see. So the only exposure is from step N up to, but not including, the step where they merge. In most cases there will be no additional feeding buffers involved, but what about the resource buffers we need for those intermediate steps?"

"That's not a problem," Mark says. "The original feeding buffer is exhausted. All my attention is on those steps anyhow."

"False alarm," Ruth apologizes.

"I don't think so," Charlie says. "I don't think this is a false alarm."
"Why?" asks Mark.
"Because, at least in my case, the critical path has started to jump all over. Every few days I have this problem. Frankly, I am about to give up."
"This is a very well-known phenomenon," Roger says. "Every project leader will tell you that the critical path changes during the project."
This is serious. I ignore Roger and concentrate on Charlie. He is not talking about a ‘would be' problem or some generalization; he is talking about an existing problem. Charlie, especially after his president being so happy about what he has achieved, would not make such a statement unless the situation was really out of hand.
"Charlie, would you describe to us, in detail, what is actually happening?"
"It's frantic. Noncritical paths, where everything was fine, where the feeding buffers had not been touched, are starting to, all of a sudden, be a problem."
"A severe attack by Murphy," I try to be sympathetic.
"That's the weird thing," Charlie responds, "no special problems, no surprises, still, we are starting to fall behind."
Now I'm confused. And so is everybody else.
"Charlie, let's take it slowly. You are working on step N of a noncritical path, and . . . Now, tell us what happens."
"It's even weirder than that," he says. "I haven't started working on step N on the noncritical path, and this noncritical path becomes a real problem. Without doing a thing, I've exhausted the feeding buffer."
"What are you talking about," Ted speaks for all of us.
"Exactly what I said. I'm supposed to start on a certain step on a noncritical path, but the resource is not available."
"Where is the resource?" Ted asks impatiently.
"Working on another noncritical path."
"So move it."
"I can't. The noncritical path it's working on is also late."
"Miracle," Ted snorts. "Can't be. You're talking nonsense."
Charlie's face is red, but he controls himself, and doesn't answer Ted. He looks at me and asks, "Can I come to the board and show the situation?"
"By all means."
As he starts to draw, he says, "This is not my real project, but it will show you my problem." Two minutes later the diagram is drawn on the board.

"What do the Xs stand for?" I ask him.
"They are steps done by the same specialist, of which we have only one. Assume that each step requires five days, and my feeding buffers are also five days. Do you see the problem?"
We look at the diagram. Charlie's problem is clear. It is also clear that this situation can happen in many projects. There are many contentions for X. For a period of time, X is overloaded and is falling behind. That's what is causing the delays, which are passed from one noncritical path to another. The feeding buffers are not enough to absorb these delays. No wonder his critical path is jumping from one path to another.
"It's obvious that I must acknowledge the limited capacity of X," Charlie says, "but then all our nice method collapses."
"Hold your horses," I say. "Let's go back to your diagram. What is the critical path here?"
"I don't know," he replies. "Not when I take the limited capacity of X into account."
I see the light. "Let's go back to our definition of critical path," I say confidently. "The longest chain of dependent steps, the longest in time. Don't ignore the limited capacity of X. Don't ignore the fact that dependencies between two steps can be because they are performed by the same resource that has limited capacity, so you cannot do both steps at the same time; you must do them sequentially rather than in parallel. That is dependency."
"So what is the critical path?" Ruth asks.
"You tell me," I address the whole class. Jim is frantically taking notes.
"We cannot start with X," Ruth says, "so we have to start somewhere. Then immediately X becomes a problem and it does determine the lead time. When we've finished with X we haven't finished the project, there are still more steps to be done."
"Exactly," I say. "Dependencies between steps can be a result of a path or a result of a common resource. Why are we so surprised that both dependencies are involved in determining the longest chain of dependent steps?"
They seem to agree. "In general," I continue, "the longest chain will be composed of sections that are path dependent and sections that are resource dependent."
"So if we stick to the definition of a critical path, we get something nobody calls a critical path?" Brian is puzzled.
"Why are you so surprised," Ted comments. "Nothing else we do is common either."
"I agree. But we'd better straighten out the terminology. Let's leave critical path to be what everyone else calls a critical path, the longest path. But we know that what counts is the constraint, and the constraint is the longest chain of dependent steps. Since we must acknowledge that dependency can be the result of a resource, we better provide another name for the chain of steps that are the constraint."
"Why not ‘critical chain'?" Brian suggests.
Sounds good.
"Critical chain it is," I declare, before I'm flooded with other, more bizarre, suggestions. People love to argue about names, and I'm all of a sudden pressed for time. We have to hammer out all the ramifications of our new realization; it will not be restricted to just a change in terminology.
"Let's go back to Charlie's example," I say. "Again, what is the critical chain?" I love this new name. "Ruth?"
"I'm stuck," she says. "There are five steps that need the X resource. What sequence should I put them in? I don't know."
"Anybody have an idea?" I ask.
People love such riddles; suggestions come from all sides. As expected, many of them contradict each other. I fight my tendency to cut this useless discussion short. It becomes more and more convoluted, and the students get more and more confused. Good. After about fifteen minutes I decide they are ready.
"How much is eight times eight?" I ask.
Nobody answers. They probably wonder if I have lost it.
"Let me remind you that in projects we are not dealing with determinate numbers," I start to clarify the intent of my question. "When we say, for example, that a step will take eight days, do we really mean that it will take precisely eight days? Of course not. So how much is eight times eight?" And I write (8 1) × (8 1) = ?
"The answer sixty-four is wrong. It gives a faulty impression of accuracy."
"Like an accountant who is forced to give an answer accurate to the cent, when even the first digit is questionable," Fred jokingly remarks.
"Correct." I like Fred's example. "Anyone see the relevancy to our debate?"
I help them. "It is a mistake to strive for accurate answers when the data is not accurate. Answers that pretend to be more accurate than the uncertainty embedded in the problem are not better answers."
Charlie does the connection. "Do you mean that the sequence in which we schedule X doesn't make any difference?"
"In some cases it does make a difference. There are endless articles that deal with such cases. But the question is, does it make a real difference?"
Count on Ruth to ask, "What do you mean by ‘real difference'?"
"A difference that is bigger than the uncertainty of the project," I answer. Before Ruth can question my answer, I do it. "What can we take as a reasonable yardstick for the uncertainty of the project?"
I let them think about it for a little while.
"The project buffer?" Brian hesitantly asks.
"Why?"
More sure of himself, he answers, "Because the project buffer is where we dampen the accumulated effects of all the uncertainties."
"What do you think?" I ask the class.
They think Brian is right. So do I.
"I don't know how many articles dealing with resource sequence optimization I have read," I tell them. "More than I care to remember. They contain many algorithms and heuristic rules to sequence resources. Between them, these articles consider everything you brought up here, and many more considerations that you haven't brought up. But I don't waste my time reading them anymore. Why? Because in each case the impact on the lead time of the project is less than even half the projectbuffer."
Jim raises an eyebrow. Of course these articles don't specify a project-buffer. I use our rule of thumb to approximate it. Assuming the time estimation of each step contains safety, the project buffer is about one quarter of the lead time. I make a mental note to clarify it for him. But the students are not going to read these academic articles, so I charge on.
I bring the discussion back to focus. "Charlie is right in bringing up resource contention as something we must consider. There are projects where the contentions are too big for our feeding buffers to absorb. But there is a difference between considering resource contention and fiddling around with optimizing the schedule of these resources."
Charlie doesn't argue, he is too practical for that. "So what am I supposed to do?"
"Remove the contentions," Ted tells him.
"Easy to say."
Ted tries to explain that it is easy, but his explanation is so convoluted, even I don't understand it.
"Would you like to come up to the board and show what you mean on the example that Brian drew?" I suggest. Ted is happy to do it, but he flounders a little. Everybody is trying to help, which doesn't help much. It's not what one might call an orderly session. But at last, Ted finishes. He made sure that no two steps done by X are scheduled in parallel. "Can you highlight the critical chain?" I request. He puts a dotted line.
"Since you changed the constraints, you must change the feeding buffers in accordance," I remind him.
With a little help from his friends he does it.
We examine the two diagrams, the one following the critical path that Charlie originally drew, and the one that Ted did. Quite a difference
.

"It delays the completion date," Charlie is concerned.

"No, it didn't." Mark says. "It just prevented you from fooling yourself."
"Of course. What I mean," Charlie clarifies, "is that resource X delays the completion date. I think that I have to check what can be off-loaded to others."
"Or off-loaded not to other people but to other times," Brian comments.
Charlie gives him a glazed look.
Brian hurries to explain. "Resource X is not loaded for the entire time of the project. If you examine the details of his work you might find that some of his activities can be done much earlier or later. From my experience, I know that many times people batch activities together, not because they are needed to be done then, but to save time."
"You are right," Brian confirms. "A major part of this person's job is documenting her code. Some of the documentation is essential for the integration of the various parts of the software. This must be done immediately. But a lot of the documentation is needed only for future maintenance. Of course it's easier to complete the documentation while the code is fresh in your mind, but you are right, she can do it later."
I still look at the two diagrams on the board. I'm not bothered by the fact that the critical chain is longer than the critical path. That's to be expected. What overwhelms me is that almost all feeding buffers have changed their locations. Is this always the case, or are we misled by an artificial example?
I haven't seen it in the three projects that have successfully finished. But they were near completion; most activities were already done. No wonder there was little resource contention.
I raise the question to the class, asking them to relate it to their projects. How serious is resource contention?
Less than ten minutes later we have the answer: "It depends."
There are many projects where it does not matter; resource contention is not a big deal. But for some other projects, and not just a few, it is.
"If there is resource contention," I remark, "the critical chain might be very different than the critical path. In those cases, what is the real danger in following the critical path rather than the critical chain?"
"It can lead to catastrophes." Charlie is alarmed. "That's what happened to me. The critical path is jumping all over. You lose control."
"It is even worse," Mark says in his deep voice. "Look at the two diagrams on the board. The feeding buffers, not to mention resource buffers, are in the wrong places; the constraint is not protected."
"And we know what happens then," Ted joins in. "Murphy is just waiting for it."
"We'd better check all our projects," Fred says to his friends. "I'm sure that we have resource contentions. A lot."
"Good," I say. "Exactly what are you going to do?"
Mark answers. "First we are going to add the resources to our PERT charts. They are not clearly marked in all projects. Then we are going to... " He stops.
"How are we going to ensure that steps done by limited resources will not be scheduled in parallel?" Ruth is concerned.
"That's my problem," Mark says, and then adds, "rather than drawing the steps on paper, we'll have to use something more flexible. For each step, we could cut a piece of paper so that the length represents the time. This way we can move them around until there is no contention."
"Good idea," Ruth agrees. "Maybe we can find suitable software."
I look at my watch. "Continue," I urge them.
"Once all contentions are removed, and I promise not to spend too much time playing with the sequence, then we identify the critical chain. And then we put in the feeding buffers." Relieved, he adds, "This will change some dates, but it doesn't change the way we learned to manage a project."
"What happens if you find a few chains that take about the same time?" Brian asks.
Mark looks at me for the answer.
"Choose one, any one," I say. "And in order to prove that I'm right, here is your homework assignment. Take the project you are working on, and do what we said today."
"We'll do it anyhow," Brian comments.
"Right. But for me, add the answer to your question. If a few chains have approximately the same length, why doesn't it matter which one you pick, as long as you pick one."
As they are leaving, Jim approaches. "Your style of teaching is really something," he compliments me. "It's like new knowledge is created right in front of the students' eyes. Fascinating."
I don't have the courage to tell him how much he is right, that before this lesson I never suspected there was something like a critical chain.