Buy in small pieces
The most useful thing you can do when buying a service is to not buy all of it at once.
You bought the work in small, separate pieces instead of one large block. Each piece is tightly scoped, due soon, and able to build on the one before.
There are two well-worn ways to do this. Phased deliveries break the work into stages with go and no-go decision points, so you can stop or change course at each one. Contracts with task authorizations let you draw work down as and when you need it, in small, controlled amounts. You can mix them.
Build it the way you would code it
If you were building the service yourself, you would not write the whole thing in one sitting. You would work out the shape of it, build a piece, check that it works, then build the next piece on top. Small steps you can test. You fix your course as you learn.
Buying in pieces is the same habit applied to contracts. Instead of one big contract for the whole job, you write several smaller ones, each for a real piece of work. The architecture is a piece. Moving the data is a piece. Each part of the service is a piece. You buy them in an order where each one teaches you something before the next begins.
Why bother, when one big contract feels simpler?
Value and problems show early.
Small pieces prove their worth soon, and surface their faults soon, while there is still time and money to act.
You replace a piece, not the programme.
If a supplier underperforms, you swap out that piece instead of losing the whole thing.
Change is absorbed.
If needs shift, the next piece takes the change, so nothing rides on a single, distant delivery.
A single big contract bets you got everything right before you started. But building a service is full of things you cannot know up front, whether the technology fits, whether it clashes with what you already run, whether the problem is harder than it looked. Small contracts let you find out cheaply and change course.
Modular, not split: the line you cannot cross
There is a legal line here, and the fear of crossing it is one reason people avoid buying in pieces. So it is worth being clear about the two things people mix up:
Contract splitting is illegal.
It means taking one job and cutting it into fake slices to get around a control, usually to keep each slice under the dollar limit that would force a competition. The pieces are not really separate. It is one job dressed up as several, to dodge a rule.
Modular contracting is legal,
and the Directive leans toward it, favouring contracts structured to allow future competition wherever possible. It means splitting a programme into pieces that are genuinely different work, each able to stand on its own, competed in the open at its real size. Nothing is hidden.
The test: would these pieces exist as separate work even if there were no dollar limit to dodge? If yes, it is modular. If the only reason they are split is to duck under a number, it is splitting. One has real seams. The other has fake ones.
Write objectives, not a fixed list
How you write what the supplier must do decides whether buying in pieces is even workable. There are two ways to write it:
A statement of work
is a fixed list of exactly what gets built and how, written as if you already know everything: "the supplier shall build these screens, in this order, by this date." It suits things that do not change, and digital work badly, because every time you learn something new you have to reopen the contract to change the list.
A statement of requirement
works better for digital. You write down the goals, and bring in people who can work out what to build to meet them: "here is what this service has to achieve, and who it is for." The details can shift as you learn, because the contract is tied to the goal, which leaves the details free to move. See statement of requirement vs statement of work.
That is what lets a piece of work change without a new contract every time, and it is what makes buying in pieces practical instead of painful.
A worked example
Case study
The same programme, bought two ways
The work does not change. The shape of the buying does.
What this protects
- Accept that the whole thing is complex and not fully knowable yet.
- Name the real pieces: the architecture, the data move, each part of the service.
- Buy each piece as its own smaller contract, often to different suppliers.
- Each piece is due soon, so value shows up early and so do problems.
- If one supplier underperforms, you replace that piece and the rest carries on.
The honest cost of buying in pieces
Buying in pieces costs effort up front. There are more contracts to run, more suppliers to coordinate, and someone has to hold the whole picture so the pieces fit. That work is why people reach for one big contract.
The trade is still worth making. A big contract feels easier right until it fails, and by then the money is spent. Buying in pieces spreads the cost: steady attention as you go, and far less to lose when something breaks. You pay in coordination now to avoid a much bigger bill later.
But won't this be a hard sell? Common worries, answered
Most of the reasons people sign one big contract are not rules. They are fears and habits. Here are the ones you will run into, and what to do about each.
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.