What delivery assurance is
Delivery assurance is having someone independent of the build team stay across a project's requirements, scope and quality while it's being delivered. The builders answer for the code. I answer to you for whether it's the right code.
It's unglamorous work: reading everything, keeping the paperwork honest, noticing early when a demo and a requirement have quietly parted company. It's also, in my experience, the difference between a specification that gets delivered and one that ends up in a drawer.
What I actually do
- Own the requirements through the build. The specification and user stories stay alive, updated and unambiguous, so nobody is building from a stale document.
- Keep the scope honest. Every change becomes a visible decision with a cost, not a drift that surfaces in the final invoice.
- Check what's demoed against what was specified. Politely, in writing, every time.
- Support acceptance testing. You'll know what "done" means before you're asked to sign anything that says it is.
- Keep client and supplier genuinely talking. Most project failures are communication failures wearing a technical costume.
- Report progress honestly. Including the uncomfortable parts, while they're still cheap to fix.
These days this can also mean AI pipelines that write and check specification detail at a scale no human team could keep up with. The judgement stays human; the drudgery doesn't have to.
When a project has already gone wrong
If you're reading this page mid-project rather than before one, you're probably seeing some of these: timelines that slip every time they're mentioned, costs that keep finding reasons to grow, demos that don't match what you thought you asked for, nobody able to tell you plainly what "done" means, and meetings that have either gone very quiet or very loud.
The first step is a short, fixed-fee review. I re-baseline the project: what was actually agreed, what actually exists, and what the honest gap is between them. Then you get an options paper, not a blame exercise: finish, fix, re-scope or stop, each with real costs attached.
Sometimes the right answer is to stop. It's much cheaper to hear that than to keep paying to avoid hearing it.
Why independent matters
The agency's project manager is usually good at their job. They also work for the agency, and every grey area in the requirements gets read, quite naturally, in the way that suits their team. That isn't villainy; it's incentives. Independence just means the requirements also get read on your behalf.
The good suppliers tend to like having me involved. Clear requirements, fast decisions and a client who understands what they're accepting make their job easier too. This isn't about catching anyone out; it's about nobody needing to be caught.
How it works
-
From day one, or from wherever you are
Ideally I'm involved from the specification onwards, often because I wrote it. But mid-project starts are common, and rescue reviews more common still.
-
An ongoing, part-time arrangement
A few days a month alongside your team, or one I've helped you put together, at an agreed monthly amount that matches the pace of the build.
-
Until it's genuinely done
Which means accepted against the specification and working in real life, not "launched and hoping". Then I get out of the way.
Common questions
What does a delivery assurance consultant do?
They stay across a software project's requirements, scope and quality while it's being built, independently of the team building it. In practice that means owning the requirements and user stories through the build, making sure every change is a decision rather than a drift, checking what's demoed against what was specified, supporting acceptance testing, and keeping the client and supplier genuinely talking. The builders answer for the code; delivery assurance answers to you for whether it's the right code.
My software project has gone wrong. Can you help?
Yes, and you're in good company, because this is common. The first step is a short, fixed-fee review: what was actually agreed, what actually exists, and what the honest gap is. You get an options paper rather than a blame exercise: finish, fix, re-scope or stop, each with real costs attached. Sometimes the right answer is to stop, and it's much cheaper to hear that than to keep paying to avoid hearing it.
Do you replace the project manager?
No. The project manager runs delivery day to day: the plan, the people, the cadence. I look after what's being delivered: the requirements, the scope, the acceptance of the work against what was specified. On bigger projects both roles exist and work well together. On smaller ones I sometimes wear both hats, but they are different jobs and it's healthy to know which one is being done.
The agency seems good. Do I still need independent oversight?
Good agencies exist and I work with several. But their project manager works for them, and every grey area in the requirements gets read, quite naturally, in the way that suits their team. Independent oversight changes the incentives without changing the relationship: the requirements get read on your behalf, changes get priced honestly, and the good agencies genuinely prefer it because decisions come faster and disputes don't fester. It costs a fraction of the build and earns it back in a single avoided misunderstanding.
What questions should I ask before hiring a software consultancy?
Five that do most of the work: Can I see case studies of work like mine, and speak to those clients? Who exactly will do my work, because the pitch team is not always the delivery team? What do I own at the end, and can I take it elsewhere? How do changes get priced once we've started? And what happens if I want to stop halfway?
A good consultancy answers all five without flinching. If any answer is vague, that vagueness is the price you'll pay later.
How much does delivery assurance cost?
It's an ongoing part-time arrangement at an agreed monthly amount, scaled to the size and pace of the project. Typically it's small next to the build budget, and it usually pays for itself the first time a misunderstanding gets caught in a document review instead of in month four of the build.