
Quick Summary
- Wishes, wants, and needs are three different conversations, not points on the same spectrum.
- Every IT investment should connect to at least one of the four pillars: reduce cost, increase productivity, mitigate risk, or enhance experience. If it can’t, it’s not ready for the roadmap.
- Budget, timeline, and business readiness each shape how you sequence decisions.
- Roadmap planning works best as an ongoing conversation. Organizations with strong IT partners don’t start from scratch when priorities shift.
Does your organization have more IT initiatives on your wish list than the budget to fund them? When you decide to push some of these ideas to next year, how confident are you that it was the right call?
This article gives you two practical tools to help you make better IT investment decisions. The first is a framework for telling the difference between what your organization wishes for, what it wants, and what it actually needs. The second is a filter for what belongs in the conversation now. By the end, you’ll have a clearer way to prioritize your IT roadmap and technology purchases, while getting a better sense of what ongoing planning looks like.
Wish, Want, or Need? The First Filter for Your IT Roadmap
A department head says they “need” a new platform. Leadership hears “need” and assumes it’s non-negotiable. But most of what lands on an IT roadmap isn’t actually a need, it’s a want or a wish wearing a need’s language. Before you can prioritize anything, you have to know which one you’re actually looking at, because it changes what gets approved, how fast, what questions get asked before money moves, and how much of your budget stays protected for the things that actually can’t wait.
Here’s how to tell them apart:
- A wish is aspirational and often vendor-driven or motivated by wanting to keep up with trends. It’s something you’d want if money were no object and might not be tied to a specific business problem.
- A want is more directional. You have a general sense of what you’re after, a real budget, maybe a business unit asking for it. The question is whether the direction is grounded in something the business actually needs to accomplish.
- A need is defined by what the business must accomplish, shaped by budget, timing, and what’s already in place. There’s a hard deadline, a compliance requirement like an upcoming audit, or a business outcome that depends on it, a system reaching end of support, a contract obligation, something that doesn’t get postponed without a real consequence attached.
Jeffrey Jansen, Vendor Relationship Officer and Enterprise Solutions Consultant at PC Corp, uses a car-shopping comparison to make the point. He says a client’s wish might be a Ferrari, the fully loaded platform with every feature on the list. “What I really want though is a Lexus,” he says, “and what I need is a Chevy.”
Narrowing a want down to an actual need is its own conversation, and the outcome usually looks nothing like the wish someone started with. The gap between the Ferrari and the Chevy comes down to what you’re actually trying to accomplish, not what you can spend, and that’s the question that determines which conversation you’re having with leadership and your IT provider, what it asks, what timeline it runs on, and what decision it leads to.
If you want to see what these differences look like in real dollar terms, our article on server costs breaks down why a base configuration and a fully loaded one can carry a massive price gap.
The Four Pillars Test: Does This Belong on Your Roadmap?
Once you’ve decided which category an initiative belongs in, the next question is whether it belongs in the conversation at all. Jeffrey applies a simple filter: “Better be either able to reduce cost, increase productivity, mitigate risk, or enhance experience. And if I can’t do one of those four things with the technology solution that I’m providing to a client, it’s not even worth having a discussion.” It comes down to the outcome, not the technology itself, so before weighing whether something’s possible or interesting, the first test is which of the four it actually solves for.
Here’s what that means in practice:
- Reduce cost: If you’re investing in a new technology, whatever the mechanism, you should be able to point to a number: dollars saved per year, headcount hours no longer needed, or a maintenance contract that goes away entirely. This might mean cutting licensing overhead, replacing aging hardware before maintenance costs climb, or running more workloads on fewer physical systems.
- Increase productivity: Can you show that the investment frees up time or removes friction for the people using it? For enterprise organizations, this often means automating a manual process that used to eat hours every week, cutting the back-and-forth between disconnected systems, or removing steps that slow a team down without adding any value.
- Mitigate risk: The investment might address security vulnerabilities, compliance requirements, or disaster recovery gaps. These can be just as valid as cost or productivity drivers, and sometimes more urgent. An aging environment with no backup systems in place carries real exposure: financial, operational, and reputational.
- Enhance experience: : The purchase might make systems easier to use and reduce frustration for the people who rely on them daily. That could mean employees who stop losing time to a login process that fails half the time, IT staff who spend fewer hours on repeat support tickets, or customers and partners who get a faster, more reliable interaction with your organization. A clunky or slow system erodes trust and morale in ways that don’t always show up on a financial statement, but the costs are real: good people who leave, lost productivity and disengagement from your day-to-day work.
The four pillars aren’t a hierarchy. Any of the four is a valid anchor for an investment decision, the question is simply which one applies, and whether that case can be made clearly. If the answer is uncertain, the initiative is probably still a wish and may not belong on your IT roadmap right now.
For a closer look at the four pillars and how they apply to evaluating a vendor pitch, see The IT Industry Is Great at Selling Sizzle.
How Budget, Timeline, and Business Readiness Factor Into Prioritization
Passing the four pillars test tells you what belongs on your IT roadmap, but it doesn’t tell you what to fund this quarter versus next year. Three variables shape that sequencing.
Budget Approval
In most enterprise organizations, the budget for a major purchase usually doesn’t sit with IT, it belongs to the business unit or finance lead with sign-off authority. That means even a well-justified investment can sit in a queue waiting on someone else’s approval cycle, and if you don’t build that lead time into your plan, you end up with a gap between when you want to act and when you actually can. An initiative can be your top priority and still stall, because what matters most and what you can actually move on right now are two different questions.
Timeline
Some timelines are already decided, even when they don’t feel urgent yet. Vendor end-of-life dates are the clearest example. A system moving out of support comes with a fixed date attached to it, whether or not it feels urgent today. Organizations that get caught off guard are usually the ones that waited for the manufacturer’s reminder instead of building the refresh into their planning horizon ahead of time. The roadmap item that seems furthest off is sometimes the one that needs the earliest conversation.
Business Readiness
A well-justified investment can still be poorly timed. Significant IT changes require people to change how they work, and an organization mid-way through a merger, reorg, or ERP rollout may not have the capacity to absorb another disruption. A 2025 Gartner survey found that 79% of employees have low trust in organizational change, and that number climbs higher when changes land back-to-back without room to absorb them. Readiness also means having internal resources and executive sponsorship to see the implementation through, along with infrastructure that’s actually prepared to support what’s being added, rather than straining under one more integration or workload it wasn’t built for. The real question is whether you’re in a position to do this properly right now, not just whether the business needs it.
How to Keep Your IT Roadmap Current as Priorities Shift
A roadmap built once and left alone goes stale fast.
Peter Somoya, Enterprise Solutions Consultant at PC Corp, keeps his current by treating client relationships as an ongoing conversation instead of a series of one-off transactions: “If you treat each transaction as a discrete transaction and you’re waiting for the phone to ring for them to say I need to buy this, you’re never going to be ahead of the curve, right? So what you do with your larger customers and the ones that have an ongoing cycle of activities, you probably have a monthly meeting with them.”
To keep your roadmap current, you just need someone asking the right questions often enough that nothing shows up as a complete surprise “What are you guys doing? What are you working on? What’s coming up? What are you hearing from the business units? What are your planned projects? What do you see on the horizon this year that we have to address?”
He says that because you have that ongoing dialogue, you always have an idea of what’s going on and it’s not a complete surprise.
Jeffrey points to the same habit from the other side of the table: constant communication with the client about what’s changing in their environment, what projects and upgrades are coming, and giving them options rather than a single verdict. As he puts it, organizations need to be proactive in sharing “what’s changing in their environment, and what projects, what upgrades are required.”
When you’re open about what you need, it’s easier for your IT provider to offer options rather than a single verdict about what to prioritize in your IT roadmap. That might mean choosing between upgrading what’s already in place or replacing it entirely. Either way, when the context is already there from regular dialogue, new requirements show up as items to plan around rather than emergencies.
Frequently Asked Questions
How do I know if an IT request is a real need or just a want?
A wish is aspirational and typically untethered from a specific outcome. It’s usually driven by what you’re hearing from vendors or seeing in the market. A need has a deadline, a dependency, or a business outcome that won’t happen without the investment. The test is whether someone in the business is blocked or exposed without it.
How do you decide which IT projects should make it onto your roadmap?
Take the proposed investment and ask: will this reduce cost, increase productivity, mitigate risk, or enhance experience? If you can’t answer that specifically with a concrete connection to how the business operates, the investment isn’t ready for the roadmap yet. Build the case before the budget conversation, not during it.
How do you know if your organization is ready for a new IT project?
Readiness is about whether the organization can absorb and sustain the change right now, not just whether the project is justified. That means having the internal capacity to manage the implementation, clear executive sponsorship, and timing that doesn’t compete with other major transitions already underway. A project that’s well-justified but poorly timed tends to drag or stall partway through.
How do I push back on an executive request for new technology?
Run it through the four pillars: reduce cost, increase productivity, mitigate risk, or enhance experience. A leadership mandate without a defined connection to business outcomes is still a wish, even from the top floor. Go back and ask which pillar it’s solving for and what a successful outcome looks like in practice. That conversation is easier to have earlier than after procurement has started.
Turn Your IT Wish List into a Working Roadmap
Sorting your IT roadmap starts with being honest about the difference between what you wish for, what you want, and what you actually need, then applying a consistent filter to decide what belongs in the conversation now.
Without sorting your initiatives and applying the four pillars test, you end up committing budget to initiatives that haven’t been properly vetted, or sequencing work in an order that doesn’t reflect what the business needs first. An investment that can’t connect to at least one of the four pillars isn’t a roadmap item yet.
If you’re in the early stages of a procurement conversation and not sure what level of support you need, this article on IT procurement support walks through how to figure that out.
Your IT roadmap should reflect your real business priorities. PC Corp has been working with Alberta businesses and organizations for over 40 years to help make sure their IT investments are the right ones for their environment and operations. If your roadmap has more items than it has clarity, connect with our team and we’ll help you sort it out.

