Establish the baseline before promising an improvement

“Make order entry faster” sounds straightforward until the team tries to measure it. Does the task begin when someone opens the form, when the request reaches their queue, or when the missing information arrives? Does it end when the record saves or when another system accepts it? What happens to orders requiring correction?

Each definition describes something different. Choosing whichever one produces the most pleasing result makes a pilot difficult to trust.

Before promising an improvement, understand the current workflow well enough to make a comparison that means something.

Watch a complete task

Begin with the people doing the work. Observe representative tasks with their permission and appropriate care for any information involved. Trace the task across handoffs, systems, waiting periods, corrections, and interruptions. Ask where the person must remember something the software does not preserve.

Record the boundary of the workflow being investigated. A form might become quicker while the next team receives less complete information. If the intended outcome concerns the whole order-entry process, moving effort beyond the measurement boundary does not fulfill it.

Separate observations from explanations. “The operator copied an identifier between systems” describes what happened. “The second system should be removed” proposes a response. Keeping those apart leaves room to discover why the second system exists and what else depends on it.

Make a modest measurement agreement

A useful baseline describes the work, the conditions under which it was observed, and its important variation. It does not need a dashboard full of numbers.

For an order-entry pilot, the agreement might cover elapsed task time, repeated data entry, incomplete or incorrect records, and the operator’s ability to identify the next action. Some information may be counted; some may be documented through observation or conversation. Explain what each measure helps the team decide.

Choose representative cases deliberately. Common orders matter, but so do relevant differences in permissions, input quality, accessibility needs, and dependencies. If uncommon exceptions are excluded from the first bet, describe how the pilot will recognize and route them.

Be candid about the size and limits of the observation. A limited baseline can guide a bounded experiment without supporting a broad claim about every user or situation.

Set conditions before targets

Some requirements are operating boundaries rather than improvement goals. Permissions must be respected. Required business behavior must remain correct. A failure needs a detectable state and a credible recovery path. These conditions should not disappear because the revised workflow is faster.

Once the baseline is understood, discuss what improvement would be useful enough to justify the remaining investment and continuing ownership. That judgment can include maintenance effort, support burden, and the significance of the problem for affected people.

Avoid picking a percentage because it looks decisive on a slide. If the available evidence cannot support a numerical target, state the question the pilot will answer and how the crew will judge the result. Precision in wording cannot manufacture precision in knowledge.

Compare with attention to context

Pilot use often differs from ordinary use. Participants may have extra support, unusual familiarity with the task, or access to the people building the change. The incoming work may differ from the baseline period. Record these differences instead of treating every before-and-after comparison as a complete explanation.

Examine individual failures and awkward cases alongside aggregate results. A shorter average can conceal a workflow that is considerably harder for some people. A task that appears complete may still create duplicate records downstream.

Ask whether the evidence is strong enough for the next decision, not whether it proves the entire program was right. A narrow pilot may justify another narrow step. It may expose a problem that deserves investigation before any expansion.

Write the review as a decision record: what was observed, which conditions were met, what remains uncertain, and what happens next. Include responsibility for unresolved defects and the conditions for closing the pilot.

The practical starting point is small. Choose one real workflow. Define its beginning and end. Observe how it behaves before changing it. The resulting understanding is useful even if the most sensible decision is to leave the software alone and fix a handoff instead.