Project Plan

A project plan is the document that records what will be delivered, by when, by whom, at what cost, and what happens when any of those change. It is the reference the team and the stakeholders return to when there is disagreement, which is the only test of whether it was worth writing.

Two things get conflated constantly and cause most of the confusion around this topic. A Gantt chart is not a project plan — it is the schedule section of one. And a project plan is not a project charter — the charter authorises the project, the plan describes how it will run.

This guide covers what belongs in the document, how it relates to the other documents around it, and the two mechanisms that separate a working plan from a filed one: baselines and change control.

For the estimation and capacity side — turning effort into a realistic calendar — see our companion guide to the project planning process.

Quick answer

Project plan vs the documents around it

This table resolves more confusion than any other part of this article.

The charter comes first and is short: it names the sponsor and the project manager, states the objective, and grants authority to spend. The plan comes after and is long: it says how.

The brief is a summary of the plan for an audience that needs the shape without the detail — cross-functional partners, senior stakeholders, clients. Writing the brief before the plan is a common and expensive inversion, because the summary then anchors decisions that the detail has not yet tested.

The 12 sections

Not every project needs all twelve. Every project needs a deliberate decision about which to omit.

1. Executive summary. One page maximum. The deliverable, the deadline, the budget, the top three risks, and what you need from the reader. Written last, read first, and frequently the only section a sponsor opens.

2. Objectives and success criteria. What is true when this finishes that is not true now, stated so that success is verifiable rather than arguable. “Improve onboarding” is not a criterion. “New users complete setup in under 10 minutes, measured on the 30-day cohort” is.

3. Scope. What is included. Then, separately and explicitly, what is excluded. The exclusions list prevents more disputes than the inclusions list, and its absence is the single most common defect in a project plan.

4. Deliverables. The tangible outputs, each with an acceptance criterion and a named accepter. A deliverable nobody has agreed to accept is a deliverable that gets argued about at handover.

5. Work breakdown. The work decomposed to the level where one person can own an item and estimate it honestly. Deeper than that is administration; shallower and the estimate is a guess.

6. Schedule. Tasks with start and end dates, durations, dependencies and milestones. This is the section that becomes a Gantt chart, a list or a board depending on the audience. The format is presentation; the content is the plan.

7. Resources and roles. Who is assigned, at what allocation, and who decides what. A RACI table earns its place here on anything involving more than one team, because ambiguity about who approves is the most reliable source of delay.

8. Budget. Cost by category — labour, licences, vendors, contingency — and who holds authority to spend against each line.

9. Risks. Each risk with a likelihood, an impact, a mitigation and, critically, a named owner. A risk register without owners is a list of worries. Include the assumptions the plan rests on, because an assumption is a risk that has not been labelled yet.

10. Communication plan. What gets reported, to whom, how often, in what format, and the escalation path when something goes wrong. Five lines, and it removes a category of friction that otherwise consumes the project manager’s week.

11. Change control. How a change is requested, who assesses impact, who approves, and how the baseline is updated. Covered in full below.

12. Approvals. Signatures or recorded sign-off from the sponsor, the budget holder and the delivery lead. Without this the plan is a proposal.

Baselines: the part that makes a plan measurable

This is the mechanism almost every guide to project plans leaves out, and without it the document cannot answer the only question anyone asks during execution.

A baseline is the approved version of the plan, frozen at a point in time and kept for comparison. Three matter:

• Scope baseline — the agreed deliverables and work breakdown
• Schedule baseline — the agreed dates
• Cost baseline — the agreed budget

Once baselined, the plan is not edited casually. Actual progress is measured against the baseline, and the gap is the variance. “We are six days behind” is a meaningful statement only if there is a frozen date to be behind.

The practical failure is subtle and extremely common. A team keeps a single living plan and updates dates as reality shifts. Every week the plan is accurate and every week the project appears to be on schedule, because the schedule moved. The project finishes two months late and nobody can say when that became inevitable, because the evidence was overwritten.

Keep the baseline. Track actuals separately. Re-baseline only through change control, and record when and why you did it.

Change control

Plans change. The question is whether they change through a process or through attrition.

A workable change process has four steps, and can fit on half a page:

1. Request. What is the change, who asked, and why.
2. Impact assessment. Effect on scope, schedule, cost and risk, assessed by the delivery lead rather than by the requester.
3. Decision. Approve, reject or defer, by whoever holds budget authority. Recorded.
4. Update. Re-baseline and communicate. Everyone works from the same version or the process was theatre.

Two thresholds worth setting in advance. Below a defined size — say, anything under a day of effort with no schedule impact — the delivery lead can absorb it without ceremony. Above it, the process runs. Without that threshold, either everything becomes a change request and the process collapses under its own weight, or nothing does and scope creeps invisibly.

Scope creep is not caused by change. It is caused by change that never passes through step two. Each individual request is small and reasonable; the aggregate is a different project with the original deadline.

How detailed should a plan be?

The honest answer is that detail should be proportional to the cost of being wrong.

Rolling wave planning solves the tension between wanting detail and not having it yet. Plan the next phase in full detail and later phases at a coarse level, then elaborate as each approaches. It is honest about what is knowable, which a falsely precise plan for month eight is not.

The failure mode at both ends is real. Too little detail and there is nothing to measure against. Too much and the plan is out of date the week it is approved, and maintaining it costs more than the information is worth.

How long should planning take?

Nobody in this search result quantifies this, so here is a working rule.

Planning effort typically lands between 5% and 15% of total project effort. Below 5% on anything non-trivial and the plan is a wish. Above 15% and you are usually planning around uncertainty that only execution will resolve.

For a 200-person-day project, that is roughly 10 to 30 person-days across discovery, estimation, drafting, review and approval. Most of it is not writing. It is the conversations that make the writing accurate: stakeholder interviews, team estimation sessions, and the review that catches the assumption nobody had stated.

The rule that matters more than the percentage: planning stops when the next decision no longer changes with more analysis. Past that point you are deferring the start, not improving the plan.

Project plan examples by type

The sections stay the same; the emphasis moves.

Software development. Emphasis on the work breakdown, dependencies and the definition of done. Scope exclusions matter enormously because software scope is infinitely elastic. Release and rollback plans sit under deliverables.

Construction. Emphasis on sequencing, permits, inspections and weather contingency. Dependencies are hard rather than soft — you cannot pour concrete before the foundation is inspected. Schedule baseline discipline is strongest in this sector for that reason.

Marketing campaign. Emphasis on approval cycles and fixed external dates. The critical path usually runs through review time rather than production time, and plans that budget zero days for client feedback fail on that alone.

Event. Everything is a hard deadline. Emphasis on the milestone schedule, vendor dependencies and contingency, because the date does not move.

Internal process change. Emphasis on communication and stakeholders rather than tasks. The technical work is usually small; the adoption work is the project.

Across all of them, the one section whose absence predicts failure most reliably is the scope exclusions list.

Agile projects

A backlog is not a project plan, and teams working in sprints still get asked when it will be finished and what it will cost.

What changes is the level at which the plan is fixed:

• Scope is described as outcomes and epics rather than a fixed task list
• Schedule is expressed as a release plan across sprints rather than dated tasks
• Change control applies to the release scope, not to individual backlog items
• Baseline is the release commitment

What does not change: objectives, success criteria, roles, budget, risks and communication. Those sections are identical whichever methodology you use, and skipping them because the project is agile is a category error.

The practical hybrid most teams land on is a fixed-length plan at the release level and adaptive planning inside it. Our guide to choosing between Kanban, Scrum and Agile covers the methodology decision.

Why plans stop being used

Five reasons, in the order they usually occur.

No baseline. Nothing to measure against, so no reason to open it.

No named owners. Sections that belong to everyone belong to nobody.

The plan and the tool diverge. The document says one thing, the board says another, and the team trusts the board. Once that split happens the plan is dead.

No change process. Reality diverges, the plan is not updated, and it becomes a historical artefact within three weeks.

Written for the wrong reader. A plan written to satisfy a governance requirement rather than to run the work will be read once, by the person who required it.

The test for whether a plan is alive: has anyone other than its author opened it in the last two weeks, and did it settle a disagreement?

Common mistakes

Confusing the plan with the schedule. The Gantt chart is one section.

Omitting scope exclusions. The most common defect and the most expensive one.

Updating dates without a baseline. The plan stays accurate while the project drifts, and the drift becomes invisible.

Estimating in calendar time. Thirty working days is not six weeks in most months. See project planning for the conversion.

No named risk owners. A risk register with no owners is a list of worries.

Planning against headcount rather than capacity. Five people is roughly three people of assignable capacity.

Approving without the people doing the work. Estimates the team did not make are estimates the team will not meet.

Writing it once. A plan is a living document or it is a filed one.

How Monitask helps

A plan is built on estimates. Whether the next one is better than the last depends entirely on whether anyone recorded what the work actually took.

Monitask records time as it is spent. Employees clock in when they start and clock out when they stop, so nothing runs in the background without their knowledge.

• Actual hours against the plan turn the schedule baseline into a variance you can report rather than a feeling.
• Project and task-level history gives the next estimate a reference class instead of an opinion.
• Effort consumed against scope completed is the earliest reliable signal that a plan is drifting, and it moves weeks before a milestone date does.
• Capacity from recorded time replaces the headcount assumption that makes most plans optimistic from the day they are signed.

See how it works: Monitask time tracking software.

Sources

• Project Management Institute, What’s in a Project Plan? — component set including scope definition, work breakdown structure, resources and stakeholders, milestone schedule, change management and executive summary.
• A Guide to the Project Management Body of Knowledge (PMBOK Guide), Project Management Institute — scope, schedule and cost baselines, and integrated change control.

Related reading

• Project Planning: Building a Schedule That Survives Contact With the Calendar
• How to Write a Work Plan
• Project Milestones in Project Management
• Mastering Scrum Estimation Techniques for Agile Teams
• The Pros and Cons of Kanban, Scrum and Agile
• Budgeting Projects With Remote Employees
• How Many Work Days in a Year?