A Practical Guide to Government Technology Procurement in Canada

How Government Procurement Actually Works

If you have only worked in the private sector, government procurement will feel slow, rigid, and frustrating. It is all of those things - and it is that way for good reasons. Public money requires public accountability, which means structured processes, documented decisions, and audit trails.

Public Services and Procurement Canada (PSPC) is the central purchasing authority for the federal government. Most technology consulting is procured through standing offers and supply arrangements that PSPC manages. These vehicles pre-qualify vendors, establish terms and conditions, and create a streamlined process for departments to acquire services.

The process generally follows this path: the department defines its requirements, selects the appropriate procurement vehicle, issues a request for proposals (RFP) or task authorization request, evaluates responses against predetermined criteria, and awards the contract. Simple in theory. Complex in practice.

TBIPS vs ProServices vs SBIPS

Choosing the right procurement vehicle is one of the first decisions you need to get right. Each vehicle is designed for different types of work, and using the wrong one creates problems downstream.

TBIPS (Task-Based Informatics Professional Services)

Use TBIPS when you have a defined task with clear deliverables and a fixed timeline. Examples: an IT operations maturity assessment with a written report as the deliverable, a ServiceNow configuration project with specific modules to be implemented, or an observability strategy engagement with a defined roadmap output. TBIPS works well when you know what you want and can define the scope tightly.

ProServices (Professional Services)

Use ProServices for broader consulting engagements where the scope may evolve. IT advisory work, ongoing consulting support, and engagements where the consultant needs to assess the situation before defining the solution fit well here. ProServices offers more flexibility in scope and timeline than TBIPS.

SBIPS (Solution-Based Informatics Professional Services)

Use SBIPS when you need a vendor to propose a solution rather than execute a predefined task. If you know you have a problem but are not sure what the solution looks like, SBIPS gives vendors the latitude to propose their approach. This works well for complex technology challenges where the department needs expert guidance on the path forward.

Writing Requirements That Work

The Statement of Work (SOW) is the single most important document in a government technology procurement. Vague requirements produce vague proposals, which produce vague deliverables. Specific requirements attract qualified vendors and make evaluation straightforward.

The most common mistake is writing requirements that describe activities rather than outcomes. 'The consultant will assess IT operations' is an activity. 'The consultant will deliver a written assessment of IT service management maturity across five ITIL process areas, including current-state scoring, gap analysis, and a prioritized improvement roadmap' is an outcome. The second version tells vendors exactly what you expect and gives you a clear basis for evaluating whether they delivered.

• Be specific about deliverables - name the documents, assessments, configurations, or other tangible outputs you expect
• Define acceptance criteria for each deliverable - how will you know it meets your standards?
• Specify the security requirements upfront - clearance levels, Protected B handling, on-site vs remote work
• Include the timeline with milestones, not just a start and end date
• State the expertise required - years of experience, specific certifications, government experience - so vendors can propose the right people
• Separate mandatory requirements from rated criteria clearly
• Include a section on knowledge transfer - you do not want to be dependent on the consultant after they leave

Building Evaluation Criteria

Evaluation criteria determine who wins the contract. Poorly designed criteria let the wrong vendor win. Well-designed criteria ensure the most qualified vendor is selected - not just the cheapest or the most prolific proposal writer.

Government evaluations typically use a combination of mandatory requirements (pass/fail) and rated criteria (scored). The weighting between technical score and price varies by vehicle and department policy.

• Mandatory requirements should be genuine pass/fail gates - security clearance, procurement vehicle qualification, minimum experience thresholds. Do not make everything mandatory or you will disqualify good vendors on technicalities.
• Technical criteria should assess capability, not just compliance. Instead of 'Does the firm have ITIL experience?' ask 'Describe three ITIL improvement engagements in government departments, including metrics achieved.'
• Weight experience in similar environments heavily. Government IT experience is not interchangeable with commercial IT experience. A firm with ten government engagements is a better bet than a firm with a hundred commercial ones.
• Include evaluation of proposed personnel, not just the firm. The quality of the individuals who will do the work matters more than the firm's overall credentials.
• Consider including a scored interview or presentation component for high-value engagements. This lets you assess the actual people who will do the work.

Common Procurement Failures

These failures come up repeatedly in government technology procurement. Most are preventable with better requirements, better criteria, or better process.

The SOW-to-delivery gap

The SOW describes one thing. The vendor delivers another. This happens when requirements are vague enough to be interpreted multiple ways. The vendor's interpretation is usually the one that requires less effort. Fix this by writing specific, measurable deliverables with clear acceptance criteria.

Lowest price wins the wrong work

For commodity services - staff augmentation at defined skill levels - lowest price evaluation makes sense. For consulting and advisory work where quality and expertise drive outcomes, lowest price evaluation attracts vendors who cut corners. Use a quality-weighted evaluation model where technical merit carries at least 60-70% of the score.

Evaluation criteria that cannot differentiate

If your evaluation criteria consist entirely of yes/no questions ('Does the firm have ITIL experience? Yes/No'), every qualified vendor gets the same score and you are back to lowest price. Design criteria that create a scoring spread - ask for specifics, examples, and evidence that separates the excellent from the adequate.

The procurement timeline surprise

IT teams consistently underestimate how long procurement takes. From requirement definition through evaluation and contract award, expect 3-6 months for a competitive process. Plan backward from your project start date and add buffer. Starting the procurement process 'next month' for work you need to begin in 90 days is already too late.

The Vendor Evaluation Process

A structured vendor evaluation process protects against both bad choices and procurement challenges. Document every step.

1. Define the evaluation team - include technical, business, and procurement representatives. Ensure evaluators have the expertise to assess the proposals.
2. Establish scoring methodology before receiving proposals. Each evaluator should score independently against the same criteria.
3. Screen for mandatory requirements first. This eliminates non-compliant proposals before the detailed scoring begins.
4. Score technical proposals without knowing the pricing. This prevents price from biasing technical assessment.
5. Conduct consensus scoring where evaluators discuss and align their scores. Document the rationale for each score.
6. Apply the price/quality formula only after technical scoring is complete.
7. Check references for the top-scoring vendor. Ask specific questions about government experience, delivery quality, and personnel stability.
8. Document the complete evaluation, including why vendors were not selected. This protects against procurement challenges.

Indigenous Procurement Requirements

The Government of Canada has committed to achieving a minimum 5% target for procurement with Indigenous businesses under the Procurement Strategy for Indigenous Business (PSIB). This is not optional - it is a government-wide commitment that procurement teams must factor into their acquisition strategies.

For technology consulting engagements, this may mean setting aside opportunities for Indigenous-owned firms, including Indigenous subcontracting requirements in larger procurements, or applying PSIB considerations in evaluation criteria. The Treasury Board's commitment under the Indigenous Procurement Policy goes beyond the 5% minimum and aims for progressive increases.

Practically, this means departments should maintain awareness of Indigenous IT consulting firms, consider Indigenous-specific procurement vehicles where appropriate, and ensure their procurement strategies align with PSIB commitments. This is both a compliance requirement and an opportunity to support economic reconciliation.

What to Look For in a Procurement Advisory Consultant

If you need help with the procurement process itself - writing requirements, building evaluation criteria, managing the vendor evaluation - here is what to look for.

Frequently Asked Questions

Related Services