Put the practices in the contract
The rest of this playbook tells you how to run a service well. This page is about what happens to that advice when a supplier is the one doing the work.
It still has to happen. The contract is how you make sure it does.
You cannot outsource the responsibility
User research, accessibility, security, keeping the service usable and safe: none of these stop being your job because a supplier is at the keyboard. If the service is not accessible, your department is the one that has shut people out, no matter who wrote the code.
So when you buy the work, the practices do not go away. They move into the contract, and into the things you check the supplier on.
The playbook becomes the spec
This is the useful part. Every practice in this guide is something you can ask for in a contract, and the contract is where you say what the supplier has to deliver. So the playbook turns into the checklist you build that contract from.
For each practice that matters, there are two moves:
Name it.
Put it in the contract as a real deliverable.
Good clause: "The supplier will run usability testing in each phase with at least five participants from the service's real user groups, including people who use assistive technology, and give the findings to the department."
Bad clause: "The supplier will do user research with real users."
Govern it.
Decide how you will see it being done. If you cannot check a practice, you cannot govern it. Ask for the proof: the research write-ups, the accessibility audit, the test results.
Where you can, write the measure into the contract, and make it a good requirement, one that is specific, measurable, and testable. “Pages load in under three seconds for almost everyone” is checkable. “The service will be fast” is not. It is the same idea as a good dashboard: the number has to be measured. Those measures are what you hold the supplier to, and what you pay against.
What the department does
When the department builds in-house, it does the work. When it buys, or contracts a team to build, its job is to make sure the supplier does it, and does it well. That is its own kind of work, and it takes real time and attention. People sometimes treat buying as the lighter option. It usually isn't.
It also means you cannot govern what you do not understand. To know whether the supplier's research was any good, someone on your side has to know what good research looks like. To know whether the security work is real, someone has to be able to read the answer. These are the same skills the rest of the playbook teaches. You are using them to govern a supplier instead of to do the work, but they are the same skills.
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.