This website project plan template covers a full 12-week build, phase by phase, with every task, owner, duration and deliverable set out in two tables. Copy them into a spreadsheet, swap in your names and dates, and you have a working plan.

Our website project management guide covers how to run a project day to day. This page is the plan itself.

What this plan assumes

The example is a hypothetical 15-page marketing site built on a CMS.

Scope: homepage, 8 service pages, about, team, contact, a news listing and article template, and one enquiry form. No e-commerce.
Agency team: project manager (PM), designer, developer and QA tester.
Client team: a client lead who signs things off and a content owner who supplies copy.
Reviews: the client returns feedback within 2 or 3 working days, with one round of changes per stage.
Content: final copy is ready by the end of week 8.

If the site needs e-commerce, a custom integration or a URL migration, add 2 to 6 weeks to the Build phase. Do not take that time out of QA.

Days are working days for the task, and tasks in the same week can overlap.

How to set the dates

Work backwards from the launch date and not forwards from kick-off, because that shows you straight away whether the deadline is realistic.

Pick a launch day early in the week and outside the client's busy season.
Count back 12 weeks. That date is your latest possible kick-off.
Check the four gates against bank holidays and the client lead's leave.
Send calendar invitations for all four gates on day one, so the time is held.
Put a real date next to every client task, because "week 5" is easy to ignore.

If the sums leave you short, reduce the page count or move features to a second phase before you compress the plan.

Weeks 1 to 6: discovery, UX and design

Phase	Week	Task	Owner	Days	Deliverable
Discovery	1	Kick-off call	PM	0.5	Agreed goals
Discovery	1	Collect logins and access	Client lead	2	Access list
Discovery	1	Audit current site	PM	2	Content inventory
Discovery	1	Stakeholder interviews	PM	2	Interview notes
Discovery	2	Write requirements document	PM	3	Requirements v1
Discovery	2	Sitemap and user journeys	Designer	2	Sitemap v1
Discovery	2	Gate 1: scope sign-off	Client lead	1	Signed scope
UX	3	Wireframe key templates	Designer	4	Wireframes v1
UX	3 to 4	Client wireframe review	Client lead	3	Consolidated feedback
UX	4	Wireframe changes	Designer	2	Wireframes v2
UX	4	Gate 2: wireframe sign-off	Client lead	1	Signed wireframes
Content	3 to 8	Write page copy	Content owner	25	Final copy
Design	5	Homepage design	Designer	3	Homepage v1
Design	5	Client homepage review	Client lead	2	Consolidated feedback
Design	6	Inner templates, mobile and desktop	Designer	4	Full designs
Design	6	Contrast and focus state check	Designer	0.5	Accessibility notes
Design	6	Gate 3: design sign-off	Client lead	1	Signed designs

The website requirements document in week 2 is the anchor for everything after it, so it is worth the three days.

Save countless hours on your projects

Raise tasks in under 3 seconds using our revolutionary widget

Weeks 7 to 12: build, QA, UAT and launch

Phase	Week	Task	Owner	Days	Deliverable
Build	7	Staging and repository setup	Developer	1	Staging site
Build	7 to 9	Build templates	Developer	10	Templates on staging
Build	8	CMS fields and editor setup	Developer	2	Editable pages
Build	8	Form and integrations	Developer	2	Working form
Build	9	Analytics, tags, cookie consent	Developer	1	Tracking live on staging
Build	9	Enter content	Content owner	3	Populated pages
QA	10	Full QA pass	QA tester	2	Issue log
QA	10	Browser and device testing	QA tester	2	Test matrix
QA	10	Fix QA issues	Developer	3	Closed issues
UAT	11	Client UAT	Client lead	3	UAT log
UAT	11	Fix UAT issues	Developer	2	Closed issues
UAT	11	Gate 4: UAT sign-off	Client lead	1	Signed UAT
Launch	12	Pre-launch checks and redirects	Developer	1	Launch checklist
Launch	12	Go live	Developer	1	Live site
Launch	12	Smoke test on live	QA tester	0.5	Test notes
Launch	12	Client training	PM	1	Training recording
Launch	12	Handover pack	PM	1	Handover pack
Review	16	30-day review against goals	PM	0.5	Review notes

For week 11, our UAT test plan template gives the client something structured to work through. For week 12, the website handover checklist covers everything that goes in the pack.

Weeks 10 and 11 are also when feedback gets messy. QualityHive keeps QA and UAT issues on one Kanban board, each with a screenshot and the exact element pinned, and the agency page shows how client guest links fit in.

Who signs what

Four gates hold the plan together. Work on the next phase should not start until the gate before it is signed.

Gate	End of	Signed by	What it locks
1	Week 2	Client lead	Scope and requirements
2	Week 4	Client lead	Wireframes and page list
3	Week 6	Client lead	Visual design
4	Week 11	Client lead	Approval to launch

Written sign-off can be an email reply, as long as it names the version being approved. Agree the number of revision rounds in the same conversation.

Check it against your budget

Adding up the two tables by role gives you a quick way to test the plan against the budget.

Role	Days in plan	When
Project manager	10	Mostly weeks 1, 2 and 12
Designer	15.5	Weeks 2 to 6
Developer	23	Weeks 7 to 12
QA tester	4.5	Weeks 10 and 12
Client lead	14	Review windows across the project
Content owner	28	Weeks 3 to 9

That is 53 agency days, plus around half a day a week for running the project. The client figures are elapsed time and not full-time effort, but the client still needs to know the time is coming. A content owner with a day job will not write 15 pages in a fortnight.

Adjusting the plan for other projects

Treat these as planning assumptions and check them against your own past projects.

Project	What changes	Length
5-page template site	Drop UX, one design round	6 to 8 weeks
15-page marketing site	This plan as written	12 weeks
Redesign with new URLs	Add redirect map and testing	14 to 18 weeks
E-commerce store	Add products, payments, tax	16 to 20 weeks

Any project that changes URLs also needs the SEO website migration checklist built into weeks 10 to 12.

What to do when the plan slips

Client reviews and copy tend to be what moves a website launch date, because the agency team cannot do anything about either. Put this in the plan from day one:

Schedule dependenciesThis plan assumes each client review is returned within theworking days shown. If a review is late, the launch date movesby at least the same number of working days.Changes requested after a gate has been signed are treated asnew requests and quoted separately.

When you have to recover time, cut scope first. Move Should and Could items to a second phase before you shorten QA or UAT, because defects found after launch cost more to fix and are seen by real customers.

If copy is late, launch with the finished pages and add the rest in phase 2. That is usually better than holding the whole site back for two service pages.

Risks to watch

Risk	Early warning	Response
Content is late	Under half written by week 6	Move pages to phase 2
Reviews drift	Feedback a day overdue	Move launch date in writing
Scope creep	New requests after Gate 1	Quote as a change
Too many reviewers	Conflicting feedback	Route through client lead
Integration blocked	No API access by week 6	Escalate to client lead
Key person away	Leave clashes with a gate	Name a deputy approver

Weekly status update

Send this every Friday. It takes five minutes and stops the "where are we?" emails.

Project: [Name] Week: [n] of 12Status: On track / At risk / LateDone this week:- [Item]Next week:- [Item]Waiting on you:- [Item] by [date]Launch date: [date]

Revolutionise your QA processes

FAQ

What should a website project plan include?

Phases, tasks, named owners, durations, deliverables, sign-off gates and the dependencies that move the launch date. A short risk list and a weekly status update keep it in use after week one.

How long should a website project take?

As a planning assumption, 12 weeks suits a 15-page marketing site with client feedback returned on time. A templated site can take less. E-commerce, integrations and migrations take longer.

Who should own the project plan?

The project manager. One person updates it, normally every Friday, so there is a single version everyone trusts.

What is the difference between a project plan and a requirements document?

A requirements document says what the finished site must do. The project plan says who does what, by when, and what has to be signed before the next phase starts.