Warning: More inside thinking, this time about Critical Chain Project Management. Enjoy!
Rob Newbold of ProChain (and author of a number of books on CCPM) has been thinking about updating the practice of CCPM around the planning and scheduling of CCPM projects. He presented four concepts that he's implemented, most of them seem reasonable. I don't know if they are all really needed though.
First was the question of eliminating feeding buffers, about which he has talked before. The argument is essentially that feeding buffers confuse people, and that one can manage the risk by scheduling feeding chains to finish a "virtual feeding buffer" before the critical chain task. And then in execution, one can calculate the risk of delay along the feeding chain. My guess is that the calculation looks a lot like current buffer consumption calculations. One aspect of this conversation that I liked was the acknowledgement that if there are signficant delays on the critical chain, the fact that the feeding buffer is consumed may not be relevant any longer. (Most CCPM software keeps the feeding buffer fixed in time, once the project is released.) There was also a discussion of "integration risk" - essentially the more tasks feed into an integration point, the higher the likelihood of delay. I've always thought the default 50% feeding buffer was good enough, but one could argue that it should be larger. Finally, there is the issue that feeding buffers sometimes make the project longer than just the critical chain. Eliminating feeding buffers removes this concern, but there still must be a mechanism to protect the critical chain -- that's what feeding buffers do. Rob described a couple options, but he prefers to add time to the project buffer to represent this risk.
This then leads to a conversation about sizing project buffers. The default mechanism is to set the project buffer to ~50% of the critical chain (the aggressive-duration critical chain). But there are other methods, such as using a two- or three-point duration estimate and determine the variability from there. Some of the CCPM tools permit such options. And he also described again the above idea of adding time to the project buffer based on what used to be in feeding buffers or to protect against excessive integration risk. I didn't find this topic controversial at all - though it tends to lean toward the wonky side. One interesting result of acknowledging different variabilities of your tasks is that you can come up with execution projections. Rob showed a project fever chart with an overlay that showed the anticipated trend of the rest of the project. One could use this information to focus on opportunities to recover buffer, which can be helpful to the team who are trying to meet their commitments.
The third topic was in clarifying the definition and calculation of the critical chain. There are some nuances here, but the emphasis of Rob's comments is that the critical chain is the place where the project team must focus. And if the CC is unclear - or it becomes unclear during execution - then the focusing power may become lost. Essentially the critical chain becomes "the most constrained" set of tasks, which normally turns out to be the critical chain that one normally finds.
The final topic was on network analysis and managing execution, which is mostly an outcome of the above discussions and suggested solutions. The project team still promises delivery at the end of the project buffer. In combination with the words Eli Schragenheim used, the team now have a reasonable range that they can promise for delivery. During execution, Rob recommends allowing the virtual feeding buffer to move with the integration points, though I suppose there has to be some caution around allowing for significant buffer recovery. I don't particularly see the need for the suggestion to recalculate the critical chain during execution. Buffer management should always handle that - it should always point to the current source of buffer consumption, regardless if it is on the original critical chain.
In discussion at the end of the talk, I raised the bigger issue about CCPM that I have been noticing more and more. All the tweaks to the CCPM techniques are meaningless if the team who are executing the project have no common understanding of the project. I think we assume too quickly that the team are aligned and are ready to dive into the CCPM planning exercise. But without that alignment, there will be arguments over the plan and nothing we do to improve the way CCPM works will change this. There have been related conversations peppered around the conference around creating more engagement within an organization.