Deadline Scope Tradeoff Brief

intent

when time is short and scope is fat, you need to make a ruthless, honest call on what ships, what gets cut, and what gets deferred. this skill creates a one-page decision brief that separates must-ship work from negotiable work, scores tradeoffs by value and risk, names the real dangers, and drafts a stakeholder message that doesn't hide the damage. use this when a deadline is fixed, scope is bloated, and you need to move fast without lying to the people who depend on you.

inputs

the skill needs these details to run. if you're missing some, flag assumptions clearly.

core project context:

• deadline date, time, and type (external, contractual, public, internal, self-imposed)
• original scope and list of planned deliverables
• work completed, in progress, and not started
• stakeholders affected (users, customers, managers, teams, executives)
• blockers, dependencies, external delays, or resource constraints

success and risk context:

• what decision, launch, promise, or customer need does this deadline serve
• minimum proof of value or readiness required to call it done
• non-negotiable outcomes (safety, compliance, trust, contractual obligations)
• quality bar and how you'll measure it
• contractual, legal, compliance, safety, or privacy constraints
• consequences of missing the deadline vs. reducing scope
• available people, time, and budget

no external connections required. this skill is prompt-only and does not call APIs, databases, or credential systems.

procedure

step 1: map the situation (input: all core context above; output: one-paragraph situation summary)

write down the deadline, stakeholders, current progress, and main constraint. be specific about whether the deadline is immovable or can flex. list blockers that affect remaining work.

output: situation summary in one paragraph.

---

step 2: clarify the real success outcome (input: the deadline, customer/user needs, contractual requirements; output: one or two must-ship outcomes)

ask yourself:

• what user, customer, manager, or audience need must be met for this effort to count as successful?
• what decision, launch, or proof point does the deadline actually support?
• what would make the delivery unacceptable even if it ships on time?

convert this into one or two explicit must-ship outcomes. these are your north star for cutting.

output: one or two must-ship outcomes, phrased as customer or business value (not feature lists).

---

step 3: sort scope into must, should, could, remove (input: original scope, must-ship outcomes; output: four buckets of work)

classify each scope item:

• must: required for the real success outcome, safety, trust, contractual obligations, or core function. cutting this breaks the deadline goal.
• should: valuable but can be reduced or deferred if needed. lower risk to defer.
• could: nice-to-have, polish, or edge cases. first candidates for cut.
• remove: low value, duplicate, no longer aligned with the deadline goal, or risky to ship half-baked.

if everything lands in must, challenge the classification. usually, 60-70% of scope is should or could.

output: four lists of scope items.

---

step 4: score items by value, risk, and reversibility (input: should and could items; output: scored table or annotated list)

for each important item, assign or describe:

• value: high, medium, low. how much does it move the needle on the must-ship outcome?
• risk if cut: high, medium, low. what breaks or disappoints customers if this doesn't ship?
• effort remaining: high, medium, low. time and people to finish.
• dependencies: none, internal, external, blocked. does it wait on someone else?
• reversibility: easy to add later or hard to recover. can you ship without it now and patch it in version 1.1?

use the scores to reveal which items are safe to cut, which should be simplified, and which must be protected.

output: annotated list or table with scores.

---

step 5: propose simplifications (input: should and could items, effort and risk scores; output: simplified versions of each item)

for each should or could item, sketch a simpler version that still delivers value:

• reduce scope (fewer users, narrower use case, manual before automation).
• use existing assets, templates, or standard options instead of custom work.
• ship a basic version by the deadline, plan a polish pass after.
• convert a known follow-up into a feature request instead of a blocker.

keep simplifications honest. don't pretend a cut feature is still there.

output: list of simplifications with effort estimates.

---

step 6: map tradeoffs and quality risks (input: cut and simplified items, stakeholder list; output: tradeoff table or risk register)

for each option (cut, defer, simplify), name:

• what improves by doing this (deadline hit, team capacity, risk reduction).
• what gets worse or delayed (feature parity, user experience, competitive position).
• quality, operational, trust, and user impact.
• mitigation steps (communication, workaround, follow-up timeline).
• what must be disclosed before launch.

do not hide risk to make the plan look better. escalate safety, compliance, security, and trust-critical risks immediately.

output: tradeoff table or risk register.

---

step 7: draft the stakeholder update (input: recommended scope change, risks, mitigations; output: one-paragraph message)

write a concise, truthful message:

• current status and why the deadline is at risk.
• recommended scope change and why.
• what will still be delivered on the deadline.
• what will be cut, deferred, or simplified.
• risks and how you'll mitigate them.
• decision or approval needed.
• next checkpoint.

tone should be accountable, calm, and specific. no hedging or blame.

output: draft message (100-150 words).

---

step 8: produce the recommended action plan (input: must-ship items, cuts, deferrals, simplifications; output: one-page brief with next steps)

assemble the brief in the format below. include owner and timing for each action.

output: one-page brief and immediate next steps.

decision points

if the deadline is flexible: negotiate a new date with stakeholders. return to step 1 and re-estimate. do not proceed with cuts unless the stakeholder actively rejects timeline extension.

if the deadline is contractual or legal: escalate scope tradeoffs to a responsible party (legal, compliance, account manager, executive). do not recommend cutting safety, security, privacy, or compliance work without explicit written sign-off and risk review.

if everything is marked must: challenge the classification with stakeholders or a senior person. usually, this is a sign that the deadline goal was not clearly defined in step 2. go back and clarify.

if cutting or simplifying will damage customer trust or product quality materially: escalate to a decision-maker. flag the risk explicitly in the stakeholder message. do not ship without acknowledgment.

if a critical external dependency is blocked or delayed: shorten your deadline estimate to account for the delay. consider cutting work that depends on it until the blocker clears.

if you discover new scope or work in progress: re-sort and re-score. do not assume it fits in remaining time. assume scope will grow and build in a 10-15% buffer for unknowns.

if stakeholders reject the recommended plan: document their alternative and the risks they are accepting. do not proceed with a plan you believe is unsafe or dishonest.

output contract

deliver a one-page brief in markdown or plain text with this structure:

# Deadline Scope Tradeoff Brief

## 1. Situation
- Deadline: [date, time, type]
- Stakeholders: [list]
- Current progress: [work complete, in progress, not started]
- Constraint summary: [blockers, dependencies, risk]

## 2. Real Success Outcome
- Must-ship outcome 1: [customer or business value]
- Must-ship outcome 2: [customer or business value, if applicable]

## 3. Scope Sort
- Must: [list]
- Should: [list]
- Could: [list]
- Remove: [list]

## 4. Tradeoff Options
| Option | What changes | Value protected | Risk introduced | Mitigation |
|---|---|---|---|---|
| Cut [item] | [impact] | [what stays safe] | [quality, user, business risk] | [how to limit damage] |
| Simplify [item] | [reduced scope] | [core value] | [risk if basic version ships] | [workaround, follow-up plan] |
| Defer [item] | [moved to v1.1] | [deadline hit] | [competitive risk, user disappointment] | [communication plan, post-launch date] |

## 5. Recommended Plan
- Ship: [protected, must-ship items]
- Cut: [low-value, high-risk items]
- Defer: [valuable items moved to a defined later date]
- Simplify: [reduced scope for should/could items]
- Quality safeguards: [testing, review, customer communication]

## 6. Stakeholder Message
[Draft message, 100-150 words]

## 7. Immediate Action Plan
- Next 24 hours: [first moves, communication, blocking issues to resolve]
- Next checkpoint: [review date, decision gate, go/no-go decision]
- Decision needed: [from whom, what decision, by when]

if tables don't fit your format, use bullet lists instead. the brief must fit on one page or be scannable in under 3 minutes.

outcome signal

you know the skill worked when:

1. you have a deadline, stakeholder list, progress snapshot, and one-sentence constraint summary.
2. the real success outcome is clearly separate from the original scope.
3. scope is sorted into four buckets (must, should, could, remove) and you can defend each classification.
4. tradeoffs are scored by value, risk, effort, and reversibility, and the scoring reveals what's safe to cut.
5. simplifications are concrete and honest (you can describe what each one loses).
6. quality risks are named explicitly, with mitigations listed, and safety/compliance/trust risks are escalated.
7. the stakeholder message is brief, truthful, and includes what will still ship and what won't.
8. the one-page brief is complete and you can hand it to a decision-maker to say yes or no to the plan.
9. you have a next-checkpoint date and a clear owner for each action.

if stakeholders ask "what are we cutting and why" or "what will we ship by the deadline", you should be able to answer in one minute using the brief.

---

original author: OpenClaw Skill Library. enriched to implexa quality standards.