How Critical Chain Project Management Delivers Useful Tools to Visualise Project Performance
One of the rules of Critical Chain Project Management (CCPM) tells us to remove the ‘safety’ or time buffer allocated to each individual step of a project and move this to a single safety or time buffer at the project endpoint.
This is done for a number of reasons:
- to relieve or eliminate the effects of student syndrome (putting off work to the last minute),
- to ensure that any advances count (in other words, to ensure that advances aren’t absorbed by the local ‘safety’ assigned to each individual task and, instead, actively reduce the overall project delivery timescale), and
- to give a better oversight of the project and global performance against the scheduled delivery date.
The net result of this is that projects become more reliable and faster, meaning that the overall time allocated to safety can be reduced, with a commensurate reduction to overall project schedule.
Reducing the safety or time buffer and bringing forward the scheduled completion date often initially feels very uncomfortable for the project team. It is, therefore, important to recognise the potential of the project team to feel fear, or to feel threatened. After all, they are being asked to trust that the above assumptions are correct and adequately implemented in the project plan – without having experienced the benefits of the change for themselves.
Good communication and change management is a vital part of any CCPM project. Plus, managers need to make the buffer situation visual and transparent for all team members. One handy tool that CCPM gives us to clearly visualise the project buffer, and our progress against it, is the Fever Chart.
The Fever Chart is a time series graph on which the project manager can plot the progress along the critical chain over the lifetime of the project. Usually the horizontal axis represents % of project completion, while the vertical axis the % of buffer consumed.
The Fever Chart is a clear, graphical way of quickly understanding how the actual completion of the project compares to the scheduled project completion. If we know that current performance is charting somewhere in the yellow, then we can start preparing actions should the project move into the red area of the chart.
My general rule is that when in green, do nothing. When in yellow, prepare the actions in case the project becomes red. When in red, act. Managers should be paranoid but not hysterical. After all, the buffer is designed to be consumed. The team should not try to not consume it. Where multiple projects are running, with shared resource dependencies, it’s desirable to consume the buffer of projects which are currently charting in the green in order to help other project which are charting in the red.
The most important aspect of this is to ensure that the buffer situation is clearly visible to all team members.
In my experience, where projects are running largely within the green, yellow and red areas of the chart, the project team will react to buffer consumption and try to recover the buffer without the project or portfolio manager needing to intervene.
