managing-timelines

Original source / Raw SKILL.md

---
name: "managing-timelines"
description: "Turn a deadline, launch date, or delivery target into an executable Timeline Management Pack (deadline type + commitments, phase plan, milestone tracker, RAG cadence, scope/change control, stakeholder comms). Use for timeline/deadline/schedule/milestones."
---

# Managing Timelines

## Scope

**Covers**
- Turning a deadline or target date into a clear **commitment model** (commit vs forecast vs target)
- Building a phase-based plan (Discovery → Solutioning → Build → Launch) with **decision gates**
- Creating a milestone tracker with simple **RAG** (red/amber/green) status and escalation triggers
- Protecting the team when a deadline is real (treat it like **P0**, reduce distractions, control scope)
- Setting a governance + comms cadence so stakeholders get **early risk signals**, not surprises
- Handling “fast demo, slow production” cadence (especially for AI/ML features) via explicit outer-loop work

**When to use**
- “We need to ship by <date>. Create a timeline/milestone plan and status cadence.”
- “We have a launch date; convert this into phases, milestones, and a comms plan.”
- “Stakeholders keep asking for dates; define what we can actually commit to and when.”
- “The project feels off-track; set up RAG status + weekly exec review and escalation.”
- “We can demo quickly, but production will take longer—help set expectations and plan the outer loop.”

**When NOT to use**
- You haven’t defined the problem/outcome yet (use `problem-definition`)
- You need to pick which initiatives matter most (use `prioritizing-roadmap`)
- You primarily need to cut scope to fit an appetite/timebox (use `scoping-cutting`)
- You need a decision-ready PRD or build-ready spec/design doc (use `writing-prds` / `writing-specs-designs`)

## Inputs

**Minimum required**
- The deliverable and success bar (“done means…”) + key users/stakeholders
- The date type: **fixed deadline** (external) vs **target** (internal) vs **window** (e.g., “late March”)
- Constraints and non-negotiables (quality, compliance, privacy/security, platform, budget)
- Team shape + capacity assumptions (who’s building; availability; parallel work)
- Known dependencies and risks (other teams, vendors, data availability, approvals)

**Missing-info strategy**
- Ask up to 5 questions from [references/INTAKE.md](references/INTAKE.md).
- If answers aren’t available, proceed with explicit assumptions and list **Open questions** that could change the date or scope.

## Outputs (deliverables)

Produce a **Timeline Management Pack** in Markdown (in-chat; or as files if the user requests):

1) **Deadline & commitment model** (what’s fixed, what’s variable; commit vs forecast vs target language)
2) **Phase plan** (Discovery/Solutioning/Build/Launch) with outputs + decision gates + next commitment date
3) **Milestone tracker** (owners, dependencies, dates, confidence, RAG) + RAG definitions
4) **Governance cadence** (weekly review agenda, escalation triggers, decision log)
5) **Scope & change-control plan** (cut list, non-goals, “trade don’t add” rule, freeze points)
6) **Stakeholder comms pack** (weekly update template + escalation note)
7) **Risks / Open questions / Next steps** (always included)

Templates: [references/TEMPLATES.md](references/TEMPLATES.md)  
Expanded guidance: [references/WORKFLOW.md](references/WORKFLOW.md)

## Workflow (8 steps)

### 1) Intake + deadline classification
- **Inputs:** User request; [references/INTAKE.md](references/INTAKE.md).
- **Actions:** Identify the deadline type (fixed vs target vs window), the “why now”, and what variable can move (scope, resources, quality, or date).
- **Outputs:** Deadline classification + constraints snapshot.
- **Checks:** You can state: “The date is <fixed/target/window> because <reason>. The variable we will trade is <scope/resources/etc>.”

### 2) Define the commitment model (“commit vs forecast vs target”)
- **Inputs:** Deadline classification; current knowledge of scope/unknowns.
- **Actions:** Define what you will **commit** to now (usually a phase output), what you will **forecast**, and what remains a **target**. Set confidence levels and language rules for stakeholders.
- **Outputs:** Commitment model section + communication rules.
- **Checks:** Stakeholders can tell which dates are promises vs estimates.

### 3) Build a phase plan with decision gates
- **Inputs:** Deliverable; known unknowns; constraints.
- **Actions:** Break the work into Discovery → Solutioning → Build → Launch. Define the output of each phase and the decision gate (what must be true to move forward). Only commit to dates that are within control (near-term).
- **Outputs:** Phase plan with dates, outputs, and gates; “next commitment date” (when you’ll re-forecast).
- **Checks:** Every phase ends with a tangible artifact and a go/no-go decision.

### 4) Create the milestone tracker (+ “demo vs production” outer loop when relevant)
- **Inputs:** Phase plan; dependencies; team capacity.
- **Actions:** Translate phases into milestones with owners, dependencies, dates, confidence, and RAG. If AI/ML is involved, separate “first demo” from “production-ready” and explicitly add evaluation, data, safety, and reliability work.
- **Outputs:** Milestone tracker table + RAG definitions.
- **Checks:** Milestones are outcome-based (deliverables), not just activities; critical dependencies are explicit.

### 5) Set governance: RAG + weekly reviews + escalation
- **Inputs:** Milestone tracker; stakeholder map.
- **Actions:** Define update cadence (weekly by default), who reviews, and escalation triggers (what turns yellow/red). Use a simple RAG system and a short weekly review agenda to unblock work.
- **Outputs:** Governance cadence + weekly review agenda + escalation triggers.
- **Checks:** A “red” status produces a concrete ask/decision, not just a warning.

### 6) Protect the deadline: scope control + distraction shield
- **Inputs:** Deadline type; milestone risks; incoming requests.
- **Actions:** If the deadline is real, treat it like P0: define what gets deprioritized, reduce WIP, and implement change control (“trade, don’t add”). Create a cut list and freeze points (e.g., scope freeze, QA freeze).
- **Outputs:** Scope/change-control plan + cut list + freeze points.
- **Checks:** New scope cannot enter without an explicit trade-off and decision owner approval.

### 7) Stakeholder comms + expectation management
- **Inputs:** Commitment model; tracker; risks.
- **Actions:** Write a weekly update template and an escalation note. Pre-wire stakeholders about uncertainty (especially the demo→production gap). Ensure comms use correct language (commit/forecast/target) and highlight asks/decisions.
- **Outputs:** Comms pack (templates + initial draft update).
- **Checks:** Updates include “what changed since last week” and “what decision is needed by when”.

### 8) Quality gate + finalize
- **Inputs:** Full draft pack.
- **Actions:** Run [references/CHECKLISTS.md](references/CHECKLISTS.md) and score with [references/RUBRIC.md](references/RUBRIC.md). Ensure **Risks / Open questions / Next steps** exist with owners and dates.
- **Outputs:** Final Timeline Management Pack.
- **Checks:** A stakeholder can approve the plan async and the team can execute without re-litigating dates every week.

## Quality gate (required)
- Use [references/CHECKLISTS.md](references/CHECKLISTS.md) and [references/RUBRIC.md](references/RUBRIC.md).
- Always include: **Risks**, **Open questions**, **Next steps**.

## Examples

**Example 1 (fixed external date):** “We’re launching at an industry event on May 15. Create a milestone plan, RAG cadence, and a comms template for Sales/Marketing/Execs.”  
Expected: a fixed-deadline plan that treats the date as P0, with change control and clear escalation triggers.

**Example 2 (AI uneven cadence):** “We can demo an AI support agent in 2 weeks, but production will be risky. Build a plan that separates first demo vs production-ready and sets expectations.”  
Expected: milestones that include evaluation, safety/reliability, and rollout steps; explicit commit vs forecast language.

**Boundary example:** “Decide what we should build this quarter and set dates for everything.”  
Response: use `prioritizing-roadmap` first; then apply this skill to the chosen initiative(s).



---

## Referenced Files

> The following files are referenced in this skill and included for context.

### references/INTAKE.md

```markdown
# Intake (Managing Timelines)

Ask **up to 5 questions at a time**. Prefer questions that would change the date, scope, or resourcing decision.

## Quick-start (pick the most important 5)

1) **What is the date type?**
   - Fixed external deadline (event/regulatory/contract)?
   - Internal target date?
   - Window (“late March”)?
   - Who is the decision owner for changing the date or scope?

2) **What are we shipping (minimum)?**
   - “Done means…” in 1–3 bullets
   - Explicit non-goals (what is out)

3) **What constraints are non-negotiable?**
   - Quality/reliability bar, compliance/privacy/security, platform constraints
   - “Must not worsen” guardrails (e.g., latency, support load, cost)

4) **Who is the team and what is capacity?**
   - Roles (Eng/Design/DS/PMM), availability, competing priorities
   - Any planned PTO / freezes

5) **What dependencies or approvals could block us?**
   - Other teams, vendors, data access, legal/security review, launch approvals

## Deeper clarifiers (ask only if needed)

### Scope & uncertainty
- What are the biggest unknowns right now (top 3)?
- What is already decided vs still open (requirements, UX, tech approach)?

### Stakeholders & comms
- Who needs weekly updates? Who needs immediate escalation on “red”?
- What format works best (Slack/email/doc)? Any standing forums?

### Risk tolerance & trade-offs
- If we slip, what is the least-bad trade: cut scope, add resources, reduce quality, move date?
- What’s the fastest acceptable rollback/mitigation if something goes wrong at launch?

### AI/ML-specific (only if applicable)
- Is this a prototype/demo, or production user-facing?
- What is the evaluation plan (quality metrics, red-teaming, safety constraints)?
- Data availability and privacy constraints (PII, retention, vendor usage)?
- What are the “outer loop” requirements: monitoring, fallback behavior, cost/latency budgets?

## Default assumptions (if the user can’t answer)
- Treat the date as a **target**, not a commitment, until solutioning is complete.
- Commit only to the **next phase output** and a “next re-forecast date”.
- Use weekly RAG updates with explicit asks/decisions when yellow/red.


```

### references/TEMPLATES.md

```markdown
# Templates (Managing Timelines)

Copy/paste these templates to produce a Timeline Management Pack.

## 1) Timeline Management Pack (full outline)

```md
# Timeline Management Pack — <project / initiative>

## 1) Deadline & commitment model
- Date type: (fixed external / fixed internal / target / window)
- Why now:
- Decision owner (date/scope trade-offs):
- Commitment ladder:
  - Commitment (what we will deliver) + date:
  - Forecast (best estimate) + date:
  - Target (directional) + date:
- Confidence: (H/M/L) + top 3 risks:
- What is variable (scope/resources/quality/date):

## 2) Phase plan (with decision gates)
| Phase | Start | End | Output(s) | Decision gate (what must be true to proceed) | Date type (commit/forecast/target) |
|---|---:|---:|---|---|---|
| Discovery |  |  |  |  |  |
| Solutioning |  |  |  |  |  |
| Build |  |  |  |  |  |
| Launch |  |  |  |  |  |

Next commitment date (re-forecast checkpoint):

## 3) Milestone tracker + RAG
RAG definitions:
- Green:
- Yellow:
- Red:

| Milestone | Deliverable | Owner | Target date | Confidence (H/M/L) | RAG | Dependencies | Notes / next decision |
|---|---|---|---:|---|---|---|---|
|  |  |  |  |  |  |  |  |

## 4) Governance cadence
- Update cadence: (weekly default)
- Forum(s): (weekly review, standup, async doc)
- Weekly review agenda:
  1) RAG review (yellow/red)
  2) Decisions needed (by when)
  3) Scope changes + trades
  4) Next week plan
- Escalation triggers (what makes something yellow/red):
- Decision log link/location:

## 5) Scope & change-control plan
- Non-goals (explicitly out):
- Cut list (pre-approved trade-offs):
  - Cut first:
  - Cut next:
  - Never cut (non-negotiables):
- Freeze points:
  - Scope freeze:
  - Code freeze:
  - QA / launch readiness freeze:
- Change control rule (“trade, don’t add”):
  - Decision owner:
  - Evaluation criteria:
  - What gets traded off first:

## 6) Stakeholder comms pack
Weekly update template:
- Status (RAG):
- What changed since last update:
- This week’s progress:
- Next week’s plan:
- Risks (top 3):
- Decisions needed (owner + deadline):
- Scope changes (what we traded):

Escalation note template (when red):
- What is red and why:
- Impact if unchanged:
- Options:
  1) Cut scope:
  2) Add resources:
  3) Move date:
  4) Reduce quality (if allowed):
- Recommended option + decision needed by:

## 7) Risks / Open questions / Next steps
**Risks:**
- ...

**Open questions:**
- ...

**Next steps (owners + dates):**
- ...
```

## 2) Commitment language snippets (copy/paste)

```md
### Date language
- Commitment: “We will deliver <X> by <D> provided <assumptions>. If <risk> happens, we will <trade-off>.”
- Forecast: “Based on what we know today, we expect <D>. Confidence: <H/M/L>. Next update: <date>.”
- Target: “Our goal is <D>. We will confirm a commitment after <gate>.”
```

## 3) Decision log (simple)

```md
| Date | Decision | Decision owner | Context / rationale | Follow-ups (owner/date) |
|---:|---|---|---|---|
|  |  |  |  |  |
```

## 4) Risk register

```md
| Risk | Impact | Probability | Mitigation | Owner | Trigger / early signal | Status |
|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |
```

## 5) Change request (for scope control)

```md
### Change request
- Request:
- Why now:
- User impact:
- Cost (rough):
- Suggested trade-off (what to cut/defer):
- Decision owner:
- Decision needed by:
```

## 6) AI/ML outer-loop milestone prompts (only if applicable)
- Evaluation harness + acceptance metrics defined?
- Data readiness + privacy review complete?
- Safety/guardrails + fallback behavior defined?
- Monitoring + alerting + on-call/runbook ready?
- Gradual rollout plan (canary/beta) + rollback plan?


```

### references/WORKFLOW.md

```markdown
# Workflow Notes (Managing Timelines)

Use this as expanded guidance for the workflow in `skills/managing-timelines/SKILL.md`.

## Core concepts

### 1) Deadline taxonomy (what kind of “date” is this?)

- **Fixed external deadline:** tied to an external event/contract/regulatory requirement. Date is effectively immovable; scope/resources are the levers.
- **Fixed internal deadline:** leadership commitment; may still be movable, but requires explicit re-decision.
- **Target date:** directional date to guide prioritization; can move as uncertainty resolves.
- **Window:** a range (“late March”) that can tighten over time; useful when uncertainty is high.

Rule of thumb: if missing details, treat it as a **target/window**, and explicitly say what would be required to turn it into a commitment.

### 2) Commitment ladder (use precise language)

Use three date types to avoid “date soup”:

- **Commitment:** “We will deliver X by D” (only for scoped work within control)
- **Forecast:** “Based on what we know, we expect D” (subject to change as risks resolve)
- **Target:** “We want D” (directional; used for prioritization)

Always attach: confidence + top risks + next decision point.

### 3) Phase-based planning (commit only within control)

Recommended lifecycle:

1) **Discovery** (reduce problem uncertainty)
   - Outputs: problem framing, user value, success metrics/guardrails, top risks, initial approach options
2) **Solutioning** (reduce solution uncertainty)
   - Outputs: chosen approach, UX/tech outline, dependency plan, estimate range, rollout approach
3) **Build** (execution)
   - Outputs: working increment(s), QA plan, release readiness checks
4) **Launch** (safe release)
   - Outputs: rollout/rollback plan, comms, monitoring, post-launch checks

Commitment pattern: commit to **Discovery/Solutioning end dates** first; commit to Build/Launch only after solutioning and estimation.

### 4) RAG (red/amber/green) is only useful with action

Define RAG so it triggers decisions:

- **Green:** on track; no decisions needed
- **Yellow:** risk emerging; needs a decision/assist within 1 week
- **Red:** cannot meet committed date without a change (scope/date/resources/quality); needs immediate decision

RAG should come with:
- “What changed since last update”
- “Decision needed” + deadline
- “Proposed trade-off” (cut/add/shift)

### 5) Protecting a real deadline (treat it like P0)

When a deadline is real:
- Reduce distractions: cancel/defer nonessential work and meetings
- Reduce WIP: prioritize throughput; avoid parallel half-finished work
- Enforce change control: **trade, don’t add**
- Make “cut candidates” explicit early, so you’re not forced into bad last-minute cuts

## AI/ML uneven cadence (demo vs production)

If AI/ML is involved, separate:
- **Time to first demo** (often short): prototype to validate direction
- **Time to production** (often longer): evaluation, safety, reliability, cost/latency, monitoring, fallback behavior, edge cases, compliance

Add explicit outer-loop milestones:
- Evaluation harness + acceptance metrics
- Data readiness + privacy review
- Guardrails + fallback plan
- Monitoring + incident response/runbook
- Gradual rollout + post-launch calibration

## Step-by-step guidance (matches SKILL workflow)

### Step 1) Intake + deadline classification
- Confirm “why now”, what is fixed, and who can change the date or scope.
- If the user says “hard deadline” but can’t name the external constraint, treat it as a target until confirmed.

### Step 2) Commitment model
- Convert any ambiguous “ship date” language into commit/forecast/target.
- Add a rule: **never present a forecast as a commitment**.

### Step 3) Phase plan + decision gates
- Define phase outputs as artifacts a stakeholder can review async.
- Set a “next commitment date” (e.g., “We will re-forecast on <date> after solutioning”).

### Step 4) Milestones + tracker
- Milestones should be deliverables (demo, spec sign-off, dependency secured, code complete, beta shipped).
- Add confidence (H/M/L) and dependency owners.

### Step 5) Governance + escalation
- Default cadence: weekly review with a short agenda:
  1) RAG review (what’s yellow/red)
  2) Decisions/asks
  3) Scope changes
  4) Next week plan
- Ensure “red” has a single escalation path and decision owner.

### Step 6) Scope + change control
- Define freeze points: scope freeze, code freeze, QA freeze (as appropriate).
- Pre-create a cut list so you can trade scope quickly without re-litigating.

### Step 7) Stakeholder comms
- Communicate in the commitment ladder language.
- Include explicit asks and deadlines for decisions (don’t bury them).

### Step 8) Quality gate
- Ensure the final pack answers: “What are we committing to, and what must happen next to keep the date true?”


```

### references/CHECKLISTS.md

```markdown
# Checklists (Managing Timelines)

Use these before finalizing the Timeline Management Pack.

## 1) Deadline & commitment checklist
- Date type is explicit (fixed external / fixed internal / target / window).
- “Why now” is stated in 1–2 sentences.
- Commitment ladder (commit/forecast/target) is defined and used consistently.
- The plan states what variable can move (scope/resources/quality/date).
- Confidence level is stated with top risks and the next re-forecast checkpoint.

## 2) Phase plan checklist
- Discovery/Solutioning/Build/Launch phases are defined with clear outputs.
- Each phase has a decision gate (what must be true to proceed).
- Commitments are made only for phases within control; later dates are forecasts/targets.
- Dependencies/approvals are reflected in phase outputs (not hidden).

## 3) Milestone tracker + RAG checklist
- Milestones are deliverables, not vague activities.
- Every milestone has an owner and dependency notes (if any).
- RAG definitions are written and action-oriented.
- Yellow/red statuses map to explicit asks/decisions with deadlines.

## 4) Governance + cadence checklist
- Update cadence is defined (weekly default) and includes a forum for decisions.
- Weekly review agenda is included and short enough to run consistently.
- Escalation path is clear: who decides scope/date/resource trade-offs.
- A decision log exists (or a place to record decisions is specified).

## 5) Scope & change-control checklist (deadline protection)
- Non-goals are explicit.
- A cut list exists (pre-traded options) and is ordered (cut first → cut next).
- Freeze points are defined (as appropriate).
- Change control rule is stated (“trade, don’t add”) with a decision owner.
- The plan states what work gets deprioritized if the deadline is P0.

## 6) AI/ML outer-loop checklist (only if applicable)
- Demo vs production-ready are treated as separate milestones.
- Evaluation metrics + acceptance bar exist.
- Safety/guardrails + fallback behavior are defined.
- Monitoring + incident/runbook + rollback plan are included.

## 7) Finalization checklist
- The pack includes **Risks**, **Open questions**, and **Next steps** with owners + dates.
- A stakeholder could approve the plan async (it’s readable, specific, and unambiguous).


```

### references/RUBRIC.md

```markdown
# Rubric (Managing Timelines)

Score each item 0/1/2:
- 0 = missing / unusable
- 1 = present but incomplete
- 2 = clear, executable, reusable

Suggested passing bar: **>= 16/20**.

## 1) Deadline clarity (0–2)
- Date type is explicit and justified (“why now”).
- Variable levers (scope/resources/quality/date) are named.

## 2) Commitment ladder (0–2)
- Commit vs forecast vs target language is defined and used consistently.
- Confidence + next re-forecast checkpoint exist.

## 3) Phase plan + gates (0–2)
- Phases have concrete outputs and decision gates.
- Commitments are limited to what’s within control.

## 4) Milestones + ownership (0–2)
- Milestones are deliverable-based with owners, dates, dependencies.
- Confidence and RAG are included.

## 5) RAG usefulness (0–2)
- RAG definitions are action-oriented.
- Yellow/red include explicit asks/decisions with deadlines.

## 6) Governance cadence (0–2)
- Weekly review agenda + escalation path exist.
- Decision logging is covered.

## 7) Scope protection (0–2)
- Non-goals + cut list + freeze points exist.
- Change control rule (“trade, don’t add”) is operational.

## 8) Stakeholder comms (0–2)
- Templates exist and use correct commitment language.
- Updates include “what changed” + “decision needed by when”.

## 9) Risk management (0–2)
- Risks and early signals are captured with owners/mitigations.
- Open questions and next steps are actionable.

## 10) AI/ML outer loop (0–2, conditional)
- If AI/ML is involved: demo vs production separation, eval/safety/monitoring/rollout included.
- If not applicable: mark as N/A and don’t count it.


```