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

A strong answer to this behavioural question is a story with five visible parts: situation and decision at stake, how I built the costs and benefits, how I handled what I did not know, what the sponsor decided and why, and what the results were against the projection. Below is the shape, followed by a worked illustration. The figures are illustrative and every figure that comes from a calculation is worked on the page, and the rest (the outage probabilities and loss) are stated inputs (FTE means full-time equivalent, one person's working year; NPV means net present value, defined in the Numbers paragraph); substitute your own real project and real numbers, and say plainly which were measured and which estimated.

Story shape to follow

1. Situation (2 sentences): the problem, the sponsor, the money at stake, my role.
2. Costs and benefits: where each number came from (quote, benchmark, measured pilot, interview) and how I separated one-time from recurring.
3. Uncertainty: a range, the assumption that mattered most, and what I did about it (sensitivity or scenario analysis, meaning re-running the numbers with the shaky input changed; contingency, a reserve for things going wrong; staging, releasing money in steps).
4. Decision and influence: what I changed in the case for this audience.
5. Afterwards: realised versus projected, and what I would do differently.

Illustration: consolidating three monitoring tools

Situation. As an engineering lead I proposed replacing three overlapping monitoring tools with one platform. The sponsor was the VP of Engineering; approval needed the finance partner's sign-off.

Numbers. Current licences: $85,000 + $60,000 + $40,000 = $185,000 a year, plus about 0.3 FTE of maintenance, valued at $50,000 a year using the finance loaded rate (the hourly cost finance assigns to an employee, including benefits and overhead, not salary alone; 0.3 of a person at about $167,000 loaded is $50,000). New platform: $110,000 a year plus $90,000 one-time migration. Annual saving = $185,000 + $50,000 - $110,000 = $125,000. Three-year net present value (NPV: future yearly savings shrunk back to today's money, minus the cost paid today) at 8%: a dollar at the end of year t is worth 1 / 1.08^t today, and the three factors 0.9259 + 0.8573 + 0.7938 add up to 2.5771. So NPV = -$90,000 + $125,000 x 2.5771 = +$232,137; payback = 0.72 years (about 9 months).

Handling the uncertainty with limited data. Licence figures came from invoices; the platform price from a quote; the maintenance time from a two-week log kept by the team and cross-checked against an interview with another team that had migrated. The weakest input was whether all three tools could really be retired. Scenario analysis changed the recommendation: if only the two larger tools could go, saving was $85,000 + $60,000 + $25,000 maintenance - $110,000 = $60,000 a year, NPV = -$90,000 + $60,000 x 2.5771 = $64,626 and payback $90,000 / $60,000 = 1.5 years. Still positive, but the case then depended on retirement of the third tool. So I recommended a phased migration with a 12-month contract term and a gate (a checkpoint where the next step is released only if a stated condition is met) ("third tool retired by month 6 or we revisit"), rather than a three-year commitment.

Risk benefit, quantified but excluded. Faster detection might cut the chance of a major outage from 15% to 10% a year on a $400,000 loss: expected loss means probability times impact, so the reduction = (0.15 - 0.10) x $400,000 = $20,000 a year. I labelled it low confidence and left it out of the headline, mentioning it only as upside.

Tailoring. For the VP: speed, fewer pages for on-call engineers, one decision. For the finance partner: assumptions, the invoices, the range. For both: the gate.

Afterwards. The third tool was retired two months late. Its annual saving was the difference between the three-tool and two-tool cases: $125,000 - $60,000 = $65,000 ($40,000 licence plus $25,000 of maintenance). The delay cost 2/12 x $65,000 = $10,833, bringing first-year realised saving to about $114,167 against $125,000 projected (91%). I reported the gap to finance, verified the savings had held by checking the licence invoices stayed at zero for the retired tools at the next renewal, and recorded the lesson: I now add a retirement-date assumption to every consolidation case.

Other angles to have ready

• Using analysis to influence a prioritisation or sales call: show the cost of delay (the value lost for each month a change is not yet live) in dollars per month beside the cost to build.
• A $100,000-plus saving: verify it is sustainable by tracking the invoice or usage line monthly for two quarters.
• Realised versus projected: always know the gap and its cause.

Pitfalls

Generic virtues ("I am data-driven"), no number a listener can check, hiding the assumption that was wrong, and claiming a result you did not actually measure.

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

Do not force a price on them, and do not drop them either. I use four treatments, in this order of preference: monetise conservatively where a defensible link to money exists, use a proxy metric, score qualitatively where neither is credible, or report separately from the financial return. Every estimate gets a stated confidence, and the headline return is shown with and without the soft benefits so the case stands on its tangible benefits alone.

The four treatments

Document confidence for each estimate (for example high, medium, low) with its source and who owns the assumption.

Choosing the two assumptions in the attrition row. Build the replacement cost from parts HR can confirm instead of quoting a percentage of salary: for example a $12,000 agency fee, about $10,000 of lost output while a new hire ramps up over 3 months at half productivity, and $18,000 of interviewer time and temporary cover, which totals $40,000. Choose the haircut by how strong the evidence is: a drop in attrition measured in a pilot might take only a 10% to 20% cut, while a figure taken from a vendor brochure or an industry survey deserves 50% or more. Agree the percentage with Finance before showing the result, so the cut is their rule and not your lever.

Tangible versus intangible, for a customer-service initiative

• Tangible (priced directly): lower cost per ticket, fewer escalations to engineers, fewer agent overtime hours.
• Intangible (hard to price): customer satisfaction, brand perception, agent morale.

The tangible items carry the financial case; the intangible ones are shown as proxies or as separate evidence.

Long-term and indirect outcomes (brand, satisfaction)

These pay off over years and through chains of causes, so the honest claim is a range with the chain stated: "if satisfaction improves by X, churn falls by Y, worth $Z." Communicate uncertainty to finance by showing a low case, a base case and which input they should challenge, by using a short and defined horizon, and by showing the return without these benefits so the decision does not depend on them.

Trade-offs and pitfalls

Over-monetising erodes trust in the whole case; finance will discount a case in which half the value is soft. Under-reporting the intangibles can kill a project whose main value is strategic. Avoid counting a soft benefit twice (morale and attrition are the same benefit measured two ways), and never use a vendor's industry statistic as your own input without checking it applies to you. What would change my approach: if the project's main justification is strategic (for example compliance or brand repair), I would lead with the qualitative case and a cost-effectiveness view instead of ROI (return on investment, net gain divided by cost). Cost-effectiveness compares options on cost per unit of outcome without turning the outcome into dollars: for example, a $400,000 compliance programme that cuts audit findings from 20 to 8 costs $400,000 / 12 = about $33,000 per finding avoided, and a rival option at $50,000 per finding is plainly worse.

Direct answer

For a seven-year asset I would build a lifecycle cost model (the present value of everything the hardware costs from purchase to disposal) and compare options on that number, not on the purchase price. The purchase price is a large share but far from the whole cost over seven years (in the worked example below it is 630,000 of Option A's 1,166,184 present-value total, about 54%, and 750,000 of Option B's 1,158,135, about 65%), so the remaining lines decide a close call. To make it credible I need three groups of evidence: written vendor commitments (prices for years four to seven, support terms, end-of-support dates, measured power draw), operations data (what the team really spends on staff, failures and downtime today), and finance inputs (the discount rate, space and power rates, tax and legal rules for each location). Every line gets a source, and the final output is a ranking with a sensitivity range, not a single total.

The cost lines, and why each one is there

1. Acquisition: purchase, installation, integration, initial licences (year 0).
2. Support: the warranty usually covers the first years; paid support afterwards typically escalates (rises every year), so I ask for the contractual cap on escalation (a clause limiting how fast the price can rise each year), not the year-four quote alone.
3. Power and cooling: measured kilowatts at the expected load, multiplied by hours, the facility's PUE (power usage effectiveness: total facility energy divided by the energy the IT equipment uses) and the price per kilowatt-hour.
4. Space: rack space per year, or the floor-space allocation.
5. Staff: operations hours for patching, replacing parts and handling incidents.
6. Refresh and mid-life upgrades: memory, storage or controller replacements; whether the vendor still sells parts in year six.
7. Downtime cost: expected outage hours times the business cost per hour, from the vendor's failure-rate data checked against ours.
8. End of life: disposal and data-destruction costs minus resale or trade-in (residual value, what the hardware can still be sold or traded in for).
9. Cost of money: discount all future cash at the company's rate, so a dollar in year six counts for less than a dollar today. Worked once by hand at 8%: a USD 100,000 cost in year 6 has a present value (PV, its worth in today's money) of 100,000 / 1.08^6 = 100,000 / 1.5869 = about 63,017.

Worked example: two hardware platforms over seven years (illustrative inputs)

Option A costs USD 600,000 to buy; Option B costs USD 720,000 but draws less power, has cheaper and slower-escalating support, and keeps more resale value. All inputs are in the code; discount rate 8%.

import io, contextlib

RATE = 0.08          # discount rate (illustrative)
YEARS = 7
KWH_PRICE = 0.12     # USD per kWh (illustrative)
PUE = 1.5            # power usage effectiveness: facility kWh per IT kWh
FTE_COST = 140_000   # loaded cost (salary plus overheads) of one operations FTE (full-time equivalent: one person's full-time work) per year
RACK_COST = 6_000    # USD per rack (a standard cabinet that holds servers) per year (space, cooling share)

def pv(x, t):
    # present value: what a cost paid in year t is worth today
    return x / (1 + RATE) ** t

def lifecycle(name, purchase, install, kw, racks, support_y4, support_esc,
              midlife_upgrade, residual_pct, disposal, fte, power_price_mult=1.0):
    parts = {"purchase+install": purchase + install}          # paid in year 0
    for t in range(1, YEARS + 1):
        yearly = {
            "power": kw * 8760 * PUE * KWH_PRICE * power_price_mult,
            "space": racks * RACK_COST,
            "staff": fte * FTE_COST,
            # vendor warranty covers years 1-3; paid support starts in year 4 and escalates
            "support": 0.0 if t <= 3 else support_y4 * (1 + support_esc) ** (t - 4),
            "mid-life upgrade": midlife_upgrade if t == 4 else 0.0,
        }
        for k, v in yearly.items():
            parts[k] = parts.get(k, 0) + pv(v, t)
    parts["disposal net of resale"] = pv(disposal - residual_pct * purchase, YEARS)
    total = sum(parts.values())
    print(f"{name}: PV of 7-year lifecycle cost = {total:,.0f}")
    for k, v in parts.items():
        print(f"   {k:24s}{v:>12,.0f}")
    return total

def quiet(**kw):
    # same as lifecycle() but with its printing suppressed, so only the total comes back
    with contextlib.redirect_stdout(io.StringIO()):
        return lifecycle("x", **kw)

A = dict(purchase=600_000, install=30_000, kw=12, racks=2, support_y4=60_000, support_esc=0.08,
         midlife_upgrade=40_000, residual_pct=0.05, disposal=8_000, fte=0.25)
B = dict(purchase=720_000, install=30_000, kw=9, racks=2, support_y4=45_000, support_esc=0.05,
         midlife_upgrade=0, residual_pct=0.10, disposal=8_000, fte=0.25)
a = lifecycle("Option A (cheaper to buy)", **A)
b = lifecycle("Option B (dearer to buy)", **B)
print("A minus B, PV USD:", round(a - b), "| purchase price gap:", 720_000 - 600_000)

print("\nSensitivity of (A minus B), PV USD:")
print("  base:                        ", round(a - b))
print("  power price x2 on both:      ", round(quiet(**A, power_price_mult=2.0) - quiet(**B, power_price_mult=2.0)))
print("  A support escalation 15%/yr: ", round(quiet(**{**A, "support_esc": 0.15}) - b))
print("  A resale value 0%:           ", round(quiet(**{**A, "residual_pct": 0.0}) - b))

# 10-year on-prem vs cloud for an ML workload. Costs are positive numbers; index = year.
def pv_cost(flows):
    return sum(cf / (1 + RATE) ** t for t, cf in enumerate(flows))
onprem = [600_000] + [95_000] * 10     # 600,000 hardware bought today, then 95,000 a year of running cost (power, space, support, staff share)
onprem[5] += 600_000                   # hardware refresh in year 5
print("\n10-year PV cost, on-prem with year-5 refresh:", round(pv_cost(onprem)))
for m in (0.85, 1.0, 1.15, 1.3):
    cloud = [90_000] + [180_000 * m] * 10   # 90,000 one-time migration, then 180,000 a year of cloud fees; m scales the fee (1.15 = fees 15% above the quote)
    print(f"10-year PV cost, cloud at {m:.2f}x the fee:   ", round(pv_cost(cloud)))
rate_factor = sum(1 / (1 + RATE) ** t for t in range(1, 11))
print("Cloud break-even fee multiple:", round((pv_cost(onprem) - 90_000) / (180_000 * rate_factor), 3))

Output:

Option A (cheaper to buy): PV of 7-year lifecycle cost = 1,166,184
   purchase+install             630,000
   power                         98,513
   space                         62,476
   staff                        182,223
   support                      176,407
   mid-life upgrade              29,401
   disposal net of resale       -12,837
Option B (dearer to buy): PV of 7-year lifecycle cost = 1,158,135
   purchase+install             750,000
   power                         73,885
   space                         62,476
   staff                        182,223
   support                      126,894
   mid-life upgrade                   0
   disposal net of resale       -37,343
A minus B, PV USD: 8049 | purchase price gap: 120000

Sensitivity of (A minus B), PV USD:
  base:                         8049
  power price x2 on both:       32677
  A support escalation 15%/yr:  25953
  A resale value 0%:            25554

10-year PV cost, on-prem with year-5 refresh: 1645808
10-year PV cost, cloud at 0.85x the fee:    1116642
10-year PV cost, cloud at 1.00x the fee:    1297815
10-year PV cost, cloud at 1.15x the fee:    1478987
10-year PV cost, cloud at 1.30x the fee:    1660159
Cloud break-even fee multiple: 1.288

Reading it (a positive "A minus B" means A is the more expensive option): A is USD 120,000 cheaper to buy, yet over seven years it costs about USD 8,000 more in present-value terms, so on base inputs the two are effectively tied. The tie is the finding: the decision then turns on the sensitivities. If power prices double, A is about USD 33,000 worse; if A's support escalates at 15% instead of 8%, A is about USD 26,000 worse; if A's resale value is zero, A is about USD 26,000 worse. Each plausible risk moves the answer toward B, so unless A's lower purchase price carries real weight (cash constraint this year, say), I would recommend B and say what would flip it: a budget that cannot fund the extra USD 120,000 now, or a vendor commitment to cap A's support escalation.

What I need, and from whom

• Vendors: price lists and quotes covering years one to seven; the contractual cap on support escalation; end-of-support (vendor stops fixing and supporting it) and end-of-sale (vendor stops selling it) dates; spare-parts availability for the full horizon; measured power draw at our expected load rather than the nameplate rating (the maker's printed maximum, usually higher than what the unit really draws); trade-in or buy-back terms; upgrade paths; and failure-rate claims backed by reference customers I can call.
• Operations: hours spent on comparable hardware today, incident and failure history, utilisation (do we need the capacity on day one or in year four), maintenance windows, and the cost of an outage to the business.
• Finance and facilities: discount rate, power price, rack cost, and whether disposal or resale gains are taxed.

Longer comparisons the same template handles

The seven-year model above is the method; these are extensions of it.

• On-prem versus cloud over ten years: add one hardware refresh in the on-prem timeline, plus staffing, power and real estate; on the cloud side add one-time migration and recurring fees. The code above runs an illustrative ML workload: on-prem about USD 1.65 million in present value, cloud about USD 1.30 million at the base fee, and the cloud advantage disappears if fees are about 1.29 times the base. In that block the on-prem inputs are 600,000 to buy, 95,000 a year to run and a second 600,000 refresh in year 5; the cloud inputs are 90,000 to migrate and 180,000 a year in fees. The break-even multiple is (1,645,808 - 90,000) / (180,000 x 6.710), where 6.710 is the sum of the ten yearly discount factors, which gives 1.288. That break-even multiple is the number I would give the CTO (chief technology officer), because it answers "how wrong can cloud pricing get before we regret it".
• Regions: if hardware is capital spending in one country and cloud is operating spending, the tax treatment and legal costs (data-residency obligations, meaning rules that data about a country's people must stay in that country, and local contracts) differ, so I add a row for each and ask the local finance team to confirm it.
• A CTO worried that adoption adds maintenance burden: put the maintenance lines in the model explicitly (staff hours, patching, upgrade projects, support tier), show the vendor's lifecycle and support window, and list steps that limit the burden: managed support for years four to seven, standard configurations, automated patching, a decommission date set at purchase.

Trade-offs and pitfalls

• Using the purchase price as the comparison: in the example the running costs (staff, support, power and space) add up to about 45% of Option A's present-value cost and 38% of Option B's, they are spread over years, and the support and power lines are where the two options actually differ.
• Quoting year-four support and assuming it stays flat.
• Using vendor nameplate power and failure figures unverified.
• Ignoring that a seven-year horizon outlives product lines: check parts and software support through year seven, not only through warranty.
• Presenting a precise total: with a gap this small, the honest output is a ranking plus its sensitivities.