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."

2. 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.

3. 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:

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