Key takeaways
- Break the work down until every task has one owner and an end you can verify.
- Record dependencies; a plan without them cannot show the effect of a delay.
- Baseline the dates once, then track actuals against the baseline instead of quietly editing it.
- Milestones are decision or payment points, not activity labels.
- Keep a short risk log with an owner and a mitigation per risk, and review it at every progress report.
From deliverables to a work breakdown
Start from the approved proposal or scope of work, not from a blank calendar. Each deliverable becomes a phase; each phase breaks into tasks small enough that a week of slippage is visible.
- Name tasks as outcomes ("drawings approved") rather than efforts ("work on drawings").
- Give every task one accountable owner — two owners means none.
- Estimate duration and effort separately; a two-day task can span two weeks waiting for approval.
- Mark client-dependent tasks clearly, because those delays are the ones you will need evidence for.
- Stop breaking down when a task is under about a week of work.
Dependencies, critical path and float
Dependencies turn a list into a plan. Once they are recorded, the critical path — the chain with no slack — becomes obvious, and you know which delays matter and which do not.
| Concept | What it tells you | How to use it |
|---|---|---|
| Finish-to-start | Task B cannot start until A ends | Default relationship for approvals and site sequencing |
| Lag | Waiting time between two tasks | Model curing, shipping and approval windows explicitly |
| Critical path | The chain that sets the end date | Protect it: escalate its delays on the day they occur |
| Float | Slack available on a non-critical task | Move resources from float to the critical path |
| Milestone | A zero-duration decision or payment point | Tie invoices and client approvals to these |
Resourcing, budget and the risk log
A schedule without resourcing is a wish. Assign people and equipment to tasks, check nobody is booked above capacity, and keep the cost plan alongside the schedule so a delay's cost is visible immediately.
- List each role, the allocation percentage and the period required.
- Track budget per phase against the priced deliverables in the proposal.
- Log risks with probability, impact, owner and mitigation — five real risks beat twenty generic ones.
- Record assumptions in the plan itself so the baseline can be explained months later.
- Set the reporting cadence: weekly internal, fortnightly or monthly to the client.
Do not overwrite the baseline when dates move. Keep the baseline, record the actual, and note the cause — that record is what protects you in a claim or an extension-of-time discussion.
Keeping the plan alive
The plan is only useful if the actuals flow back into it. Timesheets supply the hours, progress reports supply the percentage complete and the issues, and the completion certificate closes it. If those three documents are not produced against the same task list, the plan becomes a document nobody trusts.
How to create a project plan
Step 1: Import the scope
List the approved deliverables and turn each one into a phase.
Step 2: Break down tasks
Split phases into tasks with one owner and a verifiable end each.
Step 3: Sequence and date
Add dependencies and lags, then set start and finish dates and identify the critical path.
Step 4: Resource and budget
Assign people and equipment, check capacity and align cost per phase to the priced deliverables.
Step 5: Add risks and cadence
Log key risks with owners and mitigations and fix the reporting rhythm.
Step 6: Baseline and issue
Baseline the dates, export the plan and track actuals against it from then on.
Frequently asked questions
What is the difference between a project plan and a schedule?
The schedule is the dated task list. The plan is the schedule plus scope reference, owners, resourcing, budget, risks, assumptions and the reporting and change-control rules.
How detailed should a project plan be?
Detailed enough that each task has one owner and a verifiable end, typically a few days to a week of work per task. More granularity than that costs more to maintain than it returns.
Who signs the project plan?
The project manager issues it and the client or sponsor approves it. Approval matters because the baseline dates become the reference for delay and extension discussions.
How often should a project plan be updated?
Update actuals weekly and reissue the plan whenever a change is approved or the critical path moves. Version every issue and keep the original baseline intact.