Who Actually Owns the Budget for Technology Purchases?

Getting an enterprise technology purchase approved should be straightforward. You’ve identified the need, done the research, and put together a solid case. But somewhere between the proposal and the signature, things stall. In many cases, this is because you don’t have a clear answer to one question: who actually owns this budget? Is it IT or is it someone else?

When that distinction gets lost, you may end up building your purchase case for IT rather, than for the department head who controls the funding and the wrong stakeholders end up in the room.  Projects then get delayed at steps everyone thought were already cleared.

If you want to avoid this outcome and optimize how you plan your IT budget, this post explains why that happens and what to do about to close the gap between technical decisions and business outcomes.

One thing to acknowledge before we get into it: yes, we’re an IT company. You might reasonably expect this to end with a push to spend more on technology. It won’t. The dynamics described here affect how technology decisions get made in organizations across Alberta, and we think you’re better served going into your next purchase conversation with a clear picture of how that works.

Why shouldn’t IT own the budget for technology purchases?

Simply put, IT isn’t structured to own it. IT departments exist to keep technology running reliably and at manageable cost. Their mandate is cost avoidance, which shapes how they evaluate every purchase that crosses their desk. It also means they aren’t the ones with a revenue target or an operational goal on the line.

For routine infrastructure purchases already planned in IT’s operating budget, IT often holds the relevant funding. But for anything tied to a business outcome, the budget lives with the line of business. Research projects that’ll be true for most tech budgets across the board by 2027.

A department head, a VP of operations, or a line-of-business manager is often both the sponsor and the budget owner. Their sign-off matters more than IT’s. For example:

• A field services team that needs scheduling software to reduce dispatch times. The budget comes from operations, not IT.

• A finance department replacing an outdated system to close the books faster. The budget comes from finance.

• A sales team that needs a CRM to hit a revenue target. The budget comes from sales.

• A marketing team that needs a new platform to manage campaigns and track leads. The budget comes from marketing.

Peter Somoya, Enterprise Solutions Consultant at PC Corp, has seen this play out across many enterprise purchases. When a request lands with IT, he says the first move should always be the same: “IT is an operational group that tries to reduce cost if possible. So when they need something, the first question you should say is why? And they’ll say, maybe I need to do this to support my business unit. So now you need to understand what the business unit is trying to do because they ultimately pay the bill.”

Understanding where the budget lives is the first part. The second is understanding that even when IT is fully aligned, the purchase can still stall.
 

Why do IT projects stall even after IT says yes?

IT approval is not the same as purchase approval. IT saying yes means the solution meets technical standards. It doesn’t mean the business unit has signed off, the budget is confirmed, or that the people with real decision-making authority have been part of the conversation.

Darren Armstrong, another Enterprise Solutions Consultant at PC Corp, has seen committees where upwards of 50 people have a stake in what the solution looks like and where it comes from. Some voices carry more weight than others. Some people have entrenched biases. And the person with the loudest voice isn’t always the one with the most relevant perspective.

For instance:

• A director may defer to a technical manager who has done a thorough evaluation.

• A junior team member who has been closest to the problem the technology will solve has more insight and influence than anyone with a formal leadership title.

• An accountant who likely reviewed every technology purchase that crossed the finance team’s desk may know exactly what questions leadership will ask about cost and return.

None of these positions will show up on an org chart as a decision-maker, but they often know things about the decision that no one else in the room does, which is why you may find yourself stuck at a step you thought you had already cleared if they aren’t involved.

If IT doesn’t understand your business, how can they make the right technology decisions for it?

Most of the time, nobody notices the gap between what IT knows about a system and what the business knows about it, until something goes wrong. Our enterprise procurement team once saw this become a very expensive problem for an organization and their IT team.

The email system that wasn’t mission-critical, until it was

At one point, this organization’s email system was tagged as a standard business application, which meant that its infrastructure reflected that assessment, built without redundant backups or fast-recovery architecture since the extra cost wasn’t seen as necessary.

Then the system went down.

The organization’s IT team got to work restoring it, treating it the way they’d treat any standard application. They estimated a couple of days to bring it back. But then the CEO called, upset that he couldn’t access his email. While IT had thought email was standard, not mission- or business-critical, he  explained that without it, his significant work couldn’t be accomplished. Email was how he executed contracts: attachments going back and forth with counterparties, commitments being made, deals in motion.

What a different classification would have meant

IT had never been told any of this. Had they known, the classification would have been different, and it would have changed the entire architecture built around their email system: how often backups run, whether redundancy is built in, how fast recovery resources get mobilized, and where the system sits in the restoration queue when something fails.

Instead, the IT team had to spend about four days to bring the system back up, and meanwhile, the CEO spent the entire time at home, waiting.

While supporting the email system at a higher classification would have cost roughly three times more upfront, it also would have meant recovery in hours. One conversation before the architecture was designed would have changed the classification,  recovery priority, and what those three to four days cost the organization.

How can IT and the business work toward the same outcome?

When proactive conversations happen consistently — not just when a purchase is in motion — IT stops being a gatekeeper and starts being a contributor who understands what the business is trying to do. Here’s how you achieve that:

Bring IT into the conversation before the requirement is finalized.

That’s when they can ask the questions that change the outcome and what you experience in your environment. When IT understands the business objective behind the request, they can push back on a spec that’s too narrow, flag components that are missing, and bring the right stakeholders into the room before the solution is locked. When they don’t have that context, they evaluate on cost and technical compatibility alone. While those are reasonable criteria, they often can be incomplete.

Give IT the business context before the meeting, not during it.

The conversation about why a purchase matters to the business shouldn’t happen for the first time in the room where the decision is being made. IT needs time to think through the implications, ask questions, and adjust their recommendation accordingly. A short written brief (what the business unit is trying to accomplish, what success looks like, and what it costs the organization if the solution underperforms) gives IT what they need to show up as a genuine contributor rather than a technical checkpoint.

Clarify whether the purchase is a requirement, a need, or a wish.

 A requirement is non-negotiable: the business stops or suffers without it. A need is important but has some flexibility in how it gets met. A wish is something that would be valuable but isn’t driving a real pain point. That distinction changes how the case gets framed for the budget owner, how urgently it gets prioritized, and how much scrutiny it attracts from finance. Knowing which category your purchase sits in before the proposal goes in saves a lot of revision later.

Map the committee before the proposal goes in.

A purchase proposal that satisfies IT but doesn’t address the concerns of a finance lead or a line-of-business manager will stall when it reaches them. Before the case goes in, it’s worth identifying who has a stake and what each of them will want to know. That junior team member, accountant, HR representative, or executive assistant… these people often know more about what will make the decision move than anyone with a formal title. Knowing who is supportive, who is neutral, and who may have reservations helps you build a more complete case before it reaches the decision-makers.

Frequently Asked Questions

Does the C-suite need to be involved in a technology purchase decision?

Usually at two points: when the mandate is set and when significant spend needs sign-off. In between, they typically hand execution to IT and the relevant business unit. The more useful question to ask early is what the executive sponsor needs to see to approve the investment, and whether your case is built to answer that.

How do you know if you’re talking to the right people in an enterprise technology purchasing conversation?

If every conversation is happening with IT and nobody from the business unit driving the need has been involved, there’s a gap. If nobody in the room has budget authority or direct access to whoever does, the proposal is probably being built for the wrong audience and will need to be rebuilt when it reaches the people who control the decision.

What is a buying committee in enterprise IT?

The group of people who collectively influence or approve a significant technology purchase. In enterprise organizations, it typically extends well beyond IT to include finance leads, department heads, line-of-business managers, and sometimes procurement or compliance representatives.

How do I build a business case that finance will approve, not just IT?

Frame the purchase around business outcomes, not technical specifications. Finance evaluates risk and return, so consider what this investment costs relative to the cost of not making it or making the wrong one. Connect the technology to a specific operational or revenue objective and quantify what staying on the current system is costing the business.

How do I get IT and the business on the same page before a purchase decision?

Bring IT in before the technical specifications are written and give them the business context in addition to the technical ask. The business unit also needs to share what is operationally at stake. When both sides understand the objective, the conversation about what to buy becomes clearer, making it easier to move forward.

The takeaway: know where the budget lives before the conversation starts 

Technology purchases that stall, get cut in approval, or deliver disappointing results after implementation almost always share the same root cause: the decision was made without sufficient context, and could have benefited from stronger communication and alignment between IT and business leaders

When that happens, decisions get made faster, with fewer surprises, and the technology actually delivers what the business needed from it.

If you’re currently building a purchase case, our article How to Build a Business Case for IT Investment That Leadership Will Actually Act On can help you frame the investment in a way that resonates with the people who actually control the funding.

You also don’t have to navigate these conversations or decisions alone. When you partner with our PC Corp team, you’ll get access to enterprise procurement experts who always ask why before recommending anything and understand the business context well enough to know what will work best for your budget and priorities

If you’re preparing for an IT procurement conversation, connect with us to get a clearer picture of where you stand before you walk into the room.