Prioritisation
Part of Reducing rework
Agreeing on completion criteria for a deliverable
Write observable completion criteria with the recipient, separate standing quality checks from deliverable-specific needs and manage changes clearly.
Agree with the recipient, before substantial production begins, on a small set of conditions they can check when the deliverable is handed over.
Record what it must contain or enable, which inputs and boundaries apply, and who will make the acceptance decision.
Revisit the criteria openly if the work or requirements change.
Turn the intended use into checkable conditions
Start with what the recipient needs to do with the deliverable. If an operations manager uses a weekly exception report to decide which cases need follow-up, “produce a professional report” gives little guidance. “Show open cases for the agreed week, grouped by owner, with the data cut-off stated” is something both sides can inspect.
The recipient can explain what makes the result useful; the maker can identify unavailable data, missing approvals or conflicting deadlines. Resolve those issues together before treating the criteria as agreed.
A compact record might cover:
- Content:Required sections, fields or functions.
- Basis:The approved source, period, version or assumptions.
- Quality and format:Checks relevant to use, such as readable tables and an agreed file type.
- Acceptance:The reviewer, review date and way objections will be recorded.
Avoid conditions included only because they are easy to count. A report may meet a page limit yet fail its purpose. Describe the result the recipient needs without prescribing every production step.
Separate shared checks from this deliverable’s criteria
A team may use standing checks across many outputs, such as proofreading, peer review or storing the final version in an agreed location. Criteria for a particular deliverable address its recipient’s specific need.
For example, checking spreadsheet formulas may be a standing team step; including all stores in the agreed region while excluding cancelled orders may be a condition for one report.
Keep both types of condition visible at review. If a condition cannot be checked, rewrite it or agree on what evidence would show it has been met.
Deliverable-Specific Criteria vs. Shared Quality Checks
- Deliverable-Specific CriteriaTailored to the recipient’s unique need (e.g., include only active stores in region X, exclude cancelled orders)
- Shared Team ChecksStandard practices applied across outputs (e.g., proofreading, peer review, storing final version in SharePoint)
Record changes to the finish line
If a reviewer requests another section or a different data period, compare the request with the agreed criteria. It may be a correction, a new requirement or a newly discovered risk. Agree on the response and record any effect on scope or timing rather than silently changing the original agreement.
At handover, show how the deliverable meets the current criteria. Ask the reviewer to identify any unmet condition and record required corrections, acceptance or a separate new request. An agreed list makes this decision clearer, but it does not replace judgement about a serious error discovered late.
