Delivery & Governance · 10 min read
The Project Management Plan: Ten Sections That Matter, and How to Write One in an Afternoon
What a project management plan is, how it differs from the charter and the PMP, ten sections with a question each, and a one-page plan builder.

There is a particular kind of project plan that every office produces at least once. It is 74 pages long. It has a table of contents, a revision history, a glossary and a section called "Assumptions," which contains the single assumption that everything will go fine. It is approved in a meeting. It is saved in a folder named "Final_v7_REAL." And it is never opened again, except by a new hire who is told, "Read that for background," and who bravely makes it to page nine.
That plan is not a plan. It is a monument. A real project management plan is a working tool: it answers the questions people actually ask on a Tuesday afternoon (what are we building, who decides this, when is it due, what happens if the price goes up) in a form short enough that they will look there first.
This article explains what a project management plan is, how it differs from the charter and the schedule, the ten sections that carry most of the value, and how to write one in an afternoon. At the end there is a builder that turns your answers into a one-page plan.
What a project management plan is (and is not)
The PMBOK Guide from the Project Management Institute describes the project management plan as the document that describes how the project will be executed, monitored and controlled. In plain English: it is the project's operating manual. It collects, in one place, the decisions about how you will handle scope, time, money, quality, people, communication, risk and change.
Three clarifications keep the confusion away:
It is not the schedule. The Gantt chart or the schedule is one part of the plan, a very visible part, but a bar chart does not say who approves changes or what "done" means.
It is not the charter. The project charter is short and is written first. It says why the project exists, what success looks like at a high level, who the sponsor is and that the project is authorized. The plan comes after and gives the how. A good way to remember: the charter answers "should we do this and who says so?" and the plan answers "how will we do it?"
It is not the PMP. The Project Management Professional is a certification from PMI. People sometimes write "PMP" when they mean the plan, and it causes comic misunderstandings in job interviews. In this article, "plan" means the document, always. (PMBOK and PMP are registered marks of the Project Management Institute, Inc.; this site is independent and not affiliated with PMI.)
Do you need one?
Yes, in some form, for every project, and the form changes with the size:
- A one-week task for two people: a half-page. Goal, steps, dates, who decides, what could go wrong.
- A three-month project with a small team, a vendor and a budget: two to five pages, built from the ten sections below.
- A multi-year construction project or a large program: a longer plan, often split into smaller plans (for schedule, cost, risk and so on), with a short summary on top that people really read.
The test is not length. The test is whether a new team member could read it in fifteen minutes and know how the project will run.

The ten sections that matter
Here are the ten sections I use for most small and mid-sized projects. For each one, a question to answer and a rule of thumb.
1. Purpose and success measures
Why are we doing this, and how will we know it worked? Two or three sentences linking back to the charter, plus two or three measurable results: not "improve customer service" but "reduce average reply time from 2 days to 4 hours by June 30." If you cannot measure it, say what you will observe instead. This is the section the benefits tracker later checks, and it is where benefits realization begins.
2. Scope: what is in, and what is out
What exactly are we building, and what are we not building? List the main deliverables in plain words, and write a separate list called "Out of scope." The second list is the secret weapon: it is where "oh, we assumed that was included" goes to die before it costs money. The guide to stopping scope creep explains why this one list prevents most arguments.
3. Deliverables and acceptance criteria
What will be handed over, and how will we agree it is done? For each deliverable, one line saying who accepts it and what they will check. "The website is done" is a feeling. "The twelve pages are published, load in under three seconds on a phone and the form sends an email to the office" is a test.
4. Schedule and milestones
What happens when, and what depends on what? Not the whole schedule, but the milestones, the key dependencies and the critical path in a sentence. The detailed schedule can live in its own file; the plan holds the summary and the baseline date. If you need a refresher on why dependencies matter, read the critical path method and why construction schedules slip.
5. Budget and contingency
How much, from where, and what is the reserve? The total, the main cost lines, who can approve spending and the contingency: a reserve for the surprises that will, with certainty, arrive. If you have no contingency, every surprise becomes a negotiation with your sponsor. Earned value in plain English shows how to track budget against progress once the work starts.
6. Team, roles and decisions
Who does what, and who decides? A short list of people and roles, plus a RACI chart for the three or four decisions that matter most (scope change, spend, schedule change, acceptance). Name a decision-maker and a backup. The most common reason small projects stall is not a lack of work; it is a decision waiting for someone who is on vacation.
7. Risks
What could go wrong, how likely is it, and what will we do? The top five to ten risks, each with an owner and a response. The risk register for small business has a simple format, and the toolkit has a free template. Write the risks as sentences with a cause and an effect: "If the permit is late, the foundation starts two weeks later, so the roof misses the dry season."
8. Quality
What standard must the work meet, and how will we check? Inspections, tests, reviews, checklists and who signs. For a building: the inspections and the tests. For software: the reviews and the test plan. For an event: the walk-through the day before. One line per deliverable is plenty.
9. Communication
Who needs to know what, how often and through which channel? A table of audiences (sponsor, team, customer, neighbors, vendors), what they receive, when and from whom. If you have never done this, the communication plan article and the toolkit template will take you there in twenty minutes. Decide the rhythm now: the weekly status report on Friday, the monthly review with the sponsor.
10. Change control and decision log
How will changes be requested, priced and approved? A short rule: no change goes ahead without a written request that states the cost, the schedule effect and the approver. Record the result in a change request log and record the big decisions in a decision log. In construction, this is the heart of managing change orders without a fight.

Optional sections, when the project needs them
Some projects need more. Add a section only when the project would be harmed without it:
- Procurement. If you are buying a lot from vendors: how you choose, contract and manage them. Useful for construction owners and any project that depends on a few suppliers.
- Stakeholder engagement. When the opinions of outside people can sink the project. See stakeholder mapping and the stakeholder register.
- Resources and equipment. When people or machines are scarce, as in the capacity planning article.
- Assumptions and constraints. One short list. Every assumption is a risk wearing a disguise; promote the dangerous ones into the risk register.
- Approach. If the project is agile, waterfall or a hybrid, say so in a sentence, because it changes how everything else is run.
How to write one in an afternoon
You do not need a week. Here is the sequence I use with owners and small teams.
- Start from the charter. Copy the purpose, the sponsor, the success measures and the main constraints. If there is no charter, write one first; the charter guide takes about half an hour.
- Gather the three or four people who know the work. Put the ten headings on a wall or a shared page. Spend about fifteen minutes on each heading, writing short answers in plain language.
- Write the "Out of scope" list aloud. Ask the group: "What might someone assume is included that we are not doing?" Write every answer.
- Agree the milestones and the first risks. Do not build the full schedule in the room. Agree the five or six milestones and the top five risks.
- Name the decision-maker, the backup and the rhythm. Who approves changes? When is the weekly update? When do we meet the sponsor?
- Write it up on two to five pages. Use headings, bullets and numbers. Remove every sentence that nobody would miss.
- Get the sponsor's approval and put it where people work. A shared folder, a pinned message, a printed copy in the site trailer. If people have to hunt for it, they will not use it.
- Set a review date. Plans change. Put a monthly check on the calendar to ask: "What has changed? What needs to be updated?"
A free project management plan template is planned for the website, and the publishing calendar shows its date.
Where plans go wrong
- The monument. Seventy pages nobody reads. Fix: two to five pages, with a one-page summary.
- Copy and paste. A template filled with boilerplate that does not match the project. Fix: delete every section that does not help, and write the others in your own words.
- Everything is "TBD." Placeholders that never get filled. Fix: put a date and an owner next to every TBD.
- No "out of scope" list. The silent source of most disagreements. Fix: write it at the first meeting.
- No contingency. Budget and schedule at best-case values. Fix: reserve a percentage of both and say who can spend it.
- A plan written alone. The project manager writes it in a quiet room and announces it. Fix: build it with the people who will do the work. They know what is realistic, and they are far more likely to follow a plan they helped write.
- A frozen plan. The project changes and the plan does not. Fix: update it at every approved change and every monthly review, and keep the version history short.
- Mixing up the plan and the schedule. A beautiful Gantt chart is not a plan. Fix: use the ten questions above as a checklist.
Plan, baseline and change
A last concept worth knowing: the baseline. When the sponsor approves the plan, its scope, schedule and budget become the baseline, the yardstick against which you measure progress and variance. Changes do not erase the baseline silently; they go through change control and produce a new, approved baseline. That discipline is what lets you say, with a straight face, "we are 6 days behind and $4,000 over," instead of arguing about what the plan said in the first place.
Build your one-page plan
The builder below turns your answers into a one-page project management plan. The sample is a small website relaunch, so you can see how short each answer can be. Replace each one with your own project. The tool warns when something that usually makes a plan useless is missing: no measurable success, no out-of-scope list, no dates, no contingency, no decision-maker or no change rule. Nothing you type leaves your browser.
What to do this week
Pick a project that is running right now and has no written plan, or one whose plan nobody has opened since the kickoff. Spend an hour with the people who know the work and fill in the ten headings. Write the "Out of scope" list first. Put a review date on the calendar. That hour will probably pay for itself before the end of the month.
If you would like help writing a plan for a project of your own, or reviewing one that is already running, you can reach me through the contact page.
What is the one thing every plan you have worked with forgot to mention? Tell me in the comments.
More tools. The project charter, the risk register, the RACI chart and the communication plan are free in the toolkit.
Also read. The document that comes before the plan: the project charter, what it is and how to write one. And how to keep a plan alive once the work starts: the project status report.
Need a project manager's help? See how I work with owners and teams in Utah and across the US: project management consulting in Salt Lake City and business consultant in Utah.
Frequently asked questions
What is a project management plan?
It is the document that describes how a project will be run: the scope, deliverables, schedule, budget, team and decisions, risks, quality, communication and the way changes are controlled. It is built after the project charter and updated as approved changes happen.
What is the difference between a project charter and a project management plan?
The charter is short and written first. It explains why the project exists, names the sponsor and authorizes the work. The plan comes next and describes how the work will be carried out, in enough detail for the team to act on it.
How long should a project management plan be?
As short as it can be while still answering the ten questions. A small project can fit on two pages, a mid-sized one on three to five, and a large project may need a longer plan with a short summary on top. The test is whether a new team member can read it in fifteen minutes.
Is the PMP the same as a project management plan?
No. The PMP (Project Management Professional) is a certification awarded by the Project Management Institute. A project management plan is a working document for one project. They share three letters, which causes confusion.
Monthly newsletter
Everything new, once a month.
One email on the 1st of every month with everything new: articles, series parts, news, website updates, project results, where I am working and the business opportunities I am looking at. No spam.
Join the conversation
Did this help? A quick reaction tells me what to write next.
Be the first to react.

Loading comments…