Critical Chain - Eliyahu M. Goldratt [91]
Mark stands up and starts to fill the room with his deep voice. "As you know, we are no longer dealing with the A226. That modem is past history for us."
"It's current reality for our company." Ruth doesn't want anybody to misinterpret. "It's the biggest success we ever had."
"True," Mark smiles proudly at her. "Anyway, the three of us are charged with the task of shrinking the development time of . . . all development at Genemodem."
"Yahoo," Ted whispers.
"Right from the start we knew that the biggest challenge would be to deal with resource contention." Mark pauses to find the proper way to explain the essence of their challenge.
"Haven't we already dealt with that?" Roger asks. "I thought that resource contention was solved by the concept of critical chain. What am I missing?"
If somebody has gone through a paradigm shift, it's Roger. He's dropped his facade of ‘I know it all,' and developed a keen interest in the subject. From time to time he even seeks my help on implementation issues. That shouldn't be mistaken for a change in personality. He is still as cynical and self-centered as he was.
"Critical chain," Mark explains, "removes resource contention within a project. It does not address resource contention between projects at all."
"Why don't you use the same logic for a bunch of projects? What's the difference?" Ted doesn't see the conceptual difference between one project and many.
Before Mark is able to answer, I interrupt. "Ted, in your company you do work on more than one project at a time."
"Of course."
"So you must have enough intuition to answer your own question. Try. Give an educated guess. What might be the problems?"
"Offhand, I see a synchronization problem."
"Synchronization is an impressive word," I say. "So impressive that it's often used to disguise ignorance. Ted, you don't want us to suspect you of such a thing."
"No way." And he jumps to the other extreme. "Resource contention means that the same resource is supposed to do two different steps at the same time," he wastes our time defining a term that is clear to us. "Removing resource contention between two steps," he continues methodically, "necessitates, many times, postponing one of those steps. The problem is that, as we discussed at length, there is no clear way to decide which step to postpone. It is almost an arbitrary decision."
I like the way he's approaching it. In order to force him to continue, I prod, "The same is true within one project. Why is it a bigger problem when the steps belong to two different projects?"
"Because two project leaders are involved," he confidently answers. "It's not like you work in one domain, where it doesn't matter which step you move. Here each project leader will naturally fight that the step to be postponed will not be his."
"Is it a big problem?" I continue my almost rhetorical questioning.
"Are you kidding?" Ted smiles. "Mark, now I see what you are facing. It's not just a synchronization problem, it's a nightmare."
"Fair description," Mark agrees. "Unfortunately we didn't realize how big the nightmare was before we stepped into it."
"With both feet," Ruth adds.
"Not because we are thick," Fred hurries to put in a caveat. "But because we didn't know what else to do."
"Do you want to hear what happened?" Mark asks.
I'm not the only one asking rhetorical questions.
"Well, the first problem was mechanical. Our projects, like almost any sizable projects, are described by about one hundred steps. You know, it takes some time to play with one hundred pieces of paper until all resource contentions are resolved. You move one piece to remove contention with one resource, and you have to move the other steps on the same path. This, many times, creates contention for other resources. It takes hours. Now, imagine doing it with six projects."
"So," Fred continues, "we went to our computer department."
"And that's the end of the story," Brian interrupts. "In my company everything you ask from the computer department takes months.
"It's