Decide whether one focused project is ready for a small, controlled pilot.
Define the problem, users, evidence, data boundary, assumptions, success measures, risks, timeline, outputs and stop conditions before committing to a larger implementation.
Make the pilot testable before making it larger.
A useful pilot does not begin with technology alone. It begins with a defined problem, visible evidence, controlled scope and a review decision that can be defended afterwards.
Problem & users
Define one specific need, intended users, operating setting and the decision the pilot should support.
Evidence & baseline
Record the present condition, existing data, assumptions, uncertainties and comparison point.
Test & outputs
Specify the smallest controlled activity, expected records, measurable outputs, duration and success criteria.
Risk & review
Set data limits, responsibilities, safety controls, stop conditions, escalation rules and the review gate.
Four things should be visible before the pilot begins.
The aim is not paperwork for its own sake. These controls make learning, responsibility and the final decision easier to trace.
Purpose, inclusions, exclusions, users, responsibilities, timeline and expected deliverables.
Quantitative and qualitative measures agreed before testing, not invented after the result.
What will be collected, by whom, how it will be handled, where it will be stored and for how long.
Continue, revise, repeat, pause, stop or progress to a broader readiness and assurance review.
Move from interest to a clear, documented next decision.
Scope, evidence, responsibility and review stay visible from the first step.
Define
Clarify one problem, user group, environment and intended decision.
Baseline
Record the current condition, available evidence, constraints and assumptions.
Design
Set scope, duration, outputs, success measures and stop conditions.
Run safely
Use controlled access, proportionate data handling and appropriate human oversight.
Review
Compare evidence with the agreed criteria and record the next decision.
Test one use case first. Review organisation-wide readiness separately.
Pilot Readiness and Enterprise Readiness solve different problems and should not be merged into a single decision.
Can one bounded use case be tested responsibly?
Focus on the problem, users, evidence, scope, controls, measures, stop conditions and close-out decision for one defined pilot.
Can the organisation support wider adoption?
Focus on governance, operating model, roles, controls, evidence, integration, assurance and organisational capacity before scaling.
Request a Pilot Readiness discussion.
Share the pilot problem, intended users, available evidence, data sensitivity, proposed duration, success measures and the decision the pilot should support.
A readiness pathway supports a decision. It does not replace accountable authority.
Pilot Readiness supports scope, evidence organisation, risk visibility, controlled planning and review preparation. The people and institutions responsible for the project retain authority for consequential decisions.
Keep the pilot proportionate to the evidence and consequence.
Where a project touches regulated, safety-critical, clinical, legal, financial, environmental, cybersecurity or certified engineering decisions, appropriate qualified review and external authority remain necessary.
Make the pilot small enough to control and useful enough to learn from.
Start with one defined problem, visible evidence, agreed measures and a clear review gate before committing to a larger implementation.