Process Capability: Your Research Process Is Stable. That Is Not the Same as Good Enough (2026)

A research process can be perfectly stable and still fail every requirement it was given. Stability and adequacy are separate properties, measured against separate limits, and confusing them is one of the most expensive mistakes in operations metrics. A control chart can tell you that your turnaround time is predictable. It cannot tell you that predictable is fast enough, because it never had access to the number that defines fast enough.

The short answer

There are two kinds of limit and they come from two different places. Control limits are computed from your own data and describe what your process does. Specification limits are handed to you from outside and describe what someone needs. Process capability is the ratio between them, expressed as Cp and Cpk, and it is the only one of the three that answers is this good enough.

The NIST/SEMATECH Engineering Statistics Handbook states the rule that makes the order of operations non negotiable: process capability compares the output of an in-control process to the specification limits by using capability indices. You establish stability first. Capability computed on an unstable process is a number without a referent, because the distribution it describes will not be there next month.

Two different limits, two different owners

Control limits: the voice of the process

Control limits are calculated from the process itself, typically at three sigma either side of the centre line. Nobody chooses them. They are a description of what the process has been doing, and the only way to move them is to change how the work is done. Donald Wheeler popularised the name that fixes the idea: control limits are the voice of the process.

If you have not established stability yet, that comes first, and it is covered in full in the guide on common cause and special cause variation. Everything below assumes you have a stable process.

Specification limits: the voice of the customer

Specification limits are the opposite in every respect. They are not computed from anything. Somebody decides them: a stakeholder, a service agreement, a sprint boundary, a regulator. They represent the result that is required, which is why Wheeler calls them the voice of the customer.

For research operations, specification limits are the promises your function has made. Findings within ten working days of study close. At least 90 percent of interviews reaching a quality score of 4 or better. No more than 5 percent of responses discarded for data quality. Every one of those is a specification limit, and most research teams have them without ever having written them down as numbers.

Why they must never share a chart by accident

Drawing specification limits onto a control chart is the classic error, because it invites you to react to a point that sits inside the control limits but outside the spec. That point is ordinary process behaviour. Reacting to it as though it were a special cause means tampering: adjusting a stable process in response to noise, which reliably increases variation.

The two limits answer different questions and belong in different calculations. Control limits decide whether to investigate an individual point. Specification limits, combined with the process spread, decide whether the process as a whole should be redesigned.

The four states a research process can be in

The pair of properties gives four states, and only one of them is fine.

Stable and capable

The process is predictable and it lives comfortably inside the requirement. Maintain it, chart it, and do not adjust it.

Stable and incapable

This is the state teams misdiagnose most often, and a consistently measured turnaround series of the kind Koji produces is what makes it visible. Nothing looks alarming week to week, no individual point demands attention, and the process misses the requirement consistently. There is no special cause to find, so root cause investigations of individual late studies return nothing. The requirement is being missed by the design of the process, and only a change to the process or the requirement will fix it.

Unstable and apparently capable

The process happens to be inside the spec at the moment, but it is not predictable, so this tells you nothing about next month. Capability indices computed here are not meaningful. Stabilise first.

Unstable and incapable

Both problems at once. Fix stability first anyway, because you cannot measure the effect of a capability improvement while the baseline is still moving.

Computing capability on a research metric

The formulas

Cp measures whether the process spread would fit inside the specification range at all, ignoring where it is centred:

Cp = (USL - LSL) / (6 * sigma)

Cpk measures the distance from the process mean to the nearer specification limit, so it accounts for centring:

Cpk = min[ (USL - mean) / (3 * sigma), (mean - LSL) / (3 * sigma) ]

Many research metrics have only one limit that matters, which makes the calculation simpler. Turnaround time has an upper limit and no meaningful lower one, since nobody complains that findings arrived early. In that case only the relevant half of the Cpk formula applies.

A worked example: turnaround time

A team measures working days from study close to decision-ready report. Over a stable run, the mean is 8.0 days with a standard deviation of 1.0 day. The stakeholder specification is 10 working days, the sprint boundary.

Cpk = (10 - 8.0) / (3 * 1.0) = 0.67

The mean is comfortably inside the requirement, so the process looks fine from the middle. The index says otherwise. A Cpk of 0.67 puts the specification limit exactly two standard deviations above the mean, which means roughly 2.3 percent of studies will breach it. That is about one study in 44, arriving late, forever, with no special cause to find.

The two levers, and their very different payoffs

Move the centre. Get the mean to 7.0 days with the spread unchanged, and the limit sits three standard deviations out: Cpk rises to 1.00 and the breach rate falls to about 0.13 percent.

Reduce the spread. Keep the mean at 8.0 and halve the standard deviation to 0.5 days, and the limit sits four standard deviations out: Cpk rises to 1.33 and the breach rate falls to roughly 32 parts per million.

Both are improvements. They are not remotely the same size. Tightening the spread while leaving the mean alone beat re-centring by a factor of about forty here, which is the opposite of most teams instinct, because the mean is the number that appears in the monthly report and the spread is the one nobody looks at.

What the index translates to in failures

The relationship between capability and defect rate is steeply non linear, which is why small changes in the index matter far more than they look. The NIST/SEMATECH handbook gives the reference table for a centred process:

Read the first two rows together. Going from Cp 1.00 to Cp 1.33 is a 33 percent improvement in the index, and it takes the failure rate from 2,700 parts per million to 64, a reduction of roughly 42 times. The next step, 1.33 to 1.66, is a 25 percent improvement in the index and cuts failures by a further factor of about 107.

These figures are two sided, counting breaches at both limits, which is why the 64 ppm in the table is twice the 32 ppm in the one sided turnaround example at the same index value. Check which one your metric needs before quoting a number at anyone.

The centering penalty

Same spread, different verdict

Cp and Cpk diverge whenever the process is off centre, and the gap between them is diagnostic. Cp asks whether the spread could fit. Cpk asks whether it does fit, where it actually sits.

A process can have an excellent Cp and a poor Cpk: the variation is tightly controlled and aimed at the wrong place. This is a much better problem to have than the reverse, because re-aiming a precise process is usually straightforward while making an imprecise one precise is not. When Cp is high and Cpk is low, the work is a targeting adjustment. When Cp itself is low, no amount of re-centring will help, because the spread cannot fit inside the requirement at any position.

Reading the pair

Always report both. Cpk alone hides which of the two problems you have, and the remedies are completely different. A single number that collapses a targeting problem and a variation problem into the same value will send half the teams that read it in the wrong direction.

The inversion nobody mentions

Raising your standards lowers your capability

Capability is a ratio, and only the denominator belongs to you. Here is what that means in practice.

Take the same team, the same stable process, mean 8.0 days and standard deviation 1.0. Leadership decides the promise should be five working days rather than ten, because a competitor delivers faster. Nothing about how the team works has changed. Not one procedure, not one person, not one tool.

Cpk = (5 - 8.0) / (3 * 1.0) = -1.00

The index went from 0.67 to negative. A negative Cpk means the process mean now sits outside the specification altogether. The team is measurably worse on a metric that moved entirely because someone in another room edited a requirement.

This is the sign inversion that makes capability different from every other process metric: improving the standard makes the number worse. Teams that raise their own bar get punished by their own dashboard, and teams that quietly negotiate the bar downward get rewarded by it.

Who owns the denominator

Follow that to its conclusion and you find the trap. Cpk can be improved without touching the process at all, by widening the specification. The numerator is owned by whoever writes the requirement; the denominator by whoever does the work. When those are different people, the instruction improve our Cpk this quarter has two solutions, and the cheaper one involves no work.

Worse, the index does not record which happened. A Cpk that moved from 0.9 to 1.4 looks identical whether the team halved its variation or the stakeholder relaxed the deadline by three days. Always version the specification alongside the index, and keep both with the study record in Koji or your research repository. A capability figure quoted without the spec it was computed against is not a measurement, it is a claim.

How Koji helps

Capability requires two things most research functions lack: a metric measured consistently enough to have a real standard deviation, and a requirement written as a number. Koji supplies the first and forces the second.

Consistent measurement is the harder half. Because Koji runs AI-moderated interviews and voice interviews to the same brief every time, the variation you measure is variation in the process rather than variation in who happened to moderate that week. Interview quality is scored on a consistent 1 to 5 scale across every session, which turns a subjective judgement into a series you can actually chart and then set a specification against, such as at least 90 percent of sessions at 4 or above.

The six structured question types, open_ended, scale, single_choice, multiple_choice, ranking and yes_no, matter here for a specific reason. Closed types produce values with defined ranges, which is what a specification limit needs to exist at all. You cannot write a spec limit against an open text field, but you can write one against a scale response or a yes_no proportion, and then ask whether your process is capable of meeting it.

Because Koji handles transcription and thematic analysis automatically and delivers real-time reporting, turnaround time stops being dominated by the queue in front of a human analyst, which is usually the single largest contributor to the spread. That is the variation reduction lever from the worked example, and it is the one worth about forty times the re-centring lever. Customizable AI consultants keep the analysis step consistent between studies, which protects the standard deviation you just worked to shrink. Traditional tools optimise the collection stage and leave the analysis queue untouched, which is precisely where research turnaround variation lives.

Common mistakes

Computing capability on an unstable process. The number describes a distribution that will not be there next month. Establish control first.

Plotting specification limits on a control chart. It invites tampering with a stable process, which increases variation.

Reporting Cpk without Cp. The gap between them tells you whether you have a targeting problem or a variation problem, and the fixes are unrelated.

Quoting a capability index without the specification it was computed against. The number is meaningless without its denominator, and it can be moved by editing the requirement.

Hunting for root causes of individual breaches in a stable, incapable process. There is no special cause. The process is meeting its design; the design does not meet the requirement.

Mixing one sided and two sided figures. A one sided metric at Cpk 1.33 fails at about 32 ppm, not the 64 ppm in the centred two sided table. Confirm which convention applies to the series you pulled from Koji before quoting the figure to a stakeholder.

Frequently asked questions

What is process capability?

Process capability compares the output of a stable process against the specification limits it is required to meet, using indices such as Cp and Cpk. It answers whether the process is good enough, which is a different question from whether it is predictable. A process can be entirely stable and still miss its requirement consistently.

What is the difference between control limits and specification limits?

Control limits are calculated from the process data and describe what the process actually does, often called the voice of the process. Specification limits are set by a customer or stakeholder and describe what is required, the voice of the customer. Control limits cannot be chosen and specification limits cannot be computed.

What is the difference between Cp and Cpk?

Cp measures whether the process spread would fit within the specification range, ignoring where the process is centred. Cpk accounts for centring by measuring the distance from the process mean to the nearer specification limit. When Cp is high and Cpk is low, the process is precise but aimed wrongly, which is a targeting problem rather than a variation problem.

What is a good Cpk value for a research metric?

The NIST reference table gives 1.33 as the common benchmark, corresponding to about 64 parts per million outside the limits for a centred two sided metric. Below 1.00 the process will breach its requirement routinely. Rather than adopting a manufacturing threshold uncritically, translate the index into a failure rate and ask whether that rate is acceptable to the stakeholder who set the specification.

Can I compute capability if my process is not in statistical control?

No, and the NIST handbook is explicit that capability compares the output of an in-control process to the specification limits. An unstable process has no single stable distribution, so its standard deviation does not describe future behaviour and any index built on it will not predict anything. Establish stability first.

Why did our capability score drop when we improved our standards?

Because capability is a ratio in which the specification is the numerator and your process is the denominator. Tightening a specification lowers the index even when nothing about the work has changed. This is why a capability figure should always be reported alongside the version of the specification it was computed against, otherwise improvements and renegotiations look identical in the record.

Related Resources

• Structured Questions in AI Interviews - the six question types, and why closed types are what make a specification limit possible
• Common Cause vs Special Cause in Research Metrics - establishing stability, which must come before any capability calculation
• Alarm Flooding in Research Alerting - how to alert on a limit crossing without drowning the recipient
• Survey Data Quality Guide - the data quality metrics most worth setting specification limits against
• Regression to the Mean in Research - why an extreme measurement tends to move back on its own
• Research Intake Process Guide - where turnaround time specifications get agreed in the first place