How to Compare Process Improvements Against a Baseline

A team proposing a process change will often present it with a single confident number: this will cut cycle time by two days, or this will save forty hours a week. The number sounds precise, but precise is not the same as trustworthy. The question a decision maker should always ask next is: two days less than what, exactly, and measured how? Without a clearly defined and fixed starting point, that two-day figure could be based on a best guess, a single observed case, or an average pulled from a period that happened to be unusually slow. Comparing a proposed change to a moving or poorly defined target is how organizations end up disappointed by results that technically match what was promised.

Why the baseline has to be locked before alternatives are evaluated

A baseline is a documented, fixed representation of how a process performs today, built from a specific and stated set of assumptions about case volume, case mix, and effort at each step. Locking it means that once it is agreed, it does not quietly shift while different improvement ideas are being evaluated against it. If the baseline changes each time someone tweaks an assumption, every comparison made against it becomes unreliable, because nobody can be sure whether a scenario looks better because the idea is genuinely stronger or because the baseline itself moved underneath it.

This matters more than it sounds. In practice, teams frequently discover new information partway through an evaluation, a step turns out to take longer than first estimated, or a case type that seemed rare turns out to be common, and the temptation is to fold that new information into the baseline immediately. The better discipline is to finish evaluating the current round of scenarios against the baseline as agreed, note the new information, and then deliberately re-baseline as a separate, visible step if the new information genuinely changes the starting picture. That way, everyone always knows which version of the baseline any given comparison is measured against.

What a defensible baseline actually contains

A baseline worth comparing against needs more than a single average cycle time figure. It needs to reflect a realistic mix of cases, not just the typical or best-case path, because a process that looks fine on its most common path can still have a small but troublesome share of cases that take far longer or require far more rework. It needs stated assumptions about volume and effort at each step, so that anyone reviewing the baseline later can see exactly what it is built on rather than trusting it blindly. And it needs more than one performance figure: cycle time at both a typical and a worst-case percentile, throughput, utilization at each step, and an indication of where the process bottleneck currently sits.

• A realistic mix of case types and volumes, not just the average or most common path
• Stated assumptions about effort, timing, and routing at each step
• Cycle time at a typical percentile and a worst-case percentile, not a single average
• Throughput and utilization at each step in the process
• A clear indication of where the current bottleneck sits

Evaluating scenarios fairly against that fixed point

Once the baseline is locked, each proposed improvement should be modeled as a distinct scenario using the same underlying volume and case mix assumptions as the baseline, changing only the specific elements the proposal actually alters. If a proposal removes a validation step, the scenario should keep everything else identical to the baseline and change only that step, so that any difference in the result can be attributed to that specific change rather than to some other assumption having quietly shifted at the same time. Evaluating several proposals this way, each as its own scenario against the same fixed baseline, makes it possible to compare them honestly against each other, not just against the status quo.

This discipline also protects against a common bias where the scenario a team is emotionally invested in gets modeled generously, with optimistic assumptions, while alternatives get modeled more conservatively. Using one shared baseline and one shared set of volume assumptions for every scenario removes most of that room for the comparison to be tilted, intentionally or not.

Presenting the comparison so a decision maker can trust it

The way a comparison is presented matters almost as much as the modeling behind it. A single headline number invites the question of what it is being compared to, and if that question cannot be answered clearly and immediately, the number will not survive serious scrutiny. A side-by-side view showing the baseline and each scenario together, across the same set of metrics, cycle time at more than one percentile, throughput, utilization, bottleneck location, and estimated labor or value impact, gives a decision maker something they can interrogate rather than something they have to take on faith.

A comparison laid out this way also makes it obvious when a proposal only helps one dimension, moving cycle time but leaving throughput or the bottleneck untouched, which is exactly the kind of nuance that a single confident number would have hidden. It gives the decision maker the ability to weigh trade-offs deliberately rather than accept a summary claim at face value.

Common mistakes that undermine a comparison

How Processfix supports this

Processfix locks a baseline of the current process using discrete-event Monte Carlo simulation across hundreds of cases, built from the volume, mix, and effort assumptions a team confirms. Improve and Add AI scenarios are then modeled against that same locked baseline, changing only the specific elements each scenario proposes, and compared side by side on P50 and P90 cycle time, throughput, utilization, bottleneck location, and estimated labor and value impact. The comparison, along with the assumptions behind it, can be exported as a documented PDD in Word, PDF, or Markdown, so the basis for a decision is visible and can be reviewed by anyone who was not in the room when it was made.