Map the people, decisions and prerequisites behind the pilot
Use sponsor, champion, operator and reviewer as starting roles, then map the actual decisions and evidence a pilot needs. Repair a supplied approval packet without mistaking enthusiasm, attendance or funding for technical and data authorization.
25 MIN
TL;DR: Identify who uses the workflow, supports it, funds it and authorizes its prerequisites. Record each decision's scope and evidence; agreement from one stakeholder does not automatically satisfy the others.
Where you are. Discovery has a candidate problem and open questions. Before committing a scope, find the people who can validate the workflow and the decisions required for the proposed data, environment and operating model.
Start with roles, then follow the decisions
Sponsor, champion, operator and gatekeeper form a useful first map. They are not a rule that every project has exactly four people. One person may hold multiple roles, and a large engagement may have several owners within each category.
The sponsor helps secure resources and owns or coordinates the business decision. The champion advocates and helps navigate the organization. Operators perform the affected work. Reviewers and approval owners check requirements within their remit. “Gatekeeper” is a shorthand for that last function, not a diagnosis that the person is obstructive.
| Starting role | Evidence they can contribute | Decision to clarify |
|---|---|---|
| Sponsor | Priority, resource constraints and desired outcome | Who can approve this budget and continuation? |
| Champion | Context, introductions and internal dependencies | Which decisions can they actually make? |
| Operator | Workflow, exceptions, usability and observed outcomes | Who accepts the changed working process and review effort? |
| Reviewer or approval owner | Security, data, procurement and platform requirements | Which exact use or deployment can they authorize? |
A sponsor may care deeply about latency when it drives the workflow. An operator may be required to use a tool and still report that it makes work worse. A champion may have formal authority as well as influence. Ask rather than assigning motives or power from the label.
Read a supplied approval packet
This synthetic freight pilot proposes a read-only lookup for five desk users. It needs a nightly shipment export, a manual document set and a deployed application.
| Packet entry | What it establishes | What it does not establish |
|---|---|---|
| Sponsor emails “four weeks of engineering approved” | The supplied budget decision covers that resource allocation | Data access, external inference or production launch |
| Champion arranges a demo account | A demo path is available | Production permissions for the five users |
| Desk lead agrees to two review sessions | Review time is offered for those sessions | Ongoing operating coverage or acceptance of all outputs |
| Platform team says nightly export access is technically possible | A potential integration exists | Granted credentials, approved use or a freshness guarantee |
| Security reviewer requests the data flow | Review is underway | The design has passed |
| Manual owner has not confirmed the current version | The document authority remains unresolved | That the shared-drive copy is safe to use for decisions |
No row says the production pilot is ready. Funding and a successful demo can coexist with unresolved release prerequisites. Mark the relevant decisions pending, specify their owners and identify which work can proceed with synthetic or otherwise approved data in the meantime.
Do not convert “read-only” into “harmless.” Reading can disclose information to an unauthorized person or processor. It also can produce a misleading output that changes a downstream decision. The data path and use conditions still need review.
Write a decision register, not a list of friendly contacts
For each prerequisite, record the proposed scope, responsible decision-maker, evidence requested, current status, due date and dependency. Keep status words precise: requested, under review, approved with conditions, verified, declined or no longer applicable. Approval and implementation verification may be separate entries.
A useful example is: “Platform owner: grant the application's service identity read access to export X in environment Y for the proposed five-user pilot; data owner confirms this use; credential and denied-access tests pending.” It names a decision that can be checked. “Platform is happy” does not.
Unknown ownership is a finding. Ask the champion and relevant teams who can decide; confirm the answer with that role rather than assuming an introduction transfers authority. Ask early, then update the register when scope or organization changes. A new data recipient can create a new review requirement after the kickoff was otherwise complete.
Bring reviewers a design they can inspect
Start with the data sources, recipients, identities, operations, storage/copies, deployment location and proposed retention. State unresolved items honestly. Ask what evidence the reviewer needs and which conditions must hold before the affected use.
Early contact can reveal constraints and reduce rework. It cannot guarantee a fast approval, remove a necessary queue or make every reviewer a supporter. Some findings concern the code directly; others concern contractual or operating conditions. Keep the consequence and owner concrete instead of describing all delay as politics.
If the reviewer identifies a required control, distinguish a due date for implementing it from permission to operate without it. Ask the responsible decision-maker about any permitted alternative scope. A deadline or sponsor preference alone does not waive the requirement.
Include operators without promising outcomes for them
Ask how the proposed change affects effort, responsibility, exceptions and error correction. Include relevant shifts, accessibility needs and less typical cases where the workflow differs. A single enthusiastic user can provide valuable feedback without representing everyone.
Do not assume operators oppose automation or that faster work is their only need. They may need reliable provenance, predictable handling of uncertainty or a clear way to challenge an output. Be accurate about what the project can and cannot promise, including unresolved staffing or process decisions that belong to management.
The eventual success decision should use agreed measures and the responsible governance. No single stakeholder category universally decides success. Operator evidence, business outcomes, technical requirements and operating readiness answer different questions.
Handle a changing map
If the champion changes roles, preserve the current evidence and verify the new decision paths. An existing approval may remain valid within its scope, but access, escalation and renewal responsibilities may need updates. Do not assume everything expires or everything transfers automatically.
The Engagement course later develops a sponsor-departure rehearsal. Here, the important habit is to record ownership and limits so the project can be understood without one person's memory.
The spine below is the move from a map of people to a register of decisions, ending where the lesson insists the register ends: approval and verification as two separate rows.
Do this before moving on
Turn the six-row packet into a decision register. For each row, write one next request and one observable piece of evidence that could close the relevant gap. Do not invent named people or approval dates absent from the packet.
Then respond to three changes: the sponsor asks to add an external model endpoint; a sixth user from another department wants access; the desk lead can no longer attend the reviews. Identify the affected scope and owner, and state what remains allowed under the original facts.
Your register passes when funding, advocacy, access, data use, workflow testing and launch readiness remain distinct, and every prerequisite has a confirmed owner or an explicit ownership question.
Go deeper
- Stakeholder management covers the ongoing work of keeping relevant people informed as responsibilities change.
- Explaining trade-offs is what you owe the sponsor, in their units rather than yours.
- VPC deployment explains one deployment boundary that may require platform and security review.
- Dirty data and a timeline blowup: the executive conversation is the sponsor conversation when discovery was too shallow.
- Why customer-facing engineering? is worth revisiting now that you know who is actually in the room.
Key takeaways
- Four role categories are a starting map, not a complete organization chart.
- Distinguish resources, influence, workflow evidence and approval authority.
- Track exact decisions and verified conditions rather than vague stakeholder support.
- Bring data and capability evidence to reviewers early without assuming their answer.
- Recheck the map when people, scope or data paths change.
Check yourself
Answer before you look. Recalling it is what makes it stick; recognising it does not.
1The sponsor approves four weeks of engineering. Is external model processing authorized?
2Security asks for a data-flow diagram. What is the status?
3Who universally decides whether an engagement succeeded?
Sign in to track which lessons you have finished.