scope_management v1.0.0

name: "scope_management" description: "Hold project scope against creep: write a scope statement, run lightweight change control, say no cleanly without burning the relationship, and protect the critical path. Triggers when a task keeps growing mid-flight, the user asks for extras, feedback turns into endless revisions, or a team needs a defensible yes/no process."

Scope Management

Purpose

Keep a piece of work inside the bounds it was agreed on. Most scope creep is not a bad request, it is an unevaluated one. This skill gives you a written scope statement, a change request process, honest scripts for saying no, and a decision log so past calls stay made.

Workflow

1. Write the scope statement first

Before execution starts, pin the scope in writing (template in references/change-request-template.md). Include: deliverables stated concretely ("3 homepage concepts, 2 revision rounds"), what is explicitly out of scope, constraints, assumptions, and success criteria. Chris Do's rule from 30 years of client work: the SOW is what saves you; vague agreements are where every sideways project starts.

2. Never answer a scope request on the spot

When someone asks for an extra mid-flight, buy time. "I'll assess it and get back to you by [when]." A delay gives you room to evaluate and gives them room to reflect on whether they want to go to bat for it. (HBR's guidance on refusing requests while preserving relationships.)

3. Ask the five questions

1. What specifically would you like added or changed?
2. What's motivating the request right now?
3. What are you hoping to achieve with it?
4. On a scale of 1-10, how critical is this to the goal?
5. If we need tradeoffs to fit it in, what would you give up?

Then repeat back your understanding and ask if you got it right.

4. Classify the request

• In scope: it was in the statement. Do it.
• Dependency: the agreed goal fails without it. Admit it, add it, re-baseline. Use the defining question: "Does the original scope deliver its stated goal without this item? If yes, it is an addition. If no, it is a dependency."
• Addition: log it as a change request and run the impact assessment. If the requester will not state the benefit the change is supposed to deliver, it does not go forward.
• Duplicate: already decided before. Point at the decision log entry and move on.

5. Run the impact assessment

For every change request, fill in: impact on scope (S), time (T), cost/effort (C), and whether it touches a critical-path task. Present the impact flat, without editorializing: "This would add 3 days and push the launch to Friday." Then offer the three options: accept it and move the date, defer it to Phase 2 or the backlog, or swap it in by cutting something specific. Have the stakeholder see and acknowledge the impact before any decision; most "quick additions" evaporate once the real price is visible.

6. Deliver the verdict with a script

Pick the script from references/saying-no-scripts.md that fits. The pattern is always: no flat nos without an alternative. "Yes, and here is the cost" or "Not now, but here is when" or "Not this, instead of that." Flat refusals are reserved for requests that violate the statement's success criteria, and even those get an explanation.

7. Log it and update the baseline

Every request, verdict, and tradeoff goes in the decision log. Approved changes update the scope statement and baseline so the plan reflects reality. The log is the audit trail when someone later claims a feature "was always in scope," and it closes the loop when the same request comes back months later.

Output Contract

• Scope statement: written, with in-scope / out-of-scope / assumptions / success criteria.
• Change request assessment: the request, the five answers, classification, S/T/C impact, critical-path check, and the chosen option.
• Decision log entry: date, requester, request, verdict, tradeoff made, baseline updated or not.

Operating Rules

1. No work starts on an addition before the impact assessment exists. Assessment first, execution second.
2. A refusal that was not preceded by assessment is a "bad no" (Tulgan): assess the ask on its merits, never on dislike of the asker or on exhausted capacity.
3. Out-of-scope list is as important as the in-scope list. Name what you will not do.
4. In agile contexts, scope evolves through the backlog, not scope battles: additions get prioritized, deferred, or sequenced, and Phase 2 is the honorable default home for extras.
5. Guard the critical path explicitly: changes that touch critical-path tasks need re-sequencing and a new baseline before they start, not after.
6. Batch feedback instead of reacting to each piece. Collect everything, resolve conflicting notes together, separate must-haves from nice-to-haves, then present one unified revision set ("This constitutes revision round 2 of 3").
7. Warn before the crisis, not during it: flag when the next change costs extra before the request arrives.