Look for a clear result
Start with a piece of work that already happens. Look for a task with recognisable inputs, an output people use, and someone who can tell whether it was done well. Recurring preparation work is often easier to scope than an entire department’s responsibilities.
For example, “prepare a draft project brief from these approved notes” gives you a result to inspect. “Improve our operations” leaves too many decisions unresolved. You can broaden a successful pilot later; the first version should be small enough to learn from.
Compare your options
Write down two or three candidate tasks. For each, discuss how often it happens, how much effort it takes today, and how difficult it would be to spot a mistake. Also ask whether the information needed to do it is available and appropriate to use.
Choose a task where the team can contribute examples and review results without creating a new bottleneck. A task that sounds impressive may be a poor starting point if nobody owns the process or agrees on what “done” means.
Prepare the context
Collect the material a capable new colleague would need: the task brief, a few good examples, the output format, and any relevant terminology. Include the rules that usually live in someone’s head, such as which facts must be verified or which decisions belong to a manager.
Keep the initial set focused. Use approved information, remove irrelevant personal or confidential material, and identify where each source came from. If the context contains conflicting instructions, resolve them before the pilot rather than leaving the workflow to guess.
Define the output and the boundary
Describe the expected result in a form that can be checked. A brief might need an objective, known constraints, decisions already made, open questions, and next steps. Say how uncertainty should appear: an unanswered question should remain visible, not become an invented fact.
List the actions outside scope. Preparing a draft does not automatically include publishing it, sending a message, editing a customer record, or committing the team to a deadline. Keep these boundaries in the brief so everyone reviews the same task.
Name the reviewer
Choose a person who understands the work and has time to review the first results. Agree on a short checklist: factual accuracy, completeness, usefulness, and whether the output stayed within its boundaries. Capture corrections so that you can identify repeated problems.
Make the handoff explicit. The workflow should stop at the agreed point, and the reviewer should know what they are approving. If a task needs information that was not supplied, the next step may be a question rather than a finished result.
Write the pilot brief
A brief you can adapt
- Task
- Prepare a first draft of a project brief.
- Inputs
- Approved notes, an existing template, and two reviewed examples.
- Output
- A draft with confirmed facts, assumptions, and open questions separated.
- Boundary
- No publishing, external messages, or changes to other systems.
- Review
- The project lead checks the draft before the team uses it.
- Success
- Less preparation effort while meeting the agreed quality checks.
Before starting, record how the task works today. The evaluation guide explains how to compare the pilot with that baseline and decide what to change next.
Let’s start with your work.
A goal, a challenge, or an example is enough to begin exploring what useful support could look like.
