Project plan and timeline

You turn "we need to do X by Y" into a plan with a defensible date: what is in and out of scope, every piece of work with an owner and an estimate, how the pieces depend on each other, which chain of work sets the end date, and where the slack is. The standard: anyone on the team can see what they do next and what it blocks, and the owner can see the date, the confidence in it, and what would move it.

When to use

• "Plan the office move / system rollout / product launch."
• "When will this be done realistically?"
• "Can we hit the end of November?"
• "Break this project down and assign it."
• "The plan is out of date, rebuild it."

What you need

• The goal in the owner's words, the deadline and why it matters (hard date or preference), budget, and who is available.
• The people who will do the work, to estimate it: reach them with ask_teammate or brief_team.
• Their calendars or availability, holidays and public holidays in their regions (the holidays Python package, or web_search).
• Where the team tracks work: a project tool connected on the Connections page (Asana, Jira, Linear, Trello, ClickUp, Notion) or your own browser signed in by the owner; otherwise the spreadsheet you build is the plan.

Method

1. Charter first, on one page (template in references/plan-templates.md): objective, success measures (numbers and a date), scope in and scope out, deliverables, constraints, assumptions, stakeholders, budget, key risks. Get the owner to agree it before planning tasks. Most late projects were unclear projects.
2. Work breakdown by deliverable, not by department. Decompose until each work package is roughly 1 to 10 working days of effort (the 8/80 hour rule of thumb), has one owner and a clear "done". Include the work people forget: approvals, procurement lead times, data migration, testing, training, communications, hypercare after go-live.
3. Estimate with three points, from the person who will do the work: optimistic (O), most likely (M), pessimistic (P). Expected = (O + 4M + P) / 6; spread = (P minus O) / 6. Wide spreads mark the tasks to break down further or de-risk.
4. Dependencies. For each package, what must finish before it can start (finish to start is the default; note start-to-start or lags where real, such as a 10-day supplier lead time). Add external dependencies (supplier delivery, legal sign-off) as tasks with owners.
5. Critical path. With execute_code, run the forward and backward pass (code in references/critical-path.md): early and late start and finish, float, and the chain with zero float. The project's length is that chain. Report the expected end date and the spread on the critical path (square root of the sum of the critical tasks' variances); quote a date range, not a single day, when the spread is wide.
6. Calendar it. Convert working days to dates with each person's working days, holidays and part-time patterns. Check no one is double-booked in the same week (see resource-capacity-planning for a full check).
7. Fit to the deadline. If the end date misses the deadline, show the options with their cost: cut scope (name what), add people to critical tasks that can actually be split, run tasks in parallel (fast tracking, with the extra risk named), buy time from a supplier, or move the date. The owner decides.
8. Milestones and RACI. 4 to 8 milestones that mean something to the owner (contract signed, system configured, team trained, live). A RACI for each deliverable: exactly one Accountable, at least one Responsible.
9. Baseline and change control. Once the owner approves, save the baseline dates. After that, any change to scope, budget or a milestone date goes through a short change note (what, why, impact on date and cost, decision) and the owner's approval.
10. Publish it where the team works. Create tasks in the team's project tool if connected and the owner agrees; otherwise share the workbook. Set up the weekly update rhythm (see project-status-report).

Worked example: eight tasks, one critical path

ID	Task	O / M / P days	Expected	Predecessors
A	Agree scope and charter	1 / 2 / 4	2.2
B	Shortlist suppliers	2 / 3 / 6	3.3	A
C	Design new workflow	3 / 5 / 9	5.3	A
D	Select and contract supplier	3 / 5 / 10	5.5	B
E	Configure system	4 / 6 / 12	6.7	C, D
F	Write SOPs and training	2 / 4 / 6	4.0	C
G	Train team	1 / 2 / 3	2.0	E, F
H	Go live and hypercare	3 / 5 / 8	5.2	G
Forward and backward pass (code in references/critical-path.md), scheduling each task on its expected duration rounded up to whole days:

• Critical path A, B, D, E, G, H: 28 working days. C has 4 days of float and F has 7.
• Spread on the critical path about 2.2 days (one standard deviation): quote "18 Nov, likely by 20 Nov", not a single date.
• Starting on 12 Oct with 25 and 28 Dec as holidays, go-live lands on Wednesday 18 Nov.
• E has the widest estimate (4 to 12 days): break it down or de-risk it before anything else.
• Rerun after every change; if D finishes early the critical path can move through C and F.

When the date misses the deadline

Option	What it costs	When it works
Cut scope	Named deliverables move to a phase 2	Always the first question
Crash	Add people or hours to a critical task; cost plus onboarding time	Only for tasks that divide (configuring 14 order types, yes; one contract negotiation, no)
Fast-track	Overlap tasks usually done in sequence; rework risk named	When a downstream task can start on a partial input
Buy time	Pay a supplier to expedite	When the critical path is a lead time
Move the date	The honest option	When the others cost more than the delay
Present two or three with their effect on the end date and the cost; the owner chooses.

Work people forget

Approvals and sign-offs, procurement and contract lead times, cleaning data before migration, testing with real cases, training and the hours trainees lose to it, communications to customers and staff, hypercare after go-live, and the holidays of the people on the critical path. Each goes in the plan as a task with an owner, or is written down as excluded with a reason.

Output

• project-plan-<name>.xlsx with sheets: Charter, Plan (ID, task, owner, days, predecessors, start, finish, float, critical, status, % done, plus a coloured Gantt grid with the critical path in its own colour), Milestones, RACI, Assumptions, Change log.
• A Mermaid gantt block (from the code) for docs or chat.
• A show_card: end date and range, critical path, milestones with dates, top 3 risks, decisions needed.

Checks before you finish

• Every task has an owner, an estimate from the doer (or marked as your assumption), and at least one predecessor or the start.
• No dependency loops; no task references a missing predecessor (the code stops on both).
• The critical path is computed, not guessed, and the end date matches it.
• Dates skip weekends and the holidays you checked; no person is booked beyond their available days in any week.
• Every milestone and deliverable has exactly one Accountable.
• The charter is agreed by the owner before the plan is baselined.

Pitfalls

• Planning by department instead of by deliverable, which hides handoffs.
• Single-point estimates from the planner. Ask the doers and use three points.
• No buffer, or buffer hidden in every task. Keep estimates honest and put explicit contingency at the end of the critical path or before key milestones.
• Forgetting lead times (procurement, approvals, notice periods, recruitment).
• Adding people to a late task that cannot be split. It makes it later.
• A plan nobody updates. Agree the weekly rhythm before you publish.

See also

• project-status-report, project-risk-register, resource-capacity-planning.