How to Build an IT Investment Business Case Your CFO Will Actually Approve
An IT director we worked with, brought a WiFi upgrade request to her CEO earlier this year. The spec sheet she took along covered all technical details, including access point models, a coverage map, and a rundown of the new standard versus the old one. The CEO's first question was how much it would cost. His second question, after hearing the number, was why it couldn't wait another quarter. The CTO didn't have a good answer, because she'd never had to build one. The request ended up getting stalled for six weeks.
What finally moved it wasn't a better spec sheet, but a different document entirely: three numbers on one page. This new document showed what the current network was already costing the company in dropped calls during client demos and engineering hours lost to network reconnections. The ask hadn't changed; just the framing did.
I think about that meeting a lot, because it wasn't really about WiFi. It was about the gap between the case an IT lead builds in their head and the case that actually lands with the person who has to sign off on the spend. The two aren't the same document, and treating them as interchangeable is where most infrastructure requests stall.
Every founder or IT lead who has tried to get infrastructure spend approved has run into some version of this. You know the technology is worth it, but getting someone else to write the check requires a different kind of argument, and it isn't the one you are used to making.
Why Most IT Spend Requests Get Shelved
A business case for IT infrastructure investment usually fails for reasons that have almost nothing to do with the infrastructure.
The request opens with features instead of financial impact. A proposal that leads with access point models, endpoint agent names, or server specs is describing a product, not making an investment argument, and a CFO or board member evaluating dozens of competing budget requests each quarter has no way to compare a feature list against payroll, marketing spend, or the next hire.
The proposal also tends to ignore the cost of doing nothing. Every spend decision competes against the status quo, and if doing nothing looks free, any new spend looks like pure expense by comparison. Finally, the request rarely comes with a payback window. Leadership wants to know when the investment starts paying for itself, not only that it eventually will.
None of this means the underlying case is weak. It just means that the case was never actually built. The technical judgment behind the ask and the financial argument for funding it are two entirely different documents, and the requests that are shelved only produce the first one.
There's a deeper version of this problem too. Some founders and finance leads still treat IT as a cost center rather than something that protects or creates value, and a request that only speaks in technical terms reinforces that view rather than correcting it. A business case that connects the spend to revenue protection, a client relationship that stays intact, or a compliance deadline that gets met, does more than just get one request approved. It changes how the next one requests get evaluated.
The Three Numbers Every Business Case Needs
A business case for IT infrastructure investment rests on three figures, and building it well means having a defensible number for each one before you walk into the room.
Cost of inaction. This is what the current situation is already costing the business, whether that shows up as engineering time lost to workarounds, downtime during critical moments, or a compliance deadline put at risk. ITIC's 2024 downtime survey found that for a small business, an hourly outage cost of $25,000 to $75,000 can be serious enough to threaten the company's survival. The exact number for your business will be different, but the exercise is the same: put a dollar figure on what waiting actually costs.
Payback window. This is how long it takes for the investment to pay for itself once made, expressed in months rather than a vague eventual return. A leadership team weighing your request against every other item on their list responds to a stated timeline far more readily than an open-ended promise of future value.
Quantified benefit. This is the actual return, and it generally falls into one of three categories:
cost avoidance, where the investment prevents a specific expense that would otherwise land later;
productivity gain, where it recovers hours currently lost to a broken process; or
risk reduction, where it lowers the financial exposure of a breach, an outage, or a compliance failure.
Pick the category that actually applies rather than reaching for all three, since a case built on one honest number outperforms one padded with three soft ones. If you want to go deeper on the actual math behind these categories, our guide to TCO and ROI as IT investment metrics walks you through the calculations.
None of these three numbers require a finance background to produce. Most of the work is honest estimation grounded in something you already track, such as ticket volume, downtime incidents, or hours logged, rather than a formal financial model. The goal isn't precision, but a defensible figure that survives the first follow-up question.
Two scenarios below show how this comes together in practice.
Case Study: The Office WiFi Upgrade Nobody Thought Was Urgent
A twenty-person fintech startup I worked with had a WiFi network installed during their initial office buildout three years earlier, sized for a twelve-person team. By the time they came to us, client demos in the main conference room dropped audio roughly once a week, and engineers routinely stepped into the hallway to get a signal strong enough for a video call. Nobody had flagged it as urgent, because nobody had put a number on what it was costing. (If you're working through what an upgrade actually involves, our complete guide to business WiFi infrastructure covers the planning side in more depth.)
We helped them build the case around three figures.
Cost of inaction: two client-facing incidents per month, each requiring a follow-up call and, in one case, a delayed contract signature the founder attributed directly to a dropped demo.
Payback window: the upgrade cost was roughly equivalent to six weeks of the engineering time currently lost to connectivity workarounds, based on a rough estimate of fifteen minutes per employee per day spent dealing with dead zones.
Quantified benefit: productivity gain, calculated conservatively at the low end of that estimate.
The founder approved the upgrade in the same meeting where the case was presented. The spec sheet hadn't changed from the version that sat untouched for a month prior. What changed was that the request now answered the question leadership actually asks, which is what happens if we don't do this and what happens if we do.
Case Study: The EDR/MDM Rollout That Got Deprioritized
A twenty-three-person healthcare startup approached us after an EDR (Endpoint Detection and Response) and MDM (Mobile Device Management) rollout had been pushed to next quarter twice in a row. Each time, the request competed against hiring and product spend and lost, because it was framed as a security upgrade rather than an investment argument. (Our earlier piece on mobile device management for small businesses covers what MDM actually does day to day.)
The business case that got it approved on the third pass leaned on risk reduction rather than a hypothetical feature list. IBM's Cost of a Data Breach Report last broke out figures by company size in its 2023 edition, putting the average cost of a breach for organizations under 500 employees at $3.31 million once legal, remediation, and lost-business costs are included. That's not a number anytwenty-three-person company can absorb, and it gave the founder a concrete point of comparison against an annual EDR and MDM cost that was a negligible fraction of that figure.
Cost of inaction: the exposure of unmanaged laptops holding patient intake data, a fact the company's cyber insurance renewal had already flagged.
Payback window: framed not as a return but as the annual premium the coverage would otherwise lose, since several cyber insurers now require endpoint management as a condition of binding a policy.
Quantified benefit: risk reduction, tied to both the breach exposure and the insurance requirement.
This scenario is not restricted to just this one company. Security spend rarely produces a clean revenue return, and trying to force one onto a request usually weakens it. Risk reduction, priced accurately against a real exposure, is its own legitimate category and doesn't need to be dressed up as something else.
When the Case Isn't There Yet
Sometimes the honest version of these three numbers doesn't add up to a compelling case, and that's useful information too. If the cost of inaction is small, the investment may not deserve to be first in line this quarter, and forcing the numbers to look more urgent than they are tends to backfire the next time you bring a request forward.
A few options exist short of dropping the request entirely:
Bundling a smaller infrastructure fix into a larger planned project, a scheduled office move, or an existing security initiative can absorb the cost without needing its own standalone justification.
Phasing the investment, addressing the highest-exposure piece now and the rest at the next budget cycle, gives leadership a smaller number to approve while the case for the remainder builds.
Tracking the cost of inaction over the following quarter, even informally, often produces the number that was missing the first time around. A request that comes back three months later with a documented pattern behind it lands very differently than the same request repeated exactly.
How to Build Your IT Investment Business Case
A few things separate a business case that gets approved from one that gets shelved again, regardless of what the investment is for.
Bring your own numbers, not vendor benchmarks. A downtime cost or a breach figure pulled from an industry report is useful context, but the number that nudges a decision is the one specific to your business, even if it's a reasonable estimate rather than a precise calculation.
State the payback window explicitly, even when it's approximate. A leadership team can work with “this pays for itself in roughly four months” far more easily than “this will save us money over time.”
Loop in whoever holds the budget earlier than feels necessary. The CFO's office or the founder tracking runway usually has context on what a given dollar figure means relative to everything else competing for it, and bringing them in before the pitch produces a stronger case than surprising them with one.
Pick one benefit category and build the case around it. A request trying to claim cost avoidance, productivity gain, and risk reduction all at once usually ends up making none of those arguments convincingly.
Separate the technical spec from the financial case. Keep the technical details, like the access point models and the endpoint agent names, in a technical appendix if you need them, but lead with the three numbers.
Building the Case Before You Need It
The CTO from the story above told me afterward that the frustrating part wasn't the six-week delay. It was realizing the upgrade had been financially justified the entire time, and nobody had written that argument down until the deadline forced the issue.
Every infrastructure recommendation should lead with the three numbers: cost of inaction, Payback window, and Quantified benefit in mind from the start, because a technically sound recommendation and an approvable one aren't always the same document. If you're sitting on an infrastructure upgrade you believe in but haven't been able to get funded, walk us through it, and we'll help you build the case that actually gets it approved.
About The Author
Evan JonesFounder and CEO of Jones IT
With over two decades of IT experience in San Francisco, Evan guides Jones IT's long-term strategy, finances, and culture, with a vision of building the city's highest-rated IT services firm. Outside of work, you'll find him on the golf course or running Bay Area Warriors, his non-profit connecting Bay Area kids to college through basketball.
Learn to build an IT investment business case that gets approved. We show you how to prove the cost of waiting vs. the cost of acting to win CFO buy-in.