Read Critical Chain: A Business Novel Online

Authors: Eliyahu M. Goldratt

Critical Chain: A Business Novel (7 page)

BOOK: Critical Chain: A Business Novel
13.19Mb size Format: txt, pdf, ePub
ads
Chapter 9

 

 

"How many of you are familiar with PERT and Gantt techniques?"

 

Almost everybody raises their hand. "What do you mean by ‘familiar'?" Ruth asks.
For lack of a better answer I say, "Good working knowledge."
"Then, I'm afraid, I'm not familiar."
"Ruth, I don't mean that you did a Ph.D. dissertation on it. Have you ever come across a Gantt chart?"
"Yes, more than once. Still a brief review would be helpful."
From the look on the other students' faces, I see that Ruth is not the only one who would like a review. Frankly, I didn't expect this; they should have learned the basics in undergraduate courses. I have such a good collection of real charts, with which I could demonstrate every possible configuration. It's a pity I don't have them with me. Should I go to my office to fetch them? It's a waste of valuable time. I'll improvise. No big deal.
"Let's take a very simple example, just enough to demonstrate the concepts."

"Good," Ruth remarks. They all laugh; no student likes complicated examples. Me either.
"Suppose," I start, still not sure of the example I'm going to pick, "the project is to...to build a plant. We need to build the building and then to make it functional."
Before Ruth asks me to define "functional," I continue, "To install the electricity lines, the water and compressed air pipes, et cetera. We also need to select and contract the various vendors to build our machines, and allow the vendors enough time to build them. Once the building and the machines are ready, we can install the machines. The plant is now ready."
"Not until you've hired and trained the people," Fred must remind us.
"What's your point?" Ted is less polite than I would have been. "Plenty of other details are not mentioned here, either."
"Let's keep the example simple," I tell Fred, and invite him to come to the board and draw the relevant PERT chart. Confidently he comes to the front. It takes him less than two minutes to draw the diagram.
"Can you invent some time estimates for the various steps?" I ask him.
"With pleasure." Being a financial manager he cannot stop himself from asking, "Do you also want estimates of investments?"
"No need."

 

 

I wait until he finishes and returns to his seat. "According to the numbers that Fred picked, it will take ninety days to build the building and thirty days to make it functional. A total of one hundred twenty days."

 

"Fred, where did you get such unrealistic numbers," Ted shouts.
"Out of thin air," Fred calmly answers.
I ignore them both and continue. "To pick the vendors takes fifteen days."
"Only in Fred's dreams."
I give Ted a look. He signals, "Sorry." I finish my sentence, "And the time it will take them to supply is another ninety days. The installation of machines takes an additional thirty days. What is the critical path?"
"The building." Ted is very vocal today.
"Why?"
"Because, according to Fred's ridiculous numbers, it takes one hundred twenty days to prepare the building while the machines are ready in one hundred five days."
"You are too hasty," I tell him. "Critical path is defined as the longest chain of dependent steps. Longest in time, of course."
"I know," he impatiently says. Then more slowly, "The critical path is the path through the steps of building the building, making it functional and installing the machines in it. A total of one hundred fifty days."
"The critical path," I remind the class, "determines the time it will take to finish the project. Any delay on the critical path will delay the completion of the project. That's why the project manager must focus on it."
Nobody has a problem with what I've said. No wonder, considering their experience in projects.
"If we call the time we start the critical path ‘time zero,' the project is planned to be finished at time one hundred and fifty. When should we start the other path? When should we start picking the vendors for the machines?"
"There is no rush there," Brian volunteers an answer. "We can start picking the vendors at time fifteen."
"What?" Ted exclaims.
I signal Ted to calm down and ask Brian to come to the board and draw the corresponding Gantt chart. He does it without any difficulty.

 

 

"Brian chose the late start for picking the vendors," I say. "But, as we all heard, Ted probably has another suggestion. But Ted, rather than giving us a whole speech, go to the board and draw your Gantt chart."

 

That throws him off balance for a second, but just for a second. When his chart is done he turns and starts attacking Brian, "I don't know what's gotten into you. You are going to tell me that in the projects you manage you really start at the latest possible time? No wonder your projects are late. You've got spare time, take it! That's my motto."

"Fine, Ted," I calm him down. "But will you please go back to your seat so we all can see what you drew?

 

 

"Gantt charts, unlike PERT diagrams, involve decisions," I highlight to the class, "the decision of the planner when to start each path. Brian chose the late start for picking the vendors while Ted has chosen the early start."

 

"Of course," Ted almost shouts. "What's the point in taking unnecessary risks!"
"The point is," Fred interjects, "to postpone the investments until they are really necessary. Don't you think that's just as important?"
"I'm not sure," is Ted's response, but it's clear that he is less sure about his position.
"It's an optimization problem," Brian is confident. "We have to weigh the savings from postponing an investment against the chance of damage resulting from finishing the project a little late."
One thing I passionately hate is optimization problems. There are so many articles about these cases, all with involved mathematical models, all so tough and time-consuming to read. And from my experience, all have little practical use. But what can I do; it is an optimization problem.
Ruth raises her hand. Here it comes. Now I'll be forced to show them the equation and how to solve it. It's going to be a boring and useless lesson. Of course, I don't remember the mathematics by heart. Sighing, I open my notebook and signal Ruth to ask her question.
To my surprise, she starts by saying, "I don't think that it's just a financial consideration. It's much more a management issue."
"Explain." I try not to appear puzzled.
"In a project there are many more paths than in our simplified example; many more entry steps."
"Of course."
"If we start all the paths at their earliest start, don't you think that the project leader will have too much on her hands? From my experience," she adds, "if I start too many things, I'm bound to lose focus, and losing focus is one thing a project leader cannot afford."
I never thought about it this way. To gain time I ask the class, "What do you think?"
"Makes sense," is Charlie's response. "Makes perfect sense. In retrospect, I think Ruth put her finger on the biggest mistake I usually make."
The expressions on most faces indicate they agree with Charlie. Fred maintains his poker face.
"What do you think, Fred?"
"I think that, except for cases where the investment is relatively large, Ruth's argument is much more important than the consideration of postponing an investment."
It takes me some time to realize that he actually agrees with Ruth. Then he explains. "If the project leader loses focus, the project is bound to be very late. The financial penalty of delaying the income from the completed project almost always dwarfs everything else."
Nobody argues. Not even Ted.
"Very nice, Ruth," I congratulate her. "It looks like you hit the nail on the head."
"I haven't finished yet," she declines the compliment. I wait for her to continue.
"Can you repeat what you said about the need to focus on the critical path?" she asks.
I don't have a clue. What is she driving at? But I also don't have any problem repeating myself. "The critical path determines when the project will be finished. Any delay on the critical path will delay the project."
"If we start at the late start, isn't it true for all the other paths as well?" she slowly asks.
I have to think it over. "If we start a path on its late start," I wonder aloud, "then that path doesn't have any time slack. Which means that any delay on that path will also cause a delay in the project."
"Exactly," Ted bursts in. "So if we start everything on its late start, everything becomes important. And I'll have to concentrate on everything. Kiss focusing good-bye."
"Concentrating on everything is synonymous with not concentrating at all," I agree with him. "So where do we stand? If the project leaders use early starts, they will lose focus. If they use late starts, focusing is not possible at all. We have to find the mechanism, the rules, that will enable a project leader to focus."
"Focusing is important," says one of the students, "but there are many other things that are just as important."
"May I say something?" Fred is provoked. He stands up, "In financial auditing we know very well that in projects, once they are approved, there is only one important thing. Not many, just one. If the project manager stays focused, every problem will be solved. If he isn't, we stop expecting benefits, we pray that the losses will not be too big." He makes his point and sits down.
"Anybody else want to comment?"
"Yes," says Mark. I gesture for him to speak up. Two minutes ago I was afraid that this session would turn out to be a boring mathematical drag, now I have an animated discussion on my hands. It's good. That's the way education should be. Connected to real life. Passionate.
Mark clears his throat, and starts, "For those of you who don't intuitively realize how important focusing is, let me remind you that we know that during the project Murphy will strike, and strike more than once. From my experience, I can tell you, if the project leader is not focused or doesn't maintain focus, the emergencies will turn the project into a fiasco."
"Hear, hear." I probably have somebody from England in the class.
"So what are we supposed to do? Early start, no good. Late start, no good."
"Use middle start?" somebody tries to joke.
"Well?" I ask, not knowing the answer.
"I said it all along," Charlie declares, and then clarifies, "I said that we need a much better way to manage our projects."
"That's what we're here for!" Mark's deep voice booms.
What a deep hole I have dug for myself. Maintaining a straight face, I calmly say, "Maybe we can approach it from another angle? A proper control mechanism should keep us focused."
Everybody is quiet because nobody, including me, understands what I actually said. Not for long.
"What do you mean by that?" Ruth asks.
When you are in a hole, stop digging, I remind myself. I'm about to admit that I'm stuck, and highlight that it's not just me but the state of the existing know-how, when I'm saved by the bell. Well, not exactly a bell, but something even louder. Ted.
"It's obvious!" he shouts at Ruth. "Everybody knows what a control mechanism is: it measures the progress of the project. The problem is," he turns to me, "that by the time the progress report indicates something is wrong, it's usually too late."
"Yes," a skinny student, sitting at the end of the second row, supports him.
"What's your name?" I ask.
"Ah...Tom."
Before he has a chance to return to his cocoon, I ask him to clarify why he thinks that progress reports usually raise the flag too late.
He doesn't answer. Fred answers for him. "A progress report will tell you that ninety percent of the project is finished in one year and then, the remaining ten percent takes another full year."
The class bursts out laughing.
"It seems like you all share this experience with Fred," I finally manage to say.
Many heads nod.
"In that case," I say, relieved, "we'd better discuss how you monitor the progress of your projects."
It's not long before we get a good handle on how progress is measured in reality. Not much different than what I found in the literature. Progress is measured according to the amount of work, or investment, already done, relative to the amount still to do. In all my students' cases, including the cases where milestones and progress payment were used, this measurement did not differentiate between work done on the critical path and work done on other paths.
"Can anybody predict the impact of measuring progress in this way?" I ask the class.
"We reward starting each path at the earliest possible time," Brian is quick to notice. "This measurement encourages the project leader to start unfocused."
"Moreover," Charlie notices, "it encourages the project leader to continue being unfocused."
"How come?"
"Because according to our measurement," he explains, "progress on one path compensates for a delay on another. So we encourage progressing fast on one path even though another path is delayed."
"What's bad about that?" Mark asks. "If I have difficulties in one path, why shouldn't I move on the other paths where I can?"
"At the end they all merge together," Charlie reminds him. "All the advance that you gain in the open paths will have to wait for the delayed path anyway. You made the investment too early, and what is worse, you allowed yourself to not concentrate on the place you should, on the delayed path that needs your attention."
Mark doesn't answer. It looks like he's doing some soulsearching.
"A shortsighted project manager," Charlie's still talking to him, "can ignore the paths that are slowed down by problems, and the measurement will still indicate that the project is progressing. The project leader looks good. For a while. A long while. Only when the work is complete on all the other open paths, and only the problematic path remains, only then will the fallacy start to be revealed. Mark, don't see this as personal criticism. I do exactly the same thing. Only in the last fifteen minutes have I become so smart."
"Thank you," says Mark. "But I still have to think about it."
I don't hurry to break the silence. It's not every day this happens to a professor. Students learning something very important that they can use. Learning and acknowledging it. Actually, it's the first time for me.
No wonder I'm slightly irritated when Fred bursts out with "Now, I finally understand."
"What?" I'm a little too snappy.
"Now I understand why so many projects take so long to complete their last ten percent. It's because, in measuring progress, we overlooked the importance of the critical path. I found the enemy, it is me. I'm the one who prepares all the project progress reports!"
What a class!

BOOK: Critical Chain: A Business Novel
13.19Mb size Format: txt, pdf, ePub
ads

Other books

The Hell Screen by I. J. Parker
With Heart to Hear by Frankie Robertson
Then & Now by Lowe, Kimberly
TIED (A Fire Born Novel) by McMann, Laney
Delia’s Crossing by VC Andrews
The Untold by Rory Michaels
The Fog of Forgetting by G. A. Morgan
Strangers at Dawn by Elizabeth Thornton
The Day the World Went Loki by Robert J. Harris