legalopsconsulting/lpm-skills/scope-change-controller

Scope Change Controller

Purpose

Manage scope across the lifecycle of a legal matter. Scope is the baseline that everything else references — status is progress against scope, risk is threat to scope delivery, budget is the price of scope. When scope is unmanaged, every other discipline is working against an unreliable target and the client gets surprised.

The fundamental problem: legal teams consistently fail to manage scope because it feels adversarial, it's perceived as the partner's job, and nobody established a simple mechanism for managing change at matter setup. The result is budget overruns, write-off conversations that could have been managed change conversations, and clients who conclude that external counsel never sticks to their budget.

Good scope management is a service to the client, not a confrontation. The client would rather have a managed conversation about additional costs mid-matter than a surprise invoice at the end. Framing scope change as professional and unemotional — an opportunity for both parties to deliver their sides of the bargain — is as important as the mechanics.

Core design philosophy: automate capture, surface for confirmation

LPMs and attorneys know that recording scope changes is valuable. They won't consistently do it because the capture overhead exceeds the perceived value at the moment it needs to happen. "Another job to do" and "reporting" are the common dismissals — missing the big unlock, which is that contemporaneous data enables learnings which enable iterative improvement. But only if we make capture as close to zero-effort as possible.

The principle across this skill: don't ask the human to create the record — create the record and ask the human to confirm it. In manual mode, this means the skill produces the draft OOS entry, the draft communication, and the draft scope register update from the input provided. In connected mode, this means Claude detects the scope signal, drafts the entry with source evidence auto-linked, and surfaces it for confirmation. The difference between "log this" (15 minutes, doesn't happen) and "I've found this — confirm or dismiss?" (30 seconds, happens).

Two layers — scale to the matter

Scope management must be proportionate. An overengineered process that nobody maintains is worse than a simple one that gets followed.

Standard (every matter)

Three deliverables, each lightweight enough that a tired LPM at 7pm on a Thursday will actually do them:

1. One-page scope summary — the 3-5 key assumptions from the engagement letter, stated plainly, with the quantifiable parameter for each. Produced at matter setup. Takes 15 minutes. Shared with the delivery team with one instruction: "If anything changes from these, tell me."

1. Simple OOS list — when something comes up that's outside scope, log it: what it is, when it was identified, whether it's been raised with the client, and the outcome. One line per item. Could be a table in an email, a few rows in a spreadsheet, or a note on the matter file.

1. Client communication draft — when an OOS item needs raising with the client, the skill drafts the email for the partner. This is where the skill adds the most value — the LPM doesn't have to draft the awkward conversation from scratch.

The Sibelius €1.6m OOS recovery happened with basic tools and discipline. Spot it, flag it, track it, invoice it.

Extended (large or complex matters)

Use when the matter economics justify the investment: £1m+ fees, 12+ month timeline, multiple jurisdictions, fixed or capped fee basis where scope sensitivity is high. The potential OOS recovery needs to exceed the overhead of maintaining the system.

Extended adds:

1. Full scope register — 10-15 items with structured fields. Maintained in an Excel workbook.

1. Fortnightly scope pulse check — a short, specific message to the delivery team referencing 3-4 highest-risk assumptions by name.

1. Scope retrospective — at matter close, analyse the delta between original and actual scope.

1. OOS call agenda — a structured document the partner walks into a client scope call with.

The trigger for Extended isn't ambition — it's matter economics. If the cap is £1.2m and potential OOS recovery is £100k+, the workbook pays for itself. If the cap is £50k on a 3-month matter, Standard is all you need.

Step-by-step process

Step 1: Determine what's needed

How this skill gets invoked in practice:

Scope management fails when it's positioned as a standalone activity. In reality, it works when it's embedded in workflows the LPM is already doing:

• At matter setup: Baseline capture as part of the matter setup process. The one planned, deliberate invocation.
• During email batch review: "Here are this week's emails on Redwood — flag any scope issues." LPMs already batch-process email for status reporting. Adding scope review to the same pass is low friction.
• Before drafting the status report: "Before I draft the status report, run the scope check on these emails." Makes scope review a precursor to an activity that's already happening.
• Before billing: "We're about to bill on Atlas. Are there any OOS items to raise first?" The billing cycle is a natural trigger point.
• When another skill flags it: The status-report-drafter or risk-and-issues-manager surfaces a scope signal. The LPM follows the handoff.
• When the partner asks: "Help me justify this overrun." Retrospective mode — always reactive, but still valuable.

In connected mode, the invocation model reverses: Claude monitors matter emails against the scope register and surfaces signals for the LPM to confirm or dismiss. The LPM doesn't invoke the skill — the skill invokes the LPM.

Common triggers:

• "Here's the engagement letter — what are the scoping assumptions?" → Scope summary (Standard) or full register (Extended)
• "Is this in scope?" / "The client wants us to also handle X" → Scope assessment
• "We've blown the budget — trace it back to the scope" → Retrospective assessment
• "Run an OOS report for the client call" → OOS call agenda (Extended)
• "The matter is closing — what changed?" → Scope retrospective (Extended)

If the user hasn't indicated the matter size, ask: "Is this a matter where a simple scope summary will do, or is it large enough to warrant the full scope register?"

Step 2: Establish the baseline

Every scope assessment needs a baseline. Ask:

• "Do you have the engagement letter, scoping email, or fee proposal?"
• "What were the key scoping assumptions in the quote?"

If no baseline document exists, flag it: "Without a documented scope baseline, it's hard to assess what's in or out. Recommend establishing one — even a short email confirming the key assumptions."

Step 3: Extract the scope baseline

Read the engagement document. Extract:

• Quantifiable parameters: Entity counts, document counts, jurisdiction lists, witness numbers, employee headcounts, lease counts. Most likely to break, easiest to track.
• Scope inclusions: What the engagement explicitly covers.
• Scope exclusions: What it explicitly does not cover. These define where OOS starts.
• Implicit boundaries: Things not mentioned that could be assumed either way. Ambiguity is a scope risk.
• Fee basis: Fixed, capped, hourly, blended, staged. Affects how scope changes are handled commercially.
• Conditions and caveats: "Based on information provided to date" / "subject to no material change" — scoping assumptions in disguise.

Standard: extract 3-5 items. Extended: extract 10-15 items. Each should be something the team would genuinely need to revisit the price on if it changed. Not an exhaustive hedge list — a focused set of material assumptions.

Surfacing historical scope knowledge at point of capture

When creating scope assumptions for a new matter, the skill should prompt for historical context: "Have you run similar matters before? Which scope assumptions typically don't hold on this type of work?"

This is the learning loop that connects Mode 4 (retrospective) back to Mode 1 (baseline capture). Without it, retrospective lessons sit in a document and the same assumptions breach in the same ways on the next matter.

In manual mode: Ask the question. The LPM knows from experience that entity counts always grow, that data rooms are always late, that employee headcounts miss contractors. Making the question routine surfaces tacit knowledge that would otherwise stay in the LPM's head.

With a pattern library (Extended): Maintain a simple reference document — "Common scope assumption breaches by matter type" — built from past retrospectives and the LPM's experience. When the skill identifies the matter type during baseline capture, it checks the library and surfaces relevant warnings:

"This is an acquisition matter. On similar matters, the following assumptions have historically been breached: entity count (average +25% vs scoped), data room readiness (average 2 weeks late), employee headcount (contractors frequently excluded from initial figures). Consider building buffers or unit-rate mechanisms for these parameters."

The pattern library doesn't need to be sophisticated — a markdown file with 3-5 common breaches per matter type is enough. It grows each time a scope retrospective is completed.

In connected mode: Claude searches SharePoint for scope retrospectives from similar matter types, extracts breach patterns, and surfaces them automatically during baseline capture. The historical data does the prompting rather than the LPM's memory.

This is the recursive improvement loop: matters produce retrospectives, retrospectives produce patterns, patterns inform the next matter's assumptions, better assumptions produce fewer breaches. Each cycle makes the scoping more accurate.

The balance between protection and credibility matters. Too many exclusions signal low confidence or intent to upsell. The test: would the LPM be comfortable explaining every scope assumption to the client at the outset? If not, it's too aggressive.

Be aware of the "buying work" pattern. Pricing aggressively low, scoping aggressively tight, then enforcing OOS on every deviation. This skill is not designed to enable that. Legitimate scope management protects both sides. If the scope register reads like a trap, it's being used wrong.

Step 4: Assess scope changes (in-flight)

When new work or a request arises, assess against the baseline:

1. Explicitly in scope? No action needed.
2. Explicitly excluded? Clear OOS. Document and raise.
3. Reasonable extension of agreed scope? Grey area. The question to surface for the partner: would a reasonable client expect this included in the price? The LPM presents the evidence — what the engagement says, what the request involves, how closely related it is to the agreed work. The partner answers the question based on their knowledge of the client. The LPM does not make this call definitively.
4. New work not contemplated? Clear OOS.
5. Same scope, more volume? Scope assumption breach. Commercial response may differ — unit-rate adjustment rather than new scope notice.

Materiality test: Would this change the fee estimate if the client asked? One extra call is variation. 15 additional entities is material. The LPM makes this judgment based on fee basis and matter economics.

Two patterns:

Proactive (the goal): divergence identified before or during the work. Client hears about it as a managed change.

Retrospective (reality): budget blown, need to trace back to root cause. Which assumptions were breached, what additional work resulted, can it be quantified? The output is an evidence trail — factual enough for a client fee conversation or an internal write-off discussion.

Step 5: Produce the output