Business Case Development and ROI Analysis Questions

Direct answer

I would justify an observability platform (tooling that collects logs, metrics and traces so teams can see why a system is failing) by tying it to the cost of incidents. Inputs: incident counts and durations today, how long detection and repair take (mean time to detect, MTTD, and mean time to repair, MTTR), how many engineers each incident pulls in, their loaded hourly cost, the dollar cost of customer-visible downtime, current tooling spend, and the platform's licence and instrumentation cost. Make the assumptions explicit (how much MTTR falls and when), compute benefits from them, and show payback on a monthly timeline with a downside case. On my illustrative numbers payback is about 27 months, which tells me to scope the first phase tightly.

Inputs I would gather

1. Incident history for 12 months: count by severity, customer-impacting or not, duration, time to detect, time to repair.
2. People cost: engineers per incident, loaded hourly rate.
3. Downtime cost: lost margin per hour, SLA credits (service-level agreement refunds), support load.
4. Today's tooling: current monitoring licences and the engineering time to keep them running.
5. Proposed cost: licence (often usage-based, meaning you pay by the volume of logs and metrics ingested, i.e. sent into the platform), one-time instrumentation effort, training.
6. Baseline KPIs (key performance indicators, the numbers you will track before and after) to track: MTTD, MTTR, alert volume, change failure rate (the share of deployments that cause an incident or need a fix).

Assumptions to state out loud

• MTTR falls by 30% (from 2.5 to 1.75 hours), and what the evidence for that is (vendor case studies are marketing; use a pilot on one service).
• Benefits start only after instrumentation is done (here month 7).
• Only customer-impacting incidents carry downtime cost.
• Tool consolidation savings are only counted if contracts are actually cancelled.

Worked example (illustrative)

One-time instrumentation (adding the code and agents that make each service emit logs, metrics and traces): the figure used in everything below is $180,000, which is 12 engineer-months at $15,000 a month (for example 2 engineers for 6 months, a deliberately narrow first phase). A broader scope of 3 engineers for 6 months would be 18 engineer-months = $270,000 and would push payback out further, which is one reason to scope tightly. The $180,000 is spread over months 1 to 6, with the licence also paid from month 1 ($10,000 a month) and benefits beginning in month 7.

Cumulative cash: by month 6 it is -$180,000 - $60,000 = -$240,000. From month 7, the net is $140,400 / 12 = $11,700 a month, so recovering $240,000 takes about 20.5 more months: payback at about month 27. If benefits come in at half the estimate, gross benefit is $260,400 / 2 = $130,200 and net run-rate is $130,200 - $120,000 = $10,200 a year after the licence (all benefit lines halved), so recovering $240,000 would take about 24 years, and the project does not pay back in any reasonable horizon. The assumption the result is most sensitive to is therefore the MTTR reduction on customer-impacting incidents.

Other situations that use the same frame

The main example above carries the full arithmetic; the variations below reuse its steps (baseline cost, assumed improvement, cost, payback, downside), so apply them in that order.

• Proactive monitoring versus reactive support: baseline tickets and escalations, count what proactive alerts would have caught earlier.
• Company-wide adoption: add developer context-switch time (the lost focus when an engineer is pulled off planned work by an unclear alert) only if you can measure it, otherwise report it as qualitative.
• Six-month, three-engineer programme or an SRE (site reliability engineering) rollout across four teams: cost them as engineer-months at loaded rate and show the opportunity cost.
• Generative-AI chatbot ROI plan: needs data (ticket volumes, resolution rates), metrics (deflection rate, the share of tickets resolved without a human agent; quality), and a horizon with a pilot gate. Illustrative: 40,000 tickets a year x 25% deflected x $6 saved per ticket = $60,000 a year, to be set against the chatbot's licence and tuning cost before any commitment.

The short executive pitch

"Every customer-impacting incident costs us about $8,000 an hour in margin and pulls four engineers off roadmap work. We have 30 such incidents a year averaging 2.5 hours. Better visibility should find causes faster and cut repair time by about 30%, worth roughly $180,000 a year in downtime alone, before licence costs. We want to start with the three services that cause most incidents, prove the reduction in a quarter, then expand." Anticipated counterarguments: cost (answer with the pilot and the retire-two-tools offset) and complexity (answer with the phased scope and a named owner).

Pitfalls

Counting a platform's benefit as a percentage of all engineering time; ignoring ingest-cost growth (the licence rising as data volume grows); counting benefits before instrumentation exists; and presenting one number rather than a base, downside and the gating pilot.

Direct answer

The $10M is justified only if three value levers together clear about $5.45M a year at steady state, and my base case reaches $6.09M a year, a thin margin of about 12%. The base case is a three-year net present value (NPV: future cash flows converted to today's money at a discount rate) of roughly +$1.0M, the best case +$8.7M, the worst case -$5.9M. Because the base case is thin and rests on one soft assumption (how much saved engineering time turns into real cash), I would ask the CFO (chief financial officer) to release the money in gated tranches (instalments, each released only when evidence shows the last one worked), not as one $10M approval.

Where the value comes from (illustrative company, every input stated)

Illustrative inputs: 1.2 million support tickets a year at $6 each; 400 engineers at $180,000 fully loaded cost (salary plus benefits and overhead); $300M of revenue touched by AI-assisted features. The $10M is spent $5.0M, $2.5M and $2.5M over three years, and benefits ramp to 25%, 70% and 100% of steady state. The discount rate is 10% (illustrative; the CFO will supply the company's own).

Contribution margin is the share of each extra revenue dollar left after the costs that rise with it (35 cents here), so $300M x 1% = $3M of extra revenue is worth $1.05M of profit. "Realised" is the share of saved time that becomes cash (avoided hires, reduced contractor spend) rather than the same people doing slightly different work. It is the number the CFO will attack.

RATE = 0.10                      # illustrative discount rate
COST = [5.0, 2.5, 2.5]           # $M in years 1-3 (total $10M)
RAMP = [0.25, 0.70, 1.00]        # share of steady-state benefit reached in each year

def run(name, tickets_m, deflect, per_ticket, engineers, time_saved, loaded_k,
        realised, rev_base_m, lift, margin=0.35):
    support = tickets_m * deflect * per_ticket                # M tickets x $/ticket = $M/yr
    prod = engineers * time_saved * loaded_k / 1000 * realised  # only the share turned into avoided hiring
    rev = rev_base_m * lift * margin                           # incremental revenue x contribution margin
    steady = support + prod + rev
    flows = [-c + steady * r for c, r in zip(COST, RAMP)]
    npv = sum(f / (1 + RATE) ** (t + 1) for t, f in enumerate(flows))
    print(f"{name:9s} support={support:4.2f} prod={prod:4.2f} rev={rev:4.2f} steady={steady:5.2f} "
          f"flows={[round(x, 2) for x in flows]} NPV={npv:6.2f}")
    return npv

# name, tickets(M/yr), deflection, $/ticket, engineers, share of time saved, $k loaded cost, realised, revenue base $M, lift
run("Base",  1.2, 0.30, 6.0, 400, 0.08, 180, 0.50, 300, 0.010)
run("Best",  1.2, 0.40, 6.0, 400, 0.12, 180, 0.70, 300, 0.020)
run("Worst", 1.2, 0.15, 6.0, 400, 0.04, 180, 0.20, 300, 0.000)

pv_cost = sum(c / (1 + RATE) ** (t + 1) for t, c in enumerate(COST))
pv_ramp = sum(r / (1 + RATE) ** (t + 1) for t, r in enumerate(RAMP))
print("PV of cost $M:", round(pv_cost, 2), "| steady-state benefit needed for NPV 0, $M/yr:", round(pv_cost / pv_ramp, 2))
for r in (0.0, 0.2, 0.4, 0.5, 0.6):
    run(f"real={r:.1f}", 1.2, 0.30, 6.0, 400, 0.08, 180, r, 300, 0.010)

The ramp (25%, 70%, 100%) is the share of steady-state benefit reached each year as teams adopt the platform: one or two teams live in year 1, most in year 2, all in year 3. In a real room I would justify it from the adoption curve of a comparable internal platform launch or a pilot, not from preference. The yearly amounts of $5.0M, $2.5M and $2.5M are all-in spend, so running the platform is already inside them; there is no separate running-cost line.

Output:

Base      support=2.16 prod=2.88 rev=1.05 steady= 6.09 flows=[-3.48, 1.76, 3.59] NPV=  0.99
Best      support=2.88 prod=6.05 rev=2.10 steady=11.03 flows=[-2.24, 5.22, 8.53] NPV=  8.68
Worst     support=1.08 prod=0.58 rev=0.00 steady= 1.66 flows=[-4.59, -1.34, -0.84] NPV= -5.91
PV of cost $M: 8.49 | steady-state benefit needed for NPV 0, $M/yr: 5.45
real=0.0  support=2.16 prod=0.00 rev=1.05 steady= 3.21 flows=[-4.2, -0.25, 0.71] NPV= -3.49
real=0.2  support=2.16 prod=1.15 rev=1.05 steady= 4.36 flows=[-3.91, 0.55, 1.86] NPV= -1.70
real=0.4  support=2.16 prod=2.30 rev=1.05 steady= 5.51 flows=[-3.62, 1.36, 3.01] NPV=  0.10
real=0.5  support=2.16 prod=2.88 rev=1.05 steady= 6.09 flows=[-3.48, 1.76, 3.59] NPV=  0.99
real=0.6  support=2.16 prod=3.46 rev=1.05 steady= 6.67 flows=[-3.33, 2.17, 4.17] NPV=  1.89

Hand check of the base case NPV: year flows are -5.0 + 0.25 x 6.09 = -3.48, -2.5 + 0.70 x 6.09 = +1.76 and -2.5 + 1.00 x 6.09 = +3.59 ($M). Discounting each at 10%: -3.48 / 1.10 = -3.16, 1.76 / 1.21 = +1.45, 3.59 / 1.331 = +2.70, which sum to about +0.99. The $5.45M break-even is the same idea backwards: the present value of the spend is 5.0/1.10 + 2.5/1.21 + 2.5/1.331 = 4.55 + 2.07 + 1.88 = 8.49, one dollar of steady benefit is worth 0.25/1.10 + 0.70/1.21 + 1.00/1.331 = 1.557 of present value across the ramp, and 8.49 / 1.557 = 5.45. Why discount at all: $1.00 arriving in year 3 is worth about $0.75 today at 10% (1 / 1.331), because money in hand today could earn a return.

Base, best and worst

The base case is only just above the $5.45M a year needed for NPV zero. In the worst case, benefits are below that year's $2.5M spend in years 2 and 3 (net cash flows of -$1.34M and -$0.84M), which is the signal to stop rather than to keep funding.

The assumptions the CFO will probe, in order

1. Realised share of engineering time. It is the most sensitive input: NPV falls to -$3.49M at 0% realised and crosses zero at about 40%. I would say the case does not stand on productivity alone and show the support lever separately, because that one has a cash line in the ledger.
2. Adoption and ramp. The 25%, 70%, 100% ramp assumes teams actually use the platform. Show the adoption target per business unit.
3. Support deflection rate. Ask what share of tickets the model resolves without a human, measured how, and what the customer-satisfaction guardrail is.
4. Run cost (ongoing usage fees and hosting, inside the yearly spend above). AI platform costs move with usage and model pricing; show cost per unit of work (for example dollars per ticket resolved) and a price-change scenario.
5. Attribution (proving the lift was caused by the feature). Revenue lift must be measured against a holdout (customers who did not get the feature) or it will be discounted to zero.
6. Alternatives. Buying vendor tools instead of building; the case should say why not.

Staging the ask

Tranche 1: $2M to put two use cases into production with a measured baseline (what the process costs today). Tranche 2: $3M to complete year one, released when the first use cases show measured deflection or time-to-delivery gains against baseline. Then $2.5M in each of years 2 and 3, each tied to adoption and the benefit run-rate. The most I can lose before the first real evidence is the $2M. This turns a $10M leap into a decision the CFO can reverse.

Trade-offs and pitfalls

• A single headline ROI percentage hides the shape: the first year is negative in every case and the payoff depends on ramp.
• Counting all saved time as cash is the classic overstatement; separate cash savings from capacity.
• Three years is short for a platform. A five-year view adds more benefit but also more run cost and more uncertainty; I would show it as a second view, not replace the three-year one.
• What flips my call: if measured realisation stays under 40% after the first tranche, I would not release the rest as an efficiency case and would either shrink scope or reframe it as a strategic capability bet, which needs a different approval conversation.