Map who a process change affects before announcing it

A process change can affect more people than those who approve it. It may add work to a reviewer, change what a requester hears, or leave downstream readers using an outdated instruction. Build an impact register before announcing the new process. Its job is to expose proposed obligations and questions, not to grant authority or assume consent.

Describe one fictional before-and-after process

Use an invented handbook workflow. Before the change, a requester submits a draft, a lead decides whether to approve it, and a coordinator tells the requester the result. The proposal adds a specialist review before the lead's decision. It also proposes an intermediate message telling the requester that review is in progress.

Keep that description beside the register. Do not begin with a list of names alone; readers need the old and proposed actions to understand the impact. State that this is a fictional planning exercise, not an implemented Kiguri workflow or an announcement of a real team's approved process.

Separate work, timing, access, and authority

For the specialist role, record the proposed review task, the draft material needed, and the point when the review should happen. For the lead, ask whether final approval authority changes or only the information arriving before it. In this example, the proposal leaves the final decision with the lead.

For the coordinator, record the new intermediate notice and its trigger. That is additional work even if it appears to be only one sentence. For the requester, record what they will be told and what action they may take while waiting. Do not let a status phrase imply a response deadline nobody accepted.

Look beyond the visible process owners

Identify people who use the output or explain the process elsewhere. A training facilitator may describe the old approval sequence in onboarding notes. A colleague maintaining the handbook instructions may need to revise those notes. A substitute coordinator may need to distinguish an intermediate notice from the final result.

Add these impacts as questions, not automatic assignments. Ask where each role relies on the current process and what would become misleading after the proposed change. Keep people who are absent from the planning conversation visible in the register instead of assuming the present group represents every affected need.

Ask representatives about specific obligations

Send each relevant role a bounded question through the team's normal process. Can the specialist review this material, and what input is missing? Can the coordinator provide the added notice, and what event reliably triggers it? Does the requester need a clear route for asking about a stalled review?

Record confirmed answers separately from proposed duties. Being named does not mean the specialist has accepted the work or has access to the draft. If authority or permission needs approval, retain that as an unresolved impact. This register explains what requires agreement; it does not replace the agreement.

Check the announcement against the register

Draft a fictional announcement stating what changes, which duties are accepted, who still approves, and how requesters receive updates. Compare each promise with its confirmed register entry. Remove unsupported timing or coverage promises. If an essential role remains unrepresented, do not present the complete process as ready.

The finished artifact identifies changed obligations, decision rights, notice needs, and open questions with their owners. Unlike a dependency diagram, it can reveal a role whose work changes even when no task waits for its output. Recheck it when the proposal changes so an earlier confirmation is not silently stretched to cover a new duty.