The costing model that died (and how to keep yours alive)
This is a composite scenario drawn from real field experience across cost-model implementations; the details, the sector and every figure are illustrative and represent no single client. It is the story of an elegant costing model that took roughly three years and a high six-figure budget to build, produced genuine insight for one glorious year, and then quietly died. What killed it was not the mathematics. It was the thing almost nobody puts in the project plan.
A large, capital-intensive infrastructure operator commissioned a global advisory firm to design a costing model. The design was excellent. Implementing it on a heavyweight enterprise cost-management platform took about eighteen months just to find someone who could build it, and another eighteen to build it. When it finally ran, it produced real answers: true cost by activity, a whale curve of profitability, decisions that had been guesses made defensible. Then the delivery teams left. No one inside owned the model, no one updated it, and within a year it had drifted so far from reality that people stopped trusting it. The investment, illustrative, but comfortably in the high six figures, was written off. The lesson is uncomfortable and well evidenced: costing models rarely fail on method. They fail on ownership and maintainability. The same ambition today, built with a modern tool, AI and a clear internal owner, reaches a first defensible model in days rather than years, keeps every number traceable, and lives inside something the client can actually run. That is the difference between a model that dies and one that stays alive.
An elegant design, and everyone in the room nodded
It began, as these things often do, with a good diagnosis. Around 2019, a large capital-intensive infrastructure operator knew what every finance chief in its position knows: the numbers coming out of the general ledger told it what it had spent, but not what anything actually cost. Cost by department, yes. Cost by activity, by service, by the things the organisation actually decided about, no. So it did the sensible thing and brought in a global advisory firm to design a proper cost model.
The design was, genuinely, good. A clean activity architecture. Resources flowing to activities, activities flowing to the services and outputs that mattered, drivers chosen with real care. It was recognisably in the tradition of time-driven activity-based costing, the discipline Kaplan and Anderson had set out a decade earlier: model the capacity, model the time each activity consumes, and let cost follow cause rather than convenient averages. The advisers documented it beautifully and recommended it be implemented on a heavyweight enterprise cost-management platform, the serious, expensive kind that large organisations buy precisely because the ambition is large. Everyone in the steering committee nodded. On paper, the hard part was done.
On paper. The blueprint answered what the model should be. It was quieter on who would build it, who would run it, and who would still care about it three budget cycles later. That silence is where the story actually lives.
Eighteen months looking for someone who could build it
Here is the part the blueprint did not anticipate. Having an elegant design and having the design on a platform are separated by a chasm, and the operator spent roughly eighteen months at the bottom of it. The conceptual model was sound. The platform was capable. But the specific skill of translating this design onto that platform, the people who could actually do it, turned out to be genuinely rare and mostly unavailable.
So the blueprint sat on a shelf. Not metaphorically; there was a bound document, and it sat there. Procurement rounds came and went. Candidates were interviewed and quietly turned out not to have done this before, only something adjacent. The window in which the original sponsors were energised about the project narrowed. This is the least dramatic act in the story and, in some ways, the most instructive: eighteen months of elapsed time and paid effort produced exactly zero working model, and no one had done anything wrong. The design was not the constraint. The scarce resource was the ability to implement it, and scarce resources, as any cost model will tell you, are where the real cost hides. The organisation was already paying, in time and momentum, long before a single number came out.
It ran, and for one year it was magnificent
Eventually a specialist implementer was found, someone who had actually done this on this class of platform, and the build began in earnest. It took about eighteen months more. That is not a scandal; a model of this ambition, on a platform of this weight, is a serious construction project with data feeds, allocation logic, reconciliation and testing. But it means that by the time the model produced its first trustworthy output, roughly three years had passed since the blueprint was signed off.
And then it worked. This is the part worth lingering on, because it was real. The model produced true cost by activity, not departmental averages dressed up. It let the organisation draw a whale curve of profitability, the cumulative-profit curve that reveals how a minority of services and relationships generate well above total profit while a long tail quietly gives it back (illustrative pattern, but a familiar one). Decisions that had been made on instinct for years, what to price, what to insource, where capacity was genuinely being consumed versus merely assumed, became defensible. People brought the model's numbers into rooms where previously they had brought opinions. For a while, the organisation could see itself clearly, some of it for the first time. Three years and a high six-figure investment, illustrative, had bought something that genuinely worked.
Then the teams left, and no one owned it
The death was not a crash. Nobody switched the model off. It died the way most costing models die, slowly, quietly, from neglect that no single person chose.
When the implementation was declared complete, the delivery teams did what delivery teams do: they left. The advisory firm rolled off. The specialist implementer moved to the next engagement. And the model, this intricate machine that turned raw ledger data into insight, was handed to an organisation that had no one whose actual job was to keep it alive. There was no internal owner. There was no maintenance cadence, no monthly rhythm of refreshing the data, revisiting the driver rates, checking that the capacity assumptions still matched a changed operation. There was no accountability, because ownership had never been designed in; the blueprint had specified the model, not the maintainer.
So reality moved, as reality does, and the model did not move with it. Activities changed. Volumes shifted. The organisation restructured a little, as organisations do. Each un-updated month, the gap between what the model said and what was true widened by a fraction. Within a year the model's numbers no longer matched anyone's lived experience of the business, and the moment a costing model stops matching reality is the moment people stop trusting it. Once they stop trusting it, they stop using it. Once they stop using it, no one can justify the effort to maintain it, which guarantees it drifts further, a quiet death spiral. The model was not decommissioned in a meeting. It was simply, gradually, abandoned. The high six-figure investment, illustrative, was written off not because the model was wrong when it was built, but because nothing was in place to keep it right.
It was never the maths
It is tempting to blame the method, or the platform, or the three-year timeline. Resist that. The design was good. The build was competent. The model, on the day it went live, was right. What killed it was structural, and it is the same thing that kills most of these projects: the effort went almost entirely into building the model and almost none into owning it. And the evidence that this is the normal failure mode, not bad luck, is overwhelming.
Large technology and change projects fail at rates that should sober anyone. The Standish Group's long-running CHAOS research has for years found that only a minority of projects finish on time, on budget and with the intended result, and that the largest and most ambitious projects fail most often, which is precisely the category a multi-year model build on a heavyweight platform sits in. The Project Management Institute's Pulse of the Profession work makes the deeper point: the failure is frequently not in delivery but in benefits realisation, organisations complete the project and then never institutionalise the value, because no one owns the outcome after the team disbands. And on the adoption side, Gartner's analytics research has repeatedly found that a large share of analytical and BI assets are underused or never adopted at all, not for want of quality but for want of an owner, a cadence and a reason to trust them. Our story is not an outlier. It is the base rate.
| What everyone assumed would kill it | What actually killed it |
|---|---|
| A flawed conceptual design | The design was sound; it was never the problem |
| The wrong methodology | Activity and time-driven logic was the right choice |
| An under-powered platform | The platform was capable; capability was not the gap |
| Bad numbers on day one | The numbers were right on day one, and only on day one |
| Nothing | No internal owner, no maintenance cadence, no accountability |
Read the right-hand column again. Four of the five assumed causes were never real. The one that was real, ownership and maintainability, was the one no one had budgeted for, because it does not show up in a design document or a platform demo. It shows up eighteen months later, as silence, when the model is due a refresh and there is no one whose job it is to give it one. A cost model is not a deliverable you finish. It is a living instrument, and living things need tending. This is also why cost intelligence belongs close to management, not locked in a specialist's platform: the practices behind activity-based management only pay off when someone inside the business acts on them month after month, and the discipline of costing unused capacity only stays honest if the capacity assumptions are revisited as the operation changes.
Days, not years, and a model that stays alive
Here is what makes the old story worth telling: the same ambition, today, does not have to end the same way. The organisation in the story was not wrong to want true cost by activity, a whale curve, defensible decisions. It was let down by how long the ambition took to reach and how little of it was built to last. Both of those have changed.
With Cost and Profitability, CostCtrl and AI working together, a first defensible model is a matter of days rather than years. The bottleneck that cost the operator its first eighteen months, finding someone who could translate a design onto a heavyweight platform, largely dissolves, because the modelling method and the tool are built for each other and AI does the heavy lifting of structuring data, proposing drivers and standing up a first cut fast. Every number stays traceable: you can follow any output back through the activities and drivers to the source figure, which is exactly the property that lets people keep trusting a model as it is challenged. And critically, the model lives inside a tool the client can actually run and maintain, not a specialist black box that leaves when the specialists do. That is what makes it sticky: the owner is internal by design, the maintenance cadence is built into how the tool is used, and refreshing the model each month is a routine, not a project. All of this for a fraction of the old investment.
| Then (the story) | Now (Cost and Profitability + CostCtrl + AI) |
|---|---|
| ~18 months to find someone who could build it | Method and tool designed together; AI accelerates the build |
| ~18 more months to a first working model | A first defensible model in days |
| Numbers trusted only until the team left | Every number traceable to its source, on demand |
| Lived in a specialist black box | Lives in a tool the client runs and maintains |
| No owner, no cadence, quiet death within a year | Internal ownership and monthly cadence built in |
| High six-figure investment written off | A fraction of the cost, and it stays alive |
This is not a pitch for buying a different platform. It is a different theory of what a costing model is. Treat it as a one-off construction project and it will behave like a building nobody maintains. Treat it as a living instrument with an owner, and it compounds in value, the whale curve you draw this year is worth more next year because it is still true. If you want to see the sharpest version of the contrast, it is the difference laid out in CostCtrl versus spreadsheets, and the value of a model that keeps producing trustworthy profitability KPIs and performance measures long after the consultants have gone. For investors, the same durability is what turns a one-time portfolio profitability diagnostic into a capability the company keeps.
Common questions about why costing models fail
- Why do costing models fail?
- Far more often from neglect than from bad method. A well-designed model is usually correct on the day it goes live; it fails later, when no one owns it, no one refreshes the data and driver rates, and it slowly drifts from a changing business until people stop trusting it. The evidence is consistent across the research on projects and analytics: the Standish CHAOS studies show that the largest, most ambitious builds fail most often, and PMI's benefits-realisation work shows that value is frequently lost after delivery, not during it. The maths is rarely the villain. Ownership and maintainability are.
- Who should own a cost model?
- Someone inside the organisation, named, before the model is built, not the implementation team, who will leave. In practice the owner sits in finance or controlling, close enough to the business to know when reality has moved and senior enough to be accountable for keeping the model current. The single most useful thing you can do at the start of a costing project is decide who runs it after the consultants go, and design the tool and cadence so that person can actually do it. A model without a named internal owner is a model with an expiry date.
- How long should a costing model take to build?
- Historically, ambitious models on heavyweight enterprise platforms took months to years, and a meaningful part of that was simply finding people who could implement the design. With a modern approach that pairs the modelling method to a purpose-built tool and uses AI to structure data and propose a first cut, a first defensible model is realistically a matter of days, then refined iteratively. Speed matters for more than cost: the faster a model produces a trustworthy answer, the sooner it earns the trust and the internal ownership that keep it alive.
- How do you keep a costing model from drifting out of date?
- Build maintenance in from the start rather than treating it as an afterthought. That means a named owner, a fixed monthly cadence to refresh data and revisit driver rates and capacity assumptions, and full traceability so any number can be followed back to its source when it is challenged. It also means the model must live in a tool the organisation can run itself, not a specialist environment that walks out the door. Drift is not inevitable; it is what happens when no routine exists to prevent it.
- Was the problem the platform, the method or the people?
- None of them, in the story here. The conceptual design was sound, the platform was capable, and the people who built it were competent. The failure was structural: effort went into building the model and almost none into owning and maintaining it after handover. Blaming the tool or the technique is comforting because it implies an easy fix, but it misreads the cause. The fix is to treat a cost model as a living instrument with a permanent internal owner, not as a project that ends the day it goes live.
References
The Standish Group, CHAOS Report (project success, failure and challenged rates, and the relationship between project size and failure). · Project Management Institute, Pulse of the Profession (delivery performance and the loss of value in benefits realisation after project close). · Gartner, research on analytics and business-intelligence adoption (the persistent gap between analytical assets built and analytical assets actually used). · Kaplan, R. S. & Anderson, S. R. Time-Driven Activity-Based Costing (Harvard Business School Press) and Kaplan, R. S. & Cooper, R. Cost & Effect (designing and, crucially, sustaining activity-based cost systems). · All engagement details, sector and figures in this piece are illustrative and composite, and represent no single client.