Business Case Development and ROI Analysis Questions

Direct answer

On a three-year view at 8%, the cloud option has a net present value (NPV, the sum of each year's cash discounted back to today, meaning future money is divided by 1.08 for each year of waiting because a dollar later is worth less than a dollar now, the 8% being the discount rate) of -$718,968 against -$760,794 for on-premises (on-prem), so cloud is cheaper by about $41,800, roughly 5%. That gap is small enough that the decision turns on things I would verify first, notably the horizon and the hardware's remaining value. Over five years the ranking reverses.

Cash flows (all costs shown as negatives, in dollars)

Convention: money at the start is year 0 (not discounted); each later year's cash is received at year end and divided by 1.08 raised to the year number.

NPV on-prem = -400,000 - 140,000 x (0.9259 + 0.8573 + 0.7938) = -$760,794.
NPV cloud = -150,000 - 240,000/1.08 - 210,000/1.08^2 - 210,000/1.08^3 = -$718,968.

Both numbers are negative because these are cost-only flows; the less negative option is cheaper in present-value terms.

What the answer is sensitive to

Break-even subscription is the yearly price at which cloud NPV equals on-prem NPV; I found it by solving that equality (a spreadsheet goal-seek does the same). Over 3 years it is about $226,000 a year (8% above the quoted $210,000); over 5 years about $196,000. Worked check for 3 years: at $226,230 cloud NPV = -150,000 - 256,230/1.08 - 226,230/1.08^2 - 226,230/1.08^3 = -$760,794, equal to on-prem. Because the quoted price is within 8% of break-even for 3 years, it sits on a knife edge (a small change in a price or assumption flips the answer). The 5-year rows use the same method: on-prem 140,000 for years 1 to 5 and cloud 210,000 for years 2 to 5 (240,000 in year 1).

What I would verify before recommending either

1. The horizon and the residual value (what the hardware could still be sold for or used for at the end of the period): how long the hardware really lasts and what it is worth at the end, since it flipped the result above.
2. Staff: who runs each option and how many people (on-prem needs administrators; cloud needs cloud operations skill), and whether any are actually released.
3. Hidden on-prem costs: power and cooling, backup, refresh cycle, security, licences. Depreciation is not a cash flow: depreciation is the accounting practice of spreading an asset's cost over its useful life as a yearly expense, but the cash left the bank in year 0 when the hardware was bought, so counting depreciation as well would count the cost twice. It stays out of the NPV; it matters only through tax (depreciation reduces taxable profit), which finance can add separately.
4. Hidden cloud costs: data egress (fees for moving data out), growth in usage, support tier, price-escalation clauses (contract terms that let the vendor raise the price each year), and whether $210,000 is a committed figure (fixed whatever you use) or a usage-based one (varies with consumption).
5. Migration risk: is $150,000 a quote or an estimate, and what contingency applies?
6. Non-cost factors: capacity for growth, resilience, compliance, and speed of delivery.

Recommendation

On these numbers it is a cost tie, so I would not decide on cost alone. I would recommend cloud only if the hardware needs refreshing within the horizon, growth is expected, and the subscription can be fixed for three years; otherwise I would keep on-prem and revisit at refresh. I would say that to the approver, with the table above.

Other shapes, same method

• Perpetual licence versus subscription (5 years): perpetual licence $300,000 plus hardware $60,000 up front and support at 10% of licence ($30,000 a year) gives NPV -$479,781; a $90,000 a year subscription (paid at year end for simplicity) gives -$359,344. Perpetual: -360,000 - 30,000 x (0.9259 + 0.8573 + 0.7938 + 0.7350 + 0.6806) = -$479,781; subscription: -90,000 x 3.9927 = -$359,344. If both options deliver the same operating savings (the same benefit either way), it cancels out of the comparison, so leave it out and compare only the costs that differ.
• 500-user SaaS (software delivered as a subscription) with 5% annual churn (users leaving each year): seats fall 500, 475, 451, 429, 407 across five years, so at $480 per user a year cost falls from $240,000 to $195,482; but check minimum-seat commitments, because many contracts do not let spend fall with churn.
• Three deployment models (on-prem, cloud-managed, SaaS): one column per model, discount to NPV, show finance the cash flows and technical teams the assumptions list.
• Tool consolidation, DB to managed service, ERP to SaaS: use the same table with line items for licences, support, internal maintenance, migration, one-time downtime and hardware disposal, and test the service cost at plus and minus 20%.
• A template without numbers: list the inputs (cost lines by year, discount rate, horizon, residual value, staff effect) so each team fills in its own.

Direct answer

On the numbers as given, the case does not work: a $2M-a-year running cost against a $1.5M-a-year benefit loses $0.5M every year, so the net present value (NPV, future cash converted to today's money at a discount rate, a yearly percentage that makes later cash count for less: at 10%, $1.10 a year from now is worth $1.00 today) is negative at any horizon. Before building a case, I would ask what the $2M is. In payments migrations it is often the gross running cost of the new platform, while the old platform's running cost disappears. If the legacy system costs, say, $1.6M a year to run (my assumption, to be confirmed; in a real room I would get it from the bank's finance team as the legacy platform's licence, hosting, support contract and operating staff cost from the cost-centre ledger), the net annual benefit becomes $1.1M and the case is roughly break-even on time, but negative once regulatory delay, failure risk and customer attrition are priced in. I would tell the board exactly that, show three scenarios plus the failure case, and name the extra benefit that would make it pay.

The model

Illustrative inputs: discount rate 10% (the board will supply its own); migration cost $4M spent up front; new platform runs at $2M a year; stated benefit $1.5M a year; legacy running cost saved $1.6M a year (to confirm); six years after the spend. The three risks:

• Regulatory delay: 25% chance that go-live slips by a year. The delay costs $0.6M of holding cost (the cost of keeping the team and old system waiting) in that year, defers the benefits and the legacy saving by a year, and the delayed year's new running cost is not incurred.
• Failed migration: 15% chance. The $4M is lost, plus $1.0M to roll back (undo the cutover) and remediate (fix what broke), and no benefit arrives; the flows are -$4.0M now, -$1.0M in year 1 and zero after.
• Customer attrition (customers leaving): at cutover, customers leave in the on-time and delayed scenarios, costing $0.3M a year of margin for the three years after go-live.

Probabilities: on time 60%, delayed 25%, failed 15% (illustrative, to be replaced by risk-team estimates). The probability-weighted result is the expected NPV: each scenario's NPV multiplied by its probability, then added.

def npv(rate, flows):
    return sum(cf / (1 + rate) ** t for t, cf in enumerate(flows))

def irr(flows):
    lo, hi = -0.99, 1.0
    if npv(lo, flows) * npv(hi, flows) > 0:
        return None
    for _ in range(200):
        mid = (lo + hi) / 2
        if npv(lo, flows) * npv(mid, flows) <= 0:
            hi = mid
        else:
            lo = mid
    return mid

def pct(x):
    return 'none' if x is None else f'{x*100:.1f}%'

RATE = 0.10          # illustrative discount rate
MIGRATION = 4.0      # $M, spent at t=0
RUN = 2.0            # $M/yr new platform running cost
BENEFIT = 1.5        # $M/yr stated benefit
LEGACY = 1.6         # $M/yr legacy running cost retired (ASSUMPTION to confirm)
ATTR = 0.3           # $M/yr margin lost to attrition, 3 years after cutover
YEARS = 6

def success(benefit=BENEFIT, attr=ATTR, legacy=LEGACY, delay=0, hold=0.0):
    f = [-MIGRATION] + [0.0] * YEARS
    for y in range(1, YEARS + 1):
        if y <= delay:
            f[y] -= hold
            continue
        f[y] += benefit + legacy - RUN
        if y - delay <= 3:
            f[y] -= attr
    return f

def failure():
    f = [-MIGRATION] + [0.0] * YEARS
    f[1] = -1.0   # rollback and remediation
    return f

literal = success(legacy=0.0, attr=0.0)
print("Literal reading (no legacy saving), yearly net:", [round(x, 2) for x in literal])
print("  NPV $M:", round(npv(RATE, literal), 2), " IRR:", pct(irr(literal)))

sc = {
 "On time":  (success(), 0.60),
 "Delayed":  (success(delay=1, hold=0.6), 0.25),
 "Failed":   (failure(), 0.15),
}
ev = 0
for k, (f, p) in sc.items():
    n = npv(RATE, f); ev += p * n
    print(f"{k:8s} p={p:.2f} NPV={n:6.2f} IRR={pct(irr(f))}")
print("Probability-weighted NPV $M:", round(ev, 2))

up = success(benefit=1.8, attr=0.0)
down = success(benefit=1.2, attr=0.6, delay=1, hold=0.6)
for k, f in (("Upside", up), ("Downside", down)):
    print(f"{k:8s} NPV={npv(RATE,f):6.2f} IRR={pct(irr(f))}")
print("On-time yearly net cash $M:", [round(x, 2) for x in success()])
print("Delayed yearly net cash $M:", [round(x, 2) for x in sc["Delayed"][0]])
cum, running = 0.0, []
for x in success():
    cum += x
    running.append(round(cum, 2))
print("On-time cumulative cash $M:", running)

def ev_npv(extra):
    s = success(legacy=LEGACY + extra)
    d = success(legacy=LEGACY + extra, delay=1, hold=0.6)
    return 0.60 * npv(RATE, s) + 0.25 * npv(RATE, d) + 0.15 * npv(RATE, failure())
lo, hi = 0.0, 5.0
for _ in range(60):
    mid = (lo + hi) / 2
    if ev_npv(mid) < 0: lo = mid
    else: hi = mid
print("Extra $M/yr needed for EV NPV = 0:", round(mid, 2), " check:", round(ev_npv(mid), 3))

What the code does, in plain words. npv divides each year's cash by 1.10 raised to that year and adds them up. irr finds the rate that makes NPV zero by halving: try a rate, see whether NPV is positive or negative, and keep the half of the range that still brackets zero, 200 times. The last loop does the same halving on the extra yearly benefit until the expected NPV is zero. By hand, the on-time case discounts as -4.00 + 0.80/1.1 + 0.80/1.21 + 0.80/1.331 + 1.10/1.4641 + 1.10/1.6105 + 1.10/1.7716 = -4.00 + 0.73 + 0.66 + 0.60 + 0.75 + 0.68 + 0.62 = +0.04. The delayed case is -4.00 - 0.55 + 0.66 + 0.60 + 0.55 + 0.68 + 0.62 = -1.43 (flows -4.0, -0.6, 0.8, 0.8, 0.8, 1.1, 1.1; the new platform's running cost is not paid in the delayed year because it is not yet live). Expected NPV = 0.60 x 0.04 + 0.25 x (-1.43) + 0.15 x (-4.91) = -1.07.

Output:

Literal reading (no legacy saving), yearly net: [-4.0, -0.5, -0.5, -0.5, -0.5, -0.5, -0.5]
  NPV $M: -6.18  IRR: none
On time  p=0.60 NPV=  0.04 IRR=10.4%
Delayed  p=0.25 NPV= -1.43 IRR=0.0%
Failed   p=0.15 NPV= -4.91 IRR=none
Probability-weighted NPV $M: -1.07
Upside   NPV=  2.10 IRR=26.4%
Downside NPV= -3.14 IRR=-14.3%
On-time yearly net cash $M: [-4.0, 0.8, 0.8, 0.8, 1.1, 1.1, 1.1]
Delayed yearly net cash $M: [-4.0, -0.6, 0.8, 0.8, 0.8, 1.1, 1.1]
On-time cumulative cash $M: [-4.0, -3.2, -2.4, -1.6, -0.5, 0.6, 1.7]
Extra $M/yr needed for EV NPV = 0: 0.31  check: -0.0

Reading the results

• Literal reading (no legacy saving): net -$0.5M a year, NPV -$6.18M. No IRR exists because the cash flows never turn positive. (IRR, internal rate of return, is the discount rate at which NPV is zero.)
• On time: NPV +$0.04M and an IRR of 10.4%, essentially the 10% hurdle (the minimum return the company requires, here equal to the discount rate). Undiscounted payback is during year 5 (cumulative cash -$0.5M at the end of year 4, +$0.6M at the end of year 5, so about 4.5 years).
• Delayed: NPV -$1.43M, IRR about 0%.
• Failed: NPV -$4.91M.
• Probability-weighted NPV: -$1.07M. The risks turn a break-even case into a clear loss, and the failure case sits in the tail (the rare, severe outcomes at the bad end of the range).
• Break-even condition: about $0.31M a year of additional benefit (on top of the $1.6M assumed legacy saving) makes the expected NPV zero.

How to show it to the board

Three scenarios side by side, because a board decides on the range, not the average:

Beside them, separately: the failure case (-$4.91M NPV, $5.0M of cash gone) and the probability-weighted figure (-$1.07M). A bank board needs the tail shown, because the cost of a failed core payments migration is not only financial. I would also show the cumulative cash curve for the on-time case (-$4.0M, -$3.2M, -$2.4M, -$1.6M, -$0.5M, +$0.6M, +$1.7M by year) to make the long payback visible.

Recommendation

Do not take this to the board as an approval request in its current form. Either (1) find the additional $0.3M a year of benefit or cost reduction, (2) phase the migration (for example one payment type first) so a failure is detected after a fraction of the $4M and the loss is capped, or (3) reduce the delay risk by engaging the regulator early. Each lever should be priced and re-run through the model. If the benefit is genuinely $1.5M against $2M of net running cost, I would say plainly that the project is a compliance or resilience investment, not a financial one, and ask the board to decide on those grounds.

Trade-offs and pitfalls

• Using a single scenario hides the risk the question asks about. Probability weights are estimates, so label them and show how the answer moves with them.
• Adjusting the cash flows for risk and also raising the discount rate would count the risk twice. For example, the failure scenario already subtracts 0.15 x $4.91M from the expected NPV; if I also raised the rate to 14% to be safe, the on-time NPV would fall from +$0.04M to -$0.42M, charging the same risk again. I adjusted the flows and kept the rate at 10%.
• The model puts all the migration cost at the start; real spending is spread, which slightly improves the NPV.
• What would change my call: confirmation that the legacy platform costs more than $1.9M a year to run, which would clear the break-even condition on its own.

Direct answer

Lay the proposal out as a year-by-year table with one row per cash flow type: one-time build cost (negative, year 0), recurring operating cost (negative, every year it runs), and benefits (positive, only from the year they start). Add a net row and a cumulative row (the running total of the net row). Here the sponsor is the executive who owns the budget and the decision to fund the project. The project "turns positive" in the year the cumulative row crosses zero, which is the payback period (time until the cumulative cash flow returns the investment). Then add a discounted row so finance can see the same crossover in today's money, plus the net present value (NPV), the sum of all flows discounted back to today.

The artifact (illustrative numbers)

Proposal: $300,000 to build in year 0, $60,000 a year to operate from year 1, benefits of $0 in year 1 (the build is being adopted), $150,000 in year 2 while usage ramps (builds up gradually as more people adopt it), and $250,000 a year from year 3. Convention: negatives are outflows and positives are inflows; year 0 is today, other flows are assumed at year end. The discount rate (the yearly percentage by which future money is shrunk to express it in today's value) is 10%, so a flow in year t is divided by 1.10 raised to the power t. Traced: year 2 is 90,000 / 1.10^2 = 90,000 / 1.21 = 74,380; year 3 is 190,000 / 1.331 = 142,750; year 1 is -60,000 / 1.10 = -54,545.

How to read it:

• Trough (the lowest point of the cumulative line): the cumulative low is -$360,000 at the end of year 1. That is the cash the sponsor must be willing to have exposed, and it is bigger than the build cost because operating cost starts before any benefit does.
• Payback: cumulative crosses zero during year 4. Interpolating: 3 + 80,000 / 190,000 = 3.42 years.
• Discounted payback: about 4.06 years, because later money is worth less (4 + 7,643 / 117,975).
• NPV over five years at 10%: +$110,332.

A chart is the best presentation: bars for net flow per year, a line for cumulative, a marker where it crosses zero, and a shaded region for the trough.

Where each cost sits

• One-time (implementation, data migration, training, parallel running, ramp-up productivity dip): year 0, or the year they are incurred. Do not bury them in the recurring row, or the steady state looks falsely cheap.
• Recurring (licences, hosting, support, people to run it): every year from go-live.
• Benefits: only from the year they are realised, using a ramp, not the steady-state figure from day one.

A second example: why the label and horizon matter

A business intelligence (BI) modernisation costs $250,000 in year 0, $40,000 a year to operate, and saves $90,000 a year of labour from year 2. Nets: -250,000, -40,000, then +50,000 a year. Cumulative after year 5 is still -$90,000. It breaks even at 1 + 290,000 / 50,000 = 6.8 years, which is longer than a typical 3 to 5 year approval horizon. Seeing this in a table is exactly the point: a case that "saves $90,000 a year" can still fail a five-year test.

Trade-offs and pitfalls

• Presenting only the steady-state annual benefit and a simple payback hides the delayed start and the ramp.
• Mixing timing assumptions (cash arriving mid-year versus at year end) silently moves payback; state the convention.
• Payback ignores everything after the crossover; NPV captures it but depends on the discount rate, so show both and state the rate.
• Show a downside column (benefits 20% lower or a year later) next to the base case; the delay assumption usually matters more than the benefit size.

Direct answer

Convert hours to dollars with a fully loaded hourly rate (salary plus benefits, payroll taxes and other employment overhead, divided by paid hours), then apply a realisation factor: the share of those freed hours that turns into something finance can see. 200 hours a year at an illustrative $56.25 an hour is $11,250 of gross capacity, but I would put a realistic range of roughly $2,800 to $11,250 in the case, with a base of about $5,600, and I would say the confidence is moderate on the hours and low on the realisation. Time saved is not cash saved until someone decides what the freed time is used for.

Step 1: the rate

Illustrative: $90,000 salary x 1.3 loading (benefits and overhead, ask finance for the real factor) = $117,000, divided by 2,080 paid hours (52 weeks x 40) = $56.25 an hour. Use the loaded rate, not salary alone, because the company pays the load too; some finance teams prefer a more conservative productive-hours denominator, so ask which basis they use and use the same one throughout.

Step 2: separate three kinds of benefit

Do not add these together unless each is supported by its own evidence, and count each hour only once.

Step 3: direct saving versus redeployment

• If the 200 hours remove paid overtime or avoid a hire, the saving is the hours times the rate: $11,250 (cash).
• If analysts spread 200 hours across 10 people, that is 20 hours each, which is not a headcount reduction. It is redeployment value: worth what the work they do instead is worth, and often not cash. Example: if those 200 hours let analysts finish a report the company would otherwise have paid a contractor $60 an hour to build, the value is 200 x $60 = $12,000 of avoided spend; if the hours go to work nobody would have paid for, the cash value is $0.
• A defensible base: 50% realisation = $5,625. Why 50%: with no evidence yet, assume about half of freed hours turn into visible value (the rest is absorbed by meetings, context switching and work that does not shrink to fit), then raise or lower it after a pilot shows what actually happened to the hours. It is a judgement, so label it as one. Low: 25% = $2,813. High: 100% = $11,250. State which scenario the rest of the case uses.

Step 4: three ways to measure the 200 hours (each with an example)

1. System timestamps: ticket or workflow logs. The task runs 40 times a month and takes 25 minutes of manual effort each: 40 x 25 = 1,000 minutes = 16.7 hours a month, x 12 = 200 hours a year. This is the strongest method, because it uses recorded volumes and durations.
2. Time-and-motion sample (watching and timing people doing the task): observe 5 analysts for a week and time the task. If it averages 0.8 hours a week each, then 5 analysts x 0.8 hours x 50 working weeks = 200 hours a year. The caveat is that people work differently when watched and one week may not be typical.
3. Self-report survey with calibration: ask the analysts how long they spend. Suppose they report 260 hours a year in total. Compare a sample against logs; if self-reports run 30% high, then 260 / 1.3 = 200 hours. Without that calibration step I would not use the raw number.

Validating a customer-claimed time saving

When the claim comes from a customer rather than your own team, I would request five data sources and one check each:

1. Workflow or ticket timestamps: confirm volumes and durations from system data.
2. Time-tracking or timesheet data: check that hours match the claim and cover the same period.
3. A direct observation sample: watch a few people do the task and compare to the claimed duration.
4. Pilot before-and-after data: run on one team, measure the same metric both sides.
5. Payroll or HR rates: confirm the hourly rate and who actually does the work.

Biased or incomplete data (only the best team pilots, self-selected volunteers, missing weeks) is handled by stating the sample, using ranges rather than one number, and discounting the claim, for example presenting 50% as base. Never present a point estimate as certain.

Avoiding double counting and the training-programme case

If two projects both claim the same analysts' reporting hours, the second project's saving is only what remains after the first. For a training programme, "ROI" is a translation from outputs (tickets resolved, error rate, time to proficiency) to a productivity estimate, with stated limits. Example: new hires take 10 weeks to reach full speed instead of 14; the 4 weeks saved x 20 hires x 40 hours x $56.25 = $180,000 of capacity, which I would present at the 50% base as about $90,000 and compare with the programme's cost. The caveat is that attributing a performance change to training alone is rarely clean.

Confidence

Hours: medium-high if from logs, medium from sampling, lower from surveys. Dollar value: lower, because it multiplies by a rate and a realisation judgement. I state the range, the weakest assumption (realisation) and the evidence I would collect next (a pilot).

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.