How Do I Know What Kind of IT Procurement Support I Actually Need?

 

Do you have an enterprise IT procurement coming up but aren’t sure whether you need someone to fill an order or someone to help you figure out what to order? Are you worried you’ll start the process, get a quote, and realize halfway through that it was built on the wrong assumptions?

The gap between “I have an IT procurement need” and “I know exactly what kind of help to ask for” is wider than most people expect. This article gives you two practical ways to close it: what kind of requirement you have, and who in your organization is driving the procurement. Then we explain what the process actually looks like for the kind of situation that fit most organizations like yours.

Of course, not every procurement situation needs a full solution design engagement. Sometimes you really do just need a price on a server. Knowing which conversation you actually need saves time on both sides.

What Are the Different Levels of IT Procurement Support?

Not every IT procurement need arrives fully formed. Some organizations know exactly what they want. Most don’t. PC Corp Enterprise Solutions Consultant, Darren Armstrong, describes the range: “At one end, someone comes to us and says, we want a server with a terabyte of memory. What’s your price? At the other end, someone says, my business isn’t working. How do I fix it?” Where you fall on that spectrum shapes what kind of support actually helps.

Let’s break down each level so you have a better picture of where you fit:

Level 1: Transactional

You know the brand, the model, the specs, and the reason for those choices. Some organizations have a mandated vendor standard, and the conversation is primarily about price, availability, and lead time. When you arrive with everything locked down, the process is fast.

Level 2:  Direction Without Specification

Level two is where most organizations sit. “Most often it’s usually, we need a server, what do you recommend?” Darren says. “That’s probably about 80% of the requests we get.” At this level, the conversation starts with questions about your environment, and the recommendation follows from those answers.

Level 3: Defined Desired Outcomes, Technical Solution Needed

Perhaps you’re deploying a payroll system or setting up a new infrastructure. Before it becomes a procurement conversation, it has to start as a design conversation. This involves discussing architecture, technical vetting, and manufacturer involvement. There may be more back and forth, but that’s what designing the correct solution requires.

Level 4: Something’s Broken, But The Problem Isn’t Defined

Level four is the least common starting point for a procurement conversation. It requires the most trust with your IT provider before you can achieve a product solution, since a partner needs enough context about your business to ask the right questions before offering any solutions. But it’s also where the work tends to have the most impact.

It’s not a problem if you don’t even know where to start or what you’re missing. The consultation is designed to surface it. What is a problem is when a vendor skips that step. If you describe a vague business outcome and receive a hardware quote before anyone has asked about your environment, workloads, or redundancy requirements, the process has already gone sideways. Procurement that starts at the wrong level tends to end with a system that doesn’t do what the business actually needed.

What Does a Level Two or Three Engagement Actually Involve?

Since most organizations land at level two or three when it comes to their IT procurement needs, it’s worth understanding what that process actually looks like.

Before any configuration work starts, the consultation is about understanding what you’re actually trying to do: the scope of what you need, whether that’s hardware, software, or both, and how all the pieces fit together. The solution takes shape from those answers.

Viable options only emerge after you’ve answered those questions. For a level two or three requirement, there could be several valid ways to build the solution. The consultation is how you narrow them down. Going in, several variables will shape which configurations are still on the table:

1. Budget: This factor tends to come up first and can immediately filter some of the options. Six configurations become four when the top two are out of range. 
2. Licensing: If the software running on your server is licensed per CPU core, processor choice has a direct impact on the software bill, not just the hardware cost. It’s one of the bigger reasons two quotes for the same project can look completely different. 
3. Redundancy Requirements: Some organizations can’t afford downtime, in which case redundancy isn’t optional. Peter Somoya, Enterprise Solutions Specialist at PC Corp, puts it directly: “If you need redundancy, you’re not buying one server, you’re buying two. Your price just doubled.” An organization that hasn’t thought through redundancy requirements can’t evaluate a quote accurately.
4. Backup Retention Policy: How long your business needs to keep backups, whether it’s a day, a week, or seven years, affects which storage configurations are viable. Regulated industries may have legal retention requirements that answer the question for them. Each answer directly affects storage sizing and which configurations remain on the table.

By the time all four variables have been applied, several configurations may be down to one or two that actually fit. That’s what protects you from purchasing a system that doesn’t do what the business needs.

The process shortens when a buyer arrives with clear answers already in hand. If you know exactly what you want and your systems are already configured, the adjustments are minimal. The more you know going in, the faster the consultation moves.

Who Is Driving the IT Procurement, and Why Does It Matter?

The source of the requirement often reveals the true level of support needed.

Darren describes a pattern that comes up often: a CEO decides the company needs to be doing AI like everyone else and passes the directive down to leadership. Nobody in that chain knows what it means in practice, so it lands on IT’s desk without much to go on. “It just kind of goes around in a circle,” he says.

That circular conversation is a level-four situation. The problem isn’t defined, so the solution can’t be either. But by the time it lands on IT’s desk, it’s often framed as a level-two request: we need hardware to support an AI initiative. A quote gets prepared for the wrong thing before the real work has started.

If the requirement originated from a C-suite mandate with no clear definition attached, it’s worth treating as a level three or four regardless of how it’s been framed internally. Diagnosis needs to come before procurement. If you’re the one who has to take that conversation back up the chain, this framework for building a business case leadership will act on is a useful next read.

How Do You Know Which Level You’re Actually At?

Look at how much of the requirement you can already define.

• If you know the brand, model, and spec, you’re at level one.

• If you have a general direction but need a recommendation, you’re at level two.

• If someone handed you a technical requirement but the business objective behind it is still fuzzy, you’re probably at level three, even if it doesn’t feel that way yet.

• If something is broken, slowing the business down, or costing more than it should, but you haven’t been able to connect it to a specific solution, that’s level four.

Most organizations land somewhere in the middle and aren’t entirely sure which description fits. But walking into that first conversation with an IT provider and having a sense of where you are changes what you’re able to ask for. Instead of waiting for a vendor to define the engagement, you can shape it. You know whether you need someone to fill an order or someone to help you think through a problem that hasn’t been fully named yet.

That distinction tends to determine how useful the conversation is.

Frequently Asked Questions

What does an IT procurement consultant do?

An IT procurement consultant helps you figure out what to buy before any purchase is made. Where a vendor fills a defined order, a consultant asks questions about your environment, workloads, and constraints first, then works toward a recommendation. Many IT partners operate in both roles. Which one you need depends on how clearly your requirement is already defined.

How do I know if I need help figuring out what to buy or just a quote?

If you know the brand, model, and spec, you probably just need a quote. If you have a general direction but aren’t sure what configuration fits, or if you know the business outcome but not the technical solution, you need a conversation before a quote. A good way to tell: if someone sent you a quote without asking about your environment first, it’s likely built on assumptions that haven’t been verified.

What should I ask an IT vendor before signing a contract?

Think through the outcome you’re trying to achieve and who else in your organization has a stake in the decision. Know whether you have a vendor standard you’re required to follow, and whether redundancy and backup retention requirements have already been defined. Ask the vendor what questions they need answered before they can configure a solution, and whether they’ve worked with similar environments before. If you don’t have all the answers going in, that’s fine. The ones you can answer will make the conversation move faster.

What should I have ready before my first IT procurement meeting?

At minimum, know who in your organization is driving the requirement and what they’re actually trying to accomplish. If the request came down from leadership without much context attached, spend some time tracing it back to the underlying business problem before the meeting. Beyond that, any documentation of your current environment, existing vendor standards, and known constraints around budget or timeline gives the conversation somewhere to start. You don’t need a complete picture. The meeting is designed to fill in the gaps.

Do I need an RFP for IT procurement?

Not always. An RFP makes sense when the requirement is well-defined, multiple vendors are being evaluated on equal terms, and the organization has a formal procurement process that requires it. For many enterprise IT purchases, especially at level two or three, the requirement isn’t fully defined yet, which means an RFP issued too early will either lock in the wrong scope or generate proposals that can’t be meaningfully compared. In those cases, a discovery conversation before the RFP is written tends to produce better results than going straight to a formal process.

Get More Out of Your Next IT Conversation

The kind of IT procurement support you need depends on two things: how clearly you can define what you’re trying to achieve, and who in your organization is driving the requirement. Getting those wrong has real consequences. When a vendor is engaged for a level-three situation as though it were a level-one transaction, the scope gets set before the problem is understood.

When your quote is built on the right assumptions, you won’t waste time or commit budget to a system that doesn’t actually solve what your business needs.

If you’re trying to understand what the full process looks like once you’ve figured out what you need, our article on why enterprise IT projects take six months walks through the timeline from first conversation to deployment.

PC Corp works with businesses and organizations in Alberta at every level, from straightforward procurement to full solution design. If you’re not sure which conversation you need, connect with our team or explore how we support enterprises like yours.