Short answer: A website build is a software project with two extra failure modes: content arriving late and stakeholders adding scope after sign-off. Run it in four phases (discovery, design, build, launch), keep iterations to two weeks once build starts, and have one PM who owns the order and one client-side owner who has authority to approve. Most failed website projects don't miss deadlines because the work was hard. They miss deadlines because nobody owned a decision.
Website development project management is when you take a website from a one-line brief to a live URL without incinerating the budget, the team, and the relationship with the client. This method of software project management has “content arriving late” and “scope added after signoff” built in as extra failure modes. The values from the Agile Manifesto still apply — customer collaboration, responding to change — but with two website-specific traps wired on top.
This guide discusses what a website project is like, how the four phases run in reality, and the two stakeholders who kill more web builds than any other variable, along with the rules that keep a website project on track. Target Audience: digital agencies, independent designers and developers, and in-house developers who build websites for clients.
A website project, plainly
A website project delivers a working website at live URL. All the other work (such as design files, asset libraries and internal documentation) is plumbing. Deliverable is the URL.
In practice, it consists of a few things.
- Discovery — what the website is for, who it's for, what success looks like, what the content will be.
- Design — visual identity, page layouts, interaction patterns, prototype.
- Build — engineering the design into a working website, populated with the real content.
- Launch — DNS, redirects, analytics, hand-off, the first iteration of fixes.
The phases are not neat; there are overlaps between the work. The design phase does not finish before build and discovery does not finish at week 3. Launch has a long impact. That being said, the four phases are a useful vocabulary with which to describe project maps. You’ll find that most project plans that do work are roughly mapped onto the agile continuum rather than running pure waterfall.
What makes website work different from generic software is the dependency on the content. Most website builds run late as copy, photography and brand assets arrive later than the design assumed. The engineering seldom goes beyond. The content always delivers. Prepare in advance.
The four phases, in real terms
Typical mid-size website 5–25 pages compressed timeline.
| Phase | Duration | What happens |
|---|---|---|
| Discovery | 1–2 weeks | Brief, audience, sitemap, success metric, content plan |
| Design | 2–4 weeks | Wireframes, brand alignment, page designs, prototype review |
| Build | 4–8 weeks | Engineering, CMS setup, content population, QA |
| Launch | 1–2 weeks | DNS, redirects, analytics, training, first-fix sprint |
Some important observations.
Many projects skip the discovery phase or give it little time. A two-week period saves two months of build. Many teams simplify it to having a brief and suffer the build re-work cost due to it. The costliest place to fail is in the market with live users.
Design and build have overlapping timelines. By the time a design system is ready, the first build sprint is already in progress. The biggest anti-pattern that kills website projects is waterfall, and trying to "finish design before starting build" is waterfall.
The build process is based on iterations. Each iteration lasts a fortnight, ending with a sprint review where the client views progress. Typically, the homepage is made to work by the first iteration. Template pages and CMS configuration gets applied on top in later iterations. If two weeks feels arbitrary, choosing the right iteration length walks through the tradeoffs.
Coming Soon: We need to redefine our understanding of a project and its phases and how post-launch work is just as important as pre-launch efforts in creating a better product. Make provision for it.
Content often delays other processes more than design or engineering do. If there isn’t a deadline set for content, it’ll come in the night before launch. Treat the content workflow as a project and not as an input.
Discovery — the cheapest place to fail
When a website project fails, the biggest cost is the months of design and engineering spent in the wrong direction. Discovery is where we figure out what to build before moving pixels.
A genuine finding produces a website.
- A clear definition of "win". Not "increase brand awareness". A measurable number with a deadline — 3% conversion rate on the contact form within 60 days of launch. Without this, every design decision is taste.
- The audience, named and specific. Not "small business owners". Pat, 38, runs a 12-person agency, wants a Trello replacement, won't read more than three lines before bouncing. Audience drives every later decision.
- A sitemap. What pages exist, what hierarchy they sit in, what the user journey is between them. Sitemap before design; design before build. (For more on this conversation, see the project management ground rules.)
- A content plan. Who writes what, by when. This is the single most under-planned artifact in website projects. Treat it as a parallel project with its own milestones.
When you miss the customer discovery phase and jump right into designing, the designs will be wrong, the builds will be redone, and the client will wonder why it slipped. People working in creative industries felt getting a brief for end products reduces subversion. Often, designers that resist discovery are those who have worked in the past on unconsumable things.
Design — overlap, don't sequence
The classic blunder on a website project is to treat design as a phase that has to finish before build can start. In real-world application, the design system and the build interweave.
The operation involves a rhythm.
- Week 1–2 of design: wireframes for top-of-funnel pages, brand alignment. Build team starts on infrastructure (CMS, repository, CI, basic templates).
- Week 3–4 of design: detailed page designs for two or three priority templates. Build team converts the first template to working code.
- Week 5+: design moves into edge cases and component variants; build runs templates and content population in parallel.
The design team consider build to be the consumer of their work; the build team treats design as a stream of inputs, not a frozen deliverable. The hand-off discussion occurs every week, not once.
Tools are less important than practice. Combining Figma with a tracker that has story-level acceptance criteria is superior to any “design-to-code” integration. The issue is communication, not file format.
Build — iteration-based, content-aware
The build phase determines whether website projects will stay on schedule or slip. The activities.
Work is delivered to the client regularly every two weeks. A Figma file wouldn’t cut it. Staging URL Contains Real Pages. If your client has not laid hands on the working site by the end of week 2 of the build, trouble is coming.
The scope should be at story-level rather than page-level because a page is too big to be a story. Separate "homepage" into "homepage hero", "homepage feature grid", "homepage testimonials" and "homepage CTA". Each of it has a story. Allget accepted from different teams. To learn more about this, see principles of effective story writing.).
Forecast using the velocity of your team and not deadlines. When the team has outputted two iterations of observed velocity, the forecast for the date of launch is reliable. Prior to that, the date is merely a guess. Never take a date on which you can’t back. Velocity is a measure of pace, not productivity — use it to project, not to whip the team.
The client is responsible for providing you content such as copy and photos. Manage these independently in the same backlog as stories. If the content is late, then this is as much of a blocker as a broken staging. Consider it like that.
Testing and quality assurance occurs within the iteration cycle and not towards its completion. Each story has client acceptance before completion. It is in the “QA phase” at the end of the project, in which website build slips by three weeks; if we accept in-iteration, that will prevent most of it.
The two stakeholders who kill more web builds than missed deadlines
Two patterns repeat themselves after observing builders of websites for twenty years as they miss deadlines. Neither engineering challenges but stakeholder challenges.
A senior stakeholder, usually either the founder or marketing lead, who signed off on the brief in week 1 and who doesn’t engage again until late in build (generally the launch week). By week 8, they’ll be checking the staging site, viewing reams of functionality, and saying: “this isn’t what I expected.” The effort of the team has been notable; but the project will have to be redone.
To fix this, there should be a single client-side owner who can approve. Not a stakeholder group. A single human, reachable by the team, empowered to say yes/no. The purpose of sprint reviews is to ensure that progress is visible to the product owner every two weeks, allowing them to catch any misalignment that may exist. If reviews are missed, the project lacks ownership and thus will not ship on time.
The scope that the committee grows after sign-off A new stakeholder joins in week 5 and just wants to add a small newsletter signup. A senior executive observed a competitor and decided we need a careers page. Every request is small. The compounding effect effectively adds three weeks and annihilates the schedule.
An explicit scope-change rule agreed at brief sign-off is the fix. Any request received post-acceptance entry will be recorded in an icebox for consideration during the next iteration. The icebox and the conversation belong to the PM. There’s a longer write-up on how to respond to new ideas mid-project that runs through the same discipline. Missing the rule leads to unrestrained scope growth in tandem with client requests, outrunning the team’s production pace. The Atlassian guide to backlog grooming is a decent reference for keeping the icebox triaged rather than abandoned.
The solutions provided are not technical, but rather organizational. Only the implementation of the project management practice can do justice to the discipline of project management. The backlog can be held by the tool; the discipline must be from the team.
Frequently asked
What is project management for website development?
The process of getting a website from brief to live URL, on time and budget. This is flavor of software project management which comes with two additional failure modes – late arrival of content and growth of scope after sign-off. The five phases are discovery, design, build, launch, and they overlap in practice, not run sequentially.
How long does a website project take?
A mid-size website of 5-25 pages can take 8-16 weeks to launch. More customized constructions take a minimum of 4-6 months. Content readiness is the biggest schedule variable; teams that block on copy and photography regularly slip 30–50%.
What's the best methodology for website development?
Agile with bi-weekly iterations. At the end of each iteration, the client can see real working pages live on staging. The most common anti-pattern being deployed today as well as the most reliable way to ship late is Waterfall (full design, then full build, then full QA).
Who owns a website project?
Agent/Build side, Client side 1x PM each with authority to approve decisions. Non-collaborative committees. One of the key factors in slippage of website projects is having many decision-makers and no owner.
What's the biggest mistake in website project management?
View content as an input not a parallel project. More often than not, web builds slip through the cracks due to copy, photography, and brand assets arriving later than was originally assumed in the design. Map out how the various content pieces will flow from one to the next with milestones of their own. Don't simply add one item in the overall schedule of "client provides content".
How do you handle scope creep on a website project?
Decide on a scope change regulation during brief sign-off. Any new requests that come after sign-off goes to the icebox and is considered later for post-launch iteration. The PM is in charge of the icebox. Due to violation of this rule, scope grows faster than the team can build and launch date keeps moving.
What's the right team for a website build?
A standard project team comprises one PM, one Designer, one or two Engineers, one Content Lead, and one Decision Maker. Larger projects require more designers and engineers. Reduction in roles for small projects. The PM and the client-side owner are the two immovable roles.
Should website projects use sprint planning and retros?
Certainly! Two week time-boxes with a planning at the start and retro at the end. If no one beyond the team is consistently present, skip the sprint review. The retro is the single most important meeting; teams that skip retro stop improving.
Still stuck
For most sites, you can expect the project will ship on time if your team has one PM, one client-side owner, a two-week iteration cadence and a content plan tracked as its own backlog. The remaining part is hygiene.
LiteTracker is a tool that holds stories, points, and accepted-only velocity in one place while surfacing blockers fast enough to prevent content killing the schedule. You can add unlimited users in the Free version. Import takes a minute. Use this if you're not looking for design output and just want code. The forcing function serves the teams.
Write the Content Brief in Week 1. Unless you want to pay for it in Week 8.