IT Procurement Process and IT Procurement Strategy cover the sequence and the planning behind it in full. This page is the short version: the specific habits that separate a well-run procurement from one that produces buyer's remorse six months in.
Before You Start Evaluating
Get IT, Finance, and Procurement in the room together, early. ach function sees a different piece of the decision. IT understands the technical requirements, Finance owns the budget and cost impact, Procurement owns process and vendor governance. A decision made without all three tends to surface problems after signature instead of before it.
Define requirements before looking at vendors. Write down what the solution needs to do, not what any particular vendor's platform already does. Requirements written after a demo tend to describe that vendor's product, which quietly eliminates every other option before the evaluation even starts.
During the Evaluation
Structure the RFP around evaluation criteria, not feature checklists. Price, solution fit, deployment timeline, post-implementation support, and training availability are all fair criteria. A feature checklist just rewards whoever's marketing team wrote the longest list.
Use proof-of-concept or live demonstrations before deciding, not after. A sandbox environment or a working pilot surfaces gaps a sales deck never will.
Separate one-time purchases from ongoing managed relationships. A hardware refresh and a multi-year MSP contract carry completely different risk profiles and should be evaluated with different weight given to vendor stability and long-term support.
After the Contract Is Signed
Document the decision and the rationale. Six months from now, someone will ask why this vendor was chosen over the alternatives. Having the answer on record saves a re-litigation of a decision that was already made carefully.
Track vendor performance against the SLA from day one.Waiting until something goes wrong to start measuring means there's no baseline to point to when it does.
Put the next review on the calendar before you need it. Revisiting a category on a schedule, ahead of renewal, keeps leverage on your side. Waiting for the renewal notice to show up means negotiating from a position with less time and less leverage.
Best Practices by Category
The habits above hold across categories, but the emphasis shifts. Software and SaaS decisions live and die on the license model, so the biggest single lever is matching seat count and tier to actual usage before signing, not after. Telecom and carrier decisions live and die on renewal timing, so the biggest lever is starting the review six to twelve months out, while there's still time to walk. Cybersecurity decisions live and die on scope clarity, so the biggest lever is defining exactly what's covered and what isn't before comparing price. See IT Category Expertise for the fuller picture of how priorities shift by category.
Common Anti-Patterns to Avoid
- Letting the incumbent set the terms of the conversation.An existing vendor's renewal proposal shouldn't define the evaluation criteria for whether to stay or switch.
- Treating the lowest price as the safest choice. The cheapest option is only safe if it also meets the requirements and support expectations; otherwise it's just deferred cost.
- Skipping the pilot to save time.A skipped proof-of-concept usually costs more time later, in a failed or delayed implementation, than it saved during evaluation.
- No one owning the vendor relationship after signature.This is the single most common way a good decision quietly turns into a mediocre one.
Frequently Asked Questions
What's the single most important best practice? Getting requirements defined and agreed before anyone talks to a vendor. Almost every other failure on this list traces back to skipping or rushing that step.
How often should these best practices be reviewed? Not on a fixed schedule so much as after every significant procurement, win or lose. A short debrief on what worked and what didn't compounds over time into a much stronger internal process.
Where to Go Next
If any of these steps consistently fall through the cracks internally, that's usually a bandwidth problem, not a skill problem. See IT Procurement Consulting for how outside support fits into a specific decision, or IT Procurement Support for the ongoing side after the contract is signed.
