1. Building the business case

Reading mode

EngineerDecision-maker

Laurent Moreau’s journal, chapter 1 (fiction)

Valenciennes, 12 March 2025. The CFO waits until everyone has spoken before dropping his figure: two hundred thousand euros in IT cost cuts over the financial year. Laurent writes it down without answering.

That same evening, Jean-Paul, the production director, calls him: the ERP has been down since 4:30 p.m., a replication failure, six hours of interruption in Valenciennes. The next day, the same thing happens in Liège, for a different reason.

On Monday, Laurent does a calculation he had never done before. How much does one hour of downtime cost? He does not know. Jean-Paul does: about eighty thousand euros of lost margin per hour in Valenciennes, at nominal output. Laurent adds up the incidents of the last twelve months: eighteen hours of cumulative downtime, all sites combined. Valued at the Valenciennes cost, that gives a high estimate of about €1.4M that nobody had ever added up.

His decision: not to answer the cut request right away. First, build a business case that changes the conversation. The problem is not removing €200,000 from the IT budget. It is demonstrating what the money invested brings in. Yet the gain shows up in production’s operating accounts, not in the IT department’s budget.

Without figures, observability remains just another IT project, and it is the first budget to be cut when things get tight. This lesson gives a method to build a case that a finance department recognizes as serious.

The real cost of incidents

Every business case starts with the cost of incidents over the last twelve months. This figure is almost always missing from existing dashboards, and its absence is already an argument: you cannot steer what you do not measure.

Four indicators structure the calculation:

• MTTD (mean time to detect): time between the start of an anomaly and its detection;
• MTTA (mean time to acknowledge): time between the alert and someone taking ownership of it;
• MTTR (mean time to recovery): time between detection and recovery;
• financial impact: margin lost during downtime, contractual penalties, customer compensation.

Cost per minute: your figure, not a study’s

The most quoted figure is Gartner’s: $5,600 per minute of network downtime on average, or about $300,000 per hour. It comes from an estimate published in 2014 by Andrew Lerner, an analyst at Gartner. It is an average, in dollars, old, and it mixes companies of all sizes. It can be used to show that an order of magnitude exists, never to put a figure on your own case.

Your figure is calculated with management control, as lost margin, not as IT cost:

hourly downtime cost  =  lost hourly margin
                       + contractual penalties per hour
                       + catch-up costs (overtime, scrap, follow-ups)
annual direct cost    =  sum of downtime hours  x  hourly cost of the system concerned

Add indirect costs separately (loss of customer trust, team hours mobilized), presenting them as an estimate along with their assumption. Mixing a validated direct cost with an assumed indirect cost weakens the whole figure.

Recommendation: the figure nobody ever wants to produce

In my view, the hardest figure to obtain in a business case is rarely the price of the platform: it is the hourly cost of a production stoppage. It may never have been calculated, or it may have been kept low so as not to worry management. I recommend not calculating it alone: do it with the site’s management controller, having them validate each assumption as you go. The figure that comes out of that session holds up in committee; the one you built on your own does not.

Calculating the return on investment

ROI (%)                  = (gains - costs) / costs x 100
payback period (months)  = initial investment / monthly gain

Gains are built from four sources, each to be quantified separately:

1. lower incident costs: fewer hours of downtime, detected earlier, recovered faster;
2. tooling rationalization: redundant licenses removed;
3. team time recovered: less alert noise, shorter diagnostics;
4. savings on the telemetry itself: see lesson 4.

Costs include licenses or infrastructure, storage, people (running the platform, instrumentation), training, change management and migration.

What does not count as a gain

The maximum NIS2 or DORA fine is not a gain: it is a risk exposure. Present it on a separate line, with its qualitative probability, rather than adding it to the gains. A CFO who sees €10M of “penalties avoided” in an ROI table stops reading the rest.

An executive committee is often more sensitive to the payback period than to ROI: “how many months until we get our money back?” speaks louder than a five-year percentage. To estimate it on your own assumptions, the MTTR business case calculates the return, the payback period and the sensitivity to assumptions.

Recommendation: beyond twelve months, change committees

In my view, a project with a payback period of more than twelve months has little chance of being approved by the executive committee of a mid-sized company. Beyond that, management sees it as a strategic bet. And a bet is decided elsewhere, often in an investment committee. I recommend one of two options: reduce the scope of the first phase to bring gains forward, or explicitly reclassify the project as strategic. A project presented somewhere in between, with a vague payback period, has little chance of getting through.

The six-step method

Order matters. Skipping a step or doing them out of order produces cases that do not convince.

flowchart LR
  E1["1. Cost of<br/>incidents"] --> E2["2. Expected<br/>gains"] --> E3["3. Full<br/>cost"] --> E4["4. ROI and<br/>payback"] --> E5["5. Three years,<br/>three scenarios"] --> E6["6. Pitch to<br/>committee"]

1. Put a figure on the cost of incidents over the last twelve months: number, duration, hourly cost per system, penalties.
2. Identify the expected gains, source by source. Make a downtime reduction assumption that you justify (for example the incidents you would have detected earlier with an alert on the user symptom).
3. Total the full cost over three years, not just the licenses.
4. Calculate the ROI and the payback period, and the net present value if your finance department uses it.
5. Project over three years with three scenarios (conservative, central, favorable) and at least two architectures compared with the same criteria (see lesson 3).
6. Pitch to the committee: five slides, ten minutes, one decision requested (see lesson 7).

The full cost, item by item

A business case that only shows licenses is disqualified at the first serious budget review. Six items are regularly underestimated:

Item	What to count	Main lever
Metrics storage	volume of active series, retention, replication	control of cardinality
Log storage	volume ingested and indexed, retention by category	hot, warm and cold tiers
Traces	spans ingested, retention	tail sampling
People	running the platform, on-call, instrumentation	automation, versioned configuration
SaaS subscriptions	billed units (hosts, volume, users, modules)	negotiation, caps, usage review
Change management	training, support, documentation	internal champions, written procedures

I do not give a price per gigabyte here, nor a total cost range by company size. They vary too much with architecture and contract to be useful out of context. The Collector cost simulator lets you put a figure on your own volume, with unit prices you enter yourself.

Six savings levers to plan from the start

These levers are decided at design time. Pulled early, they weigh on all three years of the business case.

1. Smart trace sampling: keep all traces with errors or high latency, and only a fraction of nominal traffic.
2. Differentiated retention: not all data has the same value over time; a debug log does not have the lifespan of an authentication log.
3. Controlled cardinality: no unique identifier (user, request) as a metric label.
4. An observability cost dashboard: cost per gigabyte ingested, per service, per team, with an alert on drifts.
5. Contract negotiation: commitment, caps, exit clause, always with comparable offers in hand.
6. Architecture chosen on criteria: self-managed open source, SaaS or hybrid, compared with the same grid (see the solution evaluation grid).

The effect of each lever depends on your volume and your contract. Rather than a generic percentage, measure it: the Collector cost simulator shows the bill before and after each lever.

The business case template

A template to fill in, where the “method” column matters as much as the value: that is what a CFO asks about.

Cost of incidents (last twelve months)

Item	Calculation method	Value
Major incidents	priority 1 and 2 tickets
Downtime duration	sum of downtime durations, per system	hours
Hourly cost of downtime	lost hourly margin, validated by management control	€/h
Direct cost	duration x hourly cost, per system	€
Estimated indirect cost	explicit assumption, validated or not	€
Regulatory exposure	separate line, not added to gains	qualitative

Projected gains over three years

Year	Downtime reduction assumption (to be justified)	Annual gain	Cumulative
1
2
3

Summary

Indicator	Formula	Value
Three-year ROI	(gains - costs) / costs x 100	%
Payback period	initial investment / monthly gain	months
Gains to costs ratio	total gains / total costs	to 1

Workshop: your business case

Duration: 45 minutes, alone or in pairs.

1. Put a figure on the incidents of the last twelve months: number, total duration, cumulative cost.
2. Obtain or estimate the hourly cost of downtime for your most critical system, with its assumption.
3. Formulate a downtime reduction assumption and justify it incident by incident.
4. Calculate the annual gains, the three-year ROI and the payback period in the MTTR business case.
5. Write down your two biggest uncertainties: they will be the committee’s first questions.

If you have no incident data

That is your first argument. The absence of measurement is the first symptom of a lack of observability, and the project’s first deliverable will be precisely to produce it.

My next action: what action, by what date, with whom?

Going further

• The MTTR business case, to test your assumptions.
• For an AI service: the quantified impact in the GenAI method and its exposure calculator.
• The business dimension.

Mark as read

BridgesWhat this page changes beyond the technical team.

BusinessValue, cost, risk

The key figure is not the price of the platform but the hourly cost of downtime, calculated as lost margin with management control: that is what changes the conversation.

OrganizationWho decides, who owns

A defensible business case is built by several people: CIO, management control, production managers. Assumptions validated together in a working session hold up in committee.

PeopleTeams, on-call, skills

The gains on on-call and team retention are real but hard to quantify; presenting them separately avoids weakening the rest of the case.

Business linesProduct, finance, risk, customer

For the finance department: three-year ROI, payback period in months, three scenarios, assumptions in an appendix. The format it already uses for other investments.

Why bridges matter →