The Real Reason Your Project Hasn’t Moved Forward
Your website project isn’t stuck because of technology choices, budget constraints, or a lack of creative ideas. It’s stuck because too many people have a say in every decision, and no one has the authority to make a final call. This is the single most common pattern we see when companies come to us mid-project, frustrated and behind schedule. They started with good intentions, inclusive meetings, and a desire to get buy-in from everyone. Six months later, the homepage still isn’t approved.
Stakeholder inclusion is important. Stakeholder overload is lethal. The difference between a website project that ships on time and one that drags on for a year almost always comes down to how decisions get made, not what decisions need to be made. When you give twelve people equal authority over the colour of a button, you haven’t built consensus. You’ve built a bottleneck.
How Projects Actually Get Stuck
Let’s trace the typical pattern. A marketing director identifies the need for a new website. They get approval from the CEO or managing director. Then, quite reasonably, they involve department heads because the website serves the whole business. Sales wants to make sure the lead form is prominent. Product wants detailed technical specs on every page. HR wants the careers section redesigned. Customer support wants a knowledge base. Finance wants to know the ROI before anything starts.
Each of these perspectives is valid. The problem isn’t that people care about the website. The problem is that no one has defined whose opinion carries weight on which decisions. So every meeting becomes a negotiation. Every design review generates contradictory feedback. The agency or development team receives a list of changes that cancel each other out: “make it simpler” from one stakeholder and “add more detail” from another, both delivered with equal authority.
What happens next is predictable. The project team tries to satisfy everyone, the design gets muddled, timelines slip, and the original vision disappears under layers of compromise. We’ve seen projects where a single homepage went through eleven rounds of revision, not because the design was poor, but because each review surfaced a new stakeholder with a new opinion.
The Difference Between Inclusion and Authority
There’s a critical distinction that most project teams fail to make at the outset. Being consulted is not the same as having decision-making power. A healthy project includes many voices during the discovery and requirements phase. People across the business should absolutely share their needs, frustrations with the current site, and ideas for improvement. That input is genuinely valuable.
But once you move from “what do we need?” to “what are we building?”, the group of people who can approve or reject work needs to shrink dramatically. In our experience, the ideal number of decision-makers for a website project is two to three people. One person who owns the business outcome (usually a marketing or commercial leader), one person who controls the budget, and occasionally one person who represents a technical constraint. That’s it.
Everyone else gets a clearly defined role: contributor, reviewer, or informed party. Contributors provide input during specific phases. Reviewers give feedback within a structured window. Informed parties receive updates but don’t attend design reviews. When you spell this out before the project begins, people don’t feel excluded. They feel clear.
What a RACI Model Actually Looks Like on a Website Project
You’ve probably heard of RACI charts (Responsible, Accountable, Consulted, Informed). Most teams have heard of them too. Almost nobody uses them properly on website projects because the categories feel too corporate for a creative endeavour. But adapted sensibly, a RACI-style framework saves weeks of delay.
Here’s how we typically recommend structuring it:
- Accountable (1 person): The single individual who can approve final designs, sign off on content, and resolve disputes. If this person says “go,” the project moves forward.
- Responsible (2-3 people): The working group that reviews deliverables, gathers feedback from others, and presents a consolidated view. They do the heavy lifting of internal alignment.
- Consulted (varies by phase): Subject matter experts who are asked for input during discovery and content development. Sales gets consulted on the lead generation strategy. Product gets consulted on technical content. Their input is gathered, synthesised, and presented by the responsible group.
- Informed (everyone else): People who receive project updates at milestones. They know what’s happening. They don’t attend weekly reviews.
The critical point is that the accountable person must genuinely have authority. We’ve worked on projects where the “decision-maker” was nominally the marketing director, but the CEO overruled every major decision three weeks later. That’s not a governance structure. That’s a trap. If the CEO wants to approve creative work, make them the accountable party and build the review process around their calendar.
Why Consensus Is the Enemy of Good Design
There’s a deeply held belief in many organisations that a website project should satisfy all internal stakeholders equally. This belief is wrong, and it produces mediocre websites.
Good design requires a point of view. It requires someone to say, “We’re going to prioritise this user journey over that one because it drives more revenue.” It requires the courage to leave things out. When you design by committee, you don’t get a bold, effective website. You get a compromise that offends nobody and inspires nobody. Every section gets equal visual weight. Every department gets its content on the homepage. The navigation balloons to forty items because nobody was willing to say “your page doesn’t warrant top-level navigation.”
The best websites are opinionated. They make clear choices about who they serve and what action they want visitors to take. Those choices inevitably mean that some internal stakeholders won’t see their priorities reflected as prominently as they’d like. And that’s exactly how it should be, because the website exists to serve your customers and prospects, not your org chart.
This is one of the hardest conversations to have inside a business, and it’s one of the reasons we advocate so strongly for structured discovery before design work begins. When you’ve done the work of defining target audiences, mapping user journeys, and validating business objectives with data, you have something more powerful than anyone’s opinion: you have evidence. Evidence makes it much easier for the accountable person to make a call and for everyone else to accept it.
The Hidden Cost of Design by Committee
Most teams measure the cost of a stuck project in timeline terms. “We’re three months behind schedule.” But the real costs are broader and more damaging than that.
Agency or developer fatigue is real. When a project team receives contradictory feedback repeatedly, the best people on that team start to disengage. They stop bringing creative ideas to the table because they’ve learned that ideas just get watered down. You end up with a technically competent but creatively flat website, not because you hired the wrong team, but because you exhausted them with process.
Budget erosion follows inevitably. Every round of revisions that shouldn’t have happened costs money. A typical design revision cycle costs between £1,500 and £4,000 depending on the complexity of the pages involved. If you’re running three unnecessary revision rounds because stakeholders can’t align, that’s £5,000 to £12,000 in budget consumed with zero forward progress. On a mid-market project budgeted at £40,000 to £80,000, that represents a significant percentage of total spend.
Opportunity cost is the biggest expense of all. Every month your new website doesn’t launch is a month you’re running on the old one. If the old site converts at 1.2% and the new one is projected to convert at 2.5%, each month of delay has a real revenue impact you can calculate. For a B2B company generating 500 qualified visits per month at an average deal value of £10,000, a 1.3% conversion improvement means roughly six additional opportunities per month. Delay the project by four months and you’ve left twenty-four potential deals on the table.
How to Fix the Problem Before It Starts
The easiest time to solve the stakeholder problem is before the project begins. Once you’re mid-flight with thirteen people in a Figma review, it’s painful to restructure. Here’s what we recommend to every client before a single wireframe is drawn.
Define Governance in Writing
Create a one-page project governance document that names the accountable decision-maker, lists the responsible working group, and specifies which stakeholders will be consulted at which phases. Have the accountable person sign it. Have the CEO (or whoever holds ultimate authority) acknowledge it. This sounds formal because it is. Ambiguity in governance always resolves itself in the most expensive way possible.
Run a Structured Discovery Phase
The most reliable way to prevent stakeholder chaos during design and build is to capture and consolidate everyone’s input before creative work begins. This is the core principle behind our blueprint-first guide, and it’s the approach we use on every project. During a discovery or blueprint phase, every stakeholder gets a structured opportunity to share their requirements, concerns, and priorities. Those inputs are synthesised into a validated set of requirements that the decision-maker approves. From that point forward, the requirements document is the authority, not individual opinions in review meetings.
Set Feedback Rules That Actually Work
Unstructured feedback is where projects go to die. “I don’t like it” isn’t feedback. “The hero section doesn’t communicate our primary value proposition to IT directors” is feedback. Establishing a clear feedback framework before the first review saves enormous amounts of time. We typically recommend three rules:
- Feedback must reference the agreed requirements or a specific user need. Personal aesthetic preferences don’t qualify unless you’re the accountable decision-maker.
- Feedback is collected once per deliverable, in writing, within a defined window (usually 3-5 business days). No drip-feeding changes over two weeks.
- The responsible working group consolidates all feedback into a single document before sending it to the project team. Contradictions are resolved internally first.
These rules feel restrictive at first. Within two review cycles, every team we’ve worked with has told us they wish they’d always worked this way.
What to Do When You’re Already Stuck
If you’re reading this mid-project with a sinking feeling of recognition, it’s not too late. But you do need to act deliberately. Here’s the sequence that works.
First, get the most senior sponsor in a room and have an honest conversation. The project is stuck because of governance, not because of the agency or the design. Acknowledge this openly. Most senior leaders already sense it; they just haven’t named it.
Second, appoint or reaffirm a single accountable decision-maker. This person needs genuine authority and the willingness to make calls that not everyone will agree with. If your organisation can’t identify this person, that tells you something important about whether the project should continue at all right now.
Third, hold a reset meeting with all stakeholders. Present the new governance structure. Be transparent about why: the project has stalled, the budget is being consumed without progress, and the business needs this website to launch. Most people will understand. The ones who push back are usually the ones who were causing the bottleneck, and naming the structure gives the decision-maker the framework to manage them.
Fourth, re-baseline the project plan. Work with your agency or development team to identify which completed work is still valid and which needs to be revisited. Agree on a revised timeline with the new governance model in place. This is painful but necessary. Pretending you can recover the original timeline while fixing the process simultaneously is a recipe for disappointment.
Signs You Have a Stakeholder Problem (Before It’s Obvious)
By the time a project is visibly stuck, the problem has usually been brewing for weeks. Here are the early warning signs we’ve learned to spot across dozens of projects:
The review group keeps growing. You started with five people in design reviews. Now there are nine. Someone invited the regional manager. Someone else brought their direct report “just to listen.” Each new attendee adds latency and complexity.
Feedback contradicts previous rounds. You addressed the changes from round two, and round three’s feedback essentially reverses them. This almost always means a new voice has entered the process or an existing stakeholder is reacting to someone else’s changes rather than evaluating the whole.
The phrase “run it past” appears frequently. “We just need to run it past David.” “Can we get Sarah’s eyes on this before we approve?” These phrases indicate that the person nominally in charge doesn’t actually feel empowered to decide. Every “run it past” adds a week.
Meetings end without decisions. If you leave a design review with a list of “things to think about” rather than a clear approve, reject, or specific-changes-required, you have a governance problem. Meetings that don’t produce decisions are just expensive conversations.
The agency starts asking who they should listen to. When your project team or external partners explicitly ask “whose feedback takes priority?”, they’re telling you they’ve received irreconcilable input and they need you to resolve it. Take this seriously.
Why This Keeps Happening (and How Culture Plays a Role)
Stakeholder overload isn’t usually caused by bad actors or power grabs. It’s caused by organisational culture that values inclusion over efficiency. Many mid-market companies have grown from small teams where everyone had a say in everything. That culture served them well at fifteen people. At seventy-five people, it creates paralysis.
Website projects are particularly vulnerable because they’re visible, cross-functional, and subjective. Everyone has an opinion about design. Everyone uses the website. It feels natural to involve the whole leadership team. Compare this to, say, choosing a new CRM, where most people are happy to defer to the operations team. The website feels like it belongs to everyone, which is precisely why clear governance matters more, not less.
There’s also a fear dynamic at play. The decision-maker is often reluctant to overrule a peer because they’ll have to work with that person tomorrow. Approving a homepage that the sales director publicly criticised feels politically risky. This is why executive sponsorship matters so much. When the CEO or MD has explicitly backed the governance model and the decision-maker’s authority, it becomes much safer to make the call.
Getting It Right from the Start
The most successful website projects we’ve been involved with share a common trait: they treated governance as a first-class deliverable, not an afterthought. Before the project brief was written, the team knew who would decide, who would advise, and who would be kept informed. They documented it. They communicated it. And when someone tried to expand the review committee in week four, they pointed to the document and held the line.
If you’re planning a website project, spend the first week on governance before you spend a single hour on design inspiration or technology selection. Identify your decision-maker. Get explicit executive backing for their authority. Define the feedback process. Set review windows. Communicate the structure to everyone who might expect to be involved.
This isn’t bureaucracy. It’s the difference between a project that launches in four months and one that’s still “in review” a year from now. Too many stakeholders isn’t a people problem. It’s a structure problem, and structure is something you can fix before it costs you another quarter.
Ready to get started?
