Measure it before you touch it

What a baseline has to contain

Four things, measured over at least a week of normal operation:

• Volume — how often the process actually runs, not how often people think it does.
• Time — per instance, wall-clock, including the waiting.
• Error rate — how often the current human process gets it wrong. This is the number nobody wants to collect and the one that stops you claiming a false improvement later.
• Cost — loaded, per instance.

Collect them without announcing what you are planning. Not to be secretive, but because a measured process changes when people know why it is being measured, and you want the ordinary version.

Before you touch somebody else's work

This capstone runs inside a real process that real people depend on. That carries obligations a personal project does not.

Run the baseline week

Instrument the existing process and let it run. Change nothing. Record all four numbers per instance.

While it runs, write the success condition — a specific, numeric statement of what would make this worth having done, agreed with the process owner before either of you knows the answer. "Faster" is not a success condition. "Median handling time under four minutes with an error rate no worse than today" is.

Baseline handling time

Median wall-clock time per instance across the baseline week. Median rather than mean, because one pathological case should not set your target.

Baseline error rate

How often the current process produces a wrong result, as a percentage. If nobody has ever measured this, you have already delivered something valuable and you have not built anything yet.

Publish the baseline and the success condition

Both, together, dated, before you write any code. This is the single most portfolio-valuable artefact in the catalogue, because almost nobody has one.