đ¯ Quick Answer
What: A baseline is the honest, measured starting state of a process, captured before you change anything, the same way you will measure it again afterward.
Why it matters: Without a baseline you cannot prove an improvement worked. The win lives only in people's memory, and memory does not survive a budget review.
How to apply: Before you touch the process, capture the key metrics with their spread, agree on the definitions up front, and write them down. Measure the "after" exactly the same way.
The payoff: Improvements that were baselined hold up for years. Improvements that were not get re-argued every time someone asks for evidence.
"We fixed it." It is the most satisfying sentence in operations, and the easiest one to say without proof.
A team drives down a cycle time, smooths a process, clears a backlog, and the room agrees it is better. Better than what, though? Most of the time, no one wrote down where they started. The improvement is real in the room and invisible on paper.
I have watched this play out in three industries that have never once compared notes, and the pattern is identical. The work gets done, the change feels good, and then, months later, someone senior asks the only question that matters in a review: compared to what? And the answer is a shrug dressed up as a story.
A baseline is what separates a result from a story
A baseline is the unglamorous habit that turns "it feels better" into "here is how much." Before you change anything, you capture the honest starting state: the cycle time, the defect rate, the cost, measured the way you will measure it again later. Not a tidy average pulled from one good week, but the real picture, including its spread.
It feels like delay. You can see the fix from here, the team is keen, and stopping to measure the thing you are about to change feels like bureaucracy. It is not. It is the only thing that will later let you prove the change did what you think it did.
I keep coming back to a simple image. A parent marks a child's height on the doorframe and writes the date. Years later, the whole story of a childhood is right there in a ladder of little lines. Nobody measured anything fancy. They just marked the wall before time did its work. Operations forgets to mark the wall constantly.
Why unbaselined wins evaporate
Here is the uncomfortable part. The quality of the work is not what decides whether an improvement survives. The baseline is.
I have watched genuinely good improvements get quietly killed in a budget review because no one could show the before. And I have watched mediocre ones survive, and even get funded further, because someone had the discipline to capture a starting number. The teams that can defend their results are not smarter. They are the ones who marked the wall before they started.
This is also why a baseline has to be honest, and agreed up front. A "baseline" that gets negotiated after the result is just the number that makes the result look best. The before-photo and the after-photo have to be taken the same way, with the same definition, the same sample, the same lens. Otherwise the comparison is theater. If you have ever wrestled with what to measure and how, this is where a clear data collection plan earns its keep, and where a real number on the cost of poor quality finally gives a problem the weight it deserves.
How to take a baseline that holds up
Keep it boring and it will keep its value:
Decide what the project is actually about, and pick the few metrics that capture it. Two or three honest numbers beat ten vanity ones.
Define each one in a sentence anyone could apply the same way. "Cycle time" means nothing until you say from when, to when.
Capture the spread, not just the average. A single number with no range hides exactly the variation you are trying to fix.
Write it down and have the team agree to it before you change anything.
When you measure the after, measure it identically. Same definition, same method, same lens.
If you do that, then six months later, when someone asks whether the project worked, the answer is not a story. It is two pictures, taken the same way, side by side.
If field notes like this are useful to you, I write more of them, and share the tools I build, in my newsletter.
Frequently asked questions
What is a baseline in process improvement?
A baseline is the measured starting state of a process, captured before you make any changes, using the same definitions and method you will use to measure the result later. It is the "before" that makes a later "after" mean something.
Why is a baseline so important in the Measure phase?
The Measure phase exists to establish where you really stand before you try to improve. Without that honest before-state, any later claim of improvement is unprovable, and unprovable improvements tend not to survive scrutiny or funding decisions.
How do I take a good baseline?
Pick the few metrics that genuinely describe the problem, define each one precisely, capture the spread and not just an average, write it down, and get the team to agree to it up front. Then measure the result exactly the same way.
What happens if I skip the baseline?
You end up with improvements you believe in but cannot prove. They feel real in the room and disappear the moment someone asks for before-and-after evidence, which usually happens right when budgets tighten.
Is an average enough for a baseline?
No. A single average hides the variation that is often the real problem. A baseline should capture the range, not just the center, so the comparison later is honest about consistency as well as level.
Without a baseline, improvement is a story you tell. With one, it is a result you can show.









