Deployed Works Guide
For organisationsHow To Define Done For A Capability Deployment
Agree what must exist, work or be handed over before the project can be called complete.
How To Define Done For A Capability Deployment guide trailer
A short walkthrough for this guide will appear here.
Audience
For organisations
Organisations preparing a capability deployment
Time
2 minute read
Outcome
Agree what must exist, work or be handed over before the project can be called complete.
Share this guide
PDF guide
Share this guide with your team.
Download the PDF for meetings or offline use. The web guide has the latest version.
Related guides
Before / after transformation
Turn a provider-shaped request into an outcome brief.
Use this sequence when a need starts as a provider label but the real requirement is a business result.
Start
Outcome
What needs to be different for the business, customer, team or workflow?
Diagnose
Current blocker
What is manual, blocked, risky, slow, expensive or unclear today?
Shape
Useful context
Success signals, non-negotiable constraints, evidence, timeline and budget signal.
Routes
Deployment routes
Derive viable approaches before asking the buyer to choose a person, tool, vendor or service.
Guide summary
What this guide helps you do
Who it is for
Best fit readers
- Buyers turning a capability brief into a first deployment.
The problem
Start with the outcome before choosing a capability route.
Capability deployment can drift when done is not defined. Activity feels productive, but the buyer and provider may be imagining different end states.
Step by step
Build the brief around the work.
Why done matters
Done creates a shared finish line.
Separate outcome from activity
Activity is what happens during the work.
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.
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.
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'.
Template
Definition of done worksheet
Deployment: Buyer owner: Provider: Outcome: What should change: Deliverables: 1. 2. 3.
Common mistakes
Avoid these traps
- Defining done as hours spent.
- Leaving acceptance criteria until delivery week.
- Forgetting handover until the provider is leaving.
Checklist
Ready to publish when
- Outcome and activity are separated.
- Deliverables are named.
- Acceptance criteria are testable or reviewable.
- Handover is included.
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.
Take it with you
Share this guide with your team.
Download the PDF for meetings or offline use. The web guide has the latest 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.
Agree what must exist, work or be handed over before the project can be called complete.
