How to create a project plan

What is a project plan?

• A project plan is the agreed answer to four questions: what we are delivering, in what order, by when, and who decides what.
• It is not a single Gantt chart. The schedule is one component; scope, budget, risks, roles and communication cadence are the rest.
• A plan is a baseline, not a prediction. Its value comes from being the reference point you measure change against.
• Right size beats complete: a two-page plan that the team actually reads outperforms a fifty-page document nobody opens.

Short answer: a project plan is the agreed statement of scope, sequence, cost and accountability that you measure change against. New to the discipline? Start with what project management is.

How to create a project plan in 8 steps

Work the steps in order. Each one produces an output that the next step depends on, so skipping ahead to dates is the fastest way to a plan nobody can defend.

1. 1

   Fix the objective and success measures

   Answers: Where do I start a project plan?

   Write down the measurable outcome before touching any dates.

   • State the problem in one sentence and the outcome in a number (cost, time, revenue, quality, adoption)
   • Name the sponsor who can say yes to money and the decision-makers for scope
   • Write two or three success criteria you could audit after go-live
   • Capture assumptions and constraints — these become your first risks

   Output: Signed charter with objective, success measures and named sponsor

   Half a day for most projects

   Project charter template
2. 2

   Define scope in and out, then decompose it

   Answers: How do I define the scope of a project plan?

   Turn the outcome into deliverables small enough to estimate and assign.

   • List deliverables, then explicitly list what is out of scope — the out list prevents most disputes
   • Break each deliverable into work packages of roughly 8 to 80 hours
   • Give every work package a single owner and a definition of done
   • Stop decomposing when you can estimate a package with confidence

   Output: Work breakdown structure with owners and acceptance criteria

   One to two workshops with the delivery team

3. 3

   Estimate effort and duration honestly

   Answers: How do I estimate how long a project will take?

   Produce ranges, not single numbers, and record the basis of each estimate.

   • Estimate effort first, then convert to duration using realistic availability (60 to 70 percent, not 100)
   • Use three-point estimates for anything unfamiliar: optimistic, likely, pessimistic
   • Have the people doing the work estimate it, and record the assumptions behind each number
   • Keep contingency visible as a named reserve rather than padding individual tasks

   Output: Effort and duration estimates with assumptions and reserve stated

   A day, revisited after the schedule is sequenced

4. 4

   Sequence the work and find the critical path

   Answers: How do I build the project schedule?

   Order the work by dependency, then see which chain actually controls the end date.

   • Link work packages with real dependencies only — avoid inventing sequence to tidy the chart
   • Run a forward and backward pass to calculate float and identify the critical path
   • Protect critical-path tasks with your best people and the least multitasking
   • Add milestones at decision points, not at arbitrary calendar dates

   Output: Baselined schedule with milestones, float and a marked critical path

   Half a day once the WBS is stable

   Calculate the critical path
5. 5

   Assign people, roles and budget

   Answers: Who does what on a project plan?

   Make accountability unambiguous and check the plan is actually staffable.

   • Map every deliverable to exactly one accountable owner using a RACI matrix
   • Level resources: check nobody is booked above realistic capacity in any week
   • Build the cost baseline from effort, rates, licences and third-party costs
   • Agree the approval thresholds for spend and for scope change

   Output: RACI matrix, resourced schedule and cost baseline

   Half a day

   RACI matrix template
6. 6

   Plan for risk, issues and change

   Answers: How do I handle risks in a project plan?

   Decide in advance how surprises get surfaced, owned and resolved.

   • Log the top risks with probability, impact, an owner and a specific response
   • Record assumptions and dependencies alongside risks in one RAID log
   • Define the change-control route: who raises, who assesses impact, who approves
   • Set a review rhythm so the log is a working tool, not an artifact

   Output: Live RAID log plus a one-paragraph change-control process

   Two hours to start, ongoing thereafter

   RAID log template
7. 7

   Agree the communication and reporting cadence

   Answers: How do I keep stakeholders aligned?

   Match reporting to what each stakeholder needs to decide.

   • Map stakeholders by influence and interest, and note what each one needs to know
   • Set one status format and one cadence — weekly team, monthly steering is common
   • Report against the baseline: variance, forecast, decisions needed
   • Escalate with a recommendation attached, never a problem alone

   Output: Stakeholder register and a repeatable status report

   Two hours

   Stakeholder register template
8. 8

   Baseline, then keep the plan alive

   Answers: What do I do after the plan is approved?

   Freeze a reference version and update deliberately, not silently.

   • Get explicit sponsor sign-off on scope, schedule and cost as the baseline
   • Track actuals against baseline weekly; re-baseline only through change control
   • Review the plan at each milestone and capture lessons as you go
   • Close formally: confirm acceptance, release the team, record what to reuse

   Output: Approved baseline, weekly variance tracking and a lessons-learned record

   One hour to baseline, 30 minutes weekly to maintain

   Lessons learned template

What should a project plan include?

Project plan vs schedule vs charter

• Project plan

  Why the work exists, what is in and out, who is accountable, how change and risk are handled.

  Short document plus linked artifacts (charter, RACI, RAID, budget).

• Project schedule

  When each work package happens, in what sequence, and where the critical path runs.

  Gantt chart or task board derived from the WBS.

• Project charter

  Authority to start: problem, objective, sponsor, high-level scope and budget envelope.

  One to two pages, signed before planning begins.

Six mistakes that make a plan obsolete

• Planning to 100 percent resource availability

  Plan people at 60 to 70 percent on project work; the rest goes to meetings, support and context switching.

• Dates first, work second

  Derive dates from estimated, sequenced work. A date handed down before scope is a target, not a plan.

• One giant Gantt chart as the whole plan

  Keep a short plan document; the schedule is one linked artifact among several.

• No named owner per deliverable

  Exactly one accountable owner per work package. Shared accountability is no accountability.

• Risks logged once and never revisited

  Review the RAID log in every status meeting; close risks explicitly and add new ones.

• Silent re-planning

  Change the baseline only through change control so variance stays meaningful.

Frequently asked questions

What is a project plan?

A project plan is the agreed statement of what a project will deliver, in what sequence, by when, at what cost and with who accountable. It bundles the scope statement, work breakdown structure, schedule, cost baseline, responsibility map, risk log, communication plan and change-control process into one reference that the team and sponsor work from.

How do you create a project plan step by step?

Fix the objective and success measures, define scope in and out, decompose the work, estimate effort and duration, sequence dependencies to find the critical path, assign people and budget, plan for risk and change, agree the reporting cadence, then baseline it with sponsor sign-off and track variance weekly.

What is the difference between a project plan and a project schedule?

The schedule answers when work happens; the plan answers why the work exists, what is in scope, who is accountable and how change and risk are handled. The schedule is one component of the plan, derived from the work breakdown structure.

How long should it take to write a project plan?

For a project of three to six months, expect three to five working days of elapsed effort, mostly spent in workshops with the delivery team rather than writing. Larger programmes take longer, but if planning stretches past two weeks without a baseline, the scope is probably too vague to plan yet.

What should a project plan include as a minimum?

At minimum: objective and success measures, scope in and out, a work breakdown structure with owners, a schedule with milestones, a cost baseline, a RAID log and a stated change-control route. Everything else is useful but optional.

How do you create a project plan in Excel?

Use one sheet per component: a task sheet with WBS ID, owner, effort, duration, predecessor and dates; a milestone sheet; a RAID sheet; and a simple bar view driven by start and duration columns. Our free Excel templates already follow this structure, so you can fill them in rather than build from scratch.

Do agile teams need a project plan?

Yes, but a lighter one. Agile teams still need an objective, scope boundaries, a roadmap of releases, accountability mapping and a risk log. What changes is that detailed task sequencing happens per sprint instead of up front for the whole project.