How three checks can turn a faster step into a faster business

ISO published the sixth edition of ISO 9001 on 16 September 2026, and more than one million ISO 9001 certificates in 189 countries now face a transition (ISO, 2026). Each transition reopens the quality management system, and the review usually ends with a list of improvement projects. Some of those projects will make the business slower.

In technical businesses of 10 to 250 people specifically, a Technical Leader approves most of these projects, often with a small team and little spare time. A step gets faster and its local numbers look good, then three months later lead time has grown or the cost has moved to another department.

This article argues that the step you improve matters less than where its displaced work lands. It sets out three checks to run before a project starts, covering the constraint, the buffers and the know-how at the step, with a five-question scorecard to finish. It belongs to our operational excellence series on process improvement.

Improvement that backfires is a planning issue

Improvement that backfires is a planning issue, because the damage is decided when someone chooses which step to measure. UK survey data shows the gap: businesses score far higher on responding to problems than on tracking the indicators that would reveal a moved cost (Exhibit 1).

• Local measures. The project is judged on the step it changed, so a cost that appears in purchasing or freight stays outside the project report.
• Buffers treated as waste. Stock, time and spare capacity get cut before anyone measures the variation they absorb.
• Procedures written from the document. Standard work is drafted from the old procedure, while the judgement that handled exceptions stays with one person.

In summary, each driver measures the improved step while the bill arrives later, in another department. Each one can be caught before approval.

Why does the constraint decide whether an improvement helps?

The constraint decides because the whole flow moves at the pace of its slowest step, so extra output from any other step waits in front of it. Production research shows that buffers between stations dampen fluctuations, while the bottleneck itself can shift as processing times vary (Müller, Wenzel and Windisch, 2025).

A 2026 software study shows this at scale. Per-reviewer load roughly doubled at a company whose engineers reached 2.09 times their baseline of merged pull requests (He et al., arXiv, 2026). Throughput rose and merge and revert rates held steady, while automated review overtook human review. The work had moved downstream, and the company changed how review was done to absorb it.

What goes wrong when one step gets faster?

When one step gets faster, its gain is reported where the change was made and its cost arrives somewhere else, often weeks later. We call this the downstream invoice: the bill for an improvement, sent to a department outside the project plan.

The cost lands in other people’s numbers. A study of 33,596 pull requests written by AI agents found that 61.38% had no recorded review, although the authors warn that silent approvals are invisible in the data (Duma et al., arXiv, 2026). Review activity still looked healthy on a dashboard, yet the form of oversight had changed in ways the usual metrics miss.

A wider lane before a narrow bridge: why local speed backs up the flow

Imagine widening one lane of a road just before a single-lane bridge. Cars reach the bridge sooner and the queue in front of it grows, while travel times across the river stay the same.

Measured lane by lane, the project worked. Everyone’s arrival time is still set by the bridge, which is where a Technical Leader should look first.

Three actions for technical leaders to protect the whole flow

Constraint check — locating the limiting step before choosing what to improve

Before approving a project, name the step that limits end-to-end output, using data from a full operating cycle: a year or fiscal year where demand is seasonal, three months only where the operation is stable all year. Improving any other step pushes more work toward that constraint, so the project plan must say what happens there. The aim is better performance with fewer activities, so the answer should simplify the flow and remove steps where it can.

Buffer check — sizing buffers against measured variation before removing them

Treat every buffer as a decision about variation. Before cutting stock, time or spare capacity, measure the lower and upper limits of the activities it protects, such as order frequency and supplier lead time. Removing a buffer pays off when that variation has fallen too; while it stays the same, the cost moves to the next department.

Know-how check — mapping who holds the judgement before standardising a step

Decide what the procedure is for, then set its detail: document the 20% of scenarios that cover around 80% of volume and route the rest to a supervisor or line manager. Define what counts as an exception, with limits and an expected frequency, because exceptions that repeat without a definition become the process. Economic modelling suggests the stakes rise with automation, since less experienced staff can lose skill when output depends less on their judgement (Caosun and Aral, arXiv, 2026).

How ready is your business for its next improvement project?

Your readiness shows in five questions. Score each one 0, 1 or 2, add the scores, then read the band underneath.

Question	0	1	2
Have you located the step that limits end-to-end output, using a full operating cycle of data?	No	Partly	Yes, documented
Have you estimated where the work this change removes or creates will land, and what it will cost there?	No	Partly	Yes, documented
Does each activity you plan to change have measured lower and upper limits from before the change?	No	Partly	Yes, documented
Has the business defined what counts as an exception at this step, with limits and expected frequency?	No	Partly	Yes, documented
Have you set how long you will track the new process until the team uses it consistently?	No	Partly	Yes, documented

0–3: Pause and run the constraint check first, because the downstream invoice risk is high. 4–7: Run a pilot on one team or line and track the end-to-end measures you named. 8–10: Proceed, and review the end-to-end result on the date you set for stabilisation.

What to do next

This method stops working when the constraint sits outside the business, in customer demand or a supplier’s capacity, because moving work internally leaves its pace unchanged. It also needs a full cycle of data, so a new process calls for a small pilot whose results become the baseline.

The step you improve matters less than where its displaced work lands, so look downstream before you approve. This week, take your next planned project and answer the first scorecard question with a full cycle of data.