Critical Chain: A Business Novel (16 page)

In less than half-an-hour we have a new PERT chart. It's amazing how much the computer software available today simplifies clerical work. It's also amazing to what extent this sophisticated software doesn't help us solve the real problems.

They examine the result. The situation looks much better than one might expect. Only in two feeding paths have delays already swallowed the buffer that we just created.

"I told you that it wouldn't work," one skinny guy is quick to conclude.
"What do we do about it?" Mark asks me.
"Concentrate on bringing them back on track," I answer. "But I don't see any reason for alarm. In each of these two cases the delay is about two weeks. Don't forget, if you really can't get it back on track, you still have a project buffer of two months."
That's an angle they hadn't thought about yet. The ‘feeding buffer' protects the critical path from delays occurring in the corresponding noncritical paths. But when the problem causes a delay bigger than the feeding buffer, the project completion date is still protected by the ‘project buffer.'
They like it. My attention is now on something else. On each of the two paths that are very late, the step that they are working on now is marked in red. This red color probably indicates top priority. My problem is that there are many other steps that are red.
I point to one red step where, according to their numbers, the buffer it feeds is still untouched. "What is the urgency in finishing this step?" I ask.
Nobody answers. Mark moves closer to examine what is written on the red step. He turns to one of his people. "Why the urgency?"
"I don't know," this person answers, and points to our skinny guy.
"You see the next step?" He has a matching squeaky voice. "My people are supposed to do it."
"So?"
"And they can't start before that step is finished." I still don't get it.
Mark doesn't either.
"You know that they finished everything else," comes the squeaky explanation.
They are all over him. The efficiency syndrome is alive and kicking, not just in production. I wonder how many of their ‘emergencies' are such false alarms. They probably wonder the same because they check every red dot on their chart. In the end, only four remain.
It's much better, but we still haven't finished.
"There is something else that might delay the critical path," I remind them. "Sometimes everything is ready for a step on the critical path except for the appropriate resource, which is still busy doing something else."
We discuss how to prevent such delays. They invent the resource buffer.
That's a concept I haven't yet covered in class, and their debate teaches me a lot about the practical aspects of exactly how to implement it. But I can't stay any longer. It's our theater night, and I'm not going to let Judith down.
I leave. They are deep in the details.

"It's much easier to implement than we hoped," Mark says, concluding his presentation to the class.
"Any results?" Brian asks.
Mark fidgets. "It's only four weeks since we learned in class what to do, and it's three weeks since we actually implemented it. Now, you know that in a development project of two years..."
"Three weeks is nothing," Brian completes Mark's sentence. "I know. Still, can you see any tangible results?"
"What do you mean by tangible results?" Ruth is slightly snappy. "Do you expect that in three weeks we'll complete the project? I hope not. But then, what else would you call tangible?"
"Hey, I'm not criticizing," Brian defends himself. "I think that what you've done is terrific. I just wonder if you have any hard evidence of real progress. That's all."
Fred puts his hand on Ruth's arm, and to Brian, he says. "There are some numbers. But first I have to explain something. Remember the criticisms we all had on the way we measure the progress of a project?"
"Yes. Vividly."
"Well, we changed the way we measure progress. Progress for us is now measured only on the critical path; what percent of the critical path we have already completed. That's all we care about."
"We are doing the same," Brian replies. "It does work much better."
So my students are using what they learn here. That's delightful news to me.
Fred nods and continues, "According to this measurement we have made a lot of progress in the last three weeks. For example, in the previous three months..."
"Forget the numbers," Mark interrupts. "Let me tell you what progress we made in much more real terms. Do you know what happens when it's clear to everybody that we are going to be late on delivering? Really late?"
In a bitter tone he answers his own question. "Everybody is then on the project leader's back to cut corners. First to compromise on the quality checks, then to trim targeted performance."
"Same thing in computer software," Charlie is all smiles. "No difference."
"A month ago," Mark is waving his big hands, "everyone on my team had already come to me with suggestions of which specifications to trim. They were all over me to start discussing it with my boss. Today, after only three weeks, this pressure is off. Brian, do you understand what this means?"
"They've started to believe that they can finish on time. Now that's impressive."
"Too good to be true," Ted speaks up for the first time. "I've listened carefully to what you've done, and all I have heard is that you moved some numbers around. How can it have such an impact?"
Not like Mark and Ruth, Fred is smiling. "Moving some numbers around may have a big impact. Ted, suppose that some numbers are moved from your paycheck to somebody else's. Will it have an impact?"
Ted joins the laughter. Then he clarifies, "Mark, I understand all of that, but there must be something more. What actually are you doing differently?"
"Nothing." Then, as an afterthought, he adds, "But you have to realize that the whole attitude has changed. As I already stressed, there are no more false alarms. People don't put pressure on others just because their people do not have enough to do."
Ruth steps forward. "There is another big difference. We don't have milestones anymore. It's not like it was before, when you knew you were supposed to complete your step in two weeks, so what's the rush. Now, it's different. Either you don't start a step, because it's too early, or, if a path is clear to be worked on, you work on it as fast as you can. You see, we trimmed the times to the extent that people are not sure anymore that they can finish the step on time. They don't dare procrastinate. I would say that the ‘student syndrome' basically disappeared. Don't you think so, Mark?"
"Yes, of course. You see, Ted? Before, when we used milestones, and you knew that you had two weeks to complete a step, the two weeks were yours. I, as project leader, couldn't do much to push you to finish earlier. Moreover, if I came after one week and started to press, even inquired, you would have reacted as if I were out of line. ‘There is still a week to go, what do you want?'
"Now it's different. We trimmed the times. Now people know that there is a fair chance that they will not finish the step on time. They fully understand why I'm concerned, why I came early to find out where they stand."
"That's makes sense," Ted concludes. "That will have an impact." Then he confesses, "I must say that only now do I see the human behavior aspect. I understood why we should trim the time estimate from a ninety percent chance of completing ontime to only a fifty percent chance, but only now do I see the full ramifications. In retrospect, it's obvious."
"If you do what makes sense," Ruth comments, "you find out that it makes sense from many other aspects as well." Mark is not ready yet to dive into philosophical remarks. "There is something else that should be mentioned. Multi-tasking. Eliminating the false alarm and actually shrinking the time it takes to perform a step contributed a lot to the reduction of multi-tasking. People do not jump so frequently from task to task. There is much less nervousness. How much does it contribute to the shrinkage of the lead time? I don't know, but it must be substantial."
Ruth turns to me. "Professor Silver, you visit us every week. What is your impression?"
I can only talk about what I have seen, and you can't see much in one-hour visits. "I'm in no position to evaluate by how much multi-tasking has declined. One thing is clear, though. People are more focused."
"The project is much more focused, that's for sure," Mark confirms.
"May I say something?" Fred rhetorically asks Mark. "I think that one of the major things we did was putting the resource buffer in place."
"Yes," Mark says. "Previously it was very common for everything to be ready for a step, but the people wouldn't be. They were busy working on something else. We decided that this would never happen for the steps on the critical path. Now, on the critical path, when everything else is ready we must make sure, in advance, that the resources will be ready." "How do you do that?" Ted is surprised. "This idea of resource buffer was the only thing out of what we said that I thought was totally impractical. Do you actually force a resource to do nothing one week before it's supposed to work on the critical path? And people go along with it?"
"No. We don't do it that way. A week before the expected time we just remind people that their work on the critical path is coming. Then three days ahead we give another reminder. And then again, one day before, when we know for sure that everything else is going to be ready. The important thing is that people know that when the time comes they must drop everything and work on the critical path."
"I haven't heard anybody complaining," Ruth says. "On the contrary, they appreciate the early warnings."
"This is very important," Fred emphasizes. "Without it I'm sure that most of the advances we have made would have been wasted. To show you how well we are doing, let me give you one number. Three weeks ago, when we started, the project buffer was nine weeks. Now it is still nine weeks."
"In spite of the fact," Mark adds, "that everyone thought that the times we left for each step were much too short."
"Thank you," I say. The class applauds.
As the three head back to their seats, Fred turns, "There is one thing I wanted to ask."
"Go ahead."
"I'm not happy with the way we measure the progress."
That stops Mark. "What's the problem?"
"I am monitoring just the critical path, and so far everything is fine. But I'm afraid that a problem might be brewing in a noncritical path, and by the time it reaches the stage that it delays the critical path, it will be too late."
"That's a problem." Mark is stuck in the aisle.
"Sit down," I say. "There is no problem. You are monitoring correctly."
I'm confident. In the last meeting we had with Johnny to discuss operational measurements we covered buffer management in detail. I'm convinced that what they are doing is okay.
"Fred," I say, "you are monitoring the project buffer, correct?"
"Yes."
"How?"
"It's very simple," Fred says. "If a step on the critical path is completed, for example, two days earlier than estimated, I enlarge the project buffer by two days. If it's late, I reduce the buffer. Actually I don't wait for a step to be completed. Every day the people who work on the critical path give me their estimates."
"Estimates of the percent of the work they finished?" "No, I'm not interested in that. They give me their estimate of how many days until they are going to pass the hot potato to the next step. I must say that sometimes it looks funny. For example, last week the report from day to day was four days to pass the potato; three days; six days, they ran into a problem and they panicked. Then, next morning, it's down to one day. By solving the problem, they found a good shortcut." "If you are afraid of a problem brewing in one of the noncritical paths, why don't you do the same thing there?" He looks puzzled.
"Don't we do it?" Ruth looks confused. "Mark, how do you determine if you have an emergency on a noncritical path? Don't you calculate the same for each of the feeding buffers?" "Come to think about it, basically we do. But not formally. Fred, can you monitor all the buffers, not just the project buffer?"
"No problem. I'll give you a daily report." Fred is very collaborative.
"How should they arrange such a report?" I ask the class. "According to importance," one person answers. "Define importance."
It doesn't take long for the class to create the priority list. Highest in importance are steps that reduce the project buffer, either because they are somewhat late and are on the critical path, or because although they are not on the critical path they are late to the extent that they have already swallowed the corresponding feeding buffer and then some.
Then they debate how to arrange the second category—the steps that are not yet affecting the project buffer but are consuming part of the corresponding feeding buffer. There are several suggestions.
Some claim that the only thing that makes sense is the accumulated delay, or in other words, the number of days already consumed from the corresponding buffer.
Others say that this number doesn't tell us much unless it is compared to the original length of the buffer. Ten days out of a buffer of thirty days, they claim, is much less of a problem than consuming five days out of a buffer of six. This group advocates percentage, the percent currently consumed of the corresponding buffer.
A third group, led by Ted and therefore very vocal, claims that none of the above is really important. The only thing that matters is how many days are still left in the buffer.
Personally, I don't think that it makes much difference. As long as they continuously monitor all the buffers, they will be focused. Arranging it in one way or another is not so important in my eyes. In any case, the list is relatively short. It doesn't contain the steps that are not yet supposed to be worked on, or the steps that have already passed the baton.
But it's a lively debate. Everybody is involved, even students who hadn't yet opened their mouths. So I let it go for a while. A long while. Almost to the end of the session.
It was invigorating until . . . until Roger spoiled it for me. I thought that this person came to class just because he finds sleeping in a chair more comfortable than his bed. Probably the heated debate woke him up.
When I finally summarized the three options on the board, he commented, "It will never work. No one will collaborate."
I had to really lean on him to clarify his statement.
"In my company," he pompously said, "I'm in charge of negotiations with the subcontractors. They will never agree to cut their lead time. They will never agree to report, definitely not on a daily basis. You know, you get something when you get it. Every prediction they give you, they themselves don't believe in. Like everything else that we study here, it's good in class, but reality is very different."
I started to argue with him, but he cut me off. "If you want, come with me to one of my subcontractors and talk to him."
I was furious enough to accept the challenge.
I know that it's nonsense. He will never arrange for such a meeting. But it's a pity that this excellent session finished on such a lousy note.
I'm gathering my papers when Brian approaches me. "I've already talked with the plant manager and the project leader. They are very interested in what we are learning here. You see, our project to expand the plant is in trouble."
He wants me to come to their plant. We talk some more. I gladly agree to spend a day with their team.
Lately my mood resembles a roller coaster.