To write a project plan, agree on the outcome, define deliverables, break the work into tasks, estimate the people and money needed, and build a realistic schedule. Then document risks, quality checks, communication and approvals so the team knows how delivery will be managed.
This guide takes you through ten planning steps, using an illustrative six-week website project. You can adapt the same approach to a software release, an internal improvement or a client engagement. The example figures are planning assumptions, not benchmarks or promised results.
What is a project plan?
A project plan describes how a project will be delivered, monitored and controlled. It connects scope, schedule, budget, responsibilities and decision rules. Depending on the project, these details may live in one document or in linked documents and a task board.
A project charter authorizes the project and establishes its high-level direction. The detailed plan develops how the team will deliver that direction. A schedule is one part of the plan: dates alone do not explain scope, acceptance, risks or decision authority.
New to these concepts? Start with our beginner guide to learning project management. For the broader delivery context, see the eight essential project management processes.
How to write a project plan in 10 steps
Work through these steps with the people doing and approving the work. Revisit earlier estimates when later discussions expose a constraint. Planning continues during delivery as assumptions are tested and changes are agreed.
Step 1: Agree on the business outcome
Describe the problem, the intended benefit and how success will be checked. Separate the deliverable from the outcome: launching a website is a deliverable; enabling customers to send usable enquiries is an outcome.
Example: Launch a five-page service website within six weeks. At acceptance, a customer can submit an enquiry, the business receives it, and a named person owns the response process. Set any traffic or lead targets separately with a measurement period and baseline.
Write down: the business need, measurable success criteria, sponsor and major constraints. Confirm that the project has the authorization needed before committing significant resources.
Step 2: Identify stakeholders and decision owners
Identify the sponsor, users, delivery team and external suppliers. Ask who supplies requirements, who reviews work and who accepts the finished result. Give each deliverable an accountable owner and identify the person who resolves conflicting requests.
Example: The business owner approves scope and spending; the designer owns layouts; the developer owns implementation; a business reviewer accepts the enquiry workflow. Agree how quickly each reviewer can respond.
Write down: names or roles, responsibilities, approval authority and review availability. A list of people without decision responsibilities will leave gaps.
Step 3: Define scope, deliverables and acceptance
State what is included and excluded. Describe outputs in terms someone can inspect. Record assumptions and dependencies, including content, credentials and supplier access that must be provided by others.
Example: Include Home, About, Services, FAQ and Contact pages, responsive layouts and an enquiry form. Exclude online payments, customer accounts and multilingual content. The client supplies approved copy and images by the end of week one.
Write down: deliverables and acceptance criteria. For the form, acceptance could require validation, confirmation to the visitor, delivery to the agreed inbox and successful tests on the agreed devices.
Step 4: Break deliverables into manageable work
Create a work breakdown structure or a practical task list. Include reviews, testing, content entry, deployment and handover. Tasks should be small enough to estimate and check, with a clear owner and completion condition.
Example: Break the Contact page into content approval, layout, form implementation, notification setup, testing and business acceptance. “Build website” is too broad to reveal these dependencies.
Write down: work packages, owners, dependencies and the evidence that each package is complete. Use our project management terms guide if the terminology is unfamiliar.
Step 5: Estimate effort, resources and budget
Estimate with the people who will do the work. Distinguish effort from elapsed time: a task requiring eight hours may take several days when its owner is shared across projects or waiting for a review.
Illustrative budget: 40 development hours at ₹1,000, 20 design hours at ₹1,000 and 10 testing hours at ₹800 total ₹68,000. Add ₹7,000 for agreed tools and hosting and an explicitly approved ₹10,000 contingency allowance: a planned total of ₹85,000. These are example inputs, not market rates; taxes and recurring charges must be handled explicitly in a real budget.
Write down: estimating assumptions, availability, rates, purchases, reserve ownership and spending limits. Review the estimate when scope or capacity changes.
Step 6: Build a dependency-based schedule
Sequence tasks around prerequisites and available capacity. Put review and approval time into the schedule. Identify milestones that show completed outcomes rather than time passing.
Example: Week 1 covers requirements and approved content; week 2 covers design review; weeks 3–4 cover implementation; week 5 covers testing and fixes; week 6 covers business acceptance, launch and handover. This outline is feasible only if the detailed estimates, parallel work and reviewer availability support it.
Write down: task dates, dependencies, owners, milestones and the effect of a delayed input. If approved content arrives late, discuss the impact instead of silently removing testing time.
Step 7: Plan risk responses and contingencies
Identify uncertain events that could affect the outcome. For each important risk, record likelihood, impact, an owner, a response and a trigger for action. Keep current problems in an issue log so they receive action rather than remaining hypothetical risks.
Example: Client copy may be late. The response is an early content checklist and an agreed review date. If copy is not approved by that date, the project manager escalates the schedule impact and options to the sponsor.
Write down: the risk register, response owners, escalation triggers and agreed use of contingency. Avoid adding a reserve without explaining what uncertainty it covers.
Step 8: Define quality checks and handover
Specify how deliverables will be reviewed and accepted. Include functional tests, relevant accessibility checks, supported devices, business approval and operational readiness. Decide who supports the result after launch.
Example: Test enquiry delivery, page links, mobile layouts and the agreed content. Confirm backup and recovery arrangements, access ownership, support contact and training before the website is handed over.
Write down: the review checklist, acceptance evidence, defect handling and handover responsibilities. Passing a developer’s test and gaining business acceptance are separate checks.
Step 9: Agree on communication, tracking and change control
Set a reporting rhythm that fits the project. Specify where the current plan is stored, how decisions are recorded and what requires escalation. Define how proposed changes will be assessed for scope, effort, cost, risk and schedule impact.
Example: Hold a weekly delivery review and a short checkpoint during launch week. A request to add online payments is assessed as a scope change, with an estimate and sponsor decision recorded before implementation.
Write down: meeting cadence, status measures, escalation thresholds, change approver and decision log. Use an approved revision to update baselines when required; keep the original commitments traceable.
Step 10: Review, approve and maintain the plan
Walk through the integrated plan with the team and sponsor. Check that scope fits the available budget and capacity, acceptance criteria are testable and dependencies have owners. Record approval and the agreed reference version.
Example: The sponsor approves version 1.0 of the scope, six-week schedule and ₹85,000 illustrative budget. The team tracks delivery against those commitments and raises changes when assumptions no longer hold.
Write down: approvers, approval date, version, unresolved decisions and the next review date. Approval establishes an agreed starting point; it does not end planning.
A project plan checklist you can reuse
Copy these prompts into your document or project workspace. Keep the detail proportional to the size, uncertainty and consequences of the project.
- Purpose: What problem are we solving, and what outcome will we measure?
- Scope: What will we deliver, exclude and accept?
- People: Who owns delivery, reviews, approvals and support?
- Work and dates: What tasks, dependencies and milestones are agreed?
- Resources and money: What capacity, estimates, purchases and reserves support the work?
- Uncertainty: What assumptions, risks and issues need attention?
- Quality and handover: What evidence proves readiness and acceptance?
- Control: How will we report progress, escalate and approve changes?
- Approval: Which version was agreed, by whom and when?
How to track the plan during delivery
Start with deliverables accepted, milestone progress, actual spending, unresolved issues and upcoming decisions. For a small project, a maintained task board and a short status report may be sufficient.
Where earned value management is appropriate, use EV for the budgeted value of completed work, PV for the budgeted value scheduled by the reporting date and AC for actual cost. CPI = EV ÷ AC and SPI = EV ÷ PV, where the denominators are nonzero. These indicators depend on a credible baseline and consistent progress measurement.
Illustrative checkpoint: EV of ₹30,000, AC of ₹35,000 and PV of ₹40,000 give CPI ≈ 0.86 and SPI = 0.75. The work achieved costs more than its budgeted value and is below the planned value at that point. Investigate task dependencies and remaining work before forecasting a finish date; SPI alone does not tell you how many days late a project will be.
Common project planning mistakes
- Using a date list as the whole plan: include owners, acceptance, dependencies and decisions.
- Assuming full-time availability: account for other work, leave and reviewer capacity.
- Leaving content and access to the last minute: treat external inputs as scheduled dependencies.
- Hiding uncertainty: state assumptions and agree responses when they fail.
- Updating commitments without agreement: record the impact and approval of material changes.
Adapting the plan for agile work and AI support
For agile or hybrid delivery, maintain the outcome, constraints, responsibilities and review rhythm while refining near-term work in more detail. A prioritized backlog and release forecast can support the plan. State which commitments are fixed and which can evolve through feedback.
AI can help organize notes, draft a checklist or suggest questions about dependencies. Validate every estimate and assumption with the team, use only data approved for the tool and keep accountable people responsible for decisions. See our article on AI in project planning for a related discussion.
Start with the next decision
Write a first draft around one real project. Ask the team to challenge its assumptions, ask the sponsor to resolve the outstanding decisions and agree how the plan will be maintained. A useful plan gives people enough clarity to act and enough visibility to respond when conditions change.
Further reading
For additional grounding, consult PMI’s explanation of the project charter and APM’s introduction to project planning.
The video below offers another explanation of project planning.
