Delivery quality

Keeping an engagement healthy is easier when we look up regularly and ask honest questions, rather than waiting for a steering meeting to go wrong. The delivery quality review is how we do that.

A self-assessment, not a gate

The review is a team assessing its own engagement, out loud, against a shared set of questions. It is deliberately not pass-or-fail, and the outcome is never used against anyone. The rating is only ever a way into the conversation that actually matters.

A low score is not bad news. It can mean an area we do not control, which is worth knowing, or an area we have chosen to improve, which is the point. So long as positive action follows, a low score is the review working.

How it runs

• Early, then regularly. Run a first review in the opening month, a lighter refresh each quarter, and a quick check-in monthly.
• The team, with a critical friend. The delivery lead, tech lead and the wider team all take part. Where we can, someone from outside the engagement facilitates: an experienced pair of eyes with no stake in the answer.
• Rate, then talk. Mark each area red, amber or green, and spend the time on what is amber or red, not on defending the greens.
• A few actions, owned. Leave with a short list of changes, each with an owner, and put them where the rest of the work lives.

The questions

Rate each of these as a team. They are prompts to talk around, not a form to complete:

1. Goals — is it clear what good looks like, and are we still aligned to it?
2. Plan — is there a visible plan, and are we tracking to it honestly?
3. Flow — is work moving steadily, or is it stop-start?
4. Team — is the team sustainable and supported, with no single point of failure?
5. Risks and decisions — are risks visible and owned, and are decisions written down?
6. Users — do we know who we are building for, and are we close enough to them?
7. Code and architecture — is the code base healthy and the design fit for where this is heading?
8. Testing — do we trust our tests to catch problems before a user does? See test strategy.
9. Security and compliance — are we meeting our obligations for data, access and regulation? See secure engineering.
10. Operability — could the client run this in production, and can we see what it is doing?
11. Go-live readiness — if we had to ship next week, what would stop us?

What it is for

The review exists to surface the quiet problem while it is still small, and to give a team an outside perspective before a client has to ask for one. Quality is everyone’s job here, not a stage tacked on at the end. We instil quality rather than assure it: the review is there to help a team build it in, not to inspect it in afterwards.