Draft quality and completeness criteria per deliverable
For each named deliverable, writes explicit acceptance criteria — what the client is signing off and the standard of evidence or rigour expected — before delivery begins.
In / outNamed deliverable list with definitions of done → per-deliverable acceptance criteria (quality standard + evidence threshold)
You might say…
“If we wait until the end to define what 'good enough' means, we'll argue about it when we can least afford to.”
What it does
For each named output, writes explicit acceptance criteria — what the client is accepting at sign-off and the standard of evidence or rigour expected. Used after deliverables are defined, to make 'good enough' an agreed, shared reference before delivery.
Trigger: Use after deliverables are defined and before delivery begins, to make the quality bar and completeness standard an agreed, shared reference.
Recognise the problem?
The primitives are the commodity part. The fastest next step is a conversation about composing them into something that works for you.
Start a conversation