In twelve years of managing websites, I have never seen a project die from one big mistake. They die from ten small ones, each of which looked like somebody else’s job.
The research on large projects is brutal. Bent Flyvbjerg, who has studied more of them than anyone alive, told the BCG Henderson Institute that 99.5 percent of major projects fail to deliver their targeted results on time and on budget. McKinsey and Oxford, across 5,400 IT projects, found the average one ran 45 percent over budget and delivered 56 percent less value than promised. Seventeen percent became what they called black swans, with overruns above 200 percent.
Website projects are small enough that everyone assumes they are immune. They are not. They fail the same way for the same reasons, at a scale nobody writes a case study about. The reason is not bad estimating. It is that the scope was measured in the wrong units, and the things that actually consume the budget were never on the list.
If you are the client, not the PM: skip to the ten questions at the end, then come back. If your project team cannot answer them, this article is about your project.
Why every website project plan is wrong before it starts, and the two-minute fix
In 1994, three psychologists asked students when they would finish their honors thesis. Average guess: 33.9 days. Average reality: 55.5. The study named the effect the planning fallacy, and it has been replicated on tax returns, software, and bridges. People plan from the inside, imagining the work going right. They never ask how the last ten similar projects actually went.
Flyvbjerg’s answer is called reference class forecasting, and the website version takes two minutes. Write down your last five sites: planned weeks, actual weeks. Divide. That number is your multiplier, and it is a better estimate than anything in the proposal.
The scope is written in pages. The budget is spent in decisions.
Every proposal describes scope as a page count, a feature list, a number of templates. That is what the client can picture. It is also almost unrelated to what the project will cost.
What a website consumes is decisions. Which navigation. Whether the phone number goes in the header. Whether returns are accepted on handmade items. Who writes the About page. A twelve-page site can need two hundred decisions. A forty-page site with a clear owner can need sixty. The Standish Group built an entire CHAOS report around decision latency, the gap between when a decision is needed and when it is made, and argued the gap matters more than the difficulty of the work. Nothing in twelve years has contradicted that for me.
And nobody asks the question underneath it: how many hours a week does the client actually have for this project? Every plan silently assumes five. Most owners have one, at 9 p.m., on their phone.
What prevents it. A decision register next to the task list: every open decision gets an owner, a date, and a default that takes effect if the date passes. On a store I am building now, the first thing the owner got after kickoff was not a design. It was a numbered list in two parts: things only she could do, and decisions I needed before I could start. Jeff Bezos’ rule for Amazon applies to every row: most decisions should be made with about 70 percent of the information you wish you had, and reversible ones, the two-way doors, get a light process. Shipping rates are a two-way door. The domain name is not.
The org chart is not the approval chart
The person who signs the proposal is rarely the person who can kill the site. That person shows up at 90 percent, usually a founder, a spouse, a board member, or a regional VP who was too busy for the kickoff, and says the thing that costs six weeks: “This isn’t us.”
Every PM knows this happens. Very few ask the question that prevents it, because it feels rude. “Who are the stakeholders?” gets you a cc list. The question is: who can say no at launch? And the follow-up that is even more useful: who has said no to a website before?
What prevents it. A one-line approval chart in the scope document, signed. Three names: who reviews, who approves, who can veto. Get the veto into the wireframe review, not the launch review. If the client cannot fill in the third line, the third line is the client’s spouse, and you should plan for that.
The account you inherit is scope
This never appears in a proposal, and it has stopped more launches than any design problem I have seen. The platform account, whether it is Shopify, WordPress hosting, HubSpot, or a five-year-old Squarespace trial, arrives with debt. Not code debt. Business debt.
On the store I mentioned, before I touched a template, I went through every corner of the account. Here is what was waiting.
None of that is website work. All of it stops a website from doing its job.
What prevents it. A foundation audit as the first deliverable, in writing, split into “only you can fix this” and “I need a decision.” Payments, tax, legal name, policies, plan and billing, domain, email sending, point of sale, two-factor login. Audit before design and every finding is a task. Audit after launch and every finding is an emergency.
Access is on the critical path, and nobody schedules it
Ask a client where their domain is registered. About a third do not know. Ask who has the hosting login, the DNS, the Google Analytics ownership, the tag manager, the last developer’s admin account. The answers arrive over two to three weeks, one at a time, often with the phrase “I think that was the guy before the last guy.” The plan, meanwhile, has design starting Monday.
What prevents it. An access checklist sent the day the contract is signed, tracked like a deliverable: registrar, DNS, hosting, CMS admin, analytics, Search Console, tag manager, payment processor, email sending domain. Anything not received by the end of week one goes in the status report, in red, because it is already eating the schedule.
The old site is the largest unscoped deliverable
Redesign proposals describe the new site in detail and the old site in one line: “migrate existing content.” That line is where the black swans live.
The old site has URLs that rank and nobody knows it. Content that exists nowhere except live in the CMS. A contact form that works because of a plugin nobody documented. Tracking that fires from a tag manager container two agencies ago. Or 35,000 products in 1,372 collections with a fitment system customers depend on. Every one is a deliverable the new site has to match or consciously retire, and none of them are in the page count.
What prevents it. A full crawl and inventory of the existing site before the scope is signed. Every URL with its traffic, its inbound links, its form, its tracking, and a decision. That document is the migration scope, and in my experience it moves the estimate by 15 to 30 percent. Better to find that out on the proposal than on the launch checklist.
“Just a form” is an integration
The most expensive word in a website scope is “just.” Each one is a vendor with its own roadmap, an authentication handshake, a consent requirement, a data map from your fields to somebody else’s database, and an owner who has to keep it working after you leave.
On a lending site I led optimization for, the most fragile piece of the whole program was not the personalization engine. It was a session token that had to survive the trip from the marketing site into the secure application. Nobody had scoped that handoff, because on the diagram it was an arrow.
What prevents it. An integration inventory in the scope: every system the site sends data to or receives data from, who owns the account, API or copy-paste embed, and what happens when it fails. Price each one as its own line. When “just connect it to HubSpot” has a number next to it, the client either wants it or does not, and both answers are cheaper than finding out in QA.
Approval on placeholder text is approval of nothing
A design signed off on lorem ipsum will be redesigned when the real words arrive, and none of that counts as a revision, because the client “already approved the design.”
What was approved
What arrived
Content-first is usually presented as a workflow preference. It is a budget control. On the store I am building now, the first deliverables were a product spreadsheet and a photo folder with a naming rule, before a single template existed. The design review is now a review of the site, not of a placeholder that resembles it.
What prevents it. A content readiness gate. No design review until real headlines, real product data and real photography exist for the pages being reviewed. If the About page is not written, the About page is not designed. It is scheduled.
Revision rounds are the budget unit, not hours
Most scopes say “two rounds of revisions” and never define a round. So a round becomes whatever the client sends, whenever they send it, from however many people. Six emails over nine days, each with three comments, two of which contradict the last email, is one round. Or it is six. The scope does not say, and the difference is the entire design budget.
Worse, most PMs ask for feedback the most expensive way possible: “What are your thoughts?” That is an invitation to redesign. On the current project, when I needed a direction check, I sent three visual directions and asked which one she connected with. She answered in a sentence, then asked a sharper question than mine, about whether the descriptions referred to the site or the products, and that told me exactly what the next mockup had to clarify.
A round, undefined
- “What are your thoughts?”
- Feedback by email, text, and a phone call
- Four reviewers, two of whom disagree
- Nine days, no closing date
- Round 2 begins before round 1 ends
A round, defined
- “Which of these three?”
- One consolidated document
- Named reviewers, one approver
- Five business days, then the round closes
- Round 3 has a price on it
What prevents it. Define the round in the scope: one consolidated feedback document, from named reviewers, within five business days, closed when delivered. Reviews present options, not open questions. And the third round costs money, in writing, before anyone gets attached to the idea that revisions are free.
No baseline, so every post-launch dip is an emergency
Three weeks after launch, the phone rings less. Or traffic is down. Or the owner has a feeling. Nobody measured anything before the redesign, so nobody can say whether the new site caused it, the season caused it, or a Google update caused it. What follows is the most predictable unplanned scope in the industry: an emergency investigation, at emergency rates, into a question that a spreadsheet built in week one would have answered.
There is a second version of the same failure. A site scoped in hours is a site nobody can ever say is done. “Done” was never written down as an outcome, so launch becomes an argument about whether it worked, and the argument has no referee.
What prevents it. Before launch, record twelve months of the numbers that matter: sessions by source, leads by source, calls, form fills, conversion on the pages that make money, positions for the ten queries the business depends on. Then write down what “done” means as a business outcome, over what window, with what tolerance. Inside tolerance at 30 days, it worked. Outside, you know where to look.
Launch is the most expensive week of the project, and it is usually unfunded
Every budget I have ever seen ends on launch day. Every project I have ever run has its most expensive week in the seven days after it.
The garage door company I moved off a site builder did not need me most during the build. It needed me most in the weeks after, when the new service pages started ranking and the phone calls needed routing nobody had thought about while the site was a mockup.
What prevents it. A post-launch runway in the scope, funded: 30 days, a fixed block of hours or a share of the build budget, and a short list of what it covers. Monitoring, the first real transactions, email deliverability, redirect verification, the first analytics read against the baseline, and a handover where the client learns to run what they now own.
The pattern underneath all ten, and what a website project manager is actually for
Look at the list again. Only two of the ten are about building a website. The other eight are about the systems, people and decisions around it: the account, the access, the old site, the integrations, the content, the reviewers, the baseline, the month after. The proposal describes the part above the waterline. The budget pays for the part below it.
Which leads to a definition of the job that I think is more honest than the one on most resumes, mine included. A website project manager’s job is not to manage the build. It is to move every surprise from the phase where it is a crisis to the phase where it is a line item. Flyvbjerg’s phrase for the projects that work is “think slow, act fast”: spend disproportionate time up front so execution is short and boring. Every item above is a way to do that. Boring is the goal.
Questions people ask about website project budgets
Why do website projects go over budget?
Because the scope is estimated in pages and features while the cost is driven by decisions, migration, integrations, content readiness and the work after launch, none of which appear in a typical proposal. Research on large projects finds the average IT project runs about 45 percent over budget; website projects fail the same way at a smaller scale. The fix is to scope the hidden work explicitly and estimate from how your last five projects actually went, not from how this one is planned.
What causes scope creep in web design projects?
Undefined units. A “revision round” with no definition, a design approved on placeholder text, and a “just a form” that turns out to be an integration are the three most common. Each one lets scope grow without anyone agreeing to grow it. Define the round, gate design on real content, and inventory every integration with a price, and most scope creep stops being possible.
How do you keep a website project on budget?
Move every surprise from the phase where it is a crisis to the phase where it is a line item. In practice: a decision register with owners and dates, an audit of the existing account before design, a crawl of the old site before the scope is signed, an integration inventory, a content readiness gate, defined revision rounds, a pre-launch baseline, and a funded 30-day post-launch runway. The ten questions below cover all of it.
How much contingency should a website project have?
Do not guess. Take your last five projects, divide actual weeks by planned weeks, and use the average as your multiplier. For most teams it lands between 1.4 and 2.0. That number is a better contingency than any percentage rule, because it is built from your own history instead of an industry average.
Most of the ten fixes above are reading, checking and remembering. Here is how I hand that work to Claude: the decision register from the inbox, the inherited-account audit, the crawl joined to Search Console, and ten more.
Every kickoff question above only works if the client understands it. A plain-English translator for the words we use, and what the client actually hears.