Describe Today Before You Transform It: A DevOps Baseline

Organisations hire consultants to change how software reaches customers, and the contract usually describes the future state in generous detail. It rarely describes the present state with the same care. That imbalance is why so many digital transformation programmes end with a celebration nobody can substantiate. Here, in everyday language, is what it means to record a starting position before a DevOps consulting engagement begins, and why doing so protects the client, the consultant and the budget alike.

The problem in one sentence

If you cannot describe how things work today in terms you can later re-measure, you cannot claim that anything improved. Gains only exist relative to something, so you need a recorded ‘something’ to measure them against.

Consider a company that says its releases are slow. Slow compared with what? Last year? A competitor? A feeling in the leadership team? Until the current process is written down, “slow” is a mood, not a finding, and a transformation aimed at a mood tends to drift.

What a starting position looks like

Think of it as three plain descriptions, each captured in ordinary language and ordinary numbers.

1. The route. Trace one real change from the moment someone asks for it to the moment customers can use it. List each handover, approval and waiting period you actually find, not the ones the process diagram shows.
2. The elapsed time. Record how long that route takes on several recent changes, small and large, and how much of the time is waiting rather than working.
3. The spend and the pain. Note what the current arrangement costs in licences, infrastructure and staff effort, and capture the themes people raise when asked what frustrates them.

Notice what is absent: targets. A baseline is deliberately descriptive. Goals come afterwards, and they are much more credible when they are set against recorded reality.

Why consultants should want this too

It may seem that a consultant benefits from vagueness, since vague starting points make any result look like progress. In practice the opposite holds. Engagements that begin with a shared before picture are easier to scope, easier to defend and far less likely to end in a dispute about what was delivered. The guide to taking an engagement from its opening assessment to the handover of skills frames the early phase as discovery; a recorded baseline is simply the written output of that discovery.

Where programmes go wrong without one

Three failure patterns recur.

• Retrofitted evidence. After the work, someone assembles numbers that flatter the outcome, using whatever data happens to be available. Because no earlier numbers exist, nobody can challenge them.
• Disputed credit. Releases get faster, but a separate hiring push and a quiet quarter also happened. Without a baseline, no one can separate the effects.
• Invisible regression. Some things get worse during a transformation, perhaps support workload or manual rework. If you did not record those, you will not notice.

Applying it to a cloud migration

Migration projects illustrate the point well. The material on how consultants shape a move to the cloud covers what advisers contribute technically. Before any of that begins, record how the existing environment behaves: how long a standard deployment takes, how often environments are rebuilt by hand, and what the infrastructure bill looks like in a normal month. Once workloads move, you can place the new figures beside the old ones and see what the programme changed rather than what you hoped it would.

Applying it to testing and quality

Quality work benefits in the same way. The discussion of how consultants raise quality and delivery speed through automated testing assumes a team will measure its progress. A baseline gives that assumption substance: note how long a regression cycle takes today, how many defects customers report after a release, and how many hours people spend on repeated manual checks.

A comparison from another field

The principle is not unique to technology. People organising complex services across borders face it too. BestEyeHospitals, an online guide for people arranging eye care in another country, structures its material around country pages and a stepwise enquiry, and its disclaimer tells readers the content is general information, to be checked with providers and never a reason to postpone care. Whatever the field, careful planners begin by recording what they already have, so they can tell later what changed.

How much effort does this take?

People tend to assume a baseline needs a data platform. It does not. A shared spreadsheet and a couple of hours of structured conversation will beat an elaborate tool that nobody fills in.

Less than most people expect. For a mid-sized team, capturing a starting position usually means a few interviews, a sample of recent changes traced from request to release, and an export of cost data. Allocate it as a named task inside the engagement, with an owner and a place in the plan, rather than hoping someone does it on the side.

Reading the results honestly

When the engagement ends, repeat the same three descriptions using the same method. Resist changing the questions. Then set the two records side by side and write a short commentary: what moved, what did not, what got worse and what you cannot attribute to the programme. A record that admits uncertainty is far more persuasive to a sceptical finance director than one claiming every gain.

Summary

A transformation is a claim about change, and claims need evidence on both ends. Describe the route a change takes today, time it, count what it costs and write down what frustrates people. Then keep that document safe until the work is done. It will be the most useful page in the whole engagement, because it is the only one that cannot be written afterwards.

Kabir Malhotra