Stakeholder Update

You keep the people who matter to a piece of work informed in the right amount, at the right time, through the right channel, so there are no surprises and the asks get answered. The standard: every stakeholder knows the true status, the status colour means the same thing every time, bad news arrives early with a plan, and each update can be read in two minutes.

When to use

• "Who needs to know about the office move, and how often?"
• "Write the fortnightly update for the migration project."
• "The launch is slipping, how do I tell the partners?"
• "Draft a status update for the leadership team."
• "Set up regular updates for the Acme pilot."

What you need

• The work being reported on: goals, milestones, owner, current status, risks, decisions pending. Get these from the project tracker or the project lead (ask_teammate).
• The list of people and groups affected or with influence, and the history of what they have been told (search_files, session_search).
• The owner's view on sensitivities: what can be shared with whom, especially externally.
• Access: email, chat and the tracker as connected apps or through the agent's own browser signed in by the owner. You draft; sending is the owner's decision unless they have set a standing rule for a specific internal update.

Method

1. Map the stakeholders. List each person or group.
   • Place them on a power and interest grid (after Mendelow): high power and high interest (manage closely), high power and low interest (keep satisfied), low power and high interest (keep informed), low power and low interest (monitor).
   • Note for each: what they care about, what they need from us, what we need from them, and their preferred channel.
   • Template in references/update-formats.md.
2. Set cadence and format by quadrant. Manage closely: frequent, personal (a short call or tailored note, weekly or fortnightly).
   • Keep satisfied: brief, outcome-focused, monthly or at milestones.
   • Keep informed: a regular written update or channel post.
   • Monitor: milestone announcements only.
   • Put the schedule in the calendar and set cronjob reminders to draft each update.
3. Define the status colours once. Green: on track for scope, date and budget.
   • Amber: at risk; a problem exists but the team has a credible plan to recover without changing the date or scope.
   • Red: will miss date, scope or budget without a decision or help from outside the team.
   • Write these definitions in every update or link to them.
   • Never report green when the team privately believes amber.
4. Draft the update. Use the format in the reference file: status and one-line reason; progress since last update (outcomes, not activity); next steps with dates; risks and issues with what is being done; decisions needed or asks with a deadline. Tailor depth per audience; keep the facts the same for everyone.
5. Deliver bad news well. As soon as the status turns amber or red, tell the manage-closely group before the next scheduled update, ideally in person or by call, followed by a written note.
   • Structure: what happened, the impact, what we are doing, what we need from them, when they will hear next.
   • No blame, no burying.
6. Check facts and permissions. Every date and number is confirmed with the project lead.
   • External updates contain nothing confidential that the owner has not cleared.
   • Personal data and HR matters stay out of stakeholder updates.
7. Get approval and send. Present drafts with show_card.
   • The owner approves each external update.
   • For internal updates, follow the owner's standing rules.
8. Track responses. Log questions, objections and asks from stakeholders; turn agreed actions into commitments (see meeting-actions-and-commitments). If a key stakeholder goes silent, flag it: silence from a high-power stakeholder is a risk.
9. Review the map monthly. People change roles, interest rises near launches. Update the grid and cadence.

Judgement calls

• Two stakeholders want opposite things: surface the conflict to the owner. Do not tell each side what they want to hear.
• A stakeholder wants more detail than their quadrant normally gets: give it. The grid is a starting point, not a limit.
• External stakeholders and internal problems: share the impact and the plan, never internal blame or personnel details.
• The project lead says green and the data says amber: report the more cautious status, explain why, and tell the lead before the update goes out.
• Long programmes: refresh the map at each phase change, when key people change roles, and before launches.
• Someone never reads the updates: ask how they prefer to hear, then change the channel or the length.

Example status line:

• Weak: "AMBER: some delays."
• Strong: "AMBER: supplier delivery slipped 6 days; we have moved testing earlier to absorb it and still expect launch on 12 Nov. Need from you: approve overtime budget of 4k by Fri."

Output

• stakeholders/<project>-map.md: the grid, per-stakeholder notes, cadence and channel.
• One draft update per audience per cycle, in the standard format.
• A response log and any new commitments.

Checks before you finish

• Status colour follows the written definitions and matches the team's honest view.
• Progress lists outcomes with dates, not activity.
• Asks are specific, with an owner and a deadline.
• Facts are the same across audiences; only depth differs.
• External drafts are cleared by the owner; nothing confidential leaks.
• Amber or red was communicated to key stakeholders before the scheduled update, not in it.

Pitfalls

• Watermelon status. Green outside, red inside. It always comes out, and trust goes with it.
• Activity reports. "We had six meetings" is not progress. Report outcomes.
• One update for everyone. The board member and the project team need different depth. Tailor, but never change the facts.
• Surprise by email. A key partner should never learn about a slip from a group update. Call first.
• Asks without deadlines. "We need your input" gets ignored; "we need your sign-off on the venue by Friday 17:00" gets answered.
• Silence. Skipping an update because there is no news worries people. Send a short "on track, nothing new" note.
• Changing colour definitions. If amber means "slightly behind" one week and "in trouble" the next, people stop trusting the colours. Use the written definitions every time.
• Forgetting to close. When the work ends, send a final update with outcomes against the original goals and thank the people who helped.

See also: meeting-actions-and-commitments for tracking what stakeholders agree to, and board-and-investor-update for board-level reporting.