How to Write a Project Plan: A Practical Guide
A project plan is the working document that turns “we should do this” into “here is who does what, by when, and for how much.” It takes the promise made in the project charter and breaks it into tasks, dates, people, and money. A good plan is detailed enough that a team member can open it and know exactly what they owe this week.
When to Use This
Write a project plan after the charter is signed, before the team starts delivering work. You need one whenever more than two people are working on something that takes longer than two weeks, for example, a store refit, a software rollout, an office move, or a new product launch. Even experienced teams benefit: the plan is where hidden assumptions surface, like discovering that the designer and the electrician both booked the same week. For very small jobs (a one-week marketing flyer), a simple task list will do instead.
How to Fill It Out
Section 1: Objectives and success criteria. Restate the project’s goals from the charter, then define how you will know the project succeeded. “Objective: launch online ordering. Success criteria: 50 orders in the first month, average fulfilment time under 48 hours, no unresolved customer complaints about the ordering process.” Numbers matter, “successful launch” means nothing without them.
Section 2: Work breakdown. Break the project into phases, then into tasks small enough that one person can own each one and finish it in one to five days. For a website rebuild: Phase 1, Design (homepage mockup, product page mockup, client review rounds); Phase 2, Build (front-end coding, payment integration, testing). If a task feels too big to estimate, split it further. Tasks like “develop website” are too vague; “build checkout page” is right.
Section 3: Schedule. Assign each task a start date, an end date, and an owner. Identify dependencies: which tasks must finish before others start. For example, “payment integration (12–16 May, Tom Reid) depends on test account setup (5 May, Priya Nair).” Mark the milestones from the charter on the timeline. Build in buffer time before the final deadline, a plan that needs every day to go perfectly is a plan that will be late.
Section 4: Resources and team. List everyone working on the project, their role, and roughly how much of their time is committed. “Tom Reid, front-end developer, 50% time, May–July.” Include equipment, software licences, or contractors you need to hire. This section exposes overallocation early: if three tasks all need Tom in the same week, you have a problem to solve now, not in May.
Section 5: Budget breakdown. Split the total budget into categories: staff time, contractors, materials, software, and a contingency reserve of 10–15% for surprises. For a £60,000 project: £32,000 staff, £14,000 contractor fees, £6,000 software licences, £8,000 contingency. Track spend against these categories as the project runs so you spot overruns while there is still time to act.
Section 6: Risks. Carry the top risks over from the charter and add detail: what you will do if each one happens. “Risk: only one person knows the payment system. Mitigation: Tom documents the integration as he builds it; backup developer identified (contractor, quoted £1,200/week).” A risk without a response plan is just a worry.
Section 7: Communication plan. Decide who gets told what, how often, and by whom. “Weekly status email from the project manager to all stakeholders every Friday. Monthly steering meeting with the sponsor. Urgent blockers reported to the sponsor within 24 hours.” Write it down, teams that agree this up front have far fewer misunderstandings about who should have been told what.
Section 8: Approvals. The sponsor approves the plan, confirming the dates, budget, and scope are realistic. Key team members confirm their commitments. Get this signature before the kickoff meeting.
Common Mistakes
1. Planning at the wrong level of detail. Some plans list every half-hour activity; others contain tasks like “phase 2” with no owners. Aim for tasks of one to five days, each with one owner. If you are managing daily, you are micromanaging; if a task runs longer than a week without a check-in, you have lost visibility.
2. Ignoring dependencies. Teams often schedule tasks in a neat sequence without checking what each task actually needs. Ask every task owner: “What do you need from someone else before you can start?” Write down the answers. The most common delay in small projects is waiting on something, a login, an approval, a delivery, that nobody scheduled.
3. No buffer and no contingency. Plans built on best-case estimates slip the moment anything goes wrong. Add buffer time before hard deadlines and keep a contingency budget of 10–15%. If you finish early and under budget, that is good news, not wasted planning.
4. Treating the plan as finished once written. A plan is a living document. Update it when tasks slip, scope changes, or team members leave. A plan from March that no longer reflects reality in May is not a plan, it is fiction. Set a weekly time to update it and review progress against it.
Who Needs to Sign Off
The sponsor approves the plan, they are committing the budget and the dates. The project manager signs to confirm the plan is achievable. Team leads or department heads whose staff are committed sign to confirm those commitments are real. On a typical five-person project, expect three to four signatures.
How Often to Review and Update
Update the schedule weekly, task owners report progress, completed tasks are marked done, and slipped dates are adjusted. Review the full plan (budget, risks, resources) monthly with the sponsor or at each milestone. Re-baseline the plan, get fresh sign-off, whenever the end date moves by more than a week, the budget changes by more than 10%, or a major scope change is approved.
Download the free Project Plan Template.