Eli Goldratt has written many novels beyond The Goal. One of the most important for IT professionals is his book Critical Chain.
Critical Chain is ostensibly about project management, but in reality it’s about all of demand management in a services context. The book identifies and examines key causes of project failure:
Bad multitasking. This is the frequently remarked upon churn experienced when tasks cannot be completed but instead must be juggled, with attendant “context-switching” costs.
Student syndrome. This is the tendency for work to get done at the last minute. A corollary is Parkinson’s law that “work expands so as to fill the time available for completion.” In a project context, it means that (for example) a task truly requiring three days may be estimated at fifteen days, with the task not starting in reality until day 12.
When considered as a systemic, cultural practice, student syndrome is hugely wasteful and an obstacle to execution success in many areas. Because of it, delays propagate while early deliveries do not.
Conservative local estimation, and local buffer control. Task durations are typically variable. For example, provisioning a new Unix server may typically take an average of 1.5 days effort, but 20% of the time may take four days effort. However, because of overly strong incentives in many cultures for “on time delivery!,” the server engineer will always estimate a full week to provision the server.
Then, because of student syndrome, they wait until day 3 to start, because the majority of the time they can get it done. In the meantime, the “buffer” or valuable lead time is lost to the project. Even if the server is turned over early, typically rigid project plans will still not take advantage of this. Again, negative variation propagates but positive variation does not (a key insight of The Goal as well).
Critical Chain addresses these problems through accepting variability in task execution, and capitalizing on early deliveries by centralizing buffers under project management. The concept of project critical path is extended to include the resources working on the key tasks, and the Critical Chain is the critical path combined with resource availability. The critical chain resource is expected to work on nothing but the task at hand and deliver it as soon as possible, with no local buffer management. It’s not “due by the end of the week;” the server is due NOW. And there must be a strong defense against any other demands being placed on that resource (prevent bad multitasking) until that critical chain task is completed, as fast as reasonably possible.
Ongoing re-planning of the project is therefore also needed, since taking advantage of early delivery may mean that timelines across the project need to shift. This is a complex challenge and true Critical Chain project software needs to solve a thorny non-linear problem known as the Resource-Constrained Scheduling Problem.
Critical Chain is especially applicable to environments with large numbers of small, semi-repeatable projects competing for skilled resources – very typical of a large, service request-driven IT environment, especially across the “hosting zone of contention.”
In an environment where these same resources may get called into service requests, incidents, changes, and continuous improvement efforts, the concept is promising indeed and few if any IT organizations to this author’s knowledge have extended their demand and service catalog practices to handle this challenging general case. Instead, resources find themselves at the receiving end of multiple queues with little or no guidance for prioritization.
