In Tame the Flow one of my primary concerns is about gaining better control of how work flows through a process. Naturally, it is desirable to have as stable a flow as possible; because under such conditions it becomes feasible to take advantage of Little’s Law.
In order to have a smooth and regular flow, it is necessary to be able to detect and react to oncoming problems. Especially those problems that slowly creep into your work, and slowly increase the (mean) “cycle time.”
I claim that ordinarily these problems go undetected in most instances. What usually happens is that the work load is “rebalanced”. In other words, the source of negative variability is not confronted; but it is adapted to by reducing the work load.
One way to have signals that show when this is happening is by combining a Cumulative Flow Diagram with a Buffer Control Chart, as illustrated here:
You can read the details about how the diagram is constructed in Tame the Flow. In essence the buffer control chart shares the same time line with the cumulative flow diagram, and is derived in a way similar to how Critical Chain Project Management (CCPM) of the Theory of Constraints defines and uses its project buffer.
The Doubt: Is it Correct to Refer to a ‘Buffer?’
Donald Reinertsen (@DReinertsen) in his excellent book “The Principles of Product Development Flow: Second Generation Lean Product Development” provides a plethora of advice and principles on how to manage flow.
In particular, I would like to examine Principle V11 which reads:
The Buffer Principle: Buffers trade money for variability reduction.
Some people have referred to Principle V11 to dismiss the idea of combining a Cumulative Flow Diagram with a ‘Buffer’ Control Chart.
I’ve always had mixed feelings when reading Don’s explanation of that principle. On the one side, I find myself in total agreement with Don’s explanation. On the other hand, I don’t see how it applies to what I am proposing; yet I refer to a ‘buffer.’
I believe the disturbance might have to do with the legacy of how I derived the mechanism, which comes from CCPM. In CCPM there is an explicit definition of a project ‘buffer’ which is placed at the end of the project’s activities.
The CCPM buffer originates from the (mal-)practice of ‘padding’ activity estimates which is very common in the Critical Path method. CCPM simply collects all the padding at the end of the activities (and then resizes that ‘buffer’ in a certain manner). The intent of such padding is obviously that of buying safety, to absorb unforeseen variability. The result is, as Don says, that:
A buffer converts uncertain earliness to certain lateness.
But it is Not a Buffer! (Despite the Name)
On deeper examination, what I propose is not adding a ‘buffer’ to absorb variability.’ What I am doing is setting control limits in order to be able to detect (and hence react to) unexpected negative variability in cycle time. The primary purpose is not buffering but to provide an operational monitoring tool that gives significant leading signals of oncoming risk materialization.
The chart is very similar to a control chart, and is used in similar ways. So maybe I should not refer to this as a ‘Buffer Control Chart’ (as it is customary in CCPM), but rather I should call it more appropriately a…
Cycle Time Control Chart
What do you think? Is the legacy terminology misleading? and is ‘Cycle Time Control Chart’ (or CTC Chart for short) a better name?
Comments are welcome, since the final revision of the book is not yet published, and I could still make the change.
Update July 8, 2013
On second thought ‘Cycle Time Control Chart’ is not a good choice either, since it has definitively an assumed meaning when plotting actual cycle times against time.
I am still trying to find an appropriate term for the ’thing’ I am doing. While I have a crystal clear understanding of what it is I am doing, I am not happy with the terminology. While it looks like a buffer, because of the historical heritage from CPM via CCPM, I don’ t feel this is a buffer at all. Suggestions still welcome.
Update July 9, 2013
The intent of this control chart is to give a clear indication as to how well or bad work is progressing with respect to expected (average) due date performance. It helps in creating awareness about the state of progress towards delivery. Therefore, alternatives I am considering now include:
- ‘Due Date Performance Control Chart’
- ‘Release Control Chart’
- ‘Delivery Control Chart’
The method effectively establishes three time points (yellow, red, and black threshold) after the expected (average) forecasted time of delivery. These time points act like control points, and we project through Little’s Law our latest current delivery rate into the future, to see were delivery might happen – with respect to these three control points.