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 . 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.
- 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):
- Deadline & commitment model (what’s fixed, what’s variable; commit vs forecast vs target language)
- Phase plan (Discovery/Solutioning/Build/Launch) with outputs + decision gates + next commitment date
- Milestone tracker (owners, dependencies, dates, confidence, RAG) + RAG definitions
- Governance cadence (weekly review agenda, escalation triggers, decision log)
- Scope & change-control plan (cut list, non-goals, “trade don’t add” rule, freeze points)
- Stakeholder comms pack (weekly update template + escalation note)
- Risks / Open questions / Next steps (always included)
Templates: references/TEMPLATES.md
Expanded guidance: references/WORKFLOW.md
Workflow (8 steps)
1) Intake + deadline classification
- Inputs: User request; 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 . 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 and score with 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 and 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).
1---2name: managing-timelines3description: 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.4---5
6# Managing Timelines
7
8## Scope
9
10**Covers**
11- Turning a deadline or target date into a clear **commitment model** (commit vs forecast vs target)
12- Building a phase-based plan (Discovery → Solutioning → Build → Launch) with **decision gates**
13- Creating a milestone tracker with simple **RAG** (red/amber/green) status and escalation triggers
14- Protecting the team when a deadline is real (treat it like **P0**, reduce distractions, control scope)
15- Setting a governance + comms cadence so stakeholders get **early risk signals**, not surprises
16- Handling “fast demo, slow production” cadence (especially for AI/ML features) via explicit outer-loop work
17
18**When to use**
19- “We need to ship by <date>. Create a timeline/milestone plan and status cadence.”
20- “We have a launch date; convert this into phases, milestones, and a comms plan.”
21- “Stakeholders keep asking for dates; define what we can actually commit to and when.”
22- “The project feels off-track; set up RAG status + weekly exec review and escalation.”
23- “We can demo quickly, but production will take longer—help set expectations and plan the outer loop.”
24
25**When NOT to use**
26- You haven’t defined the problem/outcome yet (use `problem-definition`)
27- You need to pick which initiatives matter most (use `prioritizing-roadmap`)
28- You primarily need to cut scope to fit an appetite/timebox (use `scoping-cutting`)
29- You need a decision-ready PRD or build-ready spec/design doc (use `writing-prds` / `writing-specs-designs`)
30
31## Inputs
32
33**Minimum required**
34- The deliverable and success bar (“done means…”) + key users/stakeholders
35- The date type: **fixed deadline** (external) vs **target** (internal) vs **window** (e.g., “late March”)
36- Constraints and non-negotiables (quality, compliance, privacy/security, platform, budget)
37- Team shape + capacity assumptions (who’s building; availability; parallel work)
38- Known dependencies and risks (other teams, vendors, data availability, approvals)
39
40**Missing-info strategy**
41- Ask up to 5 questions from [references/INTAKE.md](references/INTAKE.md).
42- If answers aren’t available, proceed with explicit assumptions and list **Open questions** that could change the date or scope.
43
44## Outputs (deliverables)
45
46Produce a **Timeline Management Pack** in Markdown (in-chat; or as files if the user requests):
47
481) **Deadline & commitment model** (what’s fixed, what’s variable; commit vs forecast vs target language)
492) **Phase plan** (Discovery/Solutioning/Build/Launch) with outputs + decision gates + next commitment date
503) **Milestone tracker** (owners, dependencies, dates, confidence, RAG) + RAG definitions
514) **Governance cadence** (weekly review agenda, escalation triggers, decision log)
525) **Scope & change-control plan** (cut list, non-goals, “trade don’t add” rule, freeze points)
536) **Stakeholder comms pack** (weekly update template + escalation note)
547) **Risks / Open questions / Next steps** (always included)
55
56Templates: [references/TEMPLATES.md](references/TEMPLATES.md)
57Expanded guidance: [references/WORKFLOW.md](references/WORKFLOW.md)
58
59## Workflow (8 steps)
60
61### 1) Intake + deadline classification
62- **Inputs:** User request; [references/INTAKE.md](references/INTAKE.md).
63- **Actions:** Identify the deadline type (fixed vs target vs window), the “why now”, and what variable can move (scope, resources, quality, or date).
64- **Outputs:** Deadline classification + constraints snapshot.
65- **Checks:** You can state: “The date is <fixed/target/window> because <reason>. The variable we will trade is <scope/resources/etc>.”
66
67### 2) Define the commitment model (“commit vs forecast vs target”)
68- **Inputs:** Deadline classification; current knowledge of scope/unknowns.
69- **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.
70- **Outputs:** Commitment model section + communication rules.
71- **Checks:** Stakeholders can tell which dates are promises vs estimates.
72
73### 3) Build a phase plan with decision gates
74- **Inputs:** Deliverable; known unknowns; constraints.
75- **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).
76- **Outputs:** Phase plan with dates, outputs, and gates; “next commitment date” (when you’ll re-forecast).
77- **Checks:** Every phase ends with a tangible artifact and a go/no-go decision.
78
79### 4) Create the milestone tracker (+ “demo vs production” outer loop when relevant)
80- **Inputs:** Phase plan; dependencies; team capacity.
81- **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.
82- **Outputs:** Milestone tracker table + RAG definitions.
83- **Checks:** Milestones are outcome-based (deliverables), not just activities; critical dependencies are explicit.
84
85### 5) Set governance: RAG + weekly reviews + escalation
86- **Inputs:** Milestone tracker; stakeholder map.
87- **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.
88- **Outputs:** Governance cadence + weekly review agenda + escalation triggers.
89- **Checks:** A “red” status produces a concrete ask/decision, not just a warning.
90
91### 6) Protect the deadline: scope control + distraction shield
92- **Inputs:** Deadline type; milestone risks; incoming requests.
93- **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).
94- **Outputs:** Scope/change-control plan + cut list + freeze points.
95- **Checks:** New scope cannot enter without an explicit trade-off and decision owner approval.
96
97### 7) Stakeholder comms + expectation management
98- **Inputs:** Commitment model; tracker; risks.
99- **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.
100- **Outputs:** Comms pack (templates + initial draft update).
101- **Checks:** Updates include “what changed since last week” and “what decision is needed by when”.
102
103### 8) Quality gate + finalize
104- **Inputs:** Full draft pack.
105- **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.
106- **Outputs:** Final Timeline Management Pack.
107- **Checks:** A stakeholder can approve the plan async and the team can execute without re-litigating dates every week.
108
109## Quality gate (required)
110- Use [references/CHECKLISTS.md](references/CHECKLISTS.md) and [references/RUBRIC.md](references/RUBRIC.md).
111- Always include: **Risks**, **Open questions**, **Next steps**.
112
113## Examples
114
115**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.”
116Expected: a fixed-deadline plan that treats the date as P0, with change control and clear escalation triggers.
117
118**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.”
119Expected: milestones that include evaluation, safety/reliability, and rollout steps; explicit commit vs forecast language.
120
121**Boundary example:** “Decide what we should build this quarter and set dates for everything.”
122Response: use `prioritizing-roadmap` first; then apply this skill to the chosen initiative(s).
123