Project Management guide · Planning and scope
Project Management Plan: Components, Steps and Example
A project management plan is the approved document that explains how a project will be carried out, monitored, controlled and closed. It brings the scope, schedule, cost, risk, quality, communication and other plans together with the baselines you measure progress against. This guide covers its components, a 10-step method, a worked example and an outline you can copy.
Key takeaways
- A project management plan explains how the project will be run, not just what it will deliver.
- It combines subsidiary management plans (scope, schedule, cost, risk and more) with the scope, schedule and cost baselines.
- Build it from the approved charter: requirements and scope first, then schedule and budget, then the supporting plans.
- Scale the level of detail to the project's size, risk and complexity; a small project may need only a few pages.
- Treat it as a living document: update it through change control and re-baseline only when changes are approved.
What is a project management plan?
A project management plan is a formal, approved document that defines how a project will be executed, monitored and controlled, and closed. It integrates the subsidiary management plans for scope, schedule, cost, quality, resources, communication, risk, procurement and stakeholders, together with the baselines used to measure performance.
The wording comes from PMI's *PMBOK Guide*, which defines the project management plan as the document that describes how the project will be executed, monitored and controlled, and closed. In practice, it is the rulebook for the project: the place the team, sponsor and stakeholders go to find out how decisions are made, how progress is reported and what happens when something changes.
A good plan answers a handful of practical questions:
- What are we delivering, and what is out of scope?
- When will the main deliverables and milestones be complete?
- How much will it cost, and how will spending be controlled?
- Who is doing the work, and who makes which decisions?
- How will we manage quality, risks, issues, suppliers and communication?
- What happens when someone asks for a change?
It is usually written by the project manager with input from the team, subject-matter experts and key stakeholders, and approved by the sponsor or project board. Developing it is a core activity of project integration management, because it ties all the other knowledge areas together.
Project management plan vs other project documents
People often use "project plan", "project management plan" and "schedule" interchangeably. They overlap, but they are not the same thing. The table below shows how the main start-up documents relate to each other.
| Document | Main purpose | Level of detail | Typical owner |
|---|---|---|---|
| Project charter | Authorises the project and names the project manager | High level, 2–4 pages | Sponsor |
| Project initiation document (PID) | PRINCE2 baseline for authorising and running the project | Detailed | Project manager, approved by the project board |
| Project management plan | Explains how the project will be executed, monitored, controlled and closed | Detailed, scaled to the project | Project manager, approved by the sponsor |
| Project schedule | Sequenced activities, durations, dependencies and dates | Detailed for timing only | Project manager or scheduler |
| Statement of work | Describes work a supplier will deliver under a contract | Detailed for the contracted work | Buyer and supplier |
| "Project plan" (informal) | Often used to mean the schedule or a short summary plan | Varies | Project manager |
The key distinction is that the charter says the project exists and why, while the project management plan says how it will be delivered. The schedule is only one part of the plan. If you work in a PRINCE2 environment, the PID plays a similar role to the project management plan but also contains the business case and the project management team structure.
Why a project management plan matters
Writing a plan takes time, so it is fair to ask what it gives you. In our experience the benefits come less from the document itself than from the thinking and agreements it forces early on.
- Shared understanding: the sponsor, team and stakeholders agree on scope, priorities and ways of working before money is spent.
- A basis for measuring progress: without approved baselines for scope, schedule and cost, you cannot say whether the project is ahead, behind or over budget.
- Faster decisions: roles, approval limits and escalation routes are agreed in advance, so issues do not stall while people work out who decides.
- Control of change: a defined change control process protects the project from scope creep.
- Fewer surprises: planning for risk, quality and procurement up front exposes problems while they are still cheap to fix.
- Easier onboarding: new team members and suppliers can read one document instead of piecing together emails and meeting notes.
Components of a project management plan
The most widely used checklist of components comes from the *PMBOK Guide* 6th edition, which describes three groups: subsidiary management plans, baselines and additional components. Later editions moved to a principles-and-performance-domains structure and put more weight on tailoring, but the 6th edition list remains a practical reference for deciding what your plan should cover.
Subsidiary management plans
Each subsidiary plan explains how one area of the project will be managed. On a small project several can be a paragraph each; on a large project each may be a separate document referenced from the main plan.
| Subsidiary plan | What it explains |
|---|---|
| Scope management plan | How scope will be defined, validated and controlled; see project scope |
| Requirements management plan | How requirements will be gathered, prioritised, traced and changed |
| Schedule management plan | The scheduling method, tool, units, update frequency and thresholds for schedule variance |
| Cost management plan | How costs are estimated, budgeted and controlled; see cost management plan |
| Quality management plan | Quality standards, metrics, reviews, acceptance checks and responsibilities |
| Resource management plan | How people, equipment and materials are acquired, assigned and released |
| Communications management plan | Who receives which information, when, in what format and from whom; see communication plan |
| Risk management plan | How risks are identified, assessed, owned and reviewed; see project risk management |
| Procurement management plan | What will be bought, contract types and how suppliers are selected and managed |
| Stakeholder engagement plan | How each stakeholder group will be involved and kept informed |
Baselines
Baselines are the approved versions of scope, schedule and cost. They change only through formal change control, and actual performance is compared against them.
| Baseline | Made up of | Used to measure |
|---|---|---|
| Scope baseline | Scope statement, work breakdown structure and WBS dictionary | Whether the right work is being delivered |
| Schedule baseline | The approved schedule with start and finish dates | Schedule variance and slippage |
| Cost baseline | The approved, time-phased budget, excluding management reserve | Cost variance and spending trends |
Together, the three form the performance measurement baseline, which is what earned value management compares against.
Additional components
The *PMBOK Guide* 6th edition also lists components that describe how the project as a whole is run:
- Change management plan: how changes are requested, assessed, approved and recorded.
- Configuration management plan: how versions of deliverables and documents are identified and controlled.
- Project life cycle description: the phases the project will pass through.
- Development approach: predictive, adaptive (Agile) or hybrid, and why.
- Management reviews: when the sponsor or steering group will review progress and make go or no-go decisions.
How to create a project management plan in 10 steps
The order below follows the logic most practitioners use: agree what you are delivering, then when and for how much, then how you will manage everything around it. In reality you will loop back as later steps expose problems with earlier ones, which is normal.
1. Start from the approved charter and business case
Read the project charter and business case closely. Note the objectives, high-level scope, fixed dates, budget range, known risks and any constraints. Everything in the plan must be consistent with these. If something in the charter is unrealistic, raise it with the sponsor now rather than burying it in the plan.
2. Identify stakeholders and gather requirements
List everyone affected by or able to influence the project, then gather and prioritise their requirements. Interviews, workshops and reviews of existing processes all help. Record requirements so you can trace each one to a deliverable later.
3. Define scope and build the work breakdown structure
Write a scope statement with clear inclusions, exclusions, deliverables and acceptance criteria. Then break the deliverables down into a work breakdown structure until each work package is small enough to estimate and assign. Our free WBS template gives you a starting structure.
4. Choose the life cycle and tailor your approach
Decide whether the project will be predictive, Agile or hybrid, which phases it will have and how much formality each area needs. A two-month internal project and a two-year regulated programme should not use the same level of documentation.
5. Build the schedule
Turn work packages into activities, sequence them with dependencies, estimate durations and identify the critical path. Add milestones for key decisions and handovers. Our guide to project scheduling walks through each step.
6. Estimate costs and set the budget
Estimate the cost of each work package using techniques such as analogous, parametric or bottom-up estimating, then add contingency for identified risks. Aggregate the estimates into a time-phased project budget and agree any management reserve with the sponsor.
7. Plan resources, roles and responsibilities
Confirm who will do the work, when they are available and what equipment or materials are needed. Use a RACI matrix to show who is responsible, accountable, consulted and informed for each major deliverable and decision.
8. Plan quality, risk, communication, procurement and stakeholder engagement
Write the supporting plans. Set quality standards and acceptance checks, run a risk workshop and start a risk register, agree reporting rhythms and channels, decide what to buy and how, and plan how you will engage each stakeholder group.
9. Define change control, baselines and reporting
Describe how changes are requested and approved, who can approve what (for example, the project manager up to a set cost, the sponsor above it) and how decisions are recorded. Set the scope, schedule and cost baselines and agree how progress will be reported, for example in a weekly status report.
10. Review, approve and kick off
Walk the sponsor and key stakeholders through the plan, resolve comments and obtain formal approval. Then hold a kickoff meeting so the whole team understands the objectives, the plan and their part in it. A plan that only the project manager has read will not guide anyone.
Project management plan example
The example below is illustrative and simplified. It shows how each part of a plan might read for a mid-sized internal project: moving a 120-person team to a new office.
| Section | Example entry |
|---|---|
| Objective | Move all staff and equipment to the new office by 28 February with no more than one working day of disruption per team. |
| Scope | Includes space planning, IT and network set-up, furniture, removals and staff communication. Excludes the building fit-out, which the landlord delivers. |
| Deliverables | Approved floor plan; working network and phones; furniture installed; staff moved; old office cleared. |
| Schedule | Planning Oct–Nov; IT installation Jan; moves over three weekends in Feb. Critical path runs through network installation. |
| Budget | Cost baseline of £180,000 plus £15,000 contingency held by the project manager; management reserve held by the sponsor. |
| Resources and roles | Project manager, facilities lead, IT lead, removals supplier. Sponsor: Operations Director. RACI for each deliverable. |
| Quality | Network tested and signed off by IT before any team moves; snagging list closed within 10 working days. |
| Risks | Late network installation (high): weekly supplier check-ins and a fallback date. Staff resistance (medium): early floor-plan previews. |
| Communications | Fortnightly email to all staff; weekly steering update to the sponsor; team briefings two weeks before each move. |
| Procurement | Removals and furniture through competitive quotes from three suppliers; fixed-price contracts. |
| Change control | Project manager approves changes up to £2,000 and two days; above that, the sponsor decides. |
| Closure | Handover to facilities, final cost report and a lessons-learned session within a month of the last move. |
Notice that each entry is specific and measurable. "Minimal disruption" becomes "no more than one working day per team", and "keep people informed" becomes a named channel and frequency.
Project management plan outline
Use this outline as the contents page for your document. Remove or merge sections that do not apply, and link to separate documents where they already exist.
- Document control: version, date, author, approvers and change history.
- Project overview: background, objectives and success criteria from the charter.
- Scope: scope statement, exclusions, deliverables, acceptance criteria and WBS.
- Development approach and life cycle: phases, methods and tailoring decisions.
- Schedule: milestone list, summary Gantt chart and schedule management rules.
- Budget: cost baseline, contingency, funding and cost control rules.
- Organisation: roles, responsibilities, RACI and decision rights.
- Resource management: staffing, equipment and materials.
- Quality management: standards, reviews and acceptance.
- Risk management: approach, scales, owners and review cycle; link to the risk register.
- Communications: stakeholders, messages, channels and frequency.
- Procurement: what will be bought and how suppliers are managed.
- Stakeholder engagement: approach for each key group.
- Change and configuration control: process, thresholds and records.
- Monitoring and reporting: status reports, reviews and key metrics.
- Closure: acceptance, handover and lessons learned.
- Appendices: detailed schedule, estimates, registers and templates.
Our free project plan template gives you a ready-made structure in Sheets, Excel and PDF. Pair it with the risk register template, communication plan template and RACI matrix template for the supporting sections.
How detailed should the plan be?
There is no fixed length. The right amount of detail is whatever lets the team work without constantly asking how things should be done, and lets the sponsor see what they are approving. As a rough guide:
| Project type | Typical plan | What to keep short |
|---|---|---|
| Small, low-risk (weeks, a few people) | A few pages or a single shared workspace page: objectives, scope, milestones, budget, roles, top risks | Procurement, configuration and detailed quality plans |
| Medium (months, one team or supplier) | A main document of moderate length with the schedule, budget and risk register as attachments | Subsidiary plans can be a section each |
| Large or regulated (a year or more, many suppliers) | A main plan that references separate subsidiary plans and registers | Repetition: link rather than copy |
Ask two questions about every section: would anyone notice if it were missing, and would they make a different decision because of it? If the answer to both is no, cut it.
Project management plans in Agile and hybrid projects
Agile teams still plan, but they plan differently. Instead of fixing detailed scope up front, they fix the vision, time and budget boundaries and the ways of working, then plan in detail one release or sprint at a time. This is sometimes called rolling-wave planning.
- Keep firm: objectives, governance, budget limits, release milestones, roles, definition of done and how stakeholders are involved.
- Keep flexible: detailed scope, which lives in the prioritised product backlog rather than a fixed scope baseline.
- Replace: the detailed Gantt chart with a product roadmap and release plan; formal change requests for scope with backlog prioritisation by the product owner.
Hybrid projects often combine both: a predictive plan for hardware, contracts or regulatory milestones, and Agile delivery for software or content.
Keeping the plan up to date
An approved plan is a baseline, not a final answer. Projects change, and the plan should change with them in a controlled way.
- Use change control: assess the impact of each change on scope, time, cost, quality and risk before approving it, then update the affected sections.
- Re-baseline only when a change is approved: do not quietly move the baseline to hide slippage; the variance is useful information.
- Review at set points: at each phase gate, after major changes and at least monthly on longer projects.
- Keep version control: record what changed, when, why and who approved it in the document control section.
- Tell people: a changed plan that nobody knows about causes as many problems as no plan.
Common project management plan mistakes
| Mistake | Why it hurts | What to do instead |
|---|---|---|
| Treating the schedule as the whole plan | Risk, quality, communication and change are left unmanaged | Cover every component, even briefly |
| Copying a template without tailoring | Long documents nobody reads, with sections that do not apply | Scale each section to the project's size and risk |
| Writing it alone | Estimates are unrealistic and the team does not feel ownership | Plan with the people who will do the work |
| Vague objectives and scope | Disputes about what "done" means | Use measurable objectives and explicit exclusions |
| No contingency | The first risk that occurs breaks the budget or deadline | Add contingency based on the risk register |
| No change thresholds | Every small change escalates, or large ones slip through | Set clear approval limits |
| Filing it after approval | The plan drifts away from reality | Review and update it at set intervals |
| Not getting formal sign-off | Stakeholders later deny agreeing to scope or budget | Record approval with names and dates |
Tools for building and maintaining the plan
Many teams write the narrative parts of the plan in a document and manage the schedule, tasks, risks and budget in project management software. Software makes it easier to keep the plan live: dependencies update automatically, dashboards show progress against the baseline, and everyone sees the same version.
When comparing tools for planning work, look for Gantt charts with dependencies and baselines, resource or workload views, custom fields for risks and issues, and reporting dashboards. Wrike, our top-ranked tool, offers interactive Gantt charts with dependencies, and shareable dashboards from its Team plan upwards, which suits teams running several projects at once, while lighter tools suit simpler plans. Our guide to Gantt chart software and the full project management tools ranking can help you choose.
Once the plan is approved, the next job is turning it into a schedule the team can follow.
Free templates for this topic
Frequently asked questions
What is a project management plan?
A project management plan is a formal, approved document that describes how a project will be executed, monitored and controlled, and closed. It brings together subsidiary plans for areas such as scope, schedule, cost, quality, risk and communication, plus the scope, schedule and cost baselines.
What are the main components of a project management plan?
Following the *PMBOK Guide* 6th edition, the plan has subsidiary management plans (scope, requirements, schedule, cost, quality, resource, communications, risk, procurement and stakeholder engagement), baselines (scope, schedule and cost) and additional components such as change and configuration management plans, the life cycle and the development approach.
What is the difference between a project plan and a project management plan?
In everyday use, "project plan" often means the schedule or a short summary of what will be delivered. The project management plan is broader: it explains how the whole project will be run, including control processes for scope, cost, quality, risk, communication and change.
Is the project schedule the same as the project management plan?
No. The schedule shows activities, durations, dependencies and dates. It is one component of the project management plan, which also covers scope, cost, quality, resources, risk, communication, procurement and change.
What are the three baselines in a project management plan?
The scope baseline, the schedule baseline and the cost baseline. Together they make up the performance measurement baseline, which actual progress is compared against. See our guide to the project baseline.
What are subsidiary plans?
Subsidiary plans are the parts of the project management plan that explain how a specific area is managed, such as the risk management plan, communications management plan or cost management plan. On small projects they can be short sections; on large projects they are often separate documents.
Who creates the project management plan?
The project manager leads its development, working with the team, subject-matter experts and key stakeholders. Estimates and plans are more realistic when the people doing the work help build them.
Who approves the project management plan?
Usually the project sponsor, sometimes together with a steering committee or other key stakeholders. Formal approval turns the plan and its baselines into the reference point for measuring performance.
How long should a project management plan be?
As long as the project needs and no longer. A small, low-risk project may need only a few pages, while a large or regulated project usually needs a main document that refers to separate subsidiary plans and registers.
How often should the project management plan be updated?
Whenever an approved change affects it, and at planned reviews such as phase gates. On longer projects, review it at least monthly so it stays aligned with how the project is actually being run.
Do Agile projects need a project management plan?
Agile projects still need agreed objectives, governance, budget limits, roles and ways of working, but detailed scope lives in the product backlog and is planned release by release. The plan is lighter and more adaptive rather than absent.
What is the difference between a project charter and a project management plan?
The project charter formally authorises the project and sets out its purpose, high-level scope and the project manager's authority. The project management plan is created afterwards and explains in detail how the project will be delivered and controlled.
What tools can I use to create a project management plan?
A word processor or shared document works for the narrative sections, and project management software with Gantt charts, dashboards and registers helps keep the schedule, risks and budget current. Our free project plan template is a good starting point.