Comments on _Critical Chain_, ch 21 & 22

Chapter 21

No new info.

Chapter 22

“Suppose that on one of the noncritical paths we are so late that we have already exhausted the entire feeding buffer, and we have started to penetrate into the project buffer. On the critical path itself we are okay."

“In the situation Ruth just described, isn't it true that the critical path has changed?" Fred answers. "That now the critical path starts at the operation where we have the problem?"

That's like saying that something can happen such that the current bottleneck switches to some other point. And I guess, by the same logic, the critical path can change such that one or more of the points on the new critical path used to be a point on the old non-critical path.

... "We put feeding buffers only where a noncritical path merges into the critical path. Changing the critical path will necessitate changing the location of many feeding buffers."

“No!" Ted responds too hastily. The thought of rearranging everything every time we face a serious delay on a noncritical path scares him. It scares me too.

That sounds like being in emergency mode. So I think that means that when the emergency is over, the old critical chain resumes. Or maybe it's better say it like this: apply the new critical chain logic until the old critical chain resumes -- this defines the moment that the emergency is over.

“If we don't do it," Ruth continues, "we're ignoring reality. Let's face it, whether or not we like it, right now the critical path does start at step N. And this path is not protected from disruptions in other paths by feeding buffers. It is also not protected by resource buffers. So the chance of recovery is reduced. On the contrary, there is a good chance that the delay will intensify. Don't you realize that we must rearrange the project?"

They discuss why they can't just change things around to account for the new critical path. 

“Because, at least in my case, the critical path has started to jump all over. Every few days I have this problem. Frankly, I am about to give up."

I guess you can control the critical path by doing things like ensuring that some particular point has plenty of capacity such that it never becomes a bottleneck (never becomes a point on the critical path). I don't mean never. I mean more like 99.9% chance of not happening.

“It's frantic. Noncritical paths, where everything was fine, where the feeding buffers had not been touched, are starting to, all of a sudden, be a problem."

I think this is to be expected given the situation. The situation is this: you have a functioning system. you find the bottleneck and increase capacity there. That increases throughput of the system. So let's say that meant shaving off 1 month from the project estimate. That would put pressure on the system such that a new bottleneck could arise. But that's not a negative symptom of bad things going on. It's a positive symptom of great things happening. 

Maybe I was confused but the discussion seems to have switched from a one critical chain issue to the issue mentioned in previous chapters about multiple projects, each one with it's own critical chain, whereby they share a point on their critical paths.

“How are we going to ensure that steps done by limited resources will not be scheduled in parallel?" Ruth is concerned.