Deployed Works Guide
For organisationsHow To Run A Paid Diagnostic Before A Larger Deployment
Use a small paid piece of work to remove uncertainty before you commit to a larger project.
How To Run A Paid Diagnostic Before A Larger Deployment guide trailer
A short walkthrough for this guide will appear here.
Audience
For organisations
Organisations considering a diagnostic before deployment
Time
2 minute read
Outcome
Use a small paid piece of work to remove uncertainty before you commit to a larger project.
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
- Teams with a capability brief that still has open questions.
The problem
Start with the outcome before choosing a capability route.
Some work is too unclear for a full deployment but too important to leave as a vague conversation. A paid diagnostic creates a bounded way to test assumptions, understand systems, inspect risk and decide whether a larger capability deployment is worth starting.
Step by step
Build the brief around the work.
When a diagnostic is the right first step
Use a diagnostic when the outcome matters but the current process, data, system access, stakeholder ownership or scope boundaries are not clear enough for delivery pricing.
Define what the diagnostic should produce
Agree concrete outputs such as a workflow map, risk register, system review, recommended first phase, estimate range, proof review or decision note.
Say what it should not become
A diagnostic is not unlimited consulting, hidden implementation, a guarantee of future deployment or a way to extract free strategy.
Scope three to ten days of discovery
Choose the smallest useful period.
Agree outputs before work starts
Write the output list into the proposal.
Complete the buyer checklist
Confirm owner, budget range, access, stakeholders, timeline, outputs, next-decision criteria and handover needs before the diagnostic starts.
Example
Use this on Deployed Works
A team wants workflow automation but cannot explain the current exception rules. They run a five-day paid diagnostic.
Template
Paid diagnostic scope template
Diagnostic purpose: Current capability brief: Diagnostic length: Provider: Buyer owner: Questions to answer: 1. 2. 3. Outputs:
Common mistakes
Avoid these traps
- Calling it a diagnostic while expecting delivery work.
- Leaving outputs vague.
- Skipping access and stakeholder planning.
Checklist
Ready to publish when
- The diagnostic has a clear owner.
- The questions and outputs are written down.
- The provider knows what access is available.
- Out-of-scope work is explicit.
FAQ
Questions this guide usually raises
How long should a paid diagnostic be?
Most first diagnostics should be three to ten days. If it needs longer, break it into phases so the buyer can inspect value and risk before continuing.
Does the diagnostic provider have to do the deployment?
No. They may be the right provider, but the diagnostic should produce useful outputs even if the buyer pauses, proceeds differently or chooses another provider.
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.
Use a small paid piece of work to remove uncertainty before you commit to a larger project.
