Course outline · choose a lesson
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
By FDEInterviews · Updated
Transcript
Before you commit a scope, find out who uses the workflow, who supports it, who funds it, and who authorizes what it needs. Then record each decision with its scope and evidence. Agreement from one stakeholder doesn't automatically satisfy the others.
Start with four roles. The sponsor secures resources and owns the business decision. The champion advocates and helps you navigate. Operators do the affected work. And reviewers approve requirements within their remit. Calling that last role the gatekeeper is shorthand, not a diagnosis that they're obstructive. And it's not always four people. One person can hold several roles.
Now read a synthetic packet for a five-user read-only pilot. The sponsor emails, four weeks of engineering approved. That covers resources, not data access or launch. The champion arranges a demo account, which isn't production permission. The platform team says export access is technically possible, which isn't a granted credential. And security asks for the data flow, which means review is underway, not passed, so for all the funding and the demo, no row in the packet says the production pilot is ready.
Read-only isn't harmless. Reading can disclose information to someone who isn't authorized, or to a processor. It can also produce a misleading output that changes a decision downstream. The data path and the conditions of use still need review.
So write a decision register, not a list of friendly contacts. For each prerequisite, record the scope, the decision-maker, the evidence, the status, a due date and the dependency. Keep status words precise: requested, under review, approved with conditions, verified or declined. Platform owner, grant the app's service identity access to read this export, for this five-user pilot, is a decision someone can check. Platform is happy, isn't.
Unknown ownership is a finding in itself. Ask the champion who can decide, then confirm it with that role. And update the register when the scope changes. A new data recipient can create a new review after kickoff looked complete, because a review approves a specific flow: these fields, to these recipients, for this use. A new recipient is a new flow, however small it looks from the engineering side.
Bring reviewers a design they can inspect, with the sources, recipients, identities, storage and retention laid out, and if they require a control, remember that a due date for building it is not permission to run without it. With operators, ask how the change affects their effort, exceptions and error correction, and don't promise outcomes that belong to management. Agree the measures and who makes the success decision, because no single role decides it by default. Operator evidence, business outcomes and technical readiness answer different questions.
So start with four roles, then follow the decisions. Keep funding, influence, workflow evidence and approval distinct, track exact decisions rather than vague support, and recheck the map whenever people, scope or data paths change. The full lesson is on fdeinterviews.com.
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.
Roles first, then the decisions
Sponsor, champion, operator and gatekeeper make a useful first map, 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, and the champion advocates and helps you find your way around the organization. Operators do the affected work, while 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 the work worse; a champion may hold formal authority as well as influence. Ask, rather than reading motives or power off the label.
A supplied approval packet
This synthetic freight pilot proposes a read-only lookup for five desk users and 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, because 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 read “read-only” as “harmless.” Reading can disclose information to an unauthorized person or processor, and it can produce a misleading output that changes a downstream decision. The data path and use conditions still need review.
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 someone can check, which “Platform is happy” does not.
Unknown ownership is a finding in itself. Ask the champion and relevant teams who can decide, and confirm the answer with that role rather than assuming an introduction transfers authority. Ask early, and update the register when scope or organization changes, since a new data recipient can create a new review requirement long after the kickoff. A review approves a specific flow: these fields, to these recipients, for this use. A new recipient is a new flow, however small the change looks from the engineering side.
A design reviewers can inspect
Start with the data sources, recipients, identities, operations, storage/copies, deployment location and proposed retention. State unresolved items honestly, and ask what evidence the reviewer needs and which conditions must hold before the affected use.
Early contact can reveal constraints and save rework, but it cannot guarantee a fast approval, remove a necessary queue or make every reviewer a supporter. Some findings are about the code itself, others about 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, because a deadline or a sponsor's preference does not waive the requirement.
Operators, included without promises made for them
Ask how the proposed change affects effort, responsibility, exceptions and error correction. Include the 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 rest on agreed measures and the responsible governance, since no single stakeholder category decides success on its own. Operator evidence, business outcomes, technical requirements and operating readiness answer different questions.
When the map changes
If the champion changes roles, preserve the current evidence and verify the new decision paths. An existing approval may stay valid within its scope while access, escalation and renewal responsibilities need updating; neither everything expiring nor everything transferring automatically is a safe assumption.
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 above 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 free to save your progress and return to this lesson.