The symptom is familiar. A team spends a quarter on improvements, the release process feels better, and then a manager asks for proof. People point at graphs that only start after the work was finished. Opinions fly, nobody can settle them, and the next budget conversation goes badly. This is a diagnosis piece: how to recognise the missing-baseline problem, what causes it, and the fix that costs the least.
The symptoms of a missing baseline
You can usually spot it from the way the team talks. Phrases such as “it seems faster” or “I’m fairly sure that used to take longer” are the giveaway. Other signs include dashboards that begin on the day the new tool went live, post-project reviews that argue about what the old setup was like, and improvements that are described only with adjectives. If three of those sound familiar, your problem is not the tooling. It is that the starting point was never recorded.
Root cause: the old state disappears quickly
Why does this happen so often? Because the moment a change goes live, the old way of working starts to vanish. Scripts are replaced, configurations overwritten, habits shift. Rebuilding an accurate copy of “before” later is expensive, and sometimes impossible. Meanwhile the incentive to measure is lowest at the beginning, when everyone is eager to get on with the interesting part. The cost of skipping the baseline appears only months afterwards, when it can no longer be paid.
Second cause: no agreed target
Teams also skip baselines because they have not decided what they want to improve. If the aim is “make operations better”, there is nothing specific to measure, so nothing gets measured. Narrow the aim first. Maybe you want to shorten the time from a finished change to a running release, cut the effort of handling a routine ticket, or reduce the cost of keeping an environment alive. Pick one or two, and the baseline practically writes itself.
The fix: a one-page starting record
Here is the smallest remedy that works. Before changing the process, produce a single page that contains:
- A step-by-step description of the process as it runs today, warts included.
- Timings for each stage, captured several times, with the observed spread.
- The running cost, covering licences, infrastructure and the hours people spend on the routine.
- Recurring complaints from users or colleagues, grouped into themes.
- The date, the people involved and how the measurements were taken.
Store it as read-only. Corrections are added underneath with their own dates, never made in place.
Check the fix against a real case
Consider a team that wants quicker recovery when something breaks. Reading about speeding up resolution of IT problems with newer platforms may inspire a purchase, but a purchase decision without a before-picture is guesswork. The team first records how incidents are handled today, who gets contacted, what the typical waiting stretches look like and which steps repeat. Only then do they try the new approach, using the same recording method. The comparison that follows is dull in the best possible way: it shows what moved and what did not.
Common failure modes of the fix
Even a good remedy can be applied badly. Watch for these:
- Taking the baseline late. If a few quick fixes have already gone in, you have moved the starting line.
- Measuring once. A single run cannot show normal variation, so you cannot judge a small change.
- Altering the method between rounds. A different data size or a different time of day makes the comparison unfair.
- Changing many things together. You will not know which change deserves the credit.
- Only reporting wins. A trustworthy record includes the experiments that showed nothing.
A helpful aside from outside engineering
The same logic applies when someone plans an involved arrangement that crosses borders. BestEyeHospitals presents itself as a directory and planning resource for overseas patients exploring eye care, and its medical disclaimer, which the site writes itself, frames its pages as general reading rather than professional medical advice. One of its FAQ entries also points out that domestic insurance often stops short of elective treatment abroad. Notes like these are a planner’s version of a baseline: they mark the boundaries before any comparing starts.
Extending the fix to machine learning work
Teams working with data models face the same issue in an acute form, because performance drifts and environments change. A piece on getting machine learning releases out faster covers the delivery side. Add a baseline to that effort: record how long a deployment takes today, how often it needs rework and what the surrounding manual effort costs. When the new routine is in place, the before-and-after comparison becomes straightforward.
How to roll the habit out without a fuss
- Add “capture baseline” as the first line of every improvement ticket, with an owner’s name.
- Give the record a standard home so people know where to look.
- Keep the template to one page, otherwise it will be skipped.
- At the review, show the baseline before showing the results.
This last point matters more than it seems. When the review opens with the before-picture, the discussion becomes about evidence. When it opens with the results alone, it becomes about opinions.
What success looks like
The problem is solved when nobody argues about what the old process was like, because the page exists and everyone has read it. Improvements are described through comparisons instead of adjectives, and the occasional verdict of “that did not help” lands calmly instead of defensively. The price is a single page and a few readings, taken before the exciting work begins. Of all the habits a technical team can adopt, it is among the cheapest, and almost certainly the one skipped most often by busy people under deadline pressure.