Project Plan Template
A one-document project plan: objective, scope, milestones, tasks with owners and dates, budget, risks and how progress is reported.
Details
project plan templateRed highlights mark what is still blank. Everything stays on this device.
| Project | [project name] |
| Project manager | [name] |
| Start | [date] |
| Target end | [date] |
| Plan dated | September 25, 2026 |
1. Objective
[what the project will achieve, and how you will know it has]
2. Scope
In scope:
[what the project will deliver, one per line]
3. Milestones
| Milestone | Date |
|---|---|
| [one milestone per line — milestone | date] |
4. Tasks
| Task | Owner | Start | End |
|---|---|---|---|
| [one task per line — task | owner | start | end] |
5. Budget
| Item | Amount ($) |
|---|---|
| [one line per cost — item | amount] |
6. Risks
| Risk | Likelihood | Response |
|---|---|---|
| [one risk per line — risk | likelihood | response] |
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.
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.
| Field | What goes in it |
|---|---|
| Project name | For example: Customer portal launch |
| Project manager | For example: Maria Lopez |
| Sponsor optional | For example: David Chen, Head of Operations |
| Start date | Free text |
| Target end date | Free text |
| Objective | For example: Launch a self-service portal where customers can track orders, download invoices and… |
| In scope | One per line |
| Out of scope optional | One per line |
| Milestones | One per line: Milestone | Date |
| Tasks | One per line: Task | Owner | Start | End |
| Budget | One per line: Item | Amount |
| Risks | One per line: Risk | Likelihood | Response |
| How progress will be reported optional | One per line |
How to write a Project Plan
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.
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.
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.
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.
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.
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
What should a project plan include?
At minimum: the project name, manager and sponsor; start and target end dates; one testable objective; what is in scope and what is out; milestones; tasks with an owner and dates for each; a budget broken into lines; the main risks with owners and responses; how progress will be reported; and who approves the plan and any later change to it.
How do I write a project plan?
Start with the objective and the scope, because everything else follows from them. Next set the milestones, then break the work between them into tasks, each with one owner and dates. Price the tasks to build the budget, list what could go wrong and who will handle it, and decide how progress will be reported. Circulate the draft to the people named in it, then get the sponsor's approval.
What is the difference between a project plan and a project charter?
A charter is short and comes first: it authorizes the project, names the sponsor and project manager, sets out the objective and high-level scope, and gives the project manager authority to use resources. The plan comes after it and says how the work will actually be done — tasks, owners, dates, budget, risks and reporting. PRINCE2 uses different names, such as the project brief and project initiation documentation, for similar ideas.
What is the difference between a milestone and a task?
A task is work: it takes time and effort, has an owner and produces something. A milestone is a checkpoint that marks a point reached, such as ‘design approved’ or ‘contract signed’, and takes no time in itself. Milestones let a sponsor see progress at a glance; tasks tell the team what to do next. A plan with only tasks shows activity but not progress.
How detailed should a project plan be?
Detailed enough that every task has one owner and can be finished within a single reporting period, and no more. A two-week office move might fit on one page; a year-long system rollout needs more. Plan the next few weeks in full and later phases in outline, adding detail as they approach. If a task needs a paragraph to explain it, it is several tasks, not one.
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.