Deployed Works Guide
How To Define Done For A Capability Deployment
Use this guide to define what done means before work starts, so delivery is judged by outcome, acceptance and handover rather than activity.
How To Define Done For A Capability Deployment guide trailer
A short walkthrough for this guide will appear here.
Audience
Organisations preparing a capability deployment
Time
9 minutes
Outcome
A written definition of done for a deployment
Share this guide
PDF guide
Download and share with your friends and colleagues.
Download this guide as a PDF and share it with your friends, colleagues or team. The web guide remains the canonical version.
Related guides
Before / after transformation
Turn a role-shaped advert into a capability brief.
Use this sequence when a need starts as a job title but the real requirement is deployed capability.
Start
Role label
Senior developer, automation consultant or product manager. Useful shorthand, but not enough to brief the work.
Diagnose
Current problem
What is manual, blocked, risky, slow or unclear today? Preserve concrete workflow details.
Shape
Deployment brief
Outcome, scope, must-haves, timeline, budget signal and what good looks like.
Review
Human-reviewed shortlist
Use fit indicators and human review to start fewer, better conversations.
Guide summary
What this guide helps you do
Who it is for
Best fit readers
- Buyers turning a capability brief into a first deployment.
- Project owners who need internal clarity before approving work.
- Teams working with external providers on technical, operational or product outcomes.
- Anyone who has seen projects drift because success was never defined.
The problem
Traditional hiring starts too late in the thinking.
Capability deployment can drift when done is not defined. Activity feels productive, but the buyer and provider may be imagining different end states. A good definition of done protects both sides by making outcomes, deliverables, acceptance criteria and handover visible before work begins.
Step by step
Build the brief around the work.
Why done matters
Done creates a shared finish line. It reduces ambiguity, helps scope decisions, supports handover and gives the buyer a fair basis for accepting or questioning the work.
Separate outcome from activity
Activity is what happens during the work. Outcome is what changes because of it. Write both, but judge the deployment by the agreed useful change.
Name the deliverables
List the things that should exist at the end: workflow, prototype, automation, report, system change, training, operating notes, dashboard or decision recommendation.
Set acceptance criteria
Define how the buyer will know a deliverable is acceptable. Criteria can include working examples, reviewed documentation, test cases, stakeholder approval, training completed or known limitations documented.
Include handover requirements
Specify who needs to understand the work, what documents or videos are needed, what system access changes after delivery and how maintenance questions will be handled.
Capture risk and open questions
Some uncertainty is normal. Write down dependencies, data risks, stakeholder decisions, access needs and areas where the provider cannot promise an outcome before inspection.
Document before work starts
Put the definition of done into the proposal, statement of work, project note or shared document. Keep it short enough that both sides will actually use it.
Use the done checklist
Before kickoff, check outcome, deliverables, acceptance, handover, owner, risks, timeline and what happens if the work needs to change.
Example
Use this on Deployed Works
A buyer asks for a reporting automation. Done is not just 'automation built'. Done means the weekly report is generated from the agreed data source, exceptions are documented, the operations owner can run it, a walkthrough is recorded and known limitations are listed for the next phase.
Template
Definition of done worksheet
Deployment: Buyer owner: Provider: Outcome: What should change: Deliverables: 1. 2. 3. Acceptance criteria: - - Handover requirements: - Documentation: - Walkthrough: - Owner training: - Maintenance notes: Open questions: Risks: Decision if scope changes: Final review date:
Common mistakes
Avoid these traps
- Defining done as hours spent.
- Leaving acceptance criteria until delivery week.
- Forgetting handover until the provider is leaving.
- Pretending uncertainty does not exist.
- Writing a definition so broad that nothing can be accepted.
Checklist
Ready to publish when
- Outcome and activity are separated.
- Deliverables are named.
- Acceptance criteria are testable or reviewable.
- Handover is included.
- Risks and open questions are visible.
- The buyer owner can accept the work.
FAQ
Questions this guide usually raises
Can done change during a deployment?
Yes, if both sides agree. The point of defining done is not to freeze reality; it is to make changes visible and deliberate.
Who owns acceptance?
The buyer should name an owner who can review, unblock and accept the work. Without an owner, delivery decisions tend to drift.
Should providers help define done?
Yes. Providers can surface risks and better criteria, but the buyer remains responsible for deciding what outcome matters.
Take it with you
Download and share with your friends and colleagues.
Download this guide as a PDF and share it with your friends, colleagues or team. The web guide remains the canonical version.
Share this guide
Use the canonical page link. No social scripts or tracking widgets are loaded.
Use the guide
Turn the work into a capability brief.
A practical guide for defining completion, acceptance, handover and success before a capability deployment starts.