Process Capability Analysis: Proving the Gain Still Holds After the Team Leaves

Process Capability Analysis re-assesses process capability after you have made a change. In the words of the tool itself, it confirms the process meets specifications sustainably. That last word matters. A single good week is not capability. Capability is the voice of the process compared against the voice of the customer, measured over enough observations to be believable.

You used capability thinking once already, back in Measure, to establish the baseline. In Control you run it again. The question has changed. In Measure you asked how bad things were. In Control you ask whether the gain is real, stable and good enough to hand over.

Reach for this tool at the point where the project team is about to stand down. The improvements are in place. The new method is documented. Somebody is about to inherit the process. Before that handover happens, you want evidence on a page rather than a feeling in the room.

Ci Flow ships with sample data so you can see the tool working before you load your own. The sample is a post-improvement capability study of invoice cycle time. This example is fictional. It exists to show the mechanics, not to describe any real organisation.

The series is labelled Invoice cycle time. The group is labelled Post-improvement. There are 30 observations, recorded as Unit 1 through Unit 30, in the order they were taken. The measurements run from a low of 9.6 to a high of 10.5. Most values cluster tightly: 10.2, 9.8, 10.1, 10.4, 9.9, 10.0 and so on through the thirty units.

Read that spread for a moment. The whole data set lives inside a band roughly one unit wide. That is the shape of a process that someone has already worked on. A pre-improvement study of the same process would almost certainly look wider and messier. The Control phase job is to confirm the narrow band is the new normal, not a lucky run.

The tool asks for four things. Observation or period gives each row a label. In the sample this is simply Unit 1 to Unit 30. Measurements in the order they were taken is the mandatory field and holds the actual numbers. Group or stratum lets you tag a slice of data, which here is Post-improvement. Series or scenario names the thing being measured, which here is Invoice cycle time.

The subgroup size is set to 1. That means every row is a single unit measured on its own, not an average of several. Individual measurements are the normal case for transactional work such as invoices, where units arrive one at a time rather than in batches.

Two setup habits will save you grief later. First, keep the rows in true time order. The tool relies on that sequence, and shuffled data destroys any read on stability. Second, use the group and series labels deliberately. If you tag this run Post-improvement, you can later add a second group and compare the two in the same frame.

Once the data is in, the tool computes the capability output on screen. You are looking at two separate ideas presented together. The first is spread. How much does the process vary from unit to unit when nothing unusual happens. The second is position. Where does that spread sit relative to the specification limits you care about.

A process can fail on either count. Wide spread inside a wide tolerance can still pass. Tight spread parked hard against one limit will fail, because any small drift pushes output over the edge. Capability indices exist to separate those two failure modes, which is why you read both rather than one.

With the sample data the story is a tight cluster. The extremes, 9.6 and 10.5, sit close to the bulk of the readings at 9.9, 10.0, 10.1 and 10.2. There is no single wild value dragging the distribution out. That is the pattern you hope to see at the end of an Improve phase.

The tool also offers an AI review that explains the result in plain language. Use it to sense check your own reading and to draft the words you will put in the handover pack. Do not let it replace the five minutes you spend looking at the numbers yourself.

Capability output is not a trophy. It is an input to four specific Control phase decisions.

The first decision is whether to close the project. If the post-improvement capability clears the threshold your sponsor agreed, you close. If it does not, you stay in Improve a little longer, however tired everyone is.

The second decision is what to monitor afterwards. A capable but off-centre process needs a tight watch on the side that is close to the limit. A centred process with moderate spread needs a watch on variation instead. The capability picture tells the process owner where to point the control chart.

The third decision is sampling effort. A process with comfortable margin can be checked less often. A process that only just passes earns more frequent checks. The fourth decision is what to promise. Capability is the honest basis for any service commitment you make downstream. Promise what the process can do, not what it did on its best day.

The most common mistake is running capability on an unstable process. Capability assumes the process behaves predictably. If special causes are still present, the indices describe a process that does not really exist. Confirm stability on a control chart first, then compute capability.

The second mistake is too few observations. Thirty individual readings, as in the sample, is a workable starting point. Ten is not. Small samples give capability numbers that swing wildly, and a swinging number invites a false celebration.

The third mistake is collecting all the data in one narrow window. Thirty invoices processed by one person on one quiet afternoon will look beautiful and will tell you almost nothing about Tuesday mornings at month end. Spread your collection across the conditions the process actually faces.

The fourth mistake is quietly moving the specification. If the limits in the Control study are looser than the limits in the Measure baseline, the improvement is on the spreadsheet, not in the process. Write the limits down once, early, and leave them alone.

The gain decays when ownership is vague. Capability analysis helps because it turns a vague claim into a repeatable measurement. Anyone can rerun the same 30 observation study in three months and compare.

Build that into the handover. Name the metric, which here is invoice cycle time. Name the specification limits. Name the sample size and the collection rule. Name the person who reruns it and how often. Then record the Control phase result as the reference point.

Use the group field to keep history in one place. Post-improvement is the first tag. A later study can carry its own tag, and the comparison becomes a two minute task rather than a small project. That is what makes the measurement survive the people who created it.

Process Capability Analysis will not tell you whether your process is stable. It assumes stability. The tool reads the numbers you give it and computes indices regardless. Stability is your judgement, made elsewhere, usually on a control chart.

It will not tell you why the process behaves as it does. There is no cause in a capability index. If the sample data had shown a wide spread, the output would have reported the width and nothing about the reason. Root cause work lives in the Analyse phase.

It will not validate your specification limits. If the limits are wrong, borrowed from another process or set by habit, the capability result is arithmetically correct and practically useless. It will not detect a measurement system problem either. Thirty readings from an inconsistent measurement method will look like process variation and get treated as such.

Finally, it will not keep the gain on its own. It records evidence at a point in time. Somebody still has to rerun it, read it and act when the picture changes. The tool makes that cheap. It does not make it automatic.