Website Project Plan Template

Most website project plans are a list of dates. They say when design starts and when the site goes live, and they say nothing about who supplies the content, what “approved” means, or what happens to the launch date when round three of revisions arrives. Then the project slips, and everyone is surprised by something that was entirely predictable.

A plan that survives a real client does three things a date list doesn't: it names an owner for every deliverable on both sides, it puts an explicit approval gate between phases, and it states in advance what a change costs. Here is that plan as a template, followed by the parts that usually go wrong.

The template

Six phases. Copy it into your proposal or your project tool, fill in the dates and names, and delete what genuinely doesn't apply to the project in front of you.

# Website Project Plan — [client] — [project]

## Summary
- Objective (what this site has to achieve, in one sentence):
- Success measures:
- Launch target:
- Budget / scope basis:

## People
- Agency lead:
- Agency build/design owners:
- Client decision maker (the one who can approve):
- Client content owner:
- Anyone whose sign-off is required but who is not in the weekly call:

## Phase 1 — Discovery
Deliverables: requirements summary, audience and goals, technical
constraints, inventory of existing content and URLs.
Client supplies: brand assets, access to analytics, hosting and domain,
any existing content.
Gate: requirements summary approved in writing.

## Phase 2 — Information architecture and content
Deliverables: sitemap, page-by-page content plan, wireframes for key
templates, redirect map if this is a rebuild.
Client supplies: final copy and images per page, to the agreed deadline.
Gate: sitemap and wireframes approved; content delivered for the pages
in this release.

## Phase 3 — Design
Deliverables: design of key templates at mobile and desktop widths,
component/style definitions, states for forms and errors.
Revisions: [n] rounds included at this phase.
Gate: designs approved. Reopening approved designs after this point is
a change request.

## Phase 4 — Build
Deliverables: templates built and populated, integrations connected,
staging environment available to the client.
Client supplies: any credentials or third-party accounts needed.
Gate: feature-complete build on staging.

## Phase 5 — Review and QA
Deliverables: internal QA pass (see the QA checklist), client review
round, fixes, re-test.
Client supplies: consolidated feedback by [date], in one place.
Revisions: [n] review rounds included.
Gate: client sign-off that the site is approved for launch.

## Phase 6 — Launch and aftercare
Deliverables: DNS cutover, production QA pass, analytics verified,
handover documentation, training session if in scope.
Aftercare: [n] days of bug fixes included, defined as defects against
the approved scope (not new requests).
Gate: project closed, or moved to a support agreement.

## Change control
- A change request is anything not in the approved scope for the
  current phase, or any reopening of a prior approval.
- Each change request is quoted with a cost and a schedule impact
  before work starts.
- Approvals happen in writing from the named decision maker.

## Dependencies and risks
- Content delivery is the most common cause of slippage; the dates
  above assume content lands on [date].
- Other known risks:

Content is the critical path, not the build

Agencies plan around their own work because that is the work they control. But on most website projects the long pole is not design or development — it's waiting for copy, images, product data and the approvals that only one person at the client can give.

That's why the template puts “client supplies” in every phase, with its own deadline. Not as a way to assign blame later, but because a deadline nobody wrote down is not a deadline. A plan that lists agency milestones precisely and client obligations vaguely is a plan that will slip, and it will slip in a way that looks like the agency's fault.

The practical version: make content delivery a dated deliverable with a named owner, and state what moves if it lands late. Not a threat — just arithmetic that everyone has seen before the date arrives instead of after.

Gates are what make phases mean anything

Phases without gates are decoration. If design can be reopened during build, then design never actually ended, and every later phase quietly absorbs the rework.

A gate needs three things: a named person who can approve, a written approval rather than a nod in a call, and a stated consequence for reopening it. That last one is not about being difficult. It is about making the cost visible at the moment of the decision, when the client can still weigh it, instead of three weeks later when it shows up as a delay nobody can explain.

Separate the review round from the QA pass

Phase 5 is two different jobs and the plan should keep them apart. QA asks whether the site works; client review asks whether it is right. Run them together and you get one list where a broken form on Safari sits beside a request for a warmer blue, and both move at the speed of the slower conversation. Our website QA checklist covers the first half; the second half is a scheduling problem.

The review round also has a predictable failure mode: feedback arrives in three channels, some of it as screenshots with arrows drawn on, most of it without saying which page or which browser. Every ambiguous item costs a follow-up, and the follow-ups are what turn a two-day review into a two-week one. Consolidating feedback into one place is half the fix; the other half is letting the client point at the thing instead of describing it. That is what tapko.app does for this phase — the comment lands attached to the element with the URL, browser and screen size already on it, which is most of what the bug report template asks for, captured without asking. The new website build use case covers how that sits inside a launch timeline.

Aftercare, defined before it starts

The window after launch is where margin goes quietly. The client is in the site daily for the first time, finds things, and sends them — a mix of real defects and new ideas, all arriving in the same channel with the same urgency.

Write the distinction into the plan while nobody is annoyed: a defect is the approved scope not working, and it is covered; a new request is a new request, and it is quoted. Also put an end date on the window, because an aftercare period with no end is a support contract you are not being paid for. Those hours are real, and they rarely appear on anyone's timesheet.

Keep the plan one page long

A thirty-page plan is a document that gets written once and read never. Everything in the template above fits on a page or two on purpose, because a plan only works if people actually look at it mid-project — and the two things they look for are what they owe next and what happens if it is late.

Detail belongs in the tracker, where it can move. The plan is the agreement, and an agreement that nobody can hold in their head is not doing its job.

Most website projects don't slip because someone was slow. They slip because a decision had no owner, an approval had no gate, or a change had no price — all of which are cheap to write down in advance and expensive to argue about later. That is the entire value of a plan. The dates are the part everyone reads; the ownership is the part that makes them hold.