TL;DR
When a website project is late, the cause is usually a decision that was delayed, not code that was slow. Every website project runs on a queue of client-side decisions about content, approvals, access, and scope. The speed of that queue predicts your launch date better than the size of the development team.
Introduction
The kickoff was in March. Launch was promised for June. It is now September, and the development team has been “almost done” for eleven weeks. Leadership asks the agency for an explanation and receives a polite list: homepage copy still in review, product photos pending, DNS access requested three times, a new feature added in July. Nobody on that list writes code.
This is the uncomfortable pattern behind most late websites. Development is rarely the bottleneck. Decisions are. And unlike developer hours, decision delays never appear on an invoice, so nobody budgets for them.
Why a Website Project Is Late Before Development Starts
A website project is late the moment decisions arrive slower than the team can use them. Website work is sequenced. Design waits on sitemap approval, templates wait on design sign-off, and launch waits on content, access, and testing. Each of those waits is a client-side decision.
The Standish Group, which benchmarks software project outcomes, calls this decision latency: the interval between when a decision is needed and when it is made. Its CHAOS 2018 research estimated that a project creates roughly one decision for every $1,000 of labor cost. A $60,000 website therefore carries around 60 decisions, and any one of them can stall the build.
The effect on outcomes is dramatic. According to Standish Group CHAOS 2020 data cited by Scaled Agile, organizations with good decision latency delivered 75 percent of projects successfully. Organizations with bad decision latency succeeded only 21 percent of the time.
Failure rates split the same way: 4 percent versus 43 percent.
The Standish Group’s own summary is blunt. The value of the interval is greater than the quality of the decision. A good decision made in two days usually beats a perfect one made in three weeks.
The Four Decision Queues That Stall Website Projects
Late website projects stall in four predictable decision queues, and each one sits on the client’s side of the table. Each has a different owner and a different way of failing.
Content
Content is the most underestimated queue. Copy, product data, images, legal text, and case studies must exist before pages can be finished and tested. When content is late, the launch slips day for day. No amount of development capacity can write your pricing page.
Approvals
Approval queues stall when sign-off belongs to a committee. A design review with five stakeholders produces five rounds of conflicting feedback. The last person to review usually reopens what the first person approved.
Access
Access covers DNS, hosting, payment gateways, CRM credentials, and API keys. These requests look trivial and routinely take weeks. On older sites with missing documentation, simply identifying who owns the hosting account can consume a full sprint.
Scope
Scope changes arrive as small, reasonable questions. “Can we also add a quote calculator?” Together they rebuild the plan without anyone resetting the date. PMI’s 2014 Pulse of the Profession report on requirements management found that poor requirements management caused 47 percent of unmet project goals.
The Decision Tax: What Slow Decisions Actually Cost
The Decision Tax is the total cost a company pays while a project decision waits, and it is charged in three currencies at once. Most leadership teams only see the first.
- The idle tax. A blocked team moves to other work. Restarting is never instant, and the original developer may now be committed elsewhere. In projects we have handled, a two-week pause often costs closer to three weeks of timeline once the restart is counted.
- The drift tax. A late decision frequently invalidates work already built. When design sign-off lands after template development has started, those templates get rebuilt. The decision was late, so the work was paid for twice.
- The delay tax. Every week before launch is a week of leads, sales, or savings the new site does not produce. PMI’s Disciplined Agile guidance defines the cost of delay as what a delay in realizing value costs an organization in lost revenue, lost opportunity, and increased risk.
Consider a simple illustration. If a new site is projected to add $30,000 a month in pipeline, each week of delay forfeits roughly $7,000. That figure belongs in the ROI case for any website investment. It almost never appears there.
The arithmetic is uncomfortable. A week spent waiting on a homepage approval can cost more than the homepage.
Why Adding Developers Rarely Rescues a Late Project
Adding developers to a late website project rarely speeds it up when the delay sits in a decision queue. More capacity downstream of a blocked decision simply means more people waiting. Fred Brooks made the broader point in The Mythical Man-Month in 1975: adding people to a late software project makes it later.
Switching vendors mid-project disappoints for the same reason. The new team inherits the same queue, plus an onboarding cost. Teams like WPRiders see this regularly in rescue projects: the previous vendor took the blame, the codebase was workable, and the real blocker was an approval chain nobody owned.
Before debating your staffing model or firing an agency, find out where the work is actually waiting. The answer is usually in a shared inbox, not a code repository.
The Decision Latency Matrix
The Decision Latency Matrix assigns every recurring project decision one owner and a maximum turnaround time before development begins. It converts vague “client responsibilities” into commitments leadership can track.
| Decision type | Typical examples | Single owner | Target turnaround | What waiting costs |
|---|---|---|---|---|
| Direction | Sitemap, platform, brand direction | Executive sponsor | 5 business days | Rework of everything downstream |
| Content | Copy, product data, images, legal text | Named content lead | Dated per milestone | Launch slips day for day |
| Approval | Design sign-off, acceptance testing | One accountable approver | 2 business days | Team reassignment and restart cost |
| Access | DNS, hosting, payment gateway, API keys | IT or operations lead | 1 business day | Critical path fully blocked |
| Scope change | New features, new integrations | Sponsor with budget authority | 3 business days, with cost and date impact | Silent timeline drift |
The turnaround targets reflect what we see working across projects, not an industry standard. Adjust them, but never leave them blank.
Three rules make the matrix work. First, one owner means one person: a committee can advise, but a named approver decides. Second, put the matrix in the contract. A proposal that lists only vendor obligations and ignores client dependencies hides the most likely cause of delay.
The third rule protects the date. New scope defaults to a later release. Launching a smaller first version and adding features after go-live protects both the timeline and the budget.
WPRiders builds the client-side decision schedule into the project plan during discovery, so dependency dates sit beside development milestones instead of surfacing as surprises in week ten.
Measure Decision Age, Not Just Progress
Decision age is the number of days a pending project decision has been waiting, and it is the most useful status metric an executive can request. Percent-complete reports hide queues. Decision age exposes them.
Replace “what is the status?” in your weekly update with three questions. What decision is the team waiting on? Who owns it? How many days old is it? Any decision older than its turnaround target escalates to the sponsor automatically. That single habit moves accountability to the place where most delay lives.
Key Takeaways
- Most late website projects are delayed by client-side decisions, not by development speed.
- Standish CHAOS 2020 data shows organizations with good decision latency succeeded on 75 percent of projects, versus 21 percent for those with bad decision latency.
- Slow decisions impose a Decision Tax in three forms: idle time, rework from late changes, and revenue lost while the new site is not live.
- Adding developers or switching vendors does not fix a project whose delay sits in a decision queue.
- Every recurring decision on a website project needs one named owner and a written turnaround time.
- Decision age, meaning how long a pending decision has waited, is a more useful executive status metric than percent complete.
Conclusion
The gap between build speed and decision speed is about to widen. AI coding tools are compressing the time developers need to produce templates, integrations, and fixes. Decision cycles inside most companies are not getting faster. The result is predictable: on the next generation of website projects, waiting will account for an even larger share of the calendar than it does today.
Companies that treat decisions as scheduled, owned, and measured work will launch in the time their competitors spend collecting feedback. The advantage will not come from a faster agency. It will come from a faster yes.
FAQs
Q1. Why do website projects take longer than planned?
Website projects usually take longer than planned because client-side decisions arrive late. Content, design approvals, system access, and scope changes all sit on the critical path, and development cannot finish until they are resolved. The Standish Group calls this decision latency and found it strongly predicts project success. Timelines that ignore client dependencies are optimistic by design, not by accident.
Q2. How much does a delayed website launch cost a business?
A delayed website launch costs a business in three ways: idle team time and restart effort, rework when late decisions invalidate finished work, and revenue or leads the new site would have generated. The third cost is usually the largest. If a new site is expected to add $30,000 a month in pipeline, each week of delay forfeits roughly $7,000 before any extra development fees.
Q3. What is decision latency in project management?
Decision latency is the time between when a project decision is needed and when it is actually made. The Standish Group introduced decision latency theory in its CHAOS 2018 research. Its CHAOS 2020 data, as reported by Scaled Agile, found that organizations with good decision latency succeeded on 75 percent of projects, while those with bad decision latency succeeded on 21 percent.
Q4. Will adding more developers speed up a late website project?
Adding more developers rarely speeds up a late website project when the delay comes from pending decisions. Extra capacity downstream of a blocked approval only increases the number of people waiting. Fred Brooks observed in 1975 that adding people to a late software project makes it later. Clearing the decision queue almost always recovers more time than expanding the team.
Q5. Who should approve decisions on a company website project?
Each type of website project decision should have one named approver with the authority to decide. Direction decisions belong to an executive sponsor, content to a named content lead, access to an IT or operations lead, and scope changes to someone with budget authority. Committees can advise, but shared approval slows every round and invites conflicting feedback.
