What a project plan should answer
- What result is the project expected to produce?
- What is inside and outside the scope?
- Who owns each deliverable?
- Which milestones, dependencies, and risks can change the schedule?
- How will stakeholders receive updates?
Copyable Markdown project plan template
# Project plan: [Project name]
**Owner:** [Name]
**Sponsor:** [Name]
**Status:** Draft
**Start date:** YYYY-MM-DD
**Target completion:** YYYY-MM-DD
## Summary
[Explain the project, problem, and intended result.]
## Objectives and success measures
| Objective | Measure | Target | Measurement date |
|---|---|---:|---|
| [Objective] | [Metric] | [Target] | YYYY-MM-DD |
## Scope
### In scope
- [Deliverable or activity]
### Out of scope
- [Explicit exclusion]
## Deliverables
| Deliverable | Owner | Acceptance criteria | Due date | Status |
|---|---|---|---|---|
| [Deliverable] | [Name] | [Completion condition] | YYYY-MM-DD | Not started |
## Milestones
| Milestone | Target date | Dependency | Status |
|---|---|---|---|
| [Milestone] | YYYY-MM-DD | [Dependency] | Not started |
## Work plan
- [ ] [Task] · **Owner:** [Name] · **Due:** YYYY-MM-DD
## Risks
| Risk | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|
| [Risk] | Low/Medium/High | Low/Medium/High | [Response] | [Name] |
## Communication plan
| Audience | Update | Channel | Frequency | Owner |
|---|---|---|---|---|
| [Audience] | [Information] | [Channel] | [Cadence] | [Name] |
## Change log
| Date | Change | Reason | Approved by |
|---|---|---|---|
| YYYY-MM-DD | [Change] | [Reason] | [Name] |
Tailor the template
For a small project, keep summary, objectives, scope, deliverables, risks, and owners. For regulated or cross-team work, retain approvals, change log, dependencies, and communication plan.
Write measurable acceptance criteria
Avoid deliverables such as “improve onboarding” with no completion condition. State what will exist and how it will be checked. For example: “Publish the five-step onboarding flow, pass keyboard testing, and reduce median completion time below four minutes in the agreed usability test.”
Treat a milestone as a meaningful state, not a list of routine tasks. “Design approved” and “10% production rollout completed” are milestones. “Hold meeting” is usually an activity.
Maintain the plan
Review the plan on a fixed cadence. Update status from evidence, add approved scope changes to the change log, and close risks only when the condition no longer applies. If a date moves, record the dependency or decision that caused it instead of silently replacing the old target.
Completed project-plan example
For a documentation migration, a measurable objective might be: “Move 120 published guides to the new system by 30 November, preserve every indexed URL and keep post-launch 404s below 0.5%.” Deliverables would include the migrated pages, redirect map, QA report and rollback plan. “Work on documentation” is an activity, not a measurable outcome.
Project plan versus project schedule
A schedule lists dates and tasks. A project plan also explains objectives, scope, ownership, acceptance, dependencies, risks and communication. Keep a detailed task board separately when the plan would otherwise become difficult to read.
Project plan FAQ
Who should write the project plan?
The accountable project owner should maintain it, with estimates and dependencies confirmed by the people doing the work.
How often should it be updated?
Update it whenever scope, milestones, ownership or material risks change. Review it on the same cadence used for status reporting.
Should completed tasks remain in the plan?
Keep milestone and change history, but move detailed completed tasks to the task system. The plan should stay useful as a current control document.