Business Case Development and ROI Analysis Questions

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.

Direct answer

Assume the benefit is overstated until evidence says otherwise, and build the checks into the process: calibrate against what past projects actually delivered (the outside view), make estimates ranges with named owners, have someone independent challenge the largest and softest numbers, and measure benefits after launch so the next estimate is better. On my own proposals I apply a haircut taken from history before anyone else does; on other people's I ask for the evidence behind each benefit line and the same calibration.

Terms: a haircut is a multiplier below 1 applied to a claimed benefit (the median realisation ratio of 0.5375, shown rounded as 0.54, turns a claimed $1,200k into $645k; exactly 0.54 would give $648k); the outside view is judging a project by how similar projects went rather than by its own plan; a prior is your starting estimate before looking at this project's own evidence; a pre-mortem is a meeting that assumes the project has already failed and lists the reasons; a red-team review is an independent group tasked with attacking the case; to double count is to claim the same benefit twice (for example two projects each claiming the same saved hours). Optimism bias is the tendency to expect better outcomes than usually occur; reference-class forecasting means estimating from the results of a set of similar past projects instead of from this project's story; calibration is checking stated confidence or estimates against actual outcomes; bootstrap resamples your own data to see how much a statistic could vary.

Why cases inflate

• The author is also the advocate and is rewarded for approval.
• Selection: the projects that get proposed and funded are the ones whose estimates came out highest.
• Benefits have no owner, so nobody is accountable afterwards; costs are easy to spot and benefits are easy to double count (two projects each claiming the same saved hours).
• Costs and timelines are underestimated at the same time as benefits are overestimated.

The practices

Core (do these on every case): 1 reference class, 3 benefit owners and 6 post-implementation review. Useful additions: 2, 4 and 5. Advanced (when the stakes and data justify it): 7.

1. Reference class. Compile promised versus delivered benefit for past projects of a similar kind. Use the ratio as a prior on the new claim.
2. Ranges and drivers, not point estimates; separate what is measured, assumed and guessed.
3. Benefit owners from the business sign each line; finance validates the baseline.
4. Independent challenge: a pre-mortem (assume it failed in 18 months, list why), a red-team review of the top three assumptions, and a double-counting check across the portfolio.
5. Staged funding so the weakest assumptions are tested before the big money.
6. Post-implementation review at 6 and 12 months; the results feed the reference class. Reward accurate forecasts, not big ones.
7. Intervals around the haircut. Resample history (bootstrap) to show how uncertain the haircut itself is; a Bayesian version starts from the history as a prior and moves toward project-specific evidence only as hard evidence accumulates. A simple illustration (the weights are illustrative): if history is worth ten projects at a 0.54 ratio and a controlled pilot is worth one project at 0.90, the blended ratio is (10 x 0.54 + 1 x 0.90) / 11 = 0.57; a larger, better pilot would get more weight and move it further.

Worked example (illustrative history of ten projects, $k a year)

import random, statistics

# Illustrative history: promised vs delivered annual benefit ($k) for ten past projects
history = [(400, 210), (250, 260), (900, 380), (150, 90), (600, 330),
           (300, 300), (800, 410), (200, 70), (500, 320), (350, 150)]
ratios = [actual / promised for promised, actual in history]
print("realisation ratios:", [round(r, 2) for r in ratios])
print(f"median {statistics.median(ratios):.2f}, mean {statistics.mean(ratios):.2f}, "
      f"share of projects delivering at least 100%: {sum(r >= 1 for r in ratios) / len(ratios):.0%}")

# Bootstrap the median: resample the ten ratios with replacement, 10,000 times, seed pinned.
# Each resample gives one possible median; sorting the 10,000 medians and dropping the lowest 250 and
# highest 250 leaves the middle 95%, so positions 250 and 9750 are the 2.5th and 97.5th percentiles.
rng = random.Random(42)
meds = sorted(statistics.median(rng.choices(ratios, k=len(ratios))) for _ in range(10_000))
lo, hi = meds[250], meds[9750]
print(f"bootstrap 95% interval for the median ratio: {lo:.2f} to {hi:.2f}")

claim = 1200  # $k a year claimed by the new proposal
print(f"claimed ${claim}k -> typical ${claim * statistics.median(ratios):.0f}k "
      f"(plausible median range ${claim * lo:.0f}k to ${claim * hi:.0f}k)")

Output:

realisation ratios: [0.53, 1.04, 0.42, 0.6, 0.55, 1.0, 0.51, 0.35, 0.64, 0.43]
median 0.54, mean 0.61, share of projects delivering at least 100%: 20%
bootstrap 95% interval for the median ratio: 0.43 to 0.80
claimed $1200k -> typical $645k (plausible median range $514k to $960k)

Only 2 of the 10 past projects delivered their promise or more; the typical project delivered about 54% (median 0.54, mean 0.61), and the bootstrap interval for that median is 0.43 to 0.80. A new proposal claiming $1,200k a year therefore plans on about $645k, with a plausible range of $514k to $960k for the typical outcome. This is a prior; a proposal with a controlled pilot behind it can be assigned a ratio nearer 1, and one resting on a vendor claim a ratio at or below the median. The ten-project sample is small, so the interval is wide, and that width is the honest message.

Pitfalls

A haircut applied to everyone equally rewards the person who inflates most; use project-specific evidence to move off the prior. Do not read history as a single constant; segment by project type. And do not let the review become punitive, or people will stop recording realised benefits.

Direct answer

I first check that the 60% is real, then split the 40% gap into its causes using the same formula the forecast was built from, then take a recommendation to the sponsors that has three parts: what the gap is made of, what has been verified versus assumed, and a corrected forecast with specific actions and owners. I tell the sponsors the number plainly and early. A sponsor who hears "60%, here is why, here is the plan and the re-forecast" stays a sponsor. A sponsor who finds out from Finance does not.

Step 1: validate the measurement before diagnosing the project

A "60% realised" figure can be wrong in three boring ways, so I rule them out first (days, not weeks):

• Same definition? Is the realised number measured the way the forecast was defined (same scope, same period, same unit, same baseline)?
• Data complete? Missing feeds, a changed ticket taxonomy, or a late finance close can make benefits look smaller than they are.
• Baseline stable? If the "before" number moved for other reasons (a price rise, a reorganisation), both sides of the comparison shift.

If a deployed model is involved and its measured impact has dropped (say 15% in six months), I check data validity first and model decay second: compare the data the model sees now with the data it was built on (for example, a new customer segment or a changed form field), check whether the cut-off score that triggers an action (the decision threshold) or the process after the model changed, and test the model on a fresh sample of recent cases where the correct answer is now known (a fresh labelled sample). Model decay means the model's accuracy falls because the world drifted away from the data it learned from. It is a diagnosis you confirm, not a default excuse.

Step 2: decompose the gap with the forecast's own drivers

Rebuild the forecast as a product of drivers (the inputs it is multiplied from), then replace each forecast driver with its actual value in turn and record how much the total moves. This table of step-by-step changes is called a driver bridge. The illustrative case: a licensed analytics tool, 400 seats at USD 900 per seat per year, forecast USD 1,440,000 of annual benefit, realised USD 864,000 (60%).

SEATS = 400
LICENCE_PER_SEAT = 900            # USD per seat per year

# value = adopters x hours saved per adopter per year x loaded $/hour (hourly pay plus overheads) x share of saved hours that become real value
forecast = dict(adopters=360, hours=100, rate=50, conversion=0.80)   # 90% of 400 seats
actual   = dict(adopters=300, hours=96,  rate=50, conversion=0.60)   # 75% of 400 seats

def value(d):
    return d["adopters"] * d["hours"] * d["rate"] * d["conversion"]

step = dict(forecast)
prev = value(step)
print(f"Forecast annual benefit: ${prev:,.0f}")
for driver in ("adopters", "hours", "rate", "conversion"):
    step[driver] = actual[driver]
    now = value(step)
    print(f"  after replacing {driver:10s} with actual: ${now:>9,.0f}  (change {now - prev:>9,.0f})")
    prev = now

licence = SEATS * LICENCE_PER_SEAT
for label, v in (("forecast", value(forecast)), ("realised", value(actual))):
    print(f"{label}: benefit ${v:,.0f}, licence ${licence:,.0f}, ROI {(v - licence) / licence:.0%}")
print(f"Realised as a share of forecast: {value(actual) / value(forecast):.0%}")

# Order-dependence check: reverse the order of the substitutions
step = dict(forecast); prev = value(step)
for driver in ("conversion", "hours", "adopters"):
    step[driver] = actual[driver]
    now = value(step)
    print(f"  (reverse order) {driver:10s} change {now - prev:>9,.0f}")
    prev = now

# Licensed seats nobody uses
idle = SEATS - actual["adopters"]
print(f"Idle seats: {idle}; licence spend on them: ${idle * LICENCE_PER_SEAT:,.0f} per year")

Output:

Forecast annual benefit: $1,440,000
  after replacing adopters   with actual: $1,200,000  (change  -240,000)
  after replacing hours      with actual: $1,152,000  (change   -48,000)
  after replacing rate       with actual: $1,152,000  (change         0)
  after replacing conversion with actual: $  864,000  (change  -288,000)
forecast: benefit $1,440,000, licence $360,000, ROI 300%
realised: benefit $864,000, licence $360,000, ROI 140%
Realised as a share of forecast: 60%
  (reverse order) conversion change  -360,000
  (reverse order) hours      change   -43,200
  (reverse order) adopters   change  -172,800
Idle seats: 100; licence spend on them: $90,000 per year

Reading the output: the 576,000 gap is made of three things. Adoption (300 of 400 seats active, 75%, against 360 planned) explains 240,000. Hours saved per active user (96 versus 100) explains little, 48,000. Conversion (the share of saved hours that became real value, 60% versus an assumed 80%) explains 288,000. The hourly rate did not move. Realised ROI (benefit minus licence cost, divided by licence cost) is 140% against a forecast 300%, so the investment still pays back, but at under half the promised return.

Two cautions I would say out loud. First, the split depends on the order you substitute drivers, because each substitution changes the base the next one is measured against (cutting adopters first shrinks the pool that a lower conversion then applies to). The reversed order gives conversion -360,000, hours -43,200 and adopters -172,800, so the rule I follow is to quote only what holds in every order: adoption and conversion are the two big ones, hours saved is small, and I do not quote 240,000 as exact. Second, a driver bridge locates the gap; it does not explain it. For each large driver I write hypotheses and test them:

Step 3: what I tell the sponsors

I send the facts first and ask for decisions second. A script I would use in the meeting:

"Twelve months in, we have realised about 864 thousand dollars a year against a forecast of 1.44 million, which is 60%. I have checked the measurement with Finance and the number holds. The gap is mostly two things: only 75% of licensed seats are active, and much of the time saved has not turned into real cost or output because no budget or target changed with it. The tool itself performs close to plan. Our corrected forecast for year two is between 0.86 and 1.2 million, depending on how far adoption (300 to 360 active seats) and conversion (60% to 70%) improve. I am asking for two decisions today: first, that you personally set tool usage as an expectation for the lowest-use teams and let us reclaim idle licences; second, that you agree we count saved time as benefit only where a budget line, hiring plan or output target changes with it, and that you accept the corrected forecast and a monthly review until we recover."

Corrective actions (owner and date on each): (1) lift adoption on the lowest-use teams, with the sponsor's own managers setting usage as an expectation, and reclaim licences that stay idle (100 idle seats cost USD 90,000 a year); (2) convert saved time into something Finance can see, either by redeploying it to a named revenue-producing task or by agreeing a hiring freeze that the saved capacity supports. Then re-forecast, and move the governance to monthly benefits reviews until the realised line recovers.

A short post-benefit review structure

Use a blameless format (focus on how the process failed, not on who failed, so people bring information instead of defending themselves): summary and impact; timeline (forecast made, go-live, first measurement); measurement validation; driver analysis; root causes (separating a cause, without which the gap would not have happened, from a contributing factor, which made it worse); what we got right; actions with owners and dates; changes to how future forecasts are made (for example, require an adoption curve and a conversion assumption signed off by the budget holder).

Trade-offs and pitfalls

• Defending the original forecast instead of re-forecasting: sponsors lose trust faster from stale numbers than from a miss.
• Treating external factors as a cause without evidence: demand a control comparison before attributing a shortfall to the market.
• Fixing adoption when the real problem is conversion: more users on a tool whose time savings never reach a budget line raises the cost without raising the benefit.
• Scapegoating the forecaster: the forecast error is itself a finding about the case's assumptions.

Direct answer

With $120,000 invested and $30,000 saved each year, over four years the total saving equals the cost: ROI = 0% and payback = 4.0 years, break-even exactly at the end of the horizon. On those terms I would not recommend it on money alone, because the net present value (NPV: the total of all cash flows after shrinking each future one to what it is worth today, since money received later is worth less than money now, here at an 8% a year discount rate) is -$20,636, and the case would rest entirely on the non-financial factors and on whether the saving lasts longer than four years.

Calculation

• Total benefit over 4 years: 4 x $30,000 = $120,000.
• ROI = ($120,000 - $120,000) / $120,000 = 0%.
• Payback = $120,000 / $30,000 = 4.0 years.
• NPV at 8% (cost now, savings at each year end): -$120,000 + $30,000 x (0.9259 + 0.8573 + 0.7938 + 0.7350) = -$20,636 (each discount factor is 1 / 1.08^n for year n, so $1 saved in year 1 is worth $0.9259 today; the factors are rounded to four decimals above, so a hand calculation lands within a few dollars of that).

Assumptions behind the numbers

1. The $30,000 is a full-year, steady saving (a run-rate: the level it settles at) from year 1 (no ramp, no extra fees).
2. $120,000 is the all-in one-off cost (licence, integration, training) with no ongoing licence or support charge. If annual fees of $5,000 exist, net saving drops to $25,000 and payback becomes 4.8 years.
3. The tool is useful for at least four years (no replacement needed) and the process volume does not fall, because savings scale with volume.
4. Savings are cash that leaves the budget, not time freed that nobody reallocates.
5. Savings arrive at year end and the discount rate is 8%; costs are paid at the start.

Two non-financial factors that could still change the decision

• Error and compliance risk: automation that cuts mistakes or creates an audit trail could justify a break-even case; one that is unmaintainable or creates a new control gap could sink a profitable one.
• Capacity and strategic position: staff freed from processing could be redeployed to revenue work, or the client may need it to handle growth without hiring. Other factors of this kind include vendor lock-in (being tied to one supplier) and employee morale and change fatigue.

How the same method handles other given figures

The same method works on other figures an interviewer might give you, shown in the table below. Terms used: gross margin is the share of revenue left after the direct cost of delivering it; contribution is the yearly profit the item adds; the ramp is the period before a benefit reaches its full size.

The ramp row shows why "assumptions about the ramp" matter: one realistic delay moves payback out by about five months (40.5 against 36).

Derivation of the ramp row: $40,000 a year is $3,333 a month. Months 1 to 3 earn nothing and months 4 to 6 earn half, $1,667 x 3 = $5,000, so after 6 months $115,000 of the $120,000 is still unrecovered. At the full $3,333 a month that takes 34.5 more months, so 6 + 34.5 = 40.5, which I round up to 41. With no ramp it is simply $120,000 / $3,333 = 36 months.

Labour-saving example (illustrative inputs): 5 staff x 6 hours a week x 48 weeks = 1,440 hours; at a $50 loaded rate, $72,000 a year. Fees of $12,000 a year give a first-year net saving of $60,000. With a $30,000 one-time cost, simple payback = $30,000 / $60,000 = 0.5 years (6 months). Time-to-market line: launching 2 months earlier on a product earning $15,000 gross margin a month adds a one-off $30,000, which I show as a separate, lower-confidence benefit.

Pitfalls

A zero ROI looks like a pass ("it pays for itself") but ignores the cost of money; counting time freed as cash; omitting ongoing fees; presenting a single point estimate instead of a range.

Direct answer

Treat the benefit as a curve, not a number. Estimate the full run-rate benefit (what the improvement is worth per month once everyone is using it), multiply it each month by an adoption share that climbs from 0% toward its ceiling, and charge the costs on their real dates, which usually start before any benefit does. Then justify the curve with evidence (pilot data, rollout schedule, comparable launches), show how NPV and payback move when the curve is slower, and track the leading indicators so the ramp can be checked after approval.

Terms used below. Run-rate means the steady monthly amount once everything is fully in use. Loaded hourly cost is what an hour of an employee really costs the company (pay plus benefits, taxes and overhead share). Leading indicators are early measures (for example weekly active users) that move before the money does. NPV (net present value) is the sum of each future cash flow divided by (1 + rate) raised to the number of periods until it arrives, so later money counts for less. The discount rate is that rate (the return you could earn elsewhere, set by finance). IRR (internal rate of return) is the discount rate at which NPV is exactly zero. Payback is the first period in which cumulative cash turns non-negative. A monthly series needs a monthly rate: use (1.10)^(1/12) - 1, not 10% / 12, so twelve months of compounding gives exactly the annual 10%.

How to build the ramp

1. Full run-rate benefit. Hours saved per person x people x loaded hourly cost x the share of saved time that becomes real cash or real extra output. Freed time is only a cash saving if the capacity is redeployed to other paid work, backfilled less (a departing person is replaced by fewer new hires), or sold; say which.
2. Adoption curve = rollout x usage x proficiency. Rollout is the share of teams that have the tool (from the deployment schedule). Usage is the share of those people who use it in a given month. Proficiency is how much of the full gain a typical user gets while still learning (a new user may get half the time saving that an expert gets). For example, 80% rollout x 70% usage x 60% proficiency is 33.6% of the full benefit. Multiply them; each has its own evidence.
3. Anchor points, then interpolate. Pick a few anchors you can defend (end of year 1: 30%, year 2: 65%, year 3: 90%) and interpolate monthly (fill the months in between with evenly spaced steps from one anchor to the next). Anchors are easier for a reviewer to challenge than a formula. An S-shaped curve (slow start, fast middle, flattening) is usually more realistic than a straight line, but a straight line between honest anchors is fine.
4. Costs on their own dates. Upfront spend lands in month 0 and run costs begin immediately; neither waits for adoption.
5. Justify the shape. In order of strength: your own pilot cohort (monthly usage of the first teams), earlier rollouts at your company, then outside benchmarks. Cap the ceiling below 100% (here 90%) because not every role gets full value. State what would make it faster or slower (training, executive mandate, integration with existing tools).

Worked example (illustrative inputs)

There are two examples. Part A is the main one: a monthly 36-month model of a tool whose benefit ramps up by anchors. Part B is a second, simpler yearly example that tests how sensitive a savings ramp is to slower adoption; it uses year-end cash flows, not monthly ones. Hand check for Part A: month 1 adoption is 30% x 1/12 = 2.5%, so benefit is $80,000 x 2.5% = $2,000, less $10,000 to run = -$8,000. Each month is then discounted by (1 + 0.0080)^month, where 0.0080 is the monthly rate (1.10^(1/12) - 1 = 0.797%); the headline NPV is the sum of all 36 of these plus the -$600,000 at month 0.

A tool is worth $80,000 per month at full run-rate, costs $600,000 upfront and $10,000 per month to run, at a 10% annual rate over 36 months.

# Part A: 36 monthly cash flows for a productivity gain that ramps up
full_monthly = 80_000.0   # $/month once every team has adopted
upfront = 600_000.0       # $ spent in month 0
run_cost = 10_000.0       # $/month licences and support
annual_rate = 0.10
r_m = (1 + annual_rate) ** (1 / 12) - 1     # equivalent monthly rate
anchors = {0: 0.0, 12: 0.30, 24: 0.65, 36: 0.90}   # share of full benefit reached

def adoption(m):
    ks = sorted(anchors)
    for a, b in zip(ks, ks[1:]):
        if a <= m <= b:
            return anchors[a] + (anchors[b] - anchors[a]) * (m - a) / (b - a)

def npv(flows, rate):           # flows[0] happens now (t = 0)
    return sum(cf / (1 + rate) ** t for t, cf in enumerate(flows))

def payback_index(flows):       # first period where cumulative cash >= 0
    cum = 0.0
    for t, cf in enumerate(flows):
        cum += cf
        if cum >= 0:
            return t
    return None

ramp = [-upfront] + [full_monthly * adoption(m) - run_cost for m in range(1, 37)]
flat = [-upfront] + [full_monthly * 0.90 - run_cost for m in range(1, 37)]  # day-one 90%
for m in (1, 6, 12, 18, 24, 30, 36):
    print(f"month {m:2d}: adoption {adoption(m):5.1%}  net cash ${ramp[m]:>9,.0f}")
print(f"ramped:   NPV ${npv(ramp, r_m):,.0f}, payback month {payback_index(ramp)}")
print(f"day-one:  NPV ${npv(flat, r_m):,.0f}, payback month {payback_index(flat)}")

# Part B (second example, yearly): five-year linear savings ramp, 10% to 40% of an addressable cost base
# (addressable cost base = the annual cost the tool can actually reduce)
def irr(flows):
    lo, hi = -0.9, 10.0
    for _ in range(200):
        mid = (lo + hi) / 2
        if npv(flows, mid) > 0:
            lo = mid
        else:
            hi = mid
    return mid

base_cost, invest, run_yr, rate = 1_000_000.0, 450_000.0, 50_000.0, 0.10
def case(stretch):                 # stretch 1.0 = plan, 0.8 = 20% slower adoption
    flows = [-invest]
    for t in range(1, 6):
        # savings share rises 7.5 points a year from a 2.5% start: 10%, 17.5%, 25%, ... 40% at stretch 1
        pct = 0.025 + 0.075 * (stretch * t)     # 10% at t=1, 40% at t=5 when stretch=1
        flows.append(base_cost * pct - run_yr)
    return flows
for name, s in (("plan", 1.0), ("20% slower", 0.8)):
    f = case(s)
    # break-even = first year cumulative cash >= 0; discounted break-even = same, but each year's cash
    # is first discounted to today's money
    cum, disc, be, dbe = 0.0, 0.0, None, None
    for t, cf in enumerate(f):
        cum += cf
        disc += cf / (1 + rate) ** t
        if be is None and cum >= 0: be = t
        if dbe is None and disc >= 0: dbe = t
    print(name, [round(x) for x in f])
    print(f"  NPV ${npv(f, rate):,.0f}  IRR {irr(f):.1%}  break-even year {be}  discounted break-even year {dbe}")

Output:

month  1: adoption  2.5%  net cash $   -8,000
month  6: adoption 15.0%  net cash $    2,000
month 12: adoption 30.0%  net cash $   14,000
month 18: adoption 47.5%  net cash $   28,000
month 24: adoption 65.0%  net cash $   42,000
month 30: adoption 77.5%  net cash $   52,000
month 36: adoption 90.0%  net cash $   62,000
ramped:   NPV $228,345, payback month 29
day-one:  NPV $1,333,560, payback month 10
plan [-450000, 50000, 125000, 200000, 275000, 350000]
  NPV $254,174  IRR 25.0%  break-even year 4  discounted break-even year 4
20% slower [-450000, 35000, 95000, 155000, 215000, 275000]
  NPV $94,386  IRR 16.0%  break-even year 4  discounted break-even year 5

Reading it: adoption is only 30% at month 12, so net cash in month 1 is negative and turns positive around month 6. The ramped case gives NPV $228,345 and payback in month 29. A model that assumed 90% of the benefit from month 1 would show NPV $1,333,560 and payback in month 10, overstating NPV by about $1.1M and understating the payback time by 19 months. The ramp, not the headline benefit, is what the approval decision turns on.

Five-year linear ramp. For a savings rate that climbs linearly from 10% of an addressable cost base in year 1 to 40% in year 5 (base $1,000,000 a year, $450,000 upfront, $50,000 a year to run, 10% rate, cash at year end), the savings share is 10%, 17.5%, 25%, 32.5% and 40% of $1,000,000 (the formula 0.025 + 0.075 x t, which is 10% at t = 1 and 40% at t = 5), less $50,000 a year to run, so the cash flows are -$450,000, then $50,000, $125,000, $200,000, $275,000, $350,000. Discounted at 10% these are -$450,000, $45,455, $103,306, $150,263, $187,829 and $217,322, which add to NPV $254,174, IRR is 25.0%, and cumulative cash turns positive in year 4 (-$75,000 at the end of year 3, +$200,000 at the end of year 4). If adoption is 20% slower (the ramp reaches in 5 years only what the plan reaches in 4; the savings share is 8.5%, 14.5%, 20.5%, 26.5% and 32.5%), the savings rates are lower in every year, NPV falls to $94,386 (about 63% lower), IRR to 16.0%, and the discounted break-even moves from year 4 to year 5. The case still clears a 10% rate but with much less cushion, and adoption pace is the assumption it is most sensitive to because the costs are fixed.

Trade-offs and pitfalls

• Ramp the benefit but not the costs: costs start on their real dates, so the early months are negative. Also model the learning dip (productivity can fall slightly during onboarding); a benefit curve that rises smoothly from month 1 and ignores that dip flatters the first year.
• An S-shaped curve is one that starts slowly, speeds up in the middle and flattens near the ceiling. Do not let the ceiling creep: the curve's end point matters as much as its slope.
• Present base, slower and faster ramps together, and name the leading indicator (monthly active users, share of work done in the tool) that tells you in month 6 which one you are on.
• Dividing the annual rate by 12 gives a slightly different (wrong) monthly rate; use the equivalent monthly rate.