Critical Chain - Eliyahu M. Goldratt [85]
"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