Life After Launch: Living Up to the Business Case

Almost every large transformation clears its technical go-live. Deloitte’s 2024 ERP survey found that around nine in ten programs finish the deployment itself. Only about four in ten hit the business transformation goals inside three years. Panorama’s 2024 report puts the benefits number in the same neighborhood: only 42% of organizations realize even half of the benefits they wrote into the case. Gartner projects that by 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business case goals, and as many as one in four will fail catastrophically.

Those numbers are not a story about bad software. They are a story about what happens in the twelve to twenty-four months after go-live, when the project team demobilizes, the sponsor turns to the next thing, and the daily job of converting the launch into the promised outcome falls to a line organization that was never handed a plan for it. Stabilization takes six to twelve months. Higher-order benefits — working capital improvement, cycle-time compression, margin move — take eighteen to twenty-four. There is one contrary data point worth holding: Panorama’s 2023 report found that among organizations that had done an ROI analysis up front and were at least a year live, 83% said the program had met their expectations. The difference is not the software they picked. It is the discipline of writing down what the case actually was and reporting against it in the language of the business until the answer is in.

A sustainment plan is not a support contract, and it is not a help desk. It is the operating model of the business on the new platform, written down before go-live and run for the twelve to twenty-four months it takes for the case to land. The programs that produce the promised value share the same short list of components. The ones that do not almost always turn out to be missing three or four of them.

A named owner, on the business side, accountable for the value in the case — not the CIO, not a project director rolling off, and not a steering committee. The owner is a line executive whose year is measured on the outcome the case promised: the days out of the close, the working capital released, the order cycle time, the on-time-in-full number, the margin on a specific product line. If nobody’s bonus moves with that number after launch, nobody owns it.

A cadence that survives the launch. Weekly stabilization reviews inside the first eight to twelve weeks that convert incidents into fixes and behaviors. A monthly process council for months three through twelve that reads the KPIs against baseline and prioritizes the next refinement release. A quarterly value review with the sponsor and CFO that reads the benefits ledger against the case. Each meeting has a standing agenda, a scorecard, and a decision output. Meetings that only report are not sustainment; they are theater.

KPIs tied to the business case, not to the software. The dashboard reads in the language of the operator — exception rate on order entry, first-pass yield on invoices, days sales outstanding, close duration, the specific line on the P&L the case said would move. System uptime and ticket volume matter for support; they do not matter for the case. Alongside the KPIs sit decision rights that hold after the program team is gone: who approves a configuration change, who signs off on a new report, who says a workaround has become a permanent requirement, who owns the master data. On the ones that fail, the answer to every one of those questions in month six is “it depends,” and by month nine the organization is quietly running on spreadsheets again.

A refinement backlog with a release train behind it. Every workaround observed in hypercare, every deferred phase-one feature, every training gap, every report the business asked for and did not get, goes into one prioritized list with a named owner and a target release. Beside it sits an exception path for the cases the design did not anticipate — the customer order rejected at 4 p.m. on a Friday, the supplier invoice that does not match the receipt. Each has a defined path, a named owner, and a service level, or the frontline invents its own and the P&L absorbs the cost silently for months.

And executive routines that keep the case on the agenda. The COO reading the value scorecard in a monthly operations review. The CFO reading the benefits ledger in the quarterly business review. When the top of the house stops asking the value question, the middle stops answering it, and the number written into the case becomes an artifact of the approval memo.

Value realization sounds like a strategy word. In practice it is a bookkeeping discipline. Every benefit claimed in the business case gets a line on a ledger. Each line has a definition in operator language, a baseline measured before or at go-live, a target, a metric source, an owner, and a review cadence. Each carries a status: realized, partial, blocked, or invalid assumption. The ledger is read monthly with the process owner and quarterly with the sponsor.

The discipline sounds obvious. It is uncommon. Panorama has repeatedly found that many organizations skip business case justification, benefits measurement, and post-implementation audits altogether. Deloitte’s Second Wave research made the point more sharply almost two decades ago: successful companies treat the business case as a live management tool that evolves as the program does, not a static document written to secure funding. Every time the plan changes — a delayed module, a re-scoped process, a new acquisition — the case changes with it, and the ledger is updated so the sponsor knows which promises are still on the table.

Baselining is the step most often skipped, and the one that makes the rest possible. If nobody measured days-to-close or invoice exception rate or working capital in the six months before go-live, there is no way to prove the new system moved either. The number gets debated for the rest of the program’s life. The programs that produce clean value stories baseline before cutover, re-baseline at hypercare exit, and hold both on the ledger. It is what lets a CFO defend the investment on an earnings call two years later.

Haribo began converting sixteen factories across ten countries onto SAP S/4HANA in October 2018, moving off a patchwork of regional systems that in some cases dated to the 1980s. Sales of the company’s trademark Gold Bear line fell 25% that year, and German supermarkets were reported out of stock on individual Haribo SKUs for days at a stretch. The company acknowledged it had also become too focused on niche products, but the pattern is the one that shows up in most post-launch stumbles: the launch surfaced problems the design had not anticipated, and the organization was set up to treat every one of them as a defect rather than as a normal input to a refinement plan.

Every large launch produces two kinds of gaps. Defects — things that must be fixed to meet the specification that was signed. And refinements — things nobody could have known until the process was running at real volume against real customers and suppliers. The programs that produce value plan the refinements in and run them like a product backlog: prioritized on business value and risk, sequenced into monthly or quarterly releases, communicated in advance to the people who have to run against the new configuration on Monday morning. The backlog has three buckets — fixes that improve operability, process reinforcements that hold behavior in place, and optimizations that move the case’s numbers. The first protects the launch. The third funds it. A program with only the first stabilizes without ever producing the value that justified the investment.

The subtler discipline sitting beside the backlog is decommissioning. The legacy report nobody trusts the new one to replace. The parallel spreadsheet the controller keeps “just in case.” The old approval workflow that never got shut off. Each is a quiet vote of no confidence in the new platform, and each is where value leaks. A sustainment plan schedules the decommissions on the same calendar as the refinements, with replacement reports certified and shadow processes retired on a date.

Programs that skip sustainment do not usually fail loudly. Revlon and Haribo are exceptions because their failures hit the P&L in the quarter after go-live. The more common failure mode is quieter and more expensive, because it takes eighteen months to become visible, and by then the program team has scattered and nobody is left to hold the case together.

The shape is consistent. Hypercare exits on the calendar rather than on evidence. The command center stands down before the exception rate has come off its peak. The refinement backlog stops being worked because there is no product owner. Forrester has found that the average organization uses only 25% to 40% of its ERP system’s available functionality in the first two years after go-live — most of what was configured is quietly not being used, and the pieces the case depended on are not necessarily the pieces that made it. Roughly 70% of total ERP cost lands after go-live, and without a sustainment plan, most of that spend is defending the launch rather than compounding it.

Then the workarounds show up. A parallel spreadsheet in finance. A local reporting tool in a plant. A super-user who becomes the informal help desk. Each is a rational response by a person trying to do their job on a system nobody finished configuring for them. Each erodes the case further, because the process the case assumed is not the process the business is running. By month twelve, the operator has a new platform, an old operating model, and a case nobody remembers the details of. Cross-referenced Prosci and Panorama data suggests organizations investing more than 15% of total platform spend in post-go-live organizational readiness report roughly 2.3 times higher benefit realization than those that do not. That gap is spent on the owner, the cadence, and the backlog that let the case actually land.

Revlon’s software worked. Haribo’s software worked. In both cases, an operator woke up in the year after go-live with a technology asset doing what the vendor said it would do, and a business that could not fully use it yet. The decision that would have changed the outcome was not a technology decision. It was the decision to fund a sustainment plan and staff it, to name an owner accountable for a number written into the case, and to keep the case on the executive agenda past the point where most organizations declare the program complete.

That decision belongs to the sponsor, and it is uncomfortable because it looks like continuing to fund a program that is supposedly already over. The charter is closed. The go-live is on the news. The integrator has demobilized. The pressure is to move on to the next thing. And the alternative — a value story that never quite lands, followed by a re-implementation two years later — is more expensive by an order of magnitude, and rarely produces a satisfying answer to what the first program actually delivered.

The organizations that will look back on this cycle of transformations with something to show for them are the ones that decided, before the launch party, who was on the hook for the number in the case, how long they were on the hook for it, and what routines and resources would hold them to it. Everyone else will have a modern platform, a stack of dashboards, and a growing suspicion that the value the case promised was never really the point of the program.