Business Case Development and ROI Analysis Questions

Direct answer

I treat benefits tracking as a small measurement programme that is agreed before the money is spent, not a report written afterwards. At approval I fix, for every promised benefit, a baseline (the measured "before" number), a named owner, a data source, a review rhythm, and the trigger that forces a decision. After go-live I watch leading indicators (early signals such as adoption) monthly and lagging indicators (the dollar outcome, such as cost per ticket) on a quarterly cycle. To prove the benefit came from this project and not from something else, I compare against a control group rather than against last year.

(Terms: go-live is the date the new tool starts being used; attribution is working out how much of a change was caused by this project and how much by other things; a leading indicator moves early and predicts the result, a lagging one is the result itself, such as dollars; steady state is when the benefit has settled at its full, stable level.)

1. The benefit register: one row per promised benefit

Why each column exists: the baseline stops arguments later about what "before" was. The owner must be the business leader who controls the change in behaviour, not the project manager, because the project team disbands and a benefit with no owner is nobody's job. The data source is agreed with Finance in advance so the number is not self-reported by the team that wants it to look good. The trigger turns a bad month into a decision instead of a discussion.

2. Roles, cadence and governance

• Sponsor (executive who approved the money): chairs the quarterly review and decides continue, fix or stop.
• Benefits owner (business line): accountable for the number, and for the behaviour change that produces it.
• Measurement analyst (a business intelligence (BI) analyst or data scientist, ideally reporting outside the delivery team): builds the dashboard and the attribution analysis.
• Finance partner: confirms any dollar figure that will be called "realised".

First-year rhythm: weekly adoption check during rollout, a monthly benefits dashboard for the owner, a quarterly sponsor review with Finance sign-off, and a formal 12-month review that compares realised to promised and re-forecasts the remaining years. After that, an annual check until the benefit is at steady state or the horizon in the case ends.

3. Attribution: proving it was this programme

A before/after comparison credits the project with everything else that changed (seasonality, a price change, a new hire). Where it can be arranged, keep a control group: teams, regions or customers that did not get the change. Where it cannot, build a matched comparison group with similar history. The method is difference-in-differences: the change in the treated group minus the change in the control group. For the data below, by hand: the pilot teams' cost per ticket fell from an average of USD 12.00 to USD 9.50, a fall of 2.50; the control teams, which did not get the tool, fell from 11.80 to 11.07, a fall of 0.73 (from other causes such as seasonality). Credit the project with the difference: 2.50 - 0.73 = 1.77 per ticket, and 1.77 x 280,000 tickets = about USD 495,000. A bootstrap, used further down, re-draws the monthly figures at random many times (with replacement) and recomputes the answer each time, to see how much the result would wobble if the months had come out slightly differently; the middle 95% of those results is the interval.

Worked example: verifying the promised USD 500,000 annual saving on support cost per ticket (illustrative data, six months before and six months after go-live).

import random
from statistics import mean

# Monthly cost per support ticket (USD), six months before and six months after go-live
pilot_before   = [12.1, 11.9, 12.2, 11.8, 12.0, 12.0]
pilot_after    = [9.7, 9.4, 9.6, 9.5, 9.3, 9.5]
control_before = [11.9, 11.7, 11.8, 11.9, 11.7, 11.8]
control_after  = [11.1, 11.0, 11.2, 11.1, 10.9, 11.1]
TICKETS_PER_YEAR = 280_000      # annual ticket volume in the pilot teams after go-live

def did(pb, pa, cb, ca):
    return (mean(pa) - mean(pb)) - (mean(ca) - mean(cb))

naive = mean(pilot_after) - mean(pilot_before)
effect = did(pilot_before, pilot_after, control_before, control_after)
print(f"Naive before/after change: {naive:.2f} USD per ticket -> ${-naive * TICKETS_PER_YEAR:,.0f} per year")
print(f"Difference-in-differences:  {effect:.2f} USD per ticket -> ${-effect * TICKETS_PER_YEAR:,.0f} per year")

# Bootstrap: resample the months at random 5,000 times to see how much that number could move
random.seed(11)
draws = []
for _ in range(5_000):
    r = lambda xs: [random.choice(xs) for _ in xs]
    draws.append(did(r(pilot_before), r(pilot_after), r(control_before), r(control_after)))
draws.sort()
lo, hi = draws[int(0.025 * len(draws))], draws[int(0.975 * len(draws))]
print(f"95% interval for the saving: ${-hi * TICKETS_PER_YEAR:,.0f} to ${-lo * TICKETS_PER_YEAR:,.0f} per year")
print("Promised saving: $500,000 per year")

Output:

Naive before/after change: -2.50 USD per ticket -> $700,000 per year
Difference-in-differences:  -1.77 USD per ticket -> $494,667 per year
95% interval for the saving: $443,333 to $546,000 per year
Promised saving: $500,000 per year

The naive before/after number (USD 700,000) overstates the saving because costs fell for everyone, including the control teams. The control-adjusted figure is about USD 495,000, and the 95% interval (USD 443,000 to USD 546,000) contains the USD 500,000 promise. That is the honest statement: "on track, within the margin of measurement", not "exactly 500k". For a real programme I also fix in advance: the measurement window (long enough to pass a full seasonal cycle and any ramp-up), the volume used to scale the per-ticket saving, and the rule that a saving only counts as realised when Finance can see it in a budget line, not only in a model.

4. Missing data and negative results

If a data source is missing, say so on the dashboard, show a range instead of a silent estimate, and name who fixes the feed and by when. If a result is negative, it goes on the same dashboard in the same month it is known, with the owner's remediation plan attached. Hiding a miss until the 12-month review turns a recoverable problem into a credibility problem. Remediation paths are pre-agreed: (1) fix adoption (training, workflow change, switch off the old process), (2) fix the solution (a defect or a mis-sized configuration), (3) re-forecast and reset expectations, (4) stop and release the remaining budget.

5. Other settings the same method covers

• ROI of a data-platform investment: a platform produces no benefit by itself. Track usage (active teams, queries) as leading indicators, then tie dollars to the specific decisions or products built on it, each with its own owner and register row. Allocate platform cost against those use cases.
• 24-month partnership pilot: set review points (for example months 6, 12, 18, 24) with success criteria written into the agreement, shared data access for both sides, and an explicit continue or exit decision at each gate.
• Long-term outcomes and renewals: score three families of outcome every quarter: business (dollars, cycle time), technical (uptime, error rate) and adoption (active users, depth of use). Present them in a quarterly business review (QBR, the regular vendor and customer progress meeting) so the renewal conversation is based on a scorecard that both sides have watched for a year.

Trade-offs and pitfalls

• Measurement has a cost: keep to a handful of metrics per case, each with an owner, rather than a forty-tile dashboard nobody reads.
• Counting hours saved as dollars saved: time only becomes cash if it is redeployed to revenue-producing work or avoids a hire.
• Re-baselining quietly: if a baseline must change, record why and who approved it.
• Moving the goalposts when results are good or bad: the measurement method is frozen at approval.

Direct answer

I would convert the six weeks into gross-margin dollars of extra in-season sales, not into revenue, and then discount that figure three ways: for the ramp (new products do not sell at full pace in their first weeks), for incrementality (some of the sales would have closed later in the season anyway), and for confidence that the six weeks are real (confidence is not a separate multiplier in the code; it is expressed by the spread between the conservative, base and optimistic cases, with the conservative case carrying the doubt). Here "pipeline" in "delivery pipeline" always means the build-and-release automation that ships the product, and "sales pipeline" means deals in progress. On the illustrative inputs below that gives about USD 50,000 (conservative), USD 126,000 (base) and USD 235,000 (optimistic), and I would present the conservative figure as the number the case relies on, with the base as the expected outcome. If missing the seasonal window entirely is a real risk, that is a separate, probability-weighted benefit, and I would show it on its own line.

The bridge from "six weeks sooner" to dollars

Faster delivery is only worth money if it changes something the business can observe. The chain is:

1. Calendar: which weeks does the product actually gain? If the product is sold in a 20-week season and the release moves from week 7 to week 1, the gain is six selling weeks inside the season. If the release would have landed before the season anyway, the benefit is close to zero.
2. Run rate: bookings (the value of signed deals, which is not yet recognised revenue or profit) per week at steady state (the normal selling pace once the product is established) in season, taken from last season's actual sales pipeline (not a forecast).
3. Ramp: new releases sell below steady state at first; I use a share of the steady-state rate.
4. Incrementality: of the sales in those extra weeks, only some are new; the rest are customers who would simply have bought later in the season. A sales-pipeline analysis of how last season's deals timed against the release date gives this share.
5. Margin: only gross margin (revenue less the cost of delivering it) is benefit to the business. Revenue is not profit.
6. Cost of delay: the same chain read backwards: each week of delay costs about the weekly gross-margin dollars above. In the base case below, six weeks are worth USD 126,000, so each week of delay costs about USD 21,000.

Worked example (illustrative inputs: USD 100,000 of weekly bookings in season, 70% gross margin)

WEEKS_GAINED = 6
WEEKLY_BOOKINGS = 100_000   # USD of bookings per week at steady state in season (from last season's pipeline)
GROSS_MARGIN = 0.70         # count margin, not revenue

# conservative / base / optimistic
cases = {
    #                ramp (share of steady-state sales in the extra weeks),
    #                incrementality (share of those sales that would NOT have simply closed later in the season)
    "conservative": dict(ramp=0.40, incremental=0.30),
    "base":         dict(ramp=0.60, incremental=0.50),
    "optimistic":   dict(ramp=0.80, incremental=0.70),
}
print("In-season gain from 6 extra selling weeks (gross-margin dollars):")
for name, c in cases.items():
    bookings = WEEKS_GAINED * WEEKLY_BOOKINGS * c["ramp"] * c["incremental"]
    print(f"  {name:13s} incremental bookings ${bookings:>9,.0f}   margin ${bookings * GROSS_MARGIN:>9,.0f}")

# Cliff case: without the faster pipeline the product misses the season with probability p.
# Then the benefit is p x (whole-season margin), not 6 weeks of sales.
SEASON_WEEKS = 20
season_margin = SEASON_WEEKS * WEEKLY_BOOKINGS * 0.60 * GROSS_MARGIN   # 0.60 = average ramp
for p in (0.10, 0.25):
    print(f"  cliff: P(miss season) {p:.0%} -> expected margin protected ${p * season_margin:,.0f}")

# Cash-timing value alone (pulling the same cash 6 weeks forward) is tiny
cash = 1_000_000
rate = 0.10   # cost of capital: the return the money could earn elsewhere
print(f"Time value of receiving ${cash:,.0f} six weeks sooner at {rate:.0%}: ${cash * rate * WEEKS_GAINED / 52:,.0f}")

Output:

In-season gain from 6 extra selling weeks (gross-margin dollars):
  conservative  incremental bookings $   72,000   margin $   50,400
  base          incremental bookings $  180,000   margin $  126,000
  optimistic    incremental bookings $  336,000   margin $  235,200
  cliff: P(miss season) 10% -> expected margin protected $84,000
  cliff: P(miss season) 25% -> expected margin protected $210,000
Time value of receiving $1,000,000 six weeks sooner at 10%: $11,538

Reading it: in the base case, 6 weeks x USD 100,000 x 0.6 ramp x 0.5 incremental = USD 180,000 of incremental bookings, and at 70% margin USD 126,000. Conservative inputs (0.4 ramp, 0.3 incremental) give USD 50,400; optimistic (0.8 and 0.7) give USD 235,200. The gap between the cases is large because the two factors that vary between cases, ramp and incrementality, multiply (0.4 x 0.3 = 0.12 in the conservative case against 0.8 x 0.7 = 0.56 in the optimistic one, a 4.7-fold spread in the result; margin is held at 70% in all three); of the two, the one I would argue hardest to pin down with data is incrementality.

Two other pieces:

• The cliff case: if there is a real chance that without the faster pipeline the release misses the season altogether, the benefit is that probability times the whole season's margin, because a missed season loses every selling week, not just six, so it is not simply 6 weeks of sales (USD 840,000 at the 0.60 average ramp used in the code, which is 20 weeks x USD 100,000 x 0.60 x 0.70). A 10% chance is worth USD 84,000, a 25% chance USD 210,000. I only use it when someone can point to a concrete past slip.
• Cash timing alone is small: receiving USD 1,000,000 six weeks sooner at a 10% cost of capital (the return the money could earn elsewhere) is worth about USD 11,500. It should not be the headline.

NPS and developer velocity

Net promoter score (NPS, a customer-loyalty survey score) and developer velocity (how fast engineers ship) are real but are proxies, not dollars. I list them as supporting evidence and do not add them to the total. If the sponsor insists on a dollar figure for velocity, I would use only the engineering hours that were redeployed to a named, revenue-bearing project, valued at loaded cost, and I would show that figure separately from the sales benefit so nothing is counted twice.

How conservative I would be

Present three cases and anchor the decision on the conservative one; the investment case should still clear its hurdle (the minimum return the company requires) there. Count only the in-season gain unless the cliff probability can be evidenced. Put one season in the headline and treat later seasons as upside, because next year's release timing depends on other things too, and compare the benefit with the delivery pipeline's full cost over the same period.

Trade-offs and pitfalls

• Counting revenue rather than margin overstates the benefit by roughly the inverse of the margin.
• Assuming every extra week sells at steady-state pace.
• Forgetting that six weeks sooner is only valuable if marketing, sales enablement and support are ready to sell in week one.
• Double counting velocity: the same engineer hours cannot both be a cost saving and the cause of the six weeks.

Direct answer

With little internal data, triangulate (cross-check one number against independent sources): collect the same benchmark from at least two independent kinds of source, check each against a short validation test, then translate the benchmark into a conservative input by taking a typical value instead of the best case, narrowing it to the part that applies to you, applying a ramp, and recording the range. Mark the input low-confidence and put a measurement step in the plan so the number gets replaced by your own data.

Six sources and how to check each

Use interviews to understand the mechanism and the range, not as a point estimate.

Turning a benchmark into a conservative input

1. Take a typical value from the distribution, not the headline: the median (the middle result when all are sorted) or the lower quartile (the value a quarter of results fall below, a deliberately cautious pick). Example: a vendor headline of 30% against a median customer at 20% means start from 20%.
2. Discount for selection bias where the source is a vendor or a case study (a haircut, a deliberate percentage cut to a number you do not fully trust, of one half is a defensible starting point, labelled as a judgement; if reference customers report getting 70% of the headline, cut by 30% instead, and show 25% and 75% haircuts as the range).
3. Restrict to the share of your volume the effect actually applies to.
4. Apply a ramp (benefits start small and build to full rate), because benefits arrive gradually.
5. Cross-check with a second, independent source and take the lower of the two when they disagree.
6. Record the range and a confidence level, and plan a pilot to replace the borrowed number.

Worked example (illustrative numbers)

A vendor says its tool cuts support tickets by 30%. We handle 10,000 tickets a month at $12 each.

• Headline: 30% x 10,000 x $12 x 12 months = $432,000 a year.
• Haircut for vendor selection bias: 30% becomes 15%.
• Applicable share: the tool only covers 60% of our ticket types, so 15% x 60% = 9% of all tickets.
• Steady state: 9% x 10,000 = 900 tickets a month x $12 x 12 = $129,600 a year.
• Year one with a 50% ramp: $64,800.
• Cross-check with a second source: an industry-body survey reports a median 10% ticket reduction on covered tickets for similar tools. Our 15% is higher, so I take the lower, 10%, and the input becomes 10% x 60% = 6% of all tickets, 600 a month x $12 x 12 = $86,400 a year. Had the survey said 18%, our 15% would stand and the figures below apply.
  The model input after the cross-check is therefore the lower figure, $86,400 a year (20% of the vendor headline, $86,400 / $432,000), with year one at 50% ramp of $43,200. The $129,600 a year (30% of the headline, year one $64,800) is what the vendor figure alone would give after the haircut and the applicable-share step, and I show it as the upper end of the range, not as the input. This example starts from the vendor's headline 30% because no median-customer figure was supplied; had one been (the 20% in step 1), I would start from that and then apply the haircut. If a four-week pilot on one team then shows a ticket reduction of at least 10% on the ticket types the tool covers (6% of all tickets), the $86,400 input is confirmed (a result near 15%, 9% of all tickets, would support moving up toward $129,600); if it shows 5% on covered tickets (3% of all), it is cut before the case is presented.

Pitfalls

• Using a benchmark whose definition differs from yours ("ticket" and "contact" are not the same thing).
• Compounding haircuts until the case is too pessimistic to fund. Say what each haircut is for and keep the range, so the reader sees the realistic middle.
• Treating a number as validated because several vendors repeat it. Repetition is not independence.

Direct answer

I build the case in five moves: frame the decision, gather and validate data, model costs and benefits with scenarios, stage the risk, then present differently to the CFO (chief financial officer) and CEO (chief executive officer). The CFO needs defensible numbers and a clear owner for each; the CEO needs the decision, the options and the strategic trade-off. Throughout, the aim is a case that survives challenge, not one that wins on a single optimistic figure.

1. Frame the decision

One sentence: "Should we invest $2M over 12 months in X, versus the status quo and one cheaper alternative?" Name the sponsor, the functions that bear costs (engineering, data, operations, marketing) and the ones that capture benefits. Agree the horizon (3 to 5 years) and the hurdle rate (the minimum return an investment must earn to be worth doing; it is used as the discount rate, the percentage by which future money is shrunk to express it in today's value) with finance before modelling.

2. Data to gather

• Baseline: current revenue, volumes, conversion, cost-to-serve (what it costs to deliver the product to each customer) and failure rates, from the system of record, signed off by finance.
• Costs: quotes, engineering estimates with contingency, run costs, shared overhead, change management, and the opportunity cost of the people.
• Benefit drivers: the specific lever (uplift in conversion, hours saved, churn avoided), with benchmarks, pilots, or expert interviews where no internal data exists.
• Constraints: capacity, dependencies, regulatory points.

3. Model and scenarios (worked example)

A personalisation engine costing $2,000,000 to build and $250,000 a year to run. Online revenue is $400,000,000, contribution margin 30% (the share of each revenue dollar left after the variable costs of making that sale, so extra revenue is worth 30 cents on the dollar to profit). The uncertain driver is revenue uplift. Benefits begin after build; cash at year end, 5-year horizon, 10% discount rate. For simplicity the model below treats the $2,000,000 as spent today and the five years of benefit and run cost as starting in year 1. Sensitivity to that simplification: the proposal says the build takes 12 months, and if benefits and run costs only start in year 2 (four years of benefit), the discount-factor sum is 3.7908 - 0.9091 = 2.8817, so Base NPV falls from +$1,601,247 to +$737,611, Low to -$991,406, and break-even uplift rises from 0.65% to 0.79% ($2,000,000 / 2.8817 + $250,000 = $944,036 a year, divided by $400,000,000 x 0.30 = $120,000,000 of contribution per 100% uplift). The phase-1 pass threshold of 0.8% proposed in section 4 would then barely clear break-even, so I would set the gate higher or confirm the build timeline before fixing it.

How NPV works. Net present value (NPV) is the total of all future cash flows, each shrunk back to today's money, minus the cost paid today. A dollar arriving at the end of year t is worth 1 / 1.10^t dollars today at 10%. The five yearly discount factors are 0.9091, 0.8264, 0.7513, 0.6830 and 0.6209, and they add up to 3.7908. So a steady yearly net benefit is worth (yearly net) x 3.7908 today. Traced for the Base row: $950,000 x 3.7908 = $3,601,247 today, minus the $2,000,000 build = +$1,601,247. Low: $350,000 x 3.7908 - $2,000,000 = -$673,225. High: $1,550,000 x 3.7908 - $2,000,000 = +$3,875,719.

Break-even uplift is the benefit that makes NPV zero. Set (annual contribution - $250,000) x 3.7908 = $2,000,000 and solve: annual contribution = $2,000,000 / 3.7908 + $250,000 = $527,595 + $250,000 = $777,595 a year, which is 0.65% uplift ($777,595 / ($400,000,000 x 0.30)). So the project pays if the uplift exceeds about 0.65%, and the sensitivity is steep: the whole case hinges on one number we have not yet measured.

4. Stage the risk

Instead of approving $2M outright, propose $400,000 for phase 1: a controlled experiment (A/B test, with a holdout group that does not get the feature), with a pre-agreed pass threshold (for example, measured uplift above 0.8%, which clears the 0.65% break-even if benefits start in year 1 but only just clears the 0.79% break-even if they start in year 2, so I would confirm the build timeline before fixing the threshold) before releasing the remaining $1.6M. This converts a $2M bet into a $400,000 option on a $2M bet: like a financial option, you pay a small price now for the right, not the obligation, to make the larger investment later, and that right is worth something because you only exercise it if the evidence is good, so most of the downside never happens. Include KPIs (key performance indicators: measurable targets) with owners and dates, and a measurement plan that finance co-owns so benefits are not self-reported.

5. Presenting the trade-offs

• To the CFO: assumptions page, base/low/high NPV, payback, break-even, the contingency, who owns each benefit line, how realised value will be tracked and reported against the case.
• To the CEO: the decision, three options (do nothing, staged, full commit), the strategic reason (competitors, customer expectation), the capital at risk at each gate, and my recommendation (staged). One page, no model.

Same skeleton for two other shapes

Pitfalls

Presenting only the base case, burying the assumption that drives value, leaving benefits unowned, and asking for the full budget before any evidence exists.

Direct answer

For a feature's one-page business case I always include net present value (NPV), payback period and return on investment (ROI), and I state the investment they rest on. NPV answers "is it worth doing once the timing of cash is counted"; payback answers "how long is our money at risk"; ROI answers "what do we get per dollar". Each covers a weakness of the others, and executives can read all three in seconds.

Four terms first. The discount rate is the annual percentage by which future money is marked down because money later is worth less than money now: at 10%, $100,000 received in year 3 is worth $100,000 / 1.10^3 = $100,000 / 1.331 = $75,131 today. The hurdle rate is the minimum return the company requires before approving a project. 'Ramping' means the benefit builds up gradually (here $70,000, then $120,000), and a result is 'sensitive' to an assumption when changing it moves the answer a lot.

One-line template and rationale for each metric

Worked example (illustrative figures)

Feature: a guided set-up checklist for new customers. Build cost $180,000 one-time. Running cost $20,000 a year. Gross benefit from fewer drop-offs: $70,000 in year 1 (ramping), $120,000 in years 2 and 3. Net annual benefit therefore $50,000, $100,000, $100,000.

• Cumulative position: -$180,000, -$130,000, -$30,000, +$70,000. Crosses zero in year 3: payback = 2 + $30,000 / $100,000 = 2.3 years (about 28 months).
• ROI over 3 years = ($250,000 - $180,000) / $180,000 = 38.9%.
• NPV at 10% = -$180,000 + $50,000/1.10 + $100,000/1.21 + $100,000/1.331 = +$23,231.

One-liners: "NPV +$23,000 at 10% over 3 years. Payback 2.3 years. ROI 39% over 3 years." The honest reading is positive but thin: NPV of $23,231 is only about 13% of the $180,000 cost, and NPV drops to zero if the year 2 net benefit falls from $100,000 to about $71,900 (a 28% shortfall: the $23,231 of NPV cushion, grown by 1.21 to year-2 terms, is $28,109). For judging whether the metrics are good, compare each with a threshold: NPV above zero at the company's hurdle rate; payback inside the period the company tolerates (often 2 to 3 years, set by finance); and ROI above what alternative uses of the money would return over the same period (38.9% over 3 years is roughly 13% a year simple, so it is clearly above a 10% hurdle but not by a wide margin). I would also add the one assumption it is most sensitive to (the year 2 benefit of $100,000 net) beside the numbers.

Sections of the one-pager

1. Problem (the customer or business pain, one sentence, with the evidence).
2. Proposed solution and scope (what ships, what does not).
3. Costs (one-time and recurring, from the table).
4. Benefits (how the number is derived, with a confidence level: quoted, measured in a test, or estimated).
5. The three metrics above.
6. Timeline (milestones and when benefit begins).
7. Risks and the decision requested (what you need approved, by when).

Level of detail by audience

• Finance leader: assumptions list, discount rate, treatment of ramp, range of outcomes. Ask them to own the baseline.
• Product manager or engineering peer: cost breakdown by team, dependencies and sequencing.
• Executive sponsor: the three one-liners, the decision, the top two risks; the model sits in an appendix.

Pitfalls

Quoting ROI without a period, hiding the horizon in the footnote, or giving only the favourable case. A one-pager with a single point estimate invites the sceptical "what if you are wrong"; a low and a high case in one extra line answers it.