Purpose and fit

Use this before inviting participants or introducing an AI-assisted process into real work. Choose a narrow scope that can be supported and reviewed with the resources available.

Before you start

Use your current problem statement, owner list, tool approvals and any existing quality or baseline records. If an approval or baseline is not yet available, draft the charter with that entry gate visibly unmet. Adapt the scope to the time, participants and data you actually have; no invented pilot results are needed.

Use only information you are authorised to share with the chosen AI tool. Adjust the prompt to the fields and context you actually have; a specially created dataset is not required.

Required inputs

  • A problem statement, intended users and bounded workflow
  • Approved tool/data arrangements and named owners
  • Baseline measures, acceptance criteria and known failure consequences
  • Participant support, issue reporting and a workable fallback process

Practical workflow

  1. Write a pilot charter: the question to answer, scope, participants, duration and boundaries. Define what is excluded.
  2. Set entry gates for data, access, quality checks, support and authorisation. Mark unmet gates as blockers to the affected activity.
  3. Agree continuation, change and stop criteria before reviewing results. Include both performance evidence and serious issues that require an immediate pause.
  4. Brief participants on the limits, review obligations, reporting route and fallback. Start only when the responsible owners confirm the entry gates.
  5. At the decision date, review measurements, participant feedback and incidents. Record the choice to continue, revise, expand or stop, with its conditions and owner. Expansion requires its own scope and approval checks.

Expected output

Expect a draft pilot charter, entry-gate checklist and review agenda. A completed-looking template does not authorise launch; actual start decisions belong to the responsible owners after the relevant checks.

A pilot charter and a review agenda covering the question, observed results, quality issues, total effort/cost, participant feedback, unresolved risks and next decision.

Human checks

People affected by the workflow have a way to raise concerns. The sponsor approves decision criteria and checks that the fallback is credible. The process owner can pause work when needed. Participants know which outputs still need review and how to report an error without waiting for the scheduled meeting.

Limitations

A pilot may not represent a larger workload or different teams. Increased usage does not establish value. A successful limited trial does not automatically authorise production use, expanded data access or customer-facing activity.

Starter checklist

Pilot question: ____________________ Sponsor / pilot owner / process owner: ____________________ Scope / participants / excluded tasks: ____________________ Start conditions / decision date: ____________________

Entry gates

  • Data, tool and access use are approved for this scope.
  • Baseline and acceptance criteria are defined.
  • Required output review and approval controls work.
  • Participants know the boundaries, support and issue-reporting route.
  • A usable fallback and stop owner are confirmed.

Decision rules, completed before launch Continue if: ____________________ Change and retest if: ____________________ Pause immediately if: ____________________ Stop if: ____________________ Expansion would require: ____________________

Review evidence

  • Accepted and failed work, with counts and observation window
  • Review, rework, fallback and support effort
  • Costs and measurement gaps
  • Incidents, near misses and participant concerns
  • Decision, rationale, conditions, owner and next review

Optional AI drafting prompt

Help me prepare the checklist above using only these authorised notes: [insert the available task, role and configuration notes]. Adapt the fields to my actual context.

Separate proposed criteria from confirmed approvals and observed results. Give each unmet entry gate an owner or unassigned label and next action. Set observable continuation/pause/stop criteria from supplied requirements, or ask for them; do not invent thresholds, record a launch, or describe a fallback as tested without evidence.

Before drafting, ask a focused question if a missing detail materially changes the task or acceptance criteria. Otherwise produce a clearly limited draft and list the gaps. Label any non-critical assumptions; never invent facts, figures, sources, approvals or completed actions.

Data and AI output disclaimer

Use relevant data that exists or that you provide, with accuracy and completeness sufficient for the task. Different AI models and versions may produce different results, and responses may vary between runs. You are responsible for checking and validating the output against your own requirements, source information and acceptance criteria before relying on it.