Procurement
Most existing government applications are bought rather than built. Sometimes the whole thing, more often a part. Procurement is that buying: the whole journey from working out what you need, through choosing a supplier, to living with the contract for as long as the service runs. The contract is one part of it.
Think of this thread as a guided tour. At each stop it tells you what happens, what only you can decide, and where to go for the binding detail.
What work stays yours
Whatever your role here, some of the work is yours to carry. Here is what usually lands on your side.
- How long it takes. Procurement runs on its own clock, often many months from first idea to signed contract. Plan your timelines around it early, so it does not catch you short.
- The decisions only you can make. What problem you are solving, what good outcomes look like, whether to reuse or buy, and how to break the work into pieces. No one can make these calls for you.
- What you bring to each approval. Every checkpoint along the way expects something from you, a document, a number, a sign-off, and the work waits until it has it.
- The accountability. You can hand a supplier the work, but the result is still yours to answer for. When the service stumbles, the responsibility lands on your desk.
- The long shadow of the buy. Today's contract shapes the whole later life of the service: what it costs, whether you can change it, and whether you can ever move off it.
You do not need to be an expert. You need to stay in charge, and to ask when you are unsure.
Choosing what to buy
"Procurement" sounds like one thing. It is a choice between four routes, and the department makes that choice back in Discovery, long before the money arrives. The route decides when the contract is signed, who does the prototyping, and how much leverage the department has at signature.
Most services combine more than one route
The commonest shape is a Finished Product plus a Team.
The department buys the product for the core of the service, and buys a team to configure it, integrate it with what the department already runs, and keep it working. Reuse behaves the same way: a Government of Canada platform costs nothing to reuse and still needs someone to configure it.
Each contract keeps its own timing.
A department buying a Team and a Finished Product signs twice: once at the end of Discovery for the team, and once at the start of Beta for the product.
The route decides when the department signs, and signature is the moment it has leverage, because nothing has been committed yet.
The steps of a procurement
- 1Look
- 2People
- 3Ask
- 4Strategy
- 5Approve
- 6Engage
- 7Award
- 8Manage
You might not run all of it yourself, but you should recognise every step.
A GOOD CONTRACT
What a good contract looks like
When a supplier builds or runs your service, the contract is where every promise lives: what they must deliver, how you will see it being done, and whether you can ever leave.
We have written out a short, real-looking sample contract for the grant portal, with each clause the rest of the playbook tells you to put in.
Describing what you buy
Every contract needs a description of the work being bought. It is usually written one of two ways, and the choice shapes whether the work can change as you learn.
A statement of work spells out exactly what gets built and how, written as if all the requirements are known up front and will not change. A statement of requirement describes what the service has to achieve and who it is for, and leaves the supplier room to work out how. One fixes the steps. The other fixes the goal.
Case study
Statement of requirement
- States the goals and who the service is for, not the steps.
- Assumes you will learn as you go, and leaves room for it.
- Reads like "here is what this service has to achieve, and who it is for."
- Fits digital work, where the problem is not fully known up front.
- The work can change without a new contract, because it is tied to the goal.
The two are not enemies. A common pattern is that the department writes the statement of requirement, and suppliers respond with their own statement of work that turns those objectives into concrete tasks. So you are not throwing the detail away. You are deciding who writes it, and when. The department sets the goal. The supplier proposes how to meet it.
A worked example
Say a department needs an online way for people to apply for a benefit.
A statement of work would list it out: build these eight screens, in this order, with these fields, connected to this system, delivered by this date.
A statement of requirement would say: people who are eligible should be able to apply online, on their own, without help, in under fifteen minutes, including people who use assistive technology. How that gets built is for the supplier to propose and for the work to settle as it goes.
The first locks the answer before anyone has tested it. The second fixes what matters and lets the answer be found.
Comparison
Traditional and agile
| Topic | Traditional | Agile |
|---|---|---|
| Requirements | Fixed up front, then sent to market | Start from a challenge and your minimum needs, refine with suppliers |
| Shape of the buy | One or two large contracts | Several smaller contracts, in series or in parallel |
| Talking to industry | Through formal documents | Early and often, in workshops and working sessions |
| Handling change | Strategy mostly frozen once approved | Strategy evolves as you learn |
| When planning happens | Mostly at the start | All the way through |
| When you know it worked | After award and delivery | At each increment along the way |
Requirements
Start from a challenge and your minimum needs, refine with suppliers
Shape of the buy
Several smaller contracts, in series or in parallel
Talking to industry
Early and often, in workshops and working sessions
Handling change
Strategy evolves as you learn
When planning happens
All the way through
When you know it worked
At each increment along the way
Agile is not always faster. The payoff is confidence. You find the problems early, while they are still cheap to fix. And because the work comes in smaller pieces, you see its value earlier too. Traditional and agile describe the shape of a buy. They are a different question from what is being bought. A department can buy a team in a traditional shape, or a product in an agile one.
Case study
The same programme, bought two ways
The safe way
Break the programme into smaller, tightly scoped contracts that build on each other, often across several suppliers. This is the agile default.
What good looks like
A handful of things, all of which you can check. Each one has its own page.
1.You looked before you bought
You checked whether you needed to buy at all, and what the real options were, before reaching for a contract. The Options analysis reference page walks through the full ladder.
— open practice page2.You bought small, in pieces
You bought the work in small, separate pieces instead of one large block.
— open practice page3.You did not over-customise
You changed your process to fit the software, rather than changing the software to fit your process.
— open practice page4.You can leave when you need to
You can leave the supplier when you need to, with your data, your code, and the knowledge to move.
— open practice page5.You kept enough in-house
You held on to enough understanding to govern the work and to handle an exit.
— open practice page6.The contract carries the practices
The contract names the work the supplier must deliver, and says how you will see it being done.
— open practice page
Why it matters
The contract decides the future of your service. What it costs over its life. Whether you can change it. Whether you can ever move off it. Most of that is settled the day you sign, and undoing it later is slow and expensive.
A good buy leaves your options open. A bad one closes them over time, for as long as the service runs, often without anyone noticing until it is too late.
Buying the agile way lowers the worst risk of all, the two-year effort that ends in "start over." When you can correct course along the way, you are never far from solid ground.
Whose job it is
Your department's. You can give the building to a supplier, but the responsibility stays with you. If the service lets a user down, "the contractor did it" is not an answer anyone will accept. The Treasury Board Directive on the Management of Procurement says it in plainer policy terms. Your department is the business owner, accountable for the outcomes from start to finish. A procurement specialist, the contracting authority, runs the buying. You own the result. Keep that split in mind at every step along the way. TBS's GCcase migration guidance sets out the same split: departments are accountable for the decision and outcomes, TBS provides enterprise direction and standards, PSPC runs the service, and EARB reviews the architecture.
What Procurement looks like in each phase
Procurement runs through the whole life of a service, but it weighs more at some stages than others.
This is where procurement weighs the most.
You work out the real problem, choose whether to reuse or buy, set the strategy, go to market, and award the contract.
Almost every decision that will bind the service for years is made here, so it is worth slowing down to get right.
The official instruments behind procurement
Everything official this subject brings with it, and where in a service's life each one comes up. The full detail, including who does the work and what the business owner personally does, is in the table on the home page.
A supplier's written statement of how far their product meets the accessibility standard, clause by clause, with the gaps named. It is a claim to be tested, not a certificate.
- AlphaGather
- BetaSign or accept
- MaturityKeep current
- Official languages in what you buyOnly ifStanding duty
The obligation to write official languages requirements into the contract, so a supplier is contractually bound to deliver both languages rather than being asked for French later as a change request.
- AlphaGather
- BetaSign or accept
- MaturityKeep current
- Security Requirements Check List (SRCL, form TBS/SCT 350-103)Only ifSubmission
A short form that states, for one specific contract, exactly what security the supplier and its people need: what level of information they will touch, what screening each role needs, and whether the company may hold government information at its own offices. It is what turns a vague sense that a contract is sensitive into the clauses that actually go into the solicitation.
- DiscoveryCheck
- AlphaFill
- BetaSign or acceptSubmit
- GrowthKeep current
- MaturityKeep current
- SunsetKeep current
- Supplier organization and personnel security screeningOnly ifAuthorization
The clearances a company and its individual staff must hold before touching sensitive government work. Departments do not clear suppliers themselves; a single federal program does it, and confirms in writing that a supplier may be awarded the work.
- AlphaCheck
- BetaGatherSign or accept
- GrowthKeep current
- MaturityKeep current
Further reading
See also
Assumptions this page makes
You are already working to the Government of Canada Digital Standards, design with users, iterate and improve frequently, work in the open, use open standards, address security and privacy, build in accessibility, empower staff, be good data stewards, design ethical services, and collaborate widely, and to the law on privacy, security, official languages, and accessibility. The standards say how the government works in the digital world. The six Government of Canada digital competencies say what every public servant has to be able to do to work that way, and the team page covers them. This guide builds on those.