Resources · Decision guide
In short
A cost-of-delay figure is one initiative's monthly value multiplied by the months the current system adds, shown as a range with its assumptions. Keep maintenance and risk on separate lines, count each dollar once, and leave out whole-system debt totals and sunk costs. A worked example takes a $40,000-a-month self-serve plan from a single number to a one-page case finance can check.
You already know the system is slowing the business down. Everyone nods when someone says "it's costing us". Then the budget meeting moves on, because nodding isn't a number, and the renewal work waits another quarter.
What finance needs is a figure it can defend: where it came from, what it assumes, how wrong it could be. That's a cost-of-delay calculation. It isn't hard, but it's easy to do badly, usually by piling every cost you can think of into one number nobody believes.
The takeaway: price one initiative, multiply its monthly value by the months the current system adds, show the range, and keep maintenance and risk on their own lines. Five steps.
Let's take each in turn, with one worked example throughout.
Cost of delay is Donald Reinertsen's term. In The Principles of Product Development Flow his third economic principle reads: "If you only quantify one thing, quantify the cost of delay."
Reinertsen also runs an exercise that shows why. Ask ten people on the same project to write down, privately, what a one-month delay would cost. When Yuval Yeret ran it at a hardware and software company, on a project with about $16 million of lifetime profit, answers ranged from zero to the full $16 million. Those people set priorities together every week.
Joshua Arnold and Özlem Yüce applied it across a large portfolio at Maersk Line, written up in Black Swan Farming using Cost of Delay. Value was wildly uneven: the most urgent quarter of requirements in one system was worth roughly a thousand times the bottom quarter. And dividing cost of delay by duration, which Arnold calls CD3, gave them one scale to order work of different sizes. You don't need the framework. You need the arithmetic.
Don't try to price the whole system. Pick the one initiative the business most wants and the system most clearly holds back. For the example, say it's a self-serve plan: customers sign up and pay without talking to sales, which the current billing and permissions code can't support.
Now ask what that plan is worth once live, per month. Build it from numbers finance already owns: expected sign-ups, average price, the margin left after payment fees and support, any sales cost it displaces. Say the middle estimate is $40,000 a month of contribution. Write down each input and who supplied it. A CFO will trust a figure built from her own forecast long before one built from yours.
One check: is it revenue or margin? Finance thinks in margin. Quote revenue and the number gets cut in the first meeting, with your credibility attached.
Most calculations go wrong here, by pricing the whole project rather than the delay. Ask your engineering lead two questions. How long would this take on a system that didn't fight us? How long will it take on the one we have? Cost of delay applies only to the difference.
In our example, a plan that would take three months on a clean codebase takes nine on the current one: the billing module has no tests, the permissions model is scattered across controllers, and the two people who understand both are also on call. The system adds six months. "We can't estimate that, the system is too unpredictable." Then estimate it as a range and say so. An unpredictable system is part of the case.
Multiply: $40,000 a month times six months is $240,000. That's the cost of waiting before a cent of maintenance is counted, and on its own it often changes the conversation. Then make it defensible by admitting what you don't know: put a low and a high on each input and show the spread.
A range that wide isn't a weakness. It tells finance which assumptions to challenge. Then check sensitivity: each extra month of delay costs $40,000, while a $5,000 error in monthly value costs $30,000 over six months. Here the delay estimate moves the answer more, so that's where to spend your effort on evidence.
One more question from the Maersk work: what shape does the value have over time? Some benefits are steady once they arrive, and delay just shifts them later. Others decay, because a competitor launches first or a contract window closes. The multiplication above assumes the steady kind. If yours decays, say so; your middle estimate is probably too low.
Now the part that gets business cases thrown out. Maintenance, risk and opportunity cost are all real, and all tempting to stack on top of the $240,000. The rule: each dollar appears once, on one line.
The cost of keeping the system as it is belongs on its own line, outside the delay figure. Count what you'd stop spending if the part in question were renewed: hours lost to patching, the upgrade you keep deferring. In McKinsey's 2023 article on technical debt, 30 percent of the CIOs surveyed believed more than 20 percent of their new-product budget was being diverted to tech debt. Your own ticket history gives finance a figure it can audit.
The trap is pricing engineer time twice: once as "wasted capacity" at salary cost, and again as the revenue those same hours would have shipped. Pick one. In a cost-of-delay case the revenue view is usually stronger, so leave the salary line out.
Risk is an expected value, not a scare story. For each named risk, estimate a probability over the period and a cost if it happens, multiply, and list it separately. An outage during the sales quarter at 10 percent probability and $200,000 impact is a $20,000 line. Don't add a vague "risk premium" on top of lines that already carry it.
Simple: the $240,000 is the opportunity cost. A separate "opportunity cost" line counts it twice, and finance will notice.
In our experience the stacked version gets rejected and the separated version gets discussed. An insurance client of ours arrived with a single "cost of technical debt" of several million, built from everything above added together. After half a day with their finance team it became three lines: delay on one pricing initiative, a maintenance figure from the ticket queue, and two risks with probabilities. The total was smaller. It was also funded.
Finance teams approve things they can read in five minutes and check in ten. One page, in this order:
What to leave out matters as much.
Fabrica's CLEAR method starts from the same place as this calculation: one business priority the current system holds back, not the system as a whole. The assessment scopes that one workflow, and the pilot is measured against a baseline you agree, covering total cost, internal effort, throughput and any freeze days, so the decision to continue rests on your figures rather than ours. We won't promise zero risk or zero migration cost, and we don't advise on accounting treatment; that stays with your finance team.
A cost-of-delay figure doesn't tell you to renew the system. It tells you what waiting costs, the number missing from every previous conversation about it. Sometimes the answer is small, and the right decision is to leave the system alone. More often the delay on one initiative already exceeds the first step of fixing it, and that comparison is what finance needs to see.
Do it for the three or four initiatives the system is holding back, divide each by the time it would take to clear the way, and you have an order to work in. Start at the top.
Tell us about it on a 30-minute call. We'll suggest a first scope and what a technical review would need to confirm.