Executing large change
How should we roll out a large system or change?
Implementing enterprise systems, migrations and operational tooling, where the risk lies in how the change is carried out.
Fewer than ten resolved cases. Read this page as a set of examples, not as a base rate.
What the cases suggest
Large implementations are the group with the worst record by far: nearly every case backfired, and most were judged poor in process. The failures share a shape. Organisations changed many things at once, went live at the worst possible time, trusted a new system before they had evidence it was correct, or ran critical work on tools never designed for it.
What separated the decisions that worked
- Big-bang switchovers, such as Hershey’s before Halloween and FoxMeyer’s warehouse and ERP together, failed; the evidence favours phased change with a way back.
- Treating a system’s output as proof, as the Post Office did with Horizon, turned a technical fault into a human disaster.
- The one success, renaming genes to suit spreadsheets, accepted the tool’s limits instead of fighting them.
Where this evidence is weak
Implementation failures are reported far more often than quiet successes, so this group overstates the odds of failure even if its lessons hold.
By who decided
| Decision-maker | Cases | Paid off | Mixed | Backfired | Too early |
|---|---|---|---|---|---|
| Market leader | 3 | 0 | 0 | 3 | 0 |
| Challenger | 1 | 0 | 0 | 1 | 0 |
| Researchers and communities | 1 | 1 | 0 | 0 | 0 |
| Public body | 3 | 0 | 0 | 3 | 0 |
The cases
Each links to the essay, memo or road not taken where the decision is described and judged, with its sources.
- Rename 27 human genes whose symbols spreadsheets turned into dates When a tool is universal, it is often cheaper to change your conventions than to change it, but notice what that says about who shapes whom.
- Install SAP R/3 and a new automated warehouse system at the same time, and bid for contracts on the basis of savings the systems were expected to deliver Do not bet the company on a system’s promised benefits before it has delivered them.
- Switch on new ERP, customer relationship and supply chain systems together in July, shortly before the Halloween ordering season Schedule irreversible changes for when you can afford them to go wrong.
- Treat data from its Horizon accounting system as reliable evidence against sub-postmasters, prosecuting and pursuing them for shortfalls, despite reports of errors When a system and a person disagree, the system’s output is a claim to be checked, not a verdict.
- Replace hundreds of legacy logistics systems with a single commercial ERP-based system while also changing its logistics processes The larger the transformation, the more it must be broken into pieces that can succeed or fail on their own.
- Adopt a standard SAP retail system while keeping its own long-standing practice of valuing inventory at purchase prices, which required extensive customisation Decide early whether you will adapt to the software or the software to you; trying to do both is the most expensive choice.
- Run a new value-at-risk model for a large derivatives portfolio on manually maintained spreadsheets When a spreadsheet becomes a system, it must be governed like one.
- Load laboratory results into a spreadsheet format with a fixed row limit as part of the national Covid-19 reporting pipeline Every tool has limits; find them before the data does.
Other kinds of decision
- Opening or closing
- Business model and pricing
- Make, buy or partner
- Acquisitions and sales
- Technology bets
- Product design
- New categories and markets
- Distribution and positioning
- Focus, exit and investment
- Trust, safety and privacy
- Organisation and governance
- Public rules
Shrikant Kumar. “Executing large change.” The Telos Decision Record, Telos, version of 2026-11-03. https://shrikantk.com/record/execution/