Cost of Inaction

Architectural investment competes for the same budget as features, and features arrive with a revenue story. Architecture arrives with "the system is old and difficult", which is true and does not compete.

The cost of inaction converts the argument: rather than asking for investment on technical grounds, it states what the current state costs per quarter, in the same units the alternative is measured in.

What it contains

• Incident cost — frequency, duration, revenue impact, and engineering time consumed. Consumed engineering time is the component teams most often omit and it is frequently the largest.
• Change cost — lead time for a typical change now versus a comparable modern system, multiplied by change volume. "Every change takes six weeks instead of one, across forty changes a year" is a defensible number.
• Opportunity cost — features not built because the system cannot support them, with specific examples the business asked for and was refused. Specificity is what makes this credible rather than rhetorical.
• Risk exposure — unsupported components, unpatchable vulnerabilities, key-person dependency, and the cost of the failure mode if realised, multiplied by a stated probability.
• Direct costs — licences, specialist contractors, hardware nobody else runs.

Implementation patterns

• State it per quarter, so it compounds visibly against a multi-quarter programme.
• Use evidence, not estimates, where evidence exists. Incident records, change lead times and licence invoices are all available and are far more persuasive than modelled figures.
• Attach it to prioritisation, not just to funding. Every proposal on an improvement portfolio should carry one, which makes items comparable and surfaces the ones that are cheap to state and expensive to ignore.
• Include time sensitivity. Data model, interface and tenancy changes get more expensive as datasets, consumers and tenants grow, so the cost of inaction rises — and stating the growth rate makes the deferral cost explicit.

Industry example

Long-running modernisation programmes live or die on this number. The programmes that get funded are not the ones with the best technical argument; they are the ones that can say what the current state costs, deliver a first slice that returns something measurable, and name what is explicitly out of scope.

The last point is the one most often missed. Modernisation programmes attract every deferred wish — unify divergent processes, introduce a canonical data model, migrate the integration platform — and each addition is defensible alone. Together they mean the programme cannot deliver anything until it delivers everything, which is the second-system effect and the most common way these efforts die.

A credible case therefore pairs the cost of inaction with an incremental delivery plan and an explicit non-goals section, plus decommissioning as a dated deliverable — because perpetual coexistence, operating both systems forever, destroys the business case that funded the work.

Failure scenarios

• Asserted rather than evidenced, so it is discounted by anyone who has seen an inflated estimate.
• Aggregated across the estate, producing a large number with no actionable slice.
• Omitting engineering time consumed by incidents and workarounds, which is usually the largest component.
• No baseline captured, so the improvement cannot be demonstrated afterwards and the next case starts from scratch.

Trade-offs

Quantifying takes real effort — pulling incident data, measuring lead times, interviewing product managers about refused requests — and the result is a range rather than a figure. It also invites scrutiny of the methodology, which is uncomfortable.

The alternative is arguing from technical virtue, which reliably loses. A contested number is a far stronger position than an uncontested opinion.

Interview question

"You need two years and no new features. The CFO asks why. Give me your first three sentences, and tell me what evidence sits behind each."