managing-timelines

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)
• You’re planning the actual launch rollout, rollback, and go/no-go (use shipping-products)
• The plan is dominated by unknowns and you need hypothesis-driven experimentation before committing to dates (use planning-under-uncertainty)

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)