Project Plan Template & Project Plan Outline

What is a Project Plan?

A project plan is the document that says what a project will deliver, what it will not, who does each piece of work, by when, for how much, and how everyone will know whether it is on track. It is what the sponsor approves and what the team works from. Without one, every stakeholder carries a different version of the project in their head, and the differences surface late, as missed dates and arguments about scope. The template follows a standard project plan outline, so you can fill it in heading by heading.

Project managers write one at the start of any piece of work with a fixed end: launching a website, moving an office, rolling out new software, running an event, renovating a store or delivering a client engagement. A small business uses a one-document plan where a large organization might keep a whole set of documents, and team leads who have never been called project managers use one to get agreement before work begins. Sponsors read it to decide whether to fund the project; team members read it to see what they own and when it is due.

There is no legal format for a project plan; what varies is the organization and the method. The PMBOK Guide from PMI, the Project Management Institute, and PRINCE2, which grew out of UK government practice, both describe planning in depth, but you do not need either to write a useful plan. Many organizations have a project office with its own template and approval limits, and grant funders, government agencies and clients often prescribe the plan they want to see. Check your organization's policy and any contract or grant terms before settling on a layout.

A project plan is not a contract. If the work is for a client, the statement of work or the contract sets the obligations, and a plan that contradicts it does not change them. It is not a project charter, which authorizes the project to exist, and it is not a status report, which says where things stand this week. Nor is it a guarantee: the budget line records what has been approved or requested, not money that is actually available, and the dates are targets until the people named against them have agreed.

What to put in a Project Plan

These are the details this template asks for. Anything left blank is marked in red on the preview so you can see what is still missing.

How to write a Project Plan

1. Name the project, manager and sponsor

   Give the project a name people will actually use. Name one project manager, who runs the work day to day, and one sponsor, who funds it, settles disputes and approves changes. A sponsor listed as ‘the leadership team’ means nobody can say yes. Add the start date and the target end date, and say what the end date depends on if it is not fixed.

2. Write an objective you can test

   State the result, not the activity, in a form someone could check on the last day. ‘Improve the website’ can never be finished. ‘Launch the redesigned online store, with checkout working on phones, before the holiday sale begins’ can be. If the project has several aims, list them in priority order, so trade-offs have an answer before anyone has to argue about them.

3. Draw the scope line both ways

   List what is in scope and, just as carefully, what is out. ‘In scope: new product pages and checkout. Out of scope: new product photography, moving the old blog posts, a mobile app.’ The out-of-scope list is the one that prevents scope creep, because when a new request arrives, it gives the project manager something written to point to instead of an argument.

4. Set milestones, then assign every task

   Milestones are checkpoints, not work: ‘design approved’, ‘site live on the test server’, ‘go-live’. Tasks are the work between them, each with one named owner — a person, not a department — plus a start date, a due date and anything it depends on. Break a task down until it can be finished within one reporting period; anything larger hides slippage until it is too late to recover.

5. Add budget, risks, reporting and approval

   Break the budget into lines — labor, contractors, software, equipment, contingency — so overspending shows up where it happens. List each risk with its likelihood, impact, owner and planned response. Say how progress will be reported, to whom and how often. Then have the sponsor approve the plan, and when scope changes, re-baseline it and record who approved the change.

How to create a work breakdown structure

A work breakdown structure, or WBS, is how you find every task before you put a date on any of them. To create a work breakdown structure, start with the project deliverables: the things the project hands over, such as ‘product pages’, ‘checkout’ and ‘staff training’. Split each deliverable into smaller parts. Keep splitting until each part can be priced, given a length of time and handed to one owner.

Then check it both ways. Everything required to complete the project should appear somewhere in the structure, and nothing outside the scope line should. The smallest parts, often called work packages, become the specific tasks in the Tasks box. Give each one an owner, a start date, an end date and anything it waits on. That is what you need to build the project schedule.

Write the structure as an indented outline or draw it as a tree, whichever your team reads more easily. Number the levels — 1, 1.1, 1.1.1 — so people can refer to a task without retyping its name. A WBS lists work, not dates. The dates come later, when you put the tasks in order against the milestones, often on a Gantt chart.

Roles and responsibilities: what RACI means

Each task in this template has one owner. On bigger projects, several people touch each piece of work, and a RACI chart sets out their roles and responsibilities. It is a simple table: tasks or deliverables down the side, people across the top, and a letter in each box. RACI stands for responsible, accountable, consulted and informed.

Check the chart before work starts. A task with no A, or with two, will stall or start an argument. A long list of people to consult slows every decision, so keep it to those whose input changes the work. Treat the owner you name for each task in this template as the accountable person.

• Responsible means the person or people who do the work.
• Accountable means the one person who answers for the result and signs it off, and each task should have exactly one.
• Consulted means the people whose advice is needed before the work is done, such as finance or legal.
• Informed means the people who are told about progress or the result but do not take part in the decision.

Project plan vs project management plan

For a small project, the plan this template produces is enough on its own. For complex projects, many organizations expand it into a project management plan: the full set of documents that says how the project will be run, checked and closed. It typically includes baselines for scope, schedule and cost, plus a plan for each part of the project, such as resources, quality, communications, risk and buying from suppliers. Your project office or method decides which ones you need.

Resource planning shows the resources required for each task: people and their hours, contractors, equipment, software and space. It shows clashes early, such as one designer booked on two tasks in the same week, and it feeds the budget. Risk management in a fuller plan goes further than the list on this page. Each risk gets a rating for how likely it is and how much harm it would do, a warning sign to watch for, and a review at every progress meeting.

Communication plans start with a list of everyone with a stake in the project, including the sponsor, the team, suppliers and the people who will use the result. For each group, say what they need to hear, how often, in what form and from whom: a weekly email to the team, a monthly one-page summary for the sponsor, a notice to customers before go-live. The box on this page for how progress will be reported holds the short version.

Common mistakes

• Writing an objective with no finish line, such as ‘improve customer experience’, leaves a project that can never be declared done or judged a success.
• Leaving the out-of-scope list empty lets every new request look like part of the job, and the budget and dates absorb work nobody approved.
• Assigning tasks to a team or a department rather than a named person means everyone assumes someone else has it, and the task stalls.
• Listing milestones as if they were tasks, with durations and owners, hides whether the project has reached its checkpoints, so status reports show activity instead of progress.
• Changing scope or dates without re-baselining the plan and recording who approved the change leaves the plan out of step with reality and starts arguments later about who agreed to what.

Frequently asked questions

This page explains general practice and is not legal advice. Requirements differ between countries and, in some cases, between states — check what applies where the document will be used.

Related templates

All templates · Management templates