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