The System Went Live; the Organisation Stayed Put
The programme was structured to add a system, when transformation requires that you subtract a way of working.
Executive Summary
For most of the past decade, the largest organisations in the industrialised world have been engaged in the same enormous act of self-renovation: the replacement of their ageing, departmental software with a single integrated enterprise suite. The millennium deadline gave the movement its urgency, and the promise gave it its glamour. We were not merely buying software, the argument ran; we were buying transformation — one version of the truth, processes rebuilt to best practice, an organisation finally able to see and manage itself as a whole.
A great many of these programmes are now complete. The systems are live. And a quieter observation, rarely printed in the annual report, recurs across sector after sector: the system went live, and the organisation stayed more or less where it was. Month-end still takes three weeks. The old spreadsheets still circulate. The plant still runs to the planner’s instinct rather than the system’s schedule. The software was installed; the way of working was not retired.
This essay is a reflection on that gap. It argues that the failure was not, in the main, a failure of software — the packages generally worked — but a category error at the heart of the enterprise: we treated the arrival of a system as if it were the same event as the change of a habit, and the two are not the same event at all. It examines why the pattern recurred so reliably, takes seriously the case that says system-first is the right order and adoption merely lags, and asks what distinguished the minority of programmes that genuinely changed how their organisations worked. The conclusion is uncomfortable but, I think, correct: a system goes live on a date that can be printed on a slide; a way of working dies only when someone with authority decides to let it, and that decision was the one we kept deferring.
The Go-Live That Changed Nothing
Consider a scene that will be familiar to anyone who has stood in a finance function in the last two years. The programme is eighteen months in and £14 million spent. The integrated suite has gone live across finance and logistics; four hundred users have been trained; the steering committee has held its celebration and the programme director has, quite reasonably, updated his curriculum vitae. It is the third week after the first month-end on the new system.
And the month-end is not closed. The financial controller’s team is doing what it did before: extracting balances into a web of spreadsheets, reconciling them by hand against a set of local databases that were supposed to have been decommissioned, and arriving — fifteen working days after period-end, exactly as before — at a set of numbers they trust. The new system holds a general ledger of great elegance and a reporting suite that, in principle, produces the month-end pack at the press of a key. Nobody presses the key. They do not trust it, because the data flowing into it is still shaped by the old process, and the old process is still running, quietly, underneath.
This is not a story about a botched implementation. The system works. It is a story about something stranger and more common: a programme that succeeded on every measure it set for itself — on time, near enough to budget, live in all locations — and yet delivered almost none of the change it was commissioned to deliver. The gap between those two facts is the subject of this essay.
What We Thought We Were Buying
It is worth being honest about the promise, because the promise is where the trouble began. The business case for these programmes was almost never written as “replace software that is expensive to maintain and will not survive the millennium.” It was written as transformation. The integrated suite would impose a single, consistent process where a dozen local variants had grown up. It would give management, for the first time, a single version of the truth rather than a reconciliation of competing versions. It would embed best practice — the accumulated process wisdom of a thousand prior implementations — directly into the way work was done. The technology was the vehicle; the destination was a different organisation.
That framing was not cynical. Much of it was sincerely believed, and some of it was even achievable. But it concealed a substitution that happened silently as the programme moved from boardroom to project floor. The thing that had been sold as organisational change was, in delivery, managed as a systems implementation. The measures of success migrated accordingly. What began as “the finance function will close the books in five days and spend its time on analysis rather than reconciliation” became “the finance modules will be configured, tested, and live by the first quarter.” These are not the same goal. The second can be achieved in full while the first is not even attempted.
The business case promised a different organisation. The project plan delivered a different system. Somewhere between the two, the word transformation quietly came to mean installation, and almost nobody noticed the substitution because both were true at once.
The reason the substitution went unnoticed is that both statements could be true simultaneously. The modules were configured and live. Every milestone on the plan was met. The programme could report success without lying, because the plan measured the system and the system had, indeed, arrived. What the plan did not measure — because it is far harder to measure, and far harder to control — was whether anyone had stopped working the old way.
The Millennium Accelerant and the New Economy Backdrop
Two forces particular to this moment sharpened the pattern, and both deserve naming, because a reader in another decade might not feel their weight.
The first was the millennium deadline. A very large share of these programmes were justified, at least in part, as the answer to the date problem in the old systems. That was a legitimate reason to act, but it did something subtle to the shape of the programme: it made the deadline the point. When the driving question is “will our systems survive the first of January,” the entire organisation’s attention fixes on the go-live, on the system being there and working on the day. The change of behaviour that was supposed to follow had no such deadline, no such visceral consequence for missing it, and so it drifted. We built a burning platform under the installation and left the transformation to look after itself.
The second force is the mood of the last two or three years — the New Economy, the conviction that technology was rewriting the rules of business, and now, as I write, the sharp correction as the air comes out of the dot-com valuations. That mood encouraged a particular error: the belief that acquiring the technology was the strategy. If the market rewarded companies for being technologically modern, then installing the most modern of all enterprise systems felt like transformation in itself. The share price did not ask whether the finance team had changed its habits. It asked whether the company was investing in the future, and a large systems programme was proof that it was. Now that the market has stopped rewarding the gesture and started asking about returns, the question of what these programmes actually changed is becoming harder to avoid.
Why the System Arrives but the Change Does Not
If the diagnosis is that we installed the system and never retired the way of working, the natural question is: why not? What is the mechanism? It is not idleness, and it is rarely incompetence. The mechanism is structural, and it repeats with enough regularity to be worth setting out plainly.
The first part of the mechanism is the difference between configuration and adoption. A system can be configured by a project team in a room. Adoption cannot. Configuration is finite, ownable, and schedulable — precisely the properties that make it fit neatly onto a plan. Adoption is diffuse, belongs to hundreds of people who did not sit in the room, and follows no schedule. So the plan optimises for what it can control. The team configures the finance modules to a high standard and declares the process reengineered; but the reengineering exists in the configuration, not yet in the behaviour of the people who close the books.
The second part is the alibi of best practice. The suites were sold on the promise that they embedded best practice, and this became a way of not having the difficult conversation. If the process is best practice by definition — because the package says so — then the organisation need not argue about how it actually wants to work. But a process embedded in software is a template, not a decision. It describes how work could flow; it cannot, by itself, make anyone stop doing it the old way. The organisation adopted the template and skipped the decision, and the template sat there, unenforced, while the real process continued in the margins.
The third part, and the most corrosive, is the shadow system. When the new suite goes live before the old way of working has been genuinely retired, people do the rational thing: they keep a private copy of the truth. The controller keeps her spreadsheets. The planner keeps his local database. The regional office keeps the report it always ran. These shadow systems are not sabotage; they are prudence, because the people using them are accountable for numbers they do not yet trust the new system to produce. But the effect is fatal to the promise. The single version of the truth becomes one version among many, and because the shadow versions are the ones people actually trust, the expensive new one becomes, in practice, a very elaborate data-entry exercise feeding reports nobody reads.
- Configuration is not adoption. The system can be built in a room; the change cannot, and the plan quietly optimises for the part it can control.
- Best practice became an alibi. A process embedded in a package is a template, not a decision — and the organisation adopted the template while skipping the decision.
- The shadow system is rational. People keep the old way running because they are accountable for numbers they do not yet trust the new system to produce, and so the single truth fragments the moment it goes live.
Underneath all three is a single confusion, and it is the heart of the matter. The programme was structured to add a system, when transformation requires that you subtract a way of working. Addition is easy and safe; you can install the new thing without disturbing anyone. Subtraction is hard and political; it means telling the controller she may no longer keep her spreadsheets, and standing behind the new numbers when they are wrong in the first three months, and refusing to let the old report be run even when someone senior asks for it. We were very good at the addition. We almost never did the subtraction.
The Case for the Defence
It would be too easy to stop there, and dishonest, because there is a serious argument on the other side, and it is held by intelligent people who have delivered real systems. It deserves to be put at its strongest rather than knocked down as a straw man.
The argument runs like this. System-first is not a mistake; it is the correct order. You cannot reengineer a process in the abstract and then find software to fit it — that way lies years of analysis and a bespoke system that costs three times as much and fails anyway. You put the standard package in, you accept its disciplines, you get the data onto a single platform, and then behaviour changes, because the old ways slowly become impossible rather than merely discouraged. Adoption, on this view, is not a failure when it lags; it is a lagging indicator, the natural tail of a change that takes years to complete. Judge these programmes at eighteen months and of course they look like installations. Judge them at five years and the spreadsheets will be gone, because the generation that clung to them will have moved on and the new joiners will know no other way.
This is a genuinely strong case, and any honest reflection has to concede its central point: sequencing the system first is often right, and expecting full behavioural change on the day of go-live is naïve. Adoption does lag, legitimately.
But the argument proves less than it claims, for one reason. It assumes that lag closes on its own, given time — that the mere continued existence of the system eventually starves the old ways of oxygen. The evidence of the last decade is that it does not, unless someone makes it. The shadow systems do not wither with time; they institutionalise. The spreadsheet that was a temporary crutch in month three becomes, by month thirty, the month-end process, documented, handed over to new joiners, and defended as how things are done here. Time alone does not retire a way of working; it entrenches whichever way of working people actually rely on. If that is the shadow system, time is the enemy of the transformation, not its ally. The lag closes only where someone with authority forces the subtraction — and that act of forcing is exactly the thing the system-first argument allows everyone to postpone. The defence is right that the system should come first. It is wrong to believe that first means only.
“A system goes live on a date that can be printed on a slide. A way of working dies only when someone with the authority to do so decides to let it — and that was the decision we kept deferring.”
The Forces That Keep the Pattern Alive
If the error is this legible, why does it recur so faithfully? Because a set of incentives, none of them villainous, align to produce it. Reflection on the pattern is incomplete without an honest look at who benefits from stopping at go-live.
The systems integrator’s contract, and therefore its incentive, almost always ends at or near the point the system is live and stable. That is the deliverable, that is the payment milestone, and the harder, slower, more political work of retiring the old ways sits awkwardly outside the scope of a firm whose expertise and commercial model are built around implementation. It is not that integrators are indifferent to benefits; it is that the commercial structure quietly defines the finish line as the moment the transformation is supposed to begin.
The executive sponsor’s clock runs the same way. Sponsors are rewarded for delivering the programme, and “delivered” has a natural, defensible meaning: it is live. The benefit that was supposed to follow — the five-day close, the reduced working capital, the analyst freed from reconciliation — arrives, if it arrives at all, over a horizon longer than most sponsors remain in post. The rational sponsor’s bankable achievement is the go-live, not the benefit, and so that is what gets managed.
And the accounting reinforces all of it. The organisation capitalises and tracks the project — its cost, its timeline, its scope — with great rigour. It rarely tracks the benefit with anything like the same discipline, because the benefit is diffuse, arrives late, and is hard to attribute cleanly to the programme rather than to everything else that changed. What gets measured gets managed; the project was measured and the benefit was not, and so the project was delivered and the benefit was left to chance.
| What Went Live | What Stayed the Same |
|---|---|
| A single general ledger of great technical elegance | A month-end close still run through spreadsheets and reconciled by hand |
| A configured, best-practice procurement process | Local buying habits and the relationships that sustained them |
| A reporting suite producing the management pack at a keystroke | A management pack still built manually, because the trusted numbers live elsewhere |
| Four hundred trained users | Four hundred people doing, in the essentials, what they did before |
| A programme reported as delivered on time and on budget | An organisation whose working capital, cycle times, and headcount were unchanged |
None of these actors is behaving badly. Each is responding sensibly to the finish line their world defines for them. The pattern persists not because people are foolish but because the incentives are arranged so that everyone’s rational stopping point is the go-live, and no one’s rational stopping point is the change.
What the Minority Did Differently
Holding this pattern up to the light risks a counsel of despair, and that would be false, because a minority of these programmes did genuinely change how their organisations worked. They are worth studying precisely because they were not distinguished by better software — they bought the same packages from the same vendors — nor, in most cases, by more money. They were distinguished by something less glamorous and much harder.
They treated the go-live as roughly the halfway point of the programme, not the end, and they resourced the second half. The budget did not fall off a cliff the day the system was live; there was money, and named senior people, committed to the year after go-live, when the real work of retiring the old ways began. In practical terms this meant a small number of unglamorous disciplines held with real stubbornness: the old reports were switched off, not merely deprecated, on a published date, and the request to switch them back on again was refused even when it came from someone senior. The shadow spreadsheets were hunted down and their owners given a genuine reason — and a genuine alternative — to abandon them. Someone owned the benefit, not the project, and stayed in post long enough to be accountable for it. And the numbers the new system produced were defended publicly through the ugly first quarter when they were wrong, rather than being quietly worked around while confidence in the system leaked away.
None of this is a methodology, and I distrust anyone who would sell it as one. It is closer to a disposition — a willingness to treat the difficult, political act of subtraction as the actual content of the transformation, rather than as an afterthought to the installation. The organisations that transformed were the ones that understood, usually because they had been burned before, that the system was the easy half.
Conclusion: Installation Is Not Change
The enterprise-system decade will be remembered, I suspect, as a period in which we became genuinely excellent at a task we had mistaken for a larger one. We learned to install extraordinarily complex integrated systems across sprawling organisations, on time and at scale, and that is a real and hard-won competence. What we did not learn, for the most part, was that installing the system and changing the organisation are two different projects that happen to share a start date — and that the second one has no go-live, no burning platform, and no natural finish line to make anyone attend to it.
The lesson is not that these programmes were a waste; the systems are real and the platforms they built will matter for decades. The lesson is more precise and more demanding: the arrival of a system is an event, and the change of a way of working is a decision, and we have persistently confused the two because the event is so much easier to see, to schedule, and to celebrate. The organisations that will get the returns are the ones that grasp, before they begin, that the day the system goes live is the day the actual work starts — the slow, unglamorous, deeply political work of persuading an organisation to let go of the way it used to be. That work cannot be bought from an integrator, cannot be configured in a room, and cannot be printed on a slide. It can only be decided, and then defended. Everything else is just installation.