Process Cycle Efficiency (PCE)
Five years ago I prepared report for a Lean transformation for a certain client department. The PCE was less than 1%! PCE is defined as the ratio between the time we actually spent working on a feature to the Lead Time. PCE is an average metric.
The purpose of this blog is to explore if there were only one metric to choose, should it be the PCE and why.
I believe in gut-feeling to drive improvements. However, our ability to obtain the support for our improvement proposals is determined by having credible measures of the current state. We should be able to demonstrate that the poor value of a metric (I suggest PCE) is the Cost of Poor Quality (CoPQ). CoPQ can be reduced if we attacked the causes of this poor value. In addition, long Lead Time is direct symptom of poor metric value. CoPQ and Delays are manifested as:
- Excessive development cost.
- Competition beats us in terms of deploying early the right features to their customers.
- Increased failure demand.
- Features fail acceptance testing even after they passed the system test.
- Excessive waiting and long Lead Times.
- Very high cost for regression testing.
The above list can be so long.
Waiting time and excessive inventory (features) for me are two different but equivalent representations of having issue with the Flow.
Cumulative Flow Diagram (CFD) provides graphically the total number of features per stage on daily basis. The wider the stage in the graph, the higher the inventory and therefore the longer the waiting time. CFD can be a tool to detect the stage having unusual waiting time. This is were the bottle-neck should be addressed. If you calculate PCE weekly, it will have low value indicating excessive inventory of the CFD for that week.
Lead Time shortening is the goal for Lean and Agile. The issue is not because we don’t know how to do the technical work, instead it is that we need to improve the hand-over of features between stages. I have been in situations were requests were taking too long to complete while the actual working time (some time called touch time) was so short. I mean working time include analysis, planning and prioritization and not just development and testing. In reality, the customer holds us responsible from the time they add their request and not from the time we start developing or even working on it. Ill-defined request means quick client turnaround for clarifications. This kind of promptness builds trust. In contrary, if we keep the ill-defined request in our input buffer for a while before asking for clarifications this reduces the predictability of the upstream.
Lead Time is elongated because of waiting. Internal defect detection can help in reducing the Lead Time but to a limited extent. External defects after the release can cause very expensive rework. This added failure demand can add overheads on the system causing rest of features to wait. Lead Time alone doesn’t tell us how long we have been actually working on a request.
PCE can drive process improvement. We can prioritize the highest contributor to the low PCE and start attacking it first. PCE drives us to think about the white space between stages instead of improving the speed of work stages.
Measuring PCE on the organization level can be particularly useful. At that level, there can be many dependencies among various teams of the organization’s value stream. PCE can drive reorganizing of teams. For example, the cause of Low PCE can be: we can’t complete a feature till a foundational component developed by another department is ready. In other token, this is a common symptom in quasi agile companies which implement agile as ceremonies instead of mind-set.
From the project management view, the value-stream of the project can involve multiple departments working in interleaved way in multiple stages. Focusing on task management will only help a little and harm a lot by:
- Failing to see white space between stages,
- PM will tend to think of the value-stream as departments instead of being transformation states, and
- No collective ownership on the outcomes, and therefore, no predictability.
There is a challenge in calculating the PCE if we don’t have an electronic tool which records automatically the working time spent on the feature per stage.