How to Write a Project Plan: 12 Checkable Blocks

Why Most "Project Plans" Are Just Task Lists

Ask six people on the same project what the plan is and you get six answers: the Gantt chart, the spreadsheet, the contract, the email thread, "the thing in Teams". That is the problem a project plan actually solves — not scheduling, but producing one agreed, checkable description of what "done" means, who owes it, and what it is allowed to cost.

The infographic this article is built on splits that description into twelve blocks. As a checklist it is long. As a structure it is five questions — what are we doing, by when, with whom, for how much, and what happens if it goes wrong — each answered with an artefact you can hand to an auditor, a customer or a supplier.

Twelve blocks, four movements: initiate (1), define and plan (2–9), run and watch (10–11), close (12).

1. Initiation: Earn the Right to Plan

Five artefacts: business case, project charter, stakeholder identification, objectives, kick-off meeting. The charter is the one that matters, because it is the only document that says what the project is not.

Objectives are the classic four constraints — scope, time, cost, quality — and the infographic puts a condition on each: scope clear, objectives aligned, charter approved. If any of the three is missing, planning is wasted effort: you will produce a precise plan for a project nobody agreed to. The kick-off is not a ceremony; it is the moment the four constraints are said out loud in front of the people who will be held to them.

2. Scope: Turn Intentions into Acceptable Nouns

Scope statement, deliverables, work breakdown structure (WBS), scope baseline, requirements gathering — five artefacts, one flow: collect requirements → define scope → create WBS → validate scope → sign-off.

The WBS is where projects are usually lost. A work package called "improve the process" cannot be estimated, cannot be assigned, and cannot be verified. The infographic splits a project into three phases with two work packages each, and then states the counts: 28 deliverables, 45 WBS elements. Those two numbers are the plan's real skeleton — 45 elements is the smallest unit you can estimate, staff and accept.

A rule that survives contact with auditors: the leaf of a WBS is a noun you can inspect, not a verb. "Containment stock sorted" is a leaf. "Handle containment" is a mood.

3. Schedule: Everything Is Not on the Critical Path

Activity definition, sequencing, duration estimation, milestones, critical path. The schedule has two views — the Gantt chart people look at, and the network diagram that actually determines the finish date.

In the example: 36 days total, 7 milestones, critical path 18 days. The gap between 18 and 36 is the whole point of the exercise. Only the critical path has no float: every day lost there is a day lost on the project. Everything else can slip inside its own float without moving the end date — which is exactly what a project manager needs to know on the morning something goes wrong.

Milestones deserve their own discipline: they must name a verifiable state, not an activity. Start, design complete, build complete, testing complete, go live — five states, each one a signature. "Phase 1 done" is not a milestone; it is an opinion.

4. Resources: The Week Where Everything Collides

Human resources, equipment, materials, allocation, team roles — and then the artefact that separates a plan from a wish: the resource loading chart.

The example runs 15 team members, 960 hours of total demand, 82% utilisation, spread over six weeks. The chart is read vertically, not horizontally: the question is which week has more demand than people. A plan that averages 82% utilisation can still have one week at 140% — and that week sets the real finish date. Under 85% average is usually a plan; over 95% is usually a story.

5. Cost: Three Numbers and One Conclusion

Budget estimation, cost baseline, cost forecasting, earned value. The infographic shows the S-curve — planned value, earned value, actual cost — and six figures: BAC $850K, PV $540K, AC $486K, CPI 1.12, SPI 1.05, EAC $910K.

The three definitions that make earned value usable:

• PV — what the plan says should be finished by now, valued at budget.
• EV — what is actually finished, valued at the same budget rates.
• AC — what has actually been spent.

CPI above 1 means you are buying more work per dollar than planned; SPI above 1 means you are ahead of schedule. Both are ratios about the past. The decision number is EAC, the forecast of the final bill — because a project can be efficient for nine months and still end over budget.

One caution the example illustrates by accident: CPI 1.12 and EAC $910K cannot both come from the same earned-value data (with BAC $850K, CPI 1.12 forecasts roughly $759K). Real dashboards produce this combination constantly, and it always means the same thing — EV is being taken from different places in different cells. Before you read the traffic lights, check that all six numbers were computed from one EV snapshot.

6. Risk: Convert "What If" into Money

Identification, analysis, mitigation planning, contingency reserve — plus the two artefacts that make risk auditable: the probability × impact heat map and the overall risk exposure.

The example carries 5 high, 7 medium and 6 low risks, with a total exposure of 12% of budget. That second number is the useful one. "We have a risk register" is not a control; "we are holding 12% of budget against identified risks, owned by these three people" is. A reserve with no named risk attached is not a reserve, it is an unallocated budget line waiting to be consumed silently.

7. Quality: Write "Good" as a Criterion

Quality standards, procedures, KPIs, continuous improvement — the PDCA loop with quality in the middle. The example commits to 0.6% defect rate, 98% quality score, 98% process compliance.

Two of those three are leading indicators and one is a result; a quality plan needs both kinds. The practical content of the section is three lists: which standard applies, who measures what at which gate, and what happens to a nonconforming deliverable. Without the second list, "quality planning" is a paragraph of intent.

8. Communication: Events, Not Vibes

Information requirements, message channels, communication matrix, stakeholder matrix. The channels are emails, reports and dashboards; the frequencies are weekly, bi-weekly, daily and real-time.

The unit of a communication plan is a row: event + audience + channel + frequency + owner. "Keep stakeholders informed" is not a plan; "project team, weekly, dashboard, Monday 09:00, PM" is. The matrix also decides what not to send — most meeting load is a communication plan that was never written.

9. Procurement: Contract Type Is Risk Allocation

Vendor selection, contract drafting, purchase schedule, procurement risks. The flow: source → evaluate and select → negotiate and contract → approve → close and review. Four contract types appear, and they differ mainly in who carries the change risk:

The example runs 4 active contracts, 12 vendors engaged, 10% savings target. The savings target is a plan number only if the contract types were chosen to make it reachable.

10. Stakeholders: Interest × Influence

Stakeholder analysis, power-interest grid, engagement strategy, influence mapping. Twenty-five stakeholders sorted by interest and influence give four strategies: manage closely (high/high), keep satisfied (high influence, low interest), keep informed (high interest, low influence), monitor (low/low).

The engagement ladder in the graphic — inform, consult, involve, collaborate, support — is more useful than the grid alone, because it names the level of involvement rather than the tone of the relationship. A regulator at "keep satisfied" and a line operator at "keep informed" both get what they need; swap them and both are unhappy.

11. Monitoring and Control: One Data Set, Three Verdicts

Performance tracking, change control, corrective actions, forecasting. The indicators are CPI, SPI and a quality index — 1.05, 1.12, 0.98 in the example — alongside issue status (open, in progress, resolved, closed), 6 change requests, 5 open issues, 92% on track.

The section only works if the numbers come from one snapshot on one day. Change control is the other half: a change without a change request is not a change, it is drift — the same failure mode quality engineers know from production, where the process quietly differs from the SOP and nobody records it. Six change requests is a healthy number for a project of this size. Zero is a warning sign, not a compliment.

12. Closure: "Done" Means Signed

Final deliverables, lessons learned, sign-off, handover, closure checklist. The example reports 100% on time, 98% on budget, 95% user satisfaction.

A closure checklist is short and unforgiving: deliverables accepted, documentation complete, client signed, contracts closed, team released, lessons captured. The last item is the one that pays for the next project — a lessons file nobody can find is the same as no lessons file.

The Twelve Blocks on One Page

What This Has to Do with 8D and APQP

The twelve blocks are not a project-management ritual imposed on quality work — they are the same structure APQP already asks for. Phase gates are initiations and scope baselines; the control plan is a quality plan; PPAP is a closure checklist with signatures. What quality engineers usually miss is narrower than "planning": the WBS leaf that nobody can inspect, the reserve with no named risk, and the change that was never raised. Those three produce the same failure in projects that "nothing changed" produces in 8D.

The relationship is worth stating plainly: a project plan turns failures that have not happened yet into clauses; an 8D turns a failure that has already happened into a cause. Both are cheaper than the third option, which is finding out in production.

The framework in this article follows the twelve-block "How to Write a Project Plan" infographic published by Template22; the numbers are that graphic's illustrative example, not a real project, and the reading cautions are ours. Adapted and rewritten for quality-engineering practice.