Quick Summary
- Leadership tends to approve IT investments grounded in business outcomes, not just technical value.
- Many IT business cases fail to connect the technology to KPIs leadership already uses.
- There’s a difference between defending a purchase and making a case for what it delivers. One invites pushback on cost; the other gets leadership asking “is this worth it?”
- Even if an IT investment doesn’t have a clear, quantifiable ROI, a sound case still needs to be made using whatever evidence is available.
If you’ve been trying to get leadership to sign off on a specific IT purchase, there’s a reasonable chance the process went something like this: you prepared a solid technical case; the internal IT team approved; but the decision got deferred. Again.
Most IT business cases don’t fail because the technology is wrong. They fail because the case was made in the wrong language. Technical teams speak the language of infrastructure. Leadership speaks the language of business outcomes: revenue, cost, profit, and risk. When those two don’t connect, the conversation hits a wall, and it has nothing to do with the technology itself.
This article is a practical framework to close that gap.
Before going any further, this article is published by IT procurement experts in Calgary and Edmonton, and we’ll be upfront about that. Since we sell technology, we have an obvious interest in helping you justify spending money on technology. But that’s not what this article will focus on. Whether you partner with us or not, if you have a technology worth investing in, this framework will help you make the case for it in a way that actually lands with the people holding the budget.
Justifying an IT purchase vs. building a business case: what’s the difference?
These two things feel similar, but they pull the conversation in very different directions:
- Justifying a purchase means defending why it’s needed. You’re basically saying: here is the problem, here is the solution, here is the cost, here is why the cost is reasonable. The issue with this approach is that it frames the investment as an expense to be defended, which often invites listeners to scrutinize the cost.
- Building a business case, on the other hand, means showing what the investment delivers based on measurable outcomes. In this case, you’re saying: here is what the current situation is costing us, here is what this investment changes, here is what that’s worth. That structure invites the leader to evaluate the return on investment.
There are also two levels at which the case needs to be made. The technology vendor needs to connect the solution to business outcomes. But so does the internal IT team presenting it to their own leadership. If the IT team can’t make that case internally, the project gets cancelled, no matter how good the technology is or how compelling the vendor presentation.
What this looks like in practice
Here’s a story from an enterprise in the energy sector that shows what’s possible when the business outcome is already part of the conversation. An IT project came in a million dollars over budget. The person responsible went to the executive sponsor expecting to explain the shortfall.
The SVP didn’t need one. He’d been sitting on a $40 million annual travel budget, flying teams around the world for geology and geophysical consultations. The technology would make most of those flights unnecessary. He figured he could cut that $40 million down to $10 within a month. A million-dollar overage wasn’t a problem worth discussing.
That’s a best-case scenario. The SVP had already connected the technology to a business outcome that overrode the budget question. Most IT decisions don’t come with that kind of built-in clarity, especially when it comes to emerging technologies like artificial intelligence. The business case has to be made explicitly, before the conversation about cost even starts. The rest of this article gives you tangible insights into how to achieve that.
Why won’t leadership approve my IT budget request?
This is one of the more frustrating experiences in enterprise IT. You took the time to evaluate the technology, vet the vendor, and make sure the solution fits the need. And yet, it still won’t get funded.
What’s usually happening is that you and leadership are having two different conversations. Most senior leaders understand enough to recognize a credible solution, but even if you’ve met every technical requirement for your organization’s IT infrastructure, your proposal may be incomplete.
The KPI Problem Most IT Teams Don’t Realize They Have
Most organizations run key performance indicators. Leadership uses them to evaluate everything, and while the specific metrics vary by industry, the principle is consistent: decisions get made when someone can show which number moves and by how much.
The failure point in most IT business cases is that nobody asked what those numbers were.
We’ve seen how one major Canadian airline made this explicit. Their senior leadership communicated three KPIs to anyone who wanted their attention: revenue per available seat mile (RASM), profit per available seat mile (PASM), and cost per available seat mile (CASM). They said, “Tie your solution to one of those three and we’ll listen. If you can’t, it’s not a priority.” One of their leaders put it plainly: you can tell me I have to spend a hundred million dollars and I’ll spend it, as long as you can show me I’ll make two hundred million back.
The groundwork is simpler than it sounds. Before you build the case, find out which business unit is behind the request and what they’re actually trying to accomplish. For public companies, a lot of that information is already in their published financial results. For others, you ask. The answers tell you which KPI you’re working with before you ever start building the case.
How can I talk to executives about IT investments?
Once you know which numbers matter, the job is translation. You’re taking what the technology does and expressing it in the right language: terms of what it moves
For example, a storage upgrade adds capacity, but the more compelling number is the revenue it protects by reducing downtime during peak periods. A remote collaboration platform saves on travel costs in ways that show up directly on the bottom line. Some investments connect to risk instead: reducing the financial exposure of a breach, a failure, or an outage.
None of these require manufacturing numbers. It requires asking a different set of questions before walking into the budget conversation:
- What is this technology replacing or enabling?
- What does that translate to in cost or revenue terms?
- Who in the business can help put a number on it?
IT teams aren’t always close to the organization’s cost structure or strategic priorities, and that’s fine. Bring the CFO’s office, the operations team, or the relevant business unit into the conversation earlier than feels necessary. They’re the ones who will benefit from the technology, and they usually hold the figures that make the case land.
Why do IT budget conversations get stuck on price?
Usually because the conversation starts with the cost before it establishes what the cost is buying.
Price is an easy thing to scrutinize. Value is harder to argue with, but it requires more work to establish. When a business case leads with the technology and its price tag, the natural response from leadership is to evaluate the number. If the executive sponsoring the project understands what the technology is actually worth to the organization, the difference in cost becomes a minor detail instead of the main focus.
Consider a highly paid specialist whose work depends on running complex models or simulations. If the right technology cuts the time it takes from eight hours to one, the value of that time to the business can far exceed the cost of the investment in their salary. But if the IT team walks in with a hardware quote and no context, the number on the page is all anyone sees.
There’s also the question of total cost of ownership. A solution that looks expensive upfront often looks very different when you factor in what the current situation is already costing: the staff time, the workarounds, the risk exposure, the productivity that’s quietly being lost. When looking at long-term ROI and TCO, you can have a solid structure that shifts the conversation from “this costs a lot” to “here’s what not doing this is costing us.”
Frequently Asked Questions
How do I get leadership to approve an IT project?
Connect the project to a business outcome leadership already cares about: revenue, cost reduction, or risk mitigation. A project that can’t be tied to one of those will struggle to compete for budget regardless of its technical merit.
How do I calculate ROI for an IT investment?
The straightforward calculation is return minus cost, divided by cost. The harder part is identifying the return. Some investments have clear financial returns. Others are more difficult to quantify, particularly security or resilience investments. For those, present a credible range with documented assumptions rather than avoiding the question entirely.
What if the benefits of an IT project are hard to quantify?
Be transparent about what can be measured and honest about what can’t. Risk reduction can often be estimated even if it can’t be precisely calculated. The goal is to give leadership enough context to make an informed decision, not to manufacture a number that looks more certain than it is.
How do I make the case for an IT investment when budget is tight?
The same way you make it any other time, but with more urgency around the cost of inaction. When resources are constrained, leadership is weighing your request against everything else on the list. The strongest answer is a clear picture of what the current situation is already costing the organization, and what changes if the investment gets made.
Who should be involved in building an IT business case?
More people than usually are. IT teams often build the case in isolation, but the business unit behind the request usually holds the numbers that make it land. Bringing in the CFO’s office, operations, or the relevant business unit earlier than feels necessary tends to produce a stronger case and a smoother approval conversation.
IT budget conversations fail on communication, not cost
Leadership makes investment decisions based on business outcomes. Revenue, cost, profit, and risk are the measures they are accountable for. An IT business case that only speaks in technical terms and doesn’t connect to one of those measures is more likely to be denied.
Remember, succeeding in an IT budget conversations won’t just rely on proposing the best technology. You need to communicate effectively by speaking the same language as the people approving the budget. This is a skill that can be learned, if you’re committed to developing it.
If you’ve worked through the framework in this article and you’re ready to build a case, the next question is often: what exactly are we making the case for? One of the most common — and most delayed — IT investments is an infrastructure refresh. This article breaks down what running outdated IT infrastructure is actually costing your organization.
And if you’re looking for professional guidance to navigate these IT procurement conversations, PC Corp has spent over 45 years working with teams with organizations across Western Canada. Connect with us to plan and procure your next IT investment with a team that understands both the technology and the business case behind it.
