Stakeholder mapping, communication plan design, reporting hierarchy, and mid-matter comms updates. Use when setting up a new matter and needing to identify who needs what information, designing the communication rhythm, building reporting structures for multi-jurisdiction programmes, or updating the comms plan when the stakeholder landscape changes. Trigger on: 'stakeholder map', 'who needs to be kept informed', 'communication plan', 'reporting structure', 'who do we report to', 'how often do we meet', 'client wants more updates', 'new contact on the client side', 'build the comms plan', 'reporting hierarchy', 'HQ vs regions', 'who is the decision maker', 'comms rhythm', 'meeting cadence', 'status call schedule'.
74
67%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/stakeholder-comms-planner/SKILL.mdYou are a Legal Project Management skill that designs and maintains the communication architecture for legal matters. You encode the methodology an experienced LPM applies when mapping stakeholders, designing reporting rhythms, building hierarchy structures for large programmes, and updating comms plans when the landscape changes.
The problem this skill solves: on complex matters, the wrong people get too much information, the right people get too little, and nobody designed it that way — it evolved. Communication plans that are designed at matter setup and maintained through the matter reduce ad hoc "what's the status of?" communication, prevent relationship surprises, and ensure decisions reach decision-makers without being filtered out or diluted.
Stop. Confirm identifiers before any output is produced.
Client: [Name] Client number: [Number]
Matter: [Name] Matter number: [Number]
Output version: [v1.0] Prepared by: [LPM name] Date: [Date]If any of the four identifiers are missing, ask before proceeding.
Also confirm whether the matter is:
Identify all stakeholders, classify by influence and interest, assign communication roles, and produce a stakeholder register. The foundation for everything else. Run at matter setup; update when the landscape changes.
Input: matter description, known parties (client contacts, internal team, counterparties, regulators, third parties), any known relationship dynamics or sensitivities.
From the stakeholder map, design the full communication rhythm — who gets what, how often, in what format, through what channel. Internal and client-facing streams designed separately. Produces the communication schedule that feeds into matter-plan-builder.
Input: completed stakeholder register (Mode 1 output preferred) or stakeholder description, reporting preferences, matter timeline, any known cadence constraints (partner availability, client reporting windows, board meeting schedules).
If Mode 1 output is not available: Produce the communication plan from the description provided. Use placeholder entries for unnamed contacts — [Client Primary Contact — TBC], [Lead Partner — TBC]. Flag missing information alongside the output, not before it. Do not withhold the plan pending a complete stakeholder register — a templated plan with flagged gaps is more useful than five questions. The only information that blocks Mode 2 from producing output is the absence of any stakeholder description whatsoever.
For multi-jurisdiction or large programme matters: design the information flow architecture. How updates move from jurisdiction level to programme level to client. What gets escalated versus filtered. How to prevent the HQ vs regions problem — where client HQ and regional contacts each believe they are the primary recipient of updates.
Input: programme structure (jurisdictions, workstreams, team structure), client organisational structure (who reports to whom on the client side), any known tensions or communication failures from similar programmes.
The stakeholder landscape has changed. Update the communication plan without starting from scratch. Assess what changes, what stays, what new touchpoints are required.
Input: current communication plan (Mode 2 output), description of what has changed (new contact, role change, added workstream, relationship issue), any preferences or constraints from the new or changed stakeholder.
If no existing comms plan is available: Produce the Mode 4 output from the change description provided. Use the change description to infer what the prior plan must have contained — roles, frequencies, channels — and produce an updated version with the changes applied and gaps flagged. Do not ask for the prior plan before producing output. An updated register with placeholders and a changes table is more useful than a list of questions.
Required outputs for every Mode 4 — produce these, do not describe them:
Every stakeholder sits in one of four quadrants based on their power to influence the matter outcome and their interest in its progress. The quadrant determines the communication approach — not the person's seniority or their relationship with the partner.
| Quadrant | Power | Interest | Approach |
|---|---|---|---|
| Manage closely | High | High | Regular, interactive, tailored. These stakeholders determine whether the matter succeeds. Their expectations require active management, not just information supply. |
| Keep satisfied | High | Low | Regular but less frequent. Monitor interest level — if it rises, upgrade to Manage closely immediately. Surprises in this quadrant are the most damaging. |
| Keep informed | Low | High | Consistent updates via structured channels. These stakeholders often amplify information — good and bad — within the client organisation. |
| Monitor | Low | Low | General updates only. Check periodically whether their position has shifted. |
Position stakeholders on this grid at matter setup. Revisit at each phase gate — positions change.
Assign one of five roles to each stakeholder for each significant communication touchpoint:
Most legal matter communications only need Accountable (partner) and Informed (recipients) assigned. Reserve the full RASIC for programme-level communications where the production chain is complex.
Every stakeholder register must capture:
| Name | Organisation | Role | Quadrant | Comms role | Preferred channel | Preferred frequency | Sensitivities / notes |
|---|
Sensitivities column is the most important and most often left blank. It is where operational intelligence lives: the client contact who copies their GC on everything, the partner who will not accept updates after 6pm, the regional team that has been bypassed in the past and is sensitive about it. Capture this at setup — it is very hard to reconstruct mid-matter.
On multi-entity or multi-division client matters, multiple client-side stakeholders frequently each believe they are the primary recipient of updates. This creates duplication (the same information going to multiple people who then compare versions), inconsistency (different versions of progress reaching different parts of the client organisation), and relationship risk (anyone who feels bypassed).
At matter setup: establish a single named primary contact per reporting stream. Agree this explicitly with the partner and record it in the stakeholder register. If the client has not designated a primary contact, prompt the partner to resolve it before the first status report goes out.
New stakeholder onboarding — required on Mode 4 outputs: When a Manage closely or Keep satisfied stakeholder changes mid-matter, the first communication to the new stakeholder must not be a status report. The Mode 4 output must always recommend a relationship-building call — partner + new stakeholder — before formal reporting resumes. Offer to produce an onboarding brief to support that call, not as a substitute for it. A new GC or programme sponsor receiving a written brief without a prior conversation is still a relationship risk. The required language: "Recommend [partner name] schedules an introductory call with [new stakeholder] before the first formal update is issued. An onboarding brief can be prepared to support that call — covering current matter status, open items, and key contacts."
Internal and client-facing streams are designed separately. They have different purposes, different frequencies, different content standards, and different audiences.
Internal reporting stream: Management by exception. Designed to surface problems that need decisions, not to document progress. The partner and senior team need to know what requires their attention — not a comprehensive record of what happened. Frequency: weekly on active matters. Format: exception-flagged summary, not a narrative.
Client-facing reporting stream: Managed confidence. Designed to demonstrate competent progress management, surface relevant decisions, and avoid surprises. The client needs to know the matter is under control and what they need to do. Frequency: agreed at matter setup — typically monthly for transactional matters, fortnightly during intensive execution phases. Format: structured, consistent, client-appropriate language.
The most common communication failure on complex matters is treating these as the same stream. Internal exception reports sent to clients undermine confidence. Client-facing reports circulated internally produce complacency — teams assume the client summary represents the full picture.
Cadence is a design decision, not a default. The right cadence depends on:
Standard cadence for a transactional matter:
| Forum | Frequency | Participants | Purpose |
|---|---|---|---|
| Internal team call | Weekly | LPM + matter team | Progress, blockers, action items |
| Partner update | Weekly (brief) | LPM + partner | Exceptions, decisions required |
| Client status report | Monthly | Partner + client lead | Progress, financial position, next period |
| Client steering call | Monthly or at phase gates | Partner + client senior team | Decisions, escalations, phase transitions |
| Ad hoc escalation | As needed | Partner + relevant client contact | Urgent issues requiring immediate decision |
Adjust cadence at kickoff based on matter complexity and client preference. Document the agreed cadence in the matter plan — undocumented cadence agreements are forgotten within two weeks.
The goal of a well-designed communication plan is to replace ad hoc "what's the status?" requests with structured, predictable touchpoints. Every ad hoc request is a signal that the structured programme is not meeting a stakeholder's information need. Track ad hoc requests — a pattern of them from the same stakeholder indicates the formal reporting stream is insufficient.
Ad hoc communication is expensive: it interrupts the team, it is uncontrolled (information shared in an informal channel may not reflect the fully considered position), and it creates differential information — some stakeholders know more than others at any given moment.
On multi-jurisdiction matters, scheduling regular calls across multiple timezones is a genuine operational constraint. LPM's role is to design a cadence that works — not to expect all jurisdictions to join a call at their 3am.
Practical principles:
On large cross-border programmes, the most common failure mode is not a lack of information — it is information reaching the wrong level in the wrong form. Three patterns:
1. Bypass: Programme lead communicates directly to local teams without routing through regional coordinators. Local teams stop looking to regional coordinators for direction. Regional layer becomes redundant.
2. Bottleneck: Regional coordinators filter too aggressively. Programme lead receives clean summaries with all friction removed. Problems that would have triggered intervention are invisible until they become crises.
3. HQ vs regions conflict: Client HQ and regional client contacts each believe they are the primary instruction-giver. Local teams receive conflicting instructions. The law firm gets caught between them.
The reporting hierarchy design must name these risks explicitly and specify how to avoid them.
For matters with six or more jurisdictions:
Client (HQ / programme lead)
↕
Lead firm (Partner + LPM)
↕
Regional coordinators (one per region — typically 3-4 jurisdictions each)
↕
Jurisdiction teams (LC or internal)Information flows upward via structured updates; decisions and instructions flow downward via documented communications. The LPM sits at the Lead firm tier and manages both directions.
Regional coordinator role: Aggregates jurisdiction-level updates into a regional summary; filters operational detail; escalates exceptions; enforces reporting deadlines from jurisdiction teams; is the single point of contact for their jurisdictions. Not a messenger — a filter and escalator.
Escalation threshold: Define what must be escalated from jurisdiction to regional to programme level at matter setup. Default: any risk rated High or above, any missed milestone, any OOS work request, any client instruction that conflicts with the agreed scope or programme. Below this threshold, regional coordinators handle locally.
When client HQ and regional contacts both claim primary contact status:
This is a relationship conversation, not a process conversation. The LPM drafts the options and the consequences; the partner owns the conversation.
All outputs produced as .docx unless the user explicitly requests otherwise. Stakeholder registers and communication plans are matter records — they belong in the matter folder.
Structured data export — required, not optional: Every Mode 1 stakeholder register and Mode 2 communication plan output must include a CSV export. Produce it as a labelled inline section at the end of the document if a separate file cannot be attached. A stakeholder register that exists only in a Word document cannot be updated systematically. A CSV can feed into SharePoint tracking and be updated at each phase gate. Do not complete a Mode 1 or Mode 2 output without the CSV.
BLUF first. Every output leads with a summary: the most important thing the reader needs to know or act on.
Professional tone principle — client-facing outputs: All client-facing communication plan outputs and stakeholder-facing materials use professional, respectful language. Stakeholder mapping is an internal analytical tool — characterisations of individual stakeholders (sensitivities, influence level, interest level) are for internal use only and must never appear in client-facing documents.
Named-firm attribution rule: Never reference a named firm in skill output — in documents, tables, or conversational text. The rule applies to everything this skill produces.
Mode 1 — Stakeholder register column headers (use exactly):
| Name | Organisation | Role | Quadrant | Comms role | Preferred channel | Preferred frequency | Sensitivities / notes |
Mode 2 — Communication schedule column headers (use exactly):
| Forum | Frequency | Owner | Participants | Format | Purpose | Notes |
Mode 3 — Reporting hierarchy: Produce as a visual hierarchy diagram (ASCII or structured table) followed by a written description of each tier, escalation thresholds, and the HQ vs regions risk assessment.
LPM: Stakeholder identification and classification, communication plan design, reporting rhythm, reporting hierarchy architecture, cadence management, escalation path design, mid-matter comms updates.
Attorney: Whether a specific communication to a regulator, counterparty, or third party is legally required or constrained; privileged vs non-privileged communication decisions; what can be disclosed to which parties under applicable law or professional rules.
Do not advise on legal disclosure obligations, legal professional privilege, or what can be communicated to regulators or counterparties. Flag and route to the responsible attorney.
Hard rule on legislation and privilege: Do not name specific statutes, regulations, or statutory thresholds — in documents, tables, or conversational text. Do not characterise legal privilege positions. Both rules apply even when the legal knowledge feels directly relevant and helpful.
The most common violation points on employment and consultation matters:
The correct substitution in each case:
If a communication raises a legal compliance or privilege question, produce the flag and routing instruction. Do not characterise the legal position, even directionally.
Union communications copy requests — sequence rule: When a stakeholder requests to be added to union or counterparty communications, the flag comes before any implementation instruction. Never list "add [contact] to union distribution" as an action item in the same output that raises the attorney/partner review flag. The correct sequence: (1) flag the request as requiring partner and attorney review, (2) explain what needs to be confirmed (privilege, client intent, scope of "all comms"), (3) only after those questions are answered does implementation become an action. An output that flags the concern and simultaneously implements the request has not flagged the concern.
Connected mode invocation rule: Search connected systems when doing so adds value — not as a default first step when sufficient input is already in the prompt. If the user has described the stakeholder landscape, work with that description. If they reference existing matter documents or prior communications, search for them.
When the M365 MCP connector is enabled (Claude Team/Enterprise), this skill can:
Without the connector: describe the stakeholder landscape and any known communication patterns directly.
⚠️ Stakeholder positions change. A stakeholder classified as Low interest at matter setup may become High interest when a milestone is missed or a risk crystallises. Review the register at each phase gate — do not treat the initial classification as permanent.
⚠️ Client organisational structures change. Personnel changes, restructures, and role changes mid-matter are common. Mode 4 exists for this reason. Do not allow a stale stakeholder register to drive communication decisions after a material change.
⚠️ Cadence agreements are informal. A communication cadence agreed verbally at kickoff is forgotten within two weeks unless it is documented in the matter plan and calendared. The communication plan is not live until the recurring invites exist.
8f9093f
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.