standardize before you improve, or you are just guessing

Everyone wants to improve their processes, and the instinct when a process is not performing is to start changing things. Try a new method, adjust a parameter, implement an idea. It feels like progress, and it is usually premature, because there is a precondition for improvement that most people skip. You cannot meaningfully improve a process that is not standardized, and jumping to change before you have a standard is not improvement, it is guessing, because without a stable baseline you have no way to tell whether your change helped, hurt, or did nothing at all.

improvement needs a baseline

The reason is straightforward once stated. To know whether a change improved a process, you have to compare the process after the change to the process before it, and that comparison only means something if the before was stable and known. If the process was varying wildly on its own, running differently depending on who was doing it and when, then you have no reliable before to compare against. You make a change, the result looks different, and you cannot tell whether your change caused the difference or whether the process just swung on its own the way it always does. Without a standard, every improvement is unmeasurable, and an unmeasurable improvement is indistinguishable from noise.

unstandardized work hides its own problems

A process that is not standardized also hides the very problems you would want to improve. When everyone does the job a little differently, the variation from those differences masks the variation from the process itself, and you cannot see clearly what is actually wrong. The problems are tangled up with the inconsistency of how the work is done, so you are trying to improve something whose actual behavior you cannot even observe, because it never behaves the same way twice. Standardizing the work is what makes the process's real problems visible, by removing the noise of inconsistent methods and leaving only the process itself to examine. You cannot fix what you cannot see, and inconsistent work keeps the real issues hidden.

the standard is the memory of improvement

There is a further reason standardization comes first, which is that it is how improvement gets held. When you do improve a process, the standard is what captures the improvement and keeps it from eroding. Without a standard, an improvement lasts only as long as people happen to remember to do it the new way, which is not long, and the process drifts back toward its old behavior. The standard is the memory of every improvement you have made, the thing that locks each gain in place so the next improvement builds on it rather than replacing ground you already won and lost. A process without standards cannot accumulate improvement, because it has nothing to hold the improvements in.

why we skip it anyway

Standardization gets skipped because it is unglamorous and feels like a delay. When a process is performing poorly, there is pressure to do something visible about it now, and standardizing the current method, which does not itself improve anything, feels like wasting time on paperwork when you could be fixing the problem. So teams jump to changes, get ambiguous results they cannot interpret, and churn through improvement efforts that never quite stick, all because they skipped the boring foundational step that would have let them actually measure whether anything worked. The urgency to improve is precisely what causes people to skip the thing that makes improvement possible.

stabilize, then improve

The disciplined sequence is to standardize first, get everyone doing the process the same documented way, achieve a stable and known baseline, and only then begin to improve, changing one thing at a time against that stable reference so you can actually see what each change does. This is slower to start and far more effective over time, because every change you make is now measurable and every gain you achieve is now held. It is the difference between improvement that compounds and change that churns. The foundation is not optional, and building on its absence is why so much improvement effort produces so little lasting result.

If your team is trying to improve a process that everyone runs a little differently, how would you actually know whether your next change helped, and if you cannot answer that, is it improvement or just guessing?