I expect that this information will not, after all, be included in the guide; I believe because the guide is primarily oriented towards construction, and this would represent too much for the construction world to swallow, relative to commonly accepted “best practices.” But in any case I’d welcome your thoughts.

Here is the description of the presentation:
Rob Newbold will draw on his 15 years of experience developing and applying critical chain software and methodology to discuss tips and traps associated with the “resource-constrained critical path.” He will start with a brief background and talk about when we do (and don’t) want to consider resources in our critical path. Then he will explain what a resource dependency is and how that changes the definition of total float and critical path. He will conclude by describing some practical issues to understand when applying resources to the critical path.

There are really four points whose vertical positions we have to decide on in order to define the regions: A and B, which are the start and finish of the yellow/red boundary; and C and D, the start and finish of the green/yellow boundary. A and B are the most important, because the red region implies a need for serious management attention. B must be enough below the 100% point to allow a reasonable chance to bring the project in on time, even if there’s a last-minute delay. A must be enough above the 0% point to accommodate reasonable startup delays, without being so high that serious startup problems may go unattended. Depending on the environment, point A could be anywhere from 10% to 40%.

Points C and D define the yellow region, where we start to say, “this project’s status may not be ok.” This is where senior management may start to pay attention. Generally point C will be at the origin, because any startup delay should provoke some concern. Point D is the fuzziest. It could be close to B, if lateness is your biggest concern and by this time there’s you have little concern that the project will be late. It could be much farther down, say at 50%, if you want to minimize delays and get the project done as quickly as possible. Ultimately, it depends on what kinds of attention and actions you want the yellow region to trigger.

There is another way of looking at this. Suppose we explicitly define the green region to be the area in which you have a 90% or greater chance of finishing on time without significant management intervention, and the yellow region the area that gives (say) a 50% or greater chance of finishing on time. If we had perfect knowledge of all the probabilities in play, those regions would not be bounded by straight lines. Without perfect knowledge, we can still estimate positions for the AB and CD lines to approximate our sense of where those regions are. We do that by making the tradeoff between the wasted management attention if the fever chart says the project is in trouble, and it really isn’t; versus the increased chance of being late if the fever chart says the project isn’t in trouble, and it really is.

A related question is, should all projects for an organization have the same fever chart regions? The answer, as usual, is: “It depends.” If, in thinking through the placement of points A through D, the answers are very similar for different projects (especially for points A, B, and C), then you should use the same fever chart regions. If there are groups of projects that have significant differences, you might want to use different region definitions depending on the group. The more uniform the fever chart regions across projects, the simpler they will be for people to understand. And keep in mind that any given multi-project fever chart can only display one set of regions.