legalopsconsulting/lpm-skills/risk-and-issues-manager

Risk and Issues Manager

Purpose

Maintain a structured RAID log (Risks, Assumptions, Issues, Decisions) for legal matters and extract structured data from unstructured correspondence. This skill operates in two modes: RAID log maintenance (creating, updating, and managing the log) and decision extraction (identifying decisions, risks, assumptions, and scope-relevant information buried in email chains and meeting notes).

The decision extraction mode is the highest-value function. Decisions get made in email constantly — "let's leave Germany out for now," "we'll use the existing holdco," "client says they don't need a valuation" — and they're never formally recorded. Six months later when scope is disputed, budget is blown, or a workstream is stuck, nobody can find the email where the decision was made. This skill catches those decisions at the point they're made and logs them with the metadata needed to make them useful later.

Operating modes

Mode 1: RAID log maintenance

Create, update, and manage the four components of the RAID log. This is the ongoing discipline — the log is a living document that's reviewed regularly and updated as the matter progresses.

Mode 2: Decision extraction from correspondence

The user pastes an email chain, meeting notes, or call notes. The skill scans for:

• Decisions — explicit or implicit choices that affect the matter's direction, scope, budget, or timeline
• Risks — newly identified uncertain events that could affect objectives
• Assumptions — premises being relied upon that may not hold, particularly inherited assumptions from DD or prior phases
• Issues — problems that have materialised and need resolution
• Scope signals — language that suggests work is moving in or out of scope, even if not explicitly framed as a scope decision

Output: structured entries ready to add to the RAID log, with flags for items that need follow-up or escalation.

Mode 3: Risk identification from context

The user describes a matter setup, and the skill identifies the key operational risks based on the matter type, jurisdictions, team structure, timeline, and commercial arrangements. This is proactive risk identification — catching risks at matter setup rather than discovering them mid-execution.

Step-by-step process

Step 1: Determine the mode

Ask the user what they need. Common triggers:

• "Here's an email chain — what decisions were made?" → Mode 2 (decision extraction)
• "Set up a RAID log for this matter" → Mode 1 (create)
• "Update the RAID log with this" → Mode 1 (update) — ask whether they have an existing log to upload
• "What are the risks on this matter?" → Mode 3 (risk identification)
• "This risk has happened" → Mode 1 (escalation: risk → issue)

If the user just pastes an email chain without specifying, default to Mode 2 (decision extraction) — this is the most common use case and the highest-value function.

Step 2: Process the input

For Mode 1 (RAID log maintenance):

Confirm the matter name and whether an existing RAID log is available to update. If the user uploads an Excel RAID log, read it and use the existing structure, numbering, and categories. If creating from scratch, use the standard structure defined below.

For Mode 2 (decision extraction):

Read the entire email chain or notes carefully. Don't skim — decisions are buried in mid-chain replies, throwaway sentences, and implicit agreements. Look for:

Explicit decisions: Direct statements of choice. "We've decided to..." / "Let's go with..." / "Client has confirmed..." / "Agreed — we'll proceed on that basis."

Implicit decisions: Choices made by omission or assumption — but only where someone with authority has genuinely chosen between alternatives. "I'll leave Germany out of the next round" (scope decision — someone chose to exclude Germany). "We don't need to worry about the valuation" (scope reduction — someone chose not to pursue it). These are dangerous because the decision-maker may not realise they've made a decision. Log with status "Implied" and flag for confirmation. Important: don't confuse routine activity with implicit decisions. Someone doing something (chasing by email, starting a review) is not a decision unless they explicitly chose that approach over alternatives.

Conditional decisions: "If the regulator comes back clean, we'll proceed with Option A." Log these as decisions with conditions noted — they need monitoring.

Reversed or contradicted decisions: Earlier in the chain someone decided X, then later someone decided not-X. Both should be logged — the reversal is itself a decision, and the history matters for scope and accountability.

Scope signals: Any language that suggests work expanding or contracting. "Can you also look at..." (scope expansion). "We don't need that anymore" (scope reduction). "That wasn't in the original brief" (scope awareness). "While you're at it..." (scope creep). These may not be formal decisions but they need to be captured and flagged for the scope-change-controller skill.

Risk signals: Language suggesting uncertainty or concern. "I'm worried about..." / "What happens if..." / "The regulator might..." / "We're running out of time on..." Also watch for absence — if a critical topic isn't mentioned when it should be, that's a risk signal.

Assumption signals: Statements that take something for granted or rely on an untested premise. "The DD confirmed the entity structure is clean" (assumption — was this actually verified?). "We should have the client's approval by next week" (assumption about client decision-making speed). "The local team can handle this within the existing budget" (assumption about cost). "The regulatory process should take about 4 weeks" (assumption about timeline). Also watch for inherited assumptions — things the team is relying on from the DD, the pitch, or a prior phase that haven't been re-validated. These are the assumptions most likely to fail because nobody is actively monitoring them.

For Mode 3 (risk identification):

Gather the matter context: type of matter, jurisdictions involved, team structure, timeline, budget basis (fixed fee, capped, hourly), client relationship, and any known constraints. Then apply the risk identification framework below.

Step 3: Produce the output

Lead with the summary. The first thing in the output should be the "Items Requiring Immediate Action" section — the 30-second version for the partner who won't read further. This is the management-by-exception headline: what's on fire, what needs a decision, what are we relying on that might not hold.

Then provide the full IRAD detail (Issues, Risks, Assumptions, Decisions) for the reader who wants the complete picture. The summary tells them what to care about; the detail tells them why.

Output structure:

1. Items requiring immediate action — prioritised summary with log IDs (Issues/Critical risks first, failed assumptions second, Implied/Pending decisions third, decisions needed fourth)
2. IRAD counters — open item counts per category with [NEW]/[UPDATED] indicators. No overall rating.
3. Risk heatmap (optional — include when format supports it easily, e.g. Excel)
4. Scope signals — anything that may change the agreed scope, flagged for scope-change-controller
5. Full IRAD log entries — Issues, Risks, Assumptions, Decisions in that order, each with the field structures below

IRAD counters

Place the counters once, immediately after the BLUF summary and before the full log detail. Do not repeat them in headers, subheadings, or elsewhere — one instance only.

A single summary line or small table showing the count of open items per category, with new and updated items highlighted. Example:

This immediately tells the reader whether the log is growing, shrinking, or stable — and where the activity is concentrated this period.

Do not produce an "overall risk rating" or "overall exposure" score. A single rating (e.g. "HIGH") is meaningless — it collapses a complex picture into a label that invites debate about the label rather than the items underneath it. The counters are the summary. They tell the reader the scale and shape of what they're dealing with. If there are 3 Critical items, the reader can see that from the counters and the BLUF — they don't need a single word to tell them the programme is in trouble.

Risk heatmap (9-box) — optional, include when format supports it easily. The standard probability × impact grid with risk IDs plotted in each cell. Colour the cells: red (top-right), amber (diagonal), green (bottom-left).

The heatmap shows clustering at a glance. If the top-right cell is crowded, the conversation is fundamentally different from when risks are spread across the grid. Update the heatmap each period — movement of risk IDs between cells over time is itself a useful signal.

Assumptions can use the same 9-box with Confidence (High/Medium/Low) on one axis and Impact if Wrong (Low/Medium/High) on the other. Low confidence + High impact assumptions are the equivalent of the top-right cell — actively monitor and validate these first. Include when the heatmap is being produced; omit when counters alone are sufficient.

In docx: Produce the heatmap as a formatted table with cell shading (red/amber/green) and risk IDs as text within cells. The counters sit as a simple one-row table between the summary and the detail.

In Excel: Use conditional formatting for heatmap colours. The counters can be COUNTIF formulas on the active log tabs, updating automatically as entries change status.

RAID log entries should follow the IRAD presentation priority (Issues, Risks, Assumptions, Decisions) — but use the structures below for each component regardless of presentation order:

Issues

Use colour coding on the Severity field to draw the eye: Critical (red), High (amber/orange), Medium (yellow), Low (green). The same colour scheme applies to Risk Exposure below.

Risks