Working with vendors and agencies
When an outside company builds your app, the contract decides much of what you can change, test and fix. This lesson covers the parts of a statement of work a PM must shape, how fixed price and time and materials move risk, a change-request process that keeps scope honest, a UAT plan with sign-off, an SLA with severity levels, a vendor scorecard and a handover plan, with templates you can use tomorrow.
By the end you can
- Shape the scope, acceptance, payment and support sections of a statement of work
- Choose between fixed price, time and materials and hybrids, knowing who carries which risk
- Run every change through one written path, and tell a defect from a change request
- Plan user acceptance testing with entry and exit criteria, and sign off cleanly
- Write an SLA with severity levels, score the vendor monthly, and make sure you could run without them
The everyday picture
You hire a builder for a house extension. The quote and the drawings say exactly what you get. You either agree a fixed price for what is on the drawings, or you pay a day rate plus materials. Halfway through you decide you want a skylight, and a good builder does not just cut a hole in the roof: she writes a change order with the extra cost and days, and waits for your signature.
Before the final payment you walk through the extension with a snag list: a door that sticks, a socket that does not work, a crack in the tiles. She fixes the snags, you sign, you pay. The warranty says a burst pipe gets a plumber within four hours, and a sticky drawer gets fixed within two weeks. And when she leaves, you get the keys, the wiring diagram and the manuals, so any electrician can work on the house later. Software from a vendor needs every one of those pieces.
Who owns what when a vendor builds
The vendor builds the software. You still own the product: the problem, the priorities, what "done" means, the launch and the outcome. The US government's 18F product guide puts the healthy pattern in one line: "The product owner is actively engaging the vendor and taking ownership of product decisions." Choosing the vendor in the first place is covered in Build, buy or partner; this lesson starts once you have chosen.
A typical split looks like this. The vendor owns engineering, its own testing, deployment to the environments, and often design. You own requirements and priorities, acceptance testing, user training, the rollout and the business results. Your legal and procurement colleagues own the contract itself. This lesson is not legal advice. Your job is to make the parts of the contract that describe the product precise: scope, acceptance, change, support and handover. Lawyers cannot write those for you, and vague product language is where most vendor disputes start.