Why Costing Models Fail After Go-Live
Most costing models do not fail on the day they launch. They fail eighteen months later, quietly, once the consultants have gone and no one owns the number any more. This piece is a composite scenario drawn from real field experience across cost-model implementations; the sector, details and figures are illustrative and represent no single client, and are best read as a warning about what happens after the go-live glow fades.
A costing model is not a deliverable, it is a living system, and living systems die without an owner and a routine. The go-live is the easy part: a polished model, a proud steering committee, a set of dashboards that finally show where money is made and lost. What kills the model is everything that comes after. Nobody is formally accountable for keeping it true. There is no maintenance rhythm, so the model slowly drifts out of step with a business that keeps changing. The one analyst who understood it moves on, and the logic leaves with them. The design was so elaborate that no one internal can sustain it. And, most fatally, the numbers never actually reach the decisions they were built to inform. The research on project abandonment, analytics adoption and the history of activity-based costing all point the same way: models fail from neglect, complexity and disconnection, not from bad math. The fix is unglamorous and reliable, clear ownership, a light maintenance cadence, deliberate simplicity, and the model embedded in a tool that a normal team can actually run rather than a fragile spreadsheet or a heavyweight platform no one can operate. Build for handover, not dependency.
The model does not die at go-live. It dies at handover.
Every cost-model implementation has a moment of triumph. The allocations reconcile, the margins finally make sense, a senior leader sees the true cost of a product or a customer for the first time and says out loud what everyone suspected. That is the go-live. It feels like the finish line. It is not; it is the start of the part that decides whether any of the investment survives.
A costing model is a representation of how a business consumes resources, and a business never stops moving. Products change, volumes shift, a new service line appears, a shared-services team reorganises, a plant is mothballed. Each of those changes quietly falsifies a model that was accurate the day it shipped. Unless someone is charged with keeping the model in step with reality, and given a routine for doing so, the model does not stay still while the business moves, it rots. Within a year the numbers are wrong, within two no one trusts them, and the expensive engagement becomes a cautionary tale told to justify never trying again. The failure is real, but it is a failure of stewardship, not of methodology.
How a good model went quiet in eighteen months
Picture a large, capital-intensive infrastructure operator, around 2019 (a composite, with illustrative figures and no real organisation behind it). A global advisory firm is brought in to build a full cost-and-profitability model. The work is genuinely good. Over several months the team stands up a heavyweight enterprise cost-management platform, wires in the source systems, defines several hundred activities, and produces a model that shows, credibly, that a meaningful slice of services, representative figures suggest on the order of a third, were being delivered below cost. Leadership is impressed. The engagement closes on a high.
Then the ordinary erosion begins. The platform requires a specialist to run the monthly refresh, and the business has exactly one person who was ever comfortable in it. Six months on, that person changes role. The activity structure, designed to impress, has hundreds of drivers that no internal manager can explain, so when a business unit reorganises, no one dares re-map it. The monthly refresh slips to quarterly, then to "when someone asks". By the eighteen-month mark the model still technically exists, but the last refresh is stale, two divisions no longer recognise their own numbers, and pricing decisions have quietly gone back to the old gut-feel spreadsheet. Nothing dramatic broke. The model simply had no owner, no rhythm, and no one who could sustain it, so it went silent. That silence, repeated across the industry, is what the failure statistics are really measuring.
The six ways a costing model dies
The post-go-live death of a costing model is not random. It happens in a small number of recognisable ways, and each has a tell-tale symptom that shows up months before anyone admits the model is failing. Learn to read the symptom and you can prevent the death. The table below is the map we work from.
| Failure mode | Symptom you see first | Prevention |
|---|---|---|
| No accountable owner | When a number is questioned, everyone points to someone else; the model belongs to "the project", which no longer exists | Name a single accountable owner in finance before go-live, with the model refresh written into their objectives, not a volunteer's spare time |
| No maintenance cadence | The "monthly" refresh slips to quarterly, then to on-request; the last-updated date drifts further from today | A fixed, light monthly rhythm with a short checklist, calendared and owned, so the model is refreshed as routine, not as a project each time |
| Model drift | New products, sites or teams appear in the business but not in the model; managers say "that is not how we work any more" | A quarterly re-map step that folds structural change into the model deliberately, treating the org chart and product list as living inputs |
| Key-person risk | Only one person can run the refresh or explain the logic; when they are away, the model is frozen | Deliberate simplicity plus documentation, so the logic lives in the tool and a written method, not in one head; at least two people can run it |
| Over-complex design | Hundreds of drivers no one can explain; managers cannot trace a number back to something they recognise | Design for the smallest model that answers the real decisions; prune drivers that add precision no decision uses |
| No link to decisions | The model produces reports that are admired, filed, and never acted on; pricing and mix choices still run on the old spreadsheet | Tie each output to a named decision and owner, a pricing gate, a portfolio review, so the model is consumed, not just produced |
Read down the middle column and a pattern emerges. Every symptom is a symptom of disconnection: the model disconnected from an owner, from a routine, from the current shape of the business, from a second pair of hands, from comprehensibility, or from the decisions it exists to serve. Keep the model connected on all six fronts and it lives. Let any one of them lapse and the clock starts.
Abandonment is the norm, not the exception
It would be comforting to think abandoned models are rare accidents. The evidence says the opposite. The Standish Group's long-running CHAOS research has, for decades, found that only a minority of technology and change projects finish on time, on budget and with the intended outcomes, while the majority are challenged or fail outright. The Project Management Institute's Pulse of the Profession studies tell a compatible story: a significant share of the money invested in projects is wasted because of poor performance, and much of that waste is not in the build but in the failure to embed and sustain what was built.
The pattern is sharpest in analytics. Gartner's research on analytics adoption has repeatedly found that only around a quarter to a third of the intended audience actually uses the analytics an organisation invests in; the rest quietly return to their own numbers. A model that is technically correct but unused is not a partial success, it is a failure that happens to reconcile. And the history of costing itself is the clearest warning of all. When Kaplan and Anderson introduced time-driven activity-based costing, their starting point was that conventional activity-based costing models were being abandoned in practice, not because the theory was wrong, but because they were costly to build, hard to maintain, and difficult to keep current as the business changed. The failure mode they diagnosed twenty years ago is the same one that silences models today: complexity that outruns the organisation's ability to sustain it. Any honest look at activity-based management has to begin there.
The traps that feel like good engineering
The dangerous failures are the ones that look like diligence while you are committing them. Four are worth naming, because teams walk into them believing they are doing the right thing.
Over-engineering as a badge of rigour. It is tempting to equate more activities, more drivers and more granularity with a better model. Past a point, extra precision buys nothing a decision will ever use, and it costs everything in maintainability. A model with hundreds of drivers is not more accurate in practice; it is more fragile, more opaque, and more certain to drift, because no one can hold it in their head or fix it when the business shifts. Precision the business cannot sustain is not precision, it is future error.
The platform no one can run. A heavyweight enterprise costing suite can produce a beautiful model and a crippling dependency in the same breath. If the monthly refresh needs a specialist licence and a rare skill set, the organisation has bought a model it cannot operate alone, and the moment the specialist leaves, the model freezes. The opposite trap is just as lethal: the entire model living in one heroic spreadsheet, undocumented and un-versioned, one broken link or one departure away from being unrecoverable.
Key-person risk dressed up as expertise. When one clever analyst owns all the logic, leadership often mistakes that concentration for strength. It is the single most common way models die. Expertise that lives only in one person is a liability the day that person is unavailable.
Building for admiration, not for decisions. A model that produces impressive reports no one acts on has failed, however elegant it is. If the pricing committee, the portfolio review and the capacity conversation are not physically consuming the model's outputs, then the model is decoration. The discipline of tying every output to a decision, a price change, a service to fix or exit, a block of unused capacity to reclaim, is what separates a model that lives from one that is quietly retired.
Build for handover, not dependency
None of the failure modes are mysterious, and none require heroics to prevent. They require four commitments made deliberately, before go-live rather than after the model has gone quiet.
One, clear ownership. Name a single accountable owner inside finance, not the consultants, and write the model into their formal objectives. Ownership that is real has a name, a mandate and time set aside; ownership that is "everyone's responsibility" is no one's. Aim for at least two people who can run the model, so a departure is an inconvenience, not a funeral.
Two, a light maintenance rhythm. A model survives on a cadence it can actually keep. A short monthly refresh with a one-page checklist, plus a quarterly step that folds in structural change, new products, new teams, reorganisations, keeps the model in step with the business without becoming a second job. Light and regular beats thorough and abandoned every time.
Three, deliberate simplicity. Design for the smallest model that answers the decisions on the table, and defend that boundary against the urge to add drivers. Every element you include is something someone must maintain, explain and trust. Simplicity is not a compromise on rigour; it is the precondition for a model that is still alive in three years. This is precisely why the discipline is measured by whether it changes decisions, not by how intricate it looks.
Four, embed the model in a tool, not a liability. The model should live somewhere that a normal team can run, not a fragile spreadsheet that dies with a broken link, and not a heavyweight platform that needs a specialist and a licence to breathe. It should be transparent enough that a manager can trace a number to its cause, cheap enough to refresh that the cadence is never skipped, and robust enough that it does not depend on one person. This is exactly the gap CostCtrl is built to close: a purpose-built costing tool that keeps the logic visible and the monthly refresh light, so the model stays owned and current instead of decaying into a spreadsheet no one trusts or a platform no one can operate. It is also why Cost and Profitability builds every engagement for handover rather than dependency, the measure of success is a model the client still runs, and still uses, long after we have gone. For investors weighing a portfolio, that durability is the whole point of a profitability diagnostic that has to outlive the diligence.
Common questions about why costing models fail after go-live
- Why do costing models fail after they go live?
- Rarely because the math is wrong. They fail from neglect and disconnection: no one is formally accountable for keeping the model current, there is no maintenance rhythm, the model drifts as the business changes, the logic lives in one person's head, the design is too complex to sustain, and the outputs never reach the decisions they were built for. The methodology usually survives the go-live intact; what dies is the stewardship around it.
- How long before an unmaintained cost model becomes unreliable?
- Faster than most leaders expect. Because a model mirrors a business that never stops changing, each product launch, reorganisation or site change quietly falsifies part of it. In practice a model with no owner and no refresh cadence tends to lose credibility within a year and be effectively abandoned within two, as the last-updated date drifts and managers stop recognising their own numbers. The decay is gradual and quiet, which is exactly why it is missed until it is too late.
- What is model drift and how do you prevent it?
- Model drift is the gap that opens between the model and the current shape of the business, new products, teams or sites that exist in reality but not in the model. You prevent it with a deliberate cadence: a light monthly refresh for the numbers and a quarterly re-map step that folds structural change in on purpose, treating the org chart and product list as living inputs rather than fixed assumptions. Drift is not prevented by building a bigger model; it is prevented by maintaining a right-sized one.
- Should a costing model live in a spreadsheet or a dedicated tool?
- A spreadsheet is fine to prototype in and dangerous to depend on: it concentrates key-person risk, breaks silently, and is hard to version or trust at scale. A heavyweight enterprise platform swaps that for a different risk, a specialist and a licence you cannot do without. The durable middle is a purpose-built tool that keeps the logic transparent, the refresh cheap, and the operation within reach of a normal finance team, so the model stays owned and current. That maintainability is the case for a tool such as CostCtrl over both extremes.
- How do you make sure a cost model actually gets used?
- Tie every output to a named decision and a named owner before go-live. A margin view should feed a pricing gate; a cost-to-serve view should feed a portfolio review; a capacity view should feed an investment conversation. If no scheduled decision consumes an output, that output is decoration and will be ignored. Adoption is designed in by connecting the model to the calendar of decisions, not hoped for after the fact, which is why success is measured by decisions changed, not reports produced.
References
Kaplan, R. S. & Anderson, S. R. Time-Driven Activity-Based Costing (Harvard Business Review, 2004, and the 2007 book) on why conventional activity-based costing models were abandoned as too costly to maintain and too hard to keep current. · The Standish Group, CHAOS Report (long-running research finding that most technology and change projects are challenged or fail rather than fully succeed). · Project Management Institute, Pulse of the Profession (on the share of project investment wasted through poor performance and weak benefit realisation). · Gartner research on analytics and business-intelligence adoption (on the persistent gap between analytics delivered and analytics actually used). · Kaplan, R. S. & Norton, D. P. The Balanced Scorecard (on linking measurement systems to the decisions and strategy they are meant to drive).