Proving an improvement was real: baselines, freed time and savings that never arrive

State what should move, and record it, before touching the process

The measurement argument always happens afterwards, when memories differ and the baseline period gets chosen to flatter. Deciding in advance which measure should move, over what period, on which product family and under what conditions removes most of that argument. It also disciplines the work, because teams asked to nominate the measure sometimes discover that the change they proposed would not move anything anybody cares about. Capture the baseline as a run of data rather than a single period, so normal variation is visible and any later movement can be judged against it.

Freed hours are not money until something takes them

A method improvement that removes effort from a task creates available time, distributed in fragments across shifts and people. It becomes a saving only if those fragments are consolidated into fewer people, redeployed to work that would otherwise have required recruitment, or converted into output the business can sell. Where none of those happens, the time is absorbed and the cost base is unchanged, whatever the calculation says. Saying so plainly protects the programme's credibility, and it forces the question of what the released capacity is for, which managers generally prefer to defer.

Local gains that never reach the accounts

A department can reduce its cost per unit by running longer batches, improve its utilisation by making stock, or hit a scrap target by reworking instead of scrapping. Each looks like an improvement locally and none of them helps the business. The check is to look one level up: did work in progress fall, did delivery improve, did the plant despatch more with the same resources, did total cost move. Where a claimed benefit cannot be traced to something the business experiences, treat it as a local effect and say so, however unpopular that makes you.

Baselines move underneath you

Mix changes, volume changes, a new product, a price change, seasonality, a customer leaving, a machine replaced for unrelated reasons. Any of these can move a measure further than the improvement did, and attributing the whole movement to the project is the standard error, usually made without intent. Where possible, compare against something that did not change, such as another line, another shift, or the same line running products outside the project scope. Where that is impossible, state the assumptions and confounding factors alongside the claim rather than presenting one confident figure.

Counting activity because results are harder

Programme reporting drifts towards events run, people trained, suggestions submitted, boards installed and audits completed, because those can be counted reliably and rise steadily. They describe effort rather than effect. A programme whose reporting consists entirely of activity counts has usually lost the thread, and it is vulnerable the moment finance asks what changed. A small set of process outcomes, such as elapsed time along a defined route, unplanned stops on named equipment, or defects escaping a given process, carries far more weight even though each moves slowly and sometimes in the wrong direction.

Frequently asked questions

How do we tell a genuine improvement from normal variation?

Look at the measure as a run of data before and after rather than as two points. Normal processes vary considerably between periods, and one good period following a change proves nothing at all. What convinces is a shift in the level that persists, or a reduction in the spread, sustained beyond the window when everybody was paying attention. If the measure returns to its previous range once the team moves on, the improvement was in the attention rather than in the process.

Should improvement projects claim financial savings at all?

Only where the money can be traced to a line somebody is accountable for, and it helps to have finance agree the method before the programme starts rather than challenge each claim afterwards. Cost avoidance, freed fragments of time and notional capacity gains are legitimate to describe but should not be totalled as though they were cash. Programmes that inflate benefits win the first review and lose the argument permanently the first time anyone reconciles the total against the accounts.

What should actually go on an improvement board in an area?

The measures the team can influence within the shift and the problems currently being worked on, not the programme's benefit total. Typically that means plan against actual for the period, what stopped, the open problems with owners, and the current target condition if the area is running an improvement routine. Anything the team cannot affect belongs elsewhere, since a board full of measures owned by other departments teaches people to ignore the board entirely.