Comments on _Critical Chain_, ch 23 & 24

Chapter 23

There's a meeting between BJ the president and the professors. They are reading a report that has comments from companies about why they don't want to send their managers to the university's executive MBA program.

One guy suggests attaching payment to production -- university only gets paid tuition after the student-manager makes the company $100,000.

the president seems to like the idea. 

Chapter 24

This chapter gets back to the problem of dealing with a shared point between multiple critical chains (different projects) whereby that shared point is a bottleneck for all the projects. 

... "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."

That's stupid. The 2 project leaders could be having meetings with their shared boss. The 3 of them could come to agreement on what to do with the shared resource that the 2 project leaders are competing for. Maybe the boss knows something that helps decide which project should get the shared resource first. And that's something that potentially the 2 project leaders already know, in which case they could have made the decision without the boss.

“To cut a long story short, we squeezed agreement," Fred summarizes days of fierce arguments into one sentence.

that is, agreement about the order in which the shared resource is used by the competing projects. 

“Mark doesn't wait long. "Did you ever see a step that finished somewhat late?" He gives them a clue. "One small deviation in one step and BOOM-you get the domino effect, contentions all over the place. We found ourselves wasting all our time sorting out fights. Ted, you called it a nightmare? You are absolutely right."

This was discussed earlier in the book, I think a couple times. If you're getting the domino effect after one step finishes late, then maybe the problem is that you don't have enough capacity in all the non-bottlenecks such that none of them become the bottleneck. 

This is weird. Systems should be designed such that the designer chooses which point is the bottleneck. And if that point becomes a non-bottleneck, that's an error -- an error between expectation and reality. The error should be corrected, both for the temporary situation and also for the longterm. Like fix it now, and then fix it so that it never happens again (or less likely to happen again).

Much of what the book has been talking about is scenarios where the system already exists and people are trying to figure out how it currently works (like figuring out which point is the bottleneck) and then they are trying to make the system work better given the current parameters (like, no extra machines, no extra people, no changes other then moving stuff and people around). 

But like another thing that could be done is you take the existing system, call it Sn (for system now), and you imagine a better system Sf (for system future). Sn is just moving stuff/people around to subordinate the non-bottlenecks to the bottleneck. This is a temporary/shortterm move. I think the longterm move should be to figure out a new system Sf which is just the old Sn's resources (stuff/people) plus some additional resources. Sf's design would do things like ensure that the point we want to be the bottleneck is the actual bottleneck. That means doing things like increasing capacity of the non-bottlenecks sufficiently such that they never become the bottleneck (not never, but like 99.5% chance of not happening).