From Data Platform to Business Value: Why the Real Work Begins After Go-Live
A data programme is a change programme wearing an engineering costume, and change is not finished when the software is.
The Celebration That Comes Too Early
There is a familiar moment in a bank’s data programme. The platform goes live. The migration completes, the pipelines run green, the dashboards render, and the programme holds its closedown. People are thanked, the budget is reconciled, the steering committee records a success. And then, over the months that follow, a quieter and more uncomfortable truth emerges: very little about how the bank actually makes decisions has changed.
The platform works. The value has not arrived.
I have seen this pattern often enough to regard it as the central risk of data transformation, and it is not a technical risk. The engineering is frequently the most successful part of the whole endeavour. The failure sits in the space between a working platform and a changed business — a space we consistently underestimate, under-resource and under-govern, because we have quietly assumed that go-live is the finish line.
A data platform is not the product. It is the factory. Shipping the factory and calling it the product is how a bank spends heavily and changes nothing.
Why Go-Live Feels Like the End — and Isn’t
Go-live feels like the end because everything the programme was structured to deliver has been delivered. The plan, the budget, the milestones, the acceptance criteria — all of them point at the technology. The programme is measured on whether the platform exists and functions, so when it exists and functions, the programme has, by its own definition, succeeded.
But the business case was never really about the platform. Nobody funds a data platform because they want a data platform. They fund it because they want better credit decisions, faster and more accurate client reporting, lower operational cost, cleaner regulatory submissions, and management information they can actually trust. Those outcomes do not switch on at go-live. They depend on people changing how they work, and that change has barely begun on the day the technology is declared complete.
The result is a programme that has optimised for the wrong finish line. It sprints to go-live, then disbands the very capability — the funding, the attention, the senior ownership — that the outcomes actually require, at precisely the moment they begin to require it.
The Gaps That Destroy the Value
When value fails to materialise after go-live, it is rarely one dramatic failure. It is the accumulation of several gaps, each individually survivable, together fatal.
- Adoption. The platform exists, but the frontline still runs on the old spreadsheets, the private extracts, the trusted local file that predates the programme. If people do not use the new source, the new source creates no value, however elegant it is.
- Ownership. No one in the business owns the data as a business asset. Engineering owns the pipes; nobody owns the meaning, the definitions, the fitness of the data for a decision. Ownerless data decays.
- Data quality. Quality that was ‘good enough to migrate’ is not the same as quality good enough to bet a client relationship or a credit decision on. The gap between those two standards is where trust quietly dies.
- Decision rights. It is unclear who is allowed to change a definition, resolve a dispute between two versions of a number, or say authoritatively what the figure is. Without that, every disagreement re-opens the same argument.
- Measurable outcomes. No one agreed, before go-live, what business result would prove the investment worked — so no one can tell afterwards whether it did. Absent measurement, the programme is judged on delivery, and delivery already happened.
Each of these is a business gap, not a technology gap. None of them is closed by more engineering.
From Platform to Use: The Bridges That Have to Be Built
If the platform is the factory, value comes from what the factory feeds. Connecting the two means building bridges the programme rarely funds.
To the frontline, value means the new data is embedded in the actual workflow — the relationship manager’s view, the analyst’s model, the daily operational routine — so that using it is easier than not using it. Adoption is a last-mile engineering problem and a human problem of habit; both have to be worked, not assumed.
To management information, value means MI is rebuilt on the trusted source rather than reconciled against it. If executives still keep their own numbers because they do not trust the platform’s, the platform has added cost, not clarity.
To risk decisions, value means the data is fit to carry the weight of a credit or exposure decision — timely, complete, and governed to a standard the risk function will stand behind. This is where the BCBS 239 expectations on aggregation and lineage stop being a compliance exercise and start being the difference between a usable platform and a decorative one.
To client service, value means a figure shown to a client is right, consistent across channels, and defensible. In a bank, a wrong number in front of a client is not a data-quality ticket. It is a breach of trust.
To operational efficiency, value means the manual reconciliations, the shadow spreadsheets and the rekeying the platform was meant to eliminate are actually retired — not left running ‘just in case’ alongside the new world, doubling the cost.
“The question is never whether the platform is live. It is whether a single real decision is being made differently because of it.”
What This Means for How We Run the Programme
If the value lives after go-live, the way we structure these programmes has to change in a few concrete ways.
- Define success as a business outcome, not a technical milestone. Write the acceptance criteria in the language of adoption, trusted MI, retired manual processes and decisions changed — not ‘platform live’. If go-live is the only gate, go-live is the only thing you will get.
- Fund the adoption curve, not just the build. Reserve budget, senior attention and delivery capability for the months after go-live. The post-live period is not warranty support; it is where the return is earned.
- Establish ownership before the platform lands. Business data owners, clear decision rights and a stewardship model should exist on the first day of use, not be improvised afterwards.
- Measure the outcome, and keep measuring. Agree the handful of business metrics that will prove the investment worked, baseline them before go-live, and track them long after the programme has closed.
- Retire the old world deliberately. Value is not created by adding a new source; it is created by decommissioning the old ones. Plan the retirement of the spreadsheets and shadow systems as explicitly as the build of the platform.
None of this is exotic. It is the recognition that a data programme is a change programme wearing an engineering costume, and change is not finished when the software is.
The Uncomfortable Reframe
The hardest part is cultural. Go-live is visible, celebratory and final; adoption is slow, diffuse and unglamorous. It is far more satisfying to cut the ribbon than to spend the following year persuading people to change a habit. But the bank did not spend its money for a ribbon.
The most useful discipline I know is to ask, at every steering committee, a single question that has nothing to do with the technology: what decision is now being made differently because of what we built? Early on the honest answer is ‘none yet’, and that answer is the entire point. It keeps the programme pointed at the outcome rather than the artefact, and it guards against the quiet, expensive fiction that shipping the platform was the same as delivering the value.
The technology going live is not the achievement. It is the moment the real work is finally allowed to begin.