Project Plan: What It Includes, How to Build One, and How to Keep It Honest
A project plan is less a prediction than a model: of the work, its order, its cost and its risks. Its value comes from being updated when reality disagrees with it.
By Capstera Business Architecture Staff · Updated
12 min read
A project plan is the document, or set of documents, that describes how a project will deliver what its charter authorizes: the scope broken into work, the schedule and its dependencies, the budget, the people and resources, the risks, how quality will be assured, how changes will be controlled, and how stakeholders will be kept informed. The project manager owns it and updates it throughout the project.
Most project plans are accurate on the day they are approved and wrong within a month. That is not a failure of planning; it is the nature of work nobody has done before. The failure is a plan that stays as it was approved while the work moves on, so the schedule on the wall describes a project that no longer exists and the steering group makes decisions against it. The best project managers treat the plan as a working model: they build it carefully, use it to see consequences before they happen, and change it, openly, when the evidence changes.
Key Takeaways
- A project plan describes how the project will be delivered, within the scope, budget and authority the charter sets.
- Its core is the scope broken into work (a work breakdown structure), sequenced into a schedule, and costed into a budget.
- The critical path, the longest chain of dependent tasks, sets the earliest finish date. Delays off the critical path matter less, until they join it.
- A plan is only as good as its dependencies. Most schedule surprises come from work outside the project the plan assumed would be ready.
- Plan around the value streams the project changes, not only its deliverables, so end-to-end testing and handover are in the schedule.
- Baseline the plan, then update the forecast openly. The gap between them is the most useful information a steering group gets.
What Is a Project Plan?
A project plan answers "how will we do it?" after the charter has answered "what are we doing, and within what limits?"
The term covers a range. On a small project it may be a single document with a schedule attached. On a large program it is a set of subsidiary plans, for scope, schedule, cost, resources, risk, quality, communication, procurement and change control, held together by an integrated plan. What makes any of them a plan rather than a wish list is that the parts agree with each other: the schedule assumes the resources the resource plan provides, and the budget pays for both.
The plan is not the same as a product roadmap. A roadmap shows how a product will evolve over time, often across many projects or releases, and is organized by outcomes and themes. A project plan covers one project's work, with tasks, dates, owners and dependencies, and ends when the project does.
What Does a Project Plan Include?
The components below appear in most planning standards. Small projects combine them; large ones give each its own document.
| Component | What it contains | Why it matters |
|---|---|---|
| Scope and work breakdown structure | The deliverables, broken down into manageable work packages | Work not in the breakdown is not in the schedule or the budget |
| Schedule | Tasks, durations, dependencies, milestones and the critical path | Shows when things happen and what drives the end date |
| Budget | Costs by work package and period, with contingency | Connects the work to the money the charter approved |
| Resource plan | Who does what, when, and at what level of commitment | Most schedules fail on people, not tasks |
| Risk register | Risks, likelihood, impact, owners and responses | Turns worries into actions with owners |
| Quality plan | Standards, reviews, testing and acceptance criteria | Defines "done" before the arguments start |
| Communication plan | Who needs what information, how often, in what form | Prevents surprises for sponsors and affected teams |
| Change control | How changes to scope, time and cost are requested and decided | Keeps the plan and the charter in agreement |
| Procurement plan | What will be bought, how and when | Purchasing lead times are often on the critical path |
| Transition and handover plan | How the result moves into operations: training, support, data, cutover | The work most often left out, and most often late |
How to Build a Project Plan
Planning is mostly decomposition, sequencing and checking. Tools help; the thinking cannot be outsourced to them.
- Start from the charter. Copy the objectives, scope boundaries, milestones, budget and authority; the plan works within them.
- Break the scope into a work breakdown structure: deliverables first, then the work packages that produce them, down to pieces small enough to estimate and assign.
- Estimate each work package with the people who will do the work, and record the assumptions behind each estimate.
- Sequence the work. Identify dependencies between packages, and on things outside the project such as other teams, suppliers and decisions.
- Find the critical path and the float on everything else.
- Assign resources, then check the schedule against real availability. Adjust dates, not people's capacity, when they conflict.
- Cost the plan by period, add contingency for identified risks, and check it against the approved budget.
- Build the risk register, quality plan, communication plan and change control process.
- Plan the transition: training, data migration, cutover, early support and handover to the operations team.
- Review the integrated plan with the team and sponsor, then baseline it.
Scheduling: Gantt Charts and the Critical Path
Two techniques from the early and mid twentieth century still shape almost every project schedule.
The Gantt chart, named after Henry Gantt, who popularized bar charts for scheduling work in the 1910s, shows tasks as bars along a timeline. It is easy to read and good for communicating a schedule. On its own it does not show why dates are what they are.
The critical path method, developed in the late 1950s by engineers at DuPont and Remington Rand, does. Each task has a duration and dependencies; the longest chain of dependent tasks from start to finish is the critical path, and its length is the earliest the project can finish. Tasks on it have no float: a day's delay to any of them delays the project. Tasks off it have some float and can slip a little without moving the end date. PERT, developed around the same time for the US Navy's Polaris program, added ranges to task durations to reflect uncertainty.
In practice, the critical path is where to focus management attention, protect resources and look for ways to shorten the schedule, for example by running tasks in parallel. The path can change: when a non-critical task slips past its float, it joins the critical path, which is why schedules need regular recalculation.
Baselines, Forecasts and Change Control
A plan has two versions that matter: what was agreed, and what is now expected.
The baseline is the plan as approved: scope, schedule and budget. It does not change except through formal change control, because it is the reference point for judging performance. The forecast is the current best estimate of how the project will actually finish, updated as work completes and new information arrives.
The gap between them is the most useful thing a steering group sees. A forecast that drifts a little later every month, with no change requests to explain it, says the plan's assumptions are failing and nobody has said so. A change request that moves the baseline, approved openly with its cost and reason recorded, says the organization has made a decision. Status reports that show only the baseline, or only the forecast, hide one of those two stories.
Project Plans and Business Architecture
Most project plans are organized around deliverables. Organizing them around the value streams the project changes catches the work that deliverable plans leave out.
Deliverable-based plans tend to finish when each component is built and tested. The business, though, does not experience components; it experiences value streams, such as a claim moving from intake to payment or an order moving from quote to cash. A project that changes three stages of a value stream must test the stream end to end, prepare each team that works in it, and plan the cutover so the stream keeps running on the day the old way stops.
When the plan names the value streams and the capabilities the project changes, those activities appear in the work breakdown structure from the start: end-to-end testing per stream, training per affected role, data readiness per capability, and early-life support until the capability performs at its target. They are rarely the most expensive part of a project. They are the part most often left out and then rushed, and the part users remember.
Go further
- Project charter — The authorization and limits the project plan works within.
- Product roadmap vs. project plan — How the two differ, and how they fit together.
- Capability roadmap — Sequencing the capability changes that a set of project plans deliver.
- Project management office — Where planning standards and portfolio views are kept.
Common Project Planning Mistakes
Most planning problems are predictable, which means most are preventable.
- Estimates made without the people doing the work. They are optimistic, and the team does not own them.
- No external dependencies. The plan assumes other teams, suppliers and decisions will be ready on time.
- Resources assumed at full availability. People on a project also have day jobs, holidays and other projects.
- Transition left out. Training, data migration, cutover and support appear as a single line at the end, or not at all.
- Contingency hidden in every estimate instead of held openly against named risks.
- Baseline never updated, forecast never shown. The steering group sees the plan, not the project.
- Too much detail too early. Planning every task for a year ahead creates a document that is out of date before it is finished. Plan near-term work in detail and later work in outline.
Frequently Asked Questions
What is a project plan?
A project plan describes how a project will deliver what its charter authorizes: the scope broken into work, the schedule and its dependencies, the budget, the resources, the risks, quality, communication and change control, and how the result will be handed over to operations.
What should a project plan include?
Scope and a work breakdown structure, a schedule with dependencies and the critical path, a budget, a resource plan, a risk register, a quality plan, a communication plan, a change control process, a procurement plan where relevant, and a transition and handover plan.
What is the difference between a project plan and a project charter?
The charter is a short, signed document that authorizes the project and sets its scope, budget and authority. The project plan describes in detail how the work will be done within those limits, and is updated throughout the project.
What is the difference between a project plan and a product roadmap?
A product roadmap shows how a product will evolve over time, often across several projects or releases, organized by outcomes. A project plan covers one project's tasks, dates, owners and dependencies, and ends with the project.
What is a work breakdown structure?
A hierarchical breakdown of the project's scope into deliverables and then into work packages small enough to estimate, assign and track. Work that is not in the breakdown is not in the schedule or the budget.
What is the critical path in a project plan?
The longest chain of dependent tasks from the start of the project to its finish. Its length is the earliest the project can finish, and any delay to a task on it delays the project.
What is a project baseline?
The approved version of the plan's scope, schedule and budget, used as the reference for measuring performance. It changes only through formal change control, while the forecast is updated as the work proceeds.
How detailed should a project plan be?
Detailed for the near term and in outline for later work, then refined as the project progresses. Large projects split the plan into subsidiary plans held together by an integrated plan.
Pro Tips
- Put every external dependency in the schedule as a task with an owner and a date.
- Report the baseline and the forecast side by side, every time.
- Plan the transition to operations as a work package with its own owner, not a line at the end.
- Name the value streams the project changes, and schedule an end-to-end test for each.
- Hold contingency openly against named risks, not hidden inside estimates.