Digital Agency for Medway Businesses

Most Projects Fail on People, Not Technology

Digital projects rarely run into trouble because something could not be built. They run into trouble because six people had different expectations, feedback arrived from everywhere at once, and nobody was certain who could actually approve anything.

The symptoms are familiar. Rounds of revisions that circle rather than converge. A stakeholder appearing late with objections to something settled weeks earlier. Contradictory feedback nobody can reconcile. Timelines slipping for reasons that have nothing to do with the work itself.

None of that is fixed by better design or faster development. It is fixed by deciding, at the start, how decisions get made.

Who Actually Decides

The first question is the most useful and the most often avoided: who has final say?

Not who should be consulted — that list is usually long and legitimately so. Who decides when opinions conflict. Ideally one person, or a small group with a way of resolving disagreement between themselves rather than passing it outward.

Where this is unclear, everything else becomes harder. Feedback arrives with equal weight from people with very different levels of authority, and whoever is doing the work is left interpreting which opinion carries. That is not their judgement to make, and they will occasionally get it wrong.

Collecting Requirements Once

Requirements gathered piecemeal produce a project that keeps changing shape.

Better to collect properly at the start — talk to everyone with a genuine stake, gather what each needs the project to achieve, and resolve the conflicts before anyone designs anything. Some requirements will be incompatible; that is normal, and it is far cheaper to discover in week one than week nine.

Writing down what has been agreed serves everyone. It gives the people doing the work a reference, and it gives stakeholders something to check against later rather than relying on recollection.

Separating Feedback From Approval

These are different things and conflating them causes considerable difficulty.

Feedback is input — observations, concerns, suggestions. Anyone with a stake can reasonably offer it. Approval is a decision that something is settled and work can proceed.

When everyone's feedback is treated as approval, nothing is ever settled, because any stakeholder can reopen anything at any point. When feedback is not sought at all, people raise objections late, which is worse.

The workable arrangement is broad consultation and narrow approval. Everyone is heard; a defined person or group decides.

Handling Contradictory Feedback

With several stakeholders, contradictory feedback is inevitable rather than exceptional.

One person wants it simpler, another wants more detail. One wants the emphasis here, another there. Both views are held sincerely and both cannot be accommodated.

What does not work is averaging them, which produces something nobody wanted. What does work is surfacing the contradiction explicitly — putting both positions in front of whoever decides and asking for a resolution, rather than quietly attempting a compromise and presenting it for approval.

That conversation is uncomfortable for about five minutes and saves a round of revisions.

Defined Review Rounds

Open-ended review is where timelines dissolve.

A defined structure helps: a set number of review rounds at each stage, with a stated purpose for each. The first round for substantial direction, the second for refinement, the third for detail. Consolidated feedback from one source rather than separate messages from six people.

The point is not rigidity. Genuinely new information should be able to change things. The point is that "one more look" without a defined end tends not to have one, and everyone loses track of whether anything has actually been agreed.

Content Responsibilities

Content is the most common cause of delay on website projects, and almost always because responsibility for it was never properly assigned.

It is assumed someone will write it. Design proceeds with placeholder text. Build proceeds with placeholder text. And at the point of launch it becomes apparent that nobody has produced any, and the person who could is not expecting to.

Worth settling early: who writes what, by when, who approves it, and what happens if it is late. Content deadlines should be treated with the same seriousness as design and development ones, because a project waits on all three equally.

Sign-Off at Each Stage

Each stage should end with somebody explicitly agreeing it is done.

Design signed off before build begins. Build signed off before launch preparation. Content approved before it is placed. Each with a named person and a date.

This sounds bureaucratic and is the opposite — it prevents the far more painful situation where design is reopened during development because it turns out nobody had actually agreed to it. Where development and design proceed on assumed approval, the rework is expensive.

One Source of Truth

With several stakeholders, information fragments across email threads, meetings, documents and calls. Two people end up working from different versions of the same decision.

A single place holding the current state — what has been agreed, what is outstanding, who owes what and when — removes most of that. It need not be sophisticated. What matters is that it exists, is current, and that everyone knows it is where to look rather than searching their inbox.

Working With a Kent-Based Digital Agency

Maidstone Digital is based in Maidstone and works with businesses and organisations in Medway, elsewhere in Kent and further afield. We do not have premises in Medway. Most work is carried out remotely and reviewed through shared documents and regular calls, though we are happy to meet where useful — and for projects with several stakeholders, an occasional session in person is often the fastest way to resolve things.

Medway Digital Agency FAQs

How do we manage feedback from several people?

Consolidate it before it reaches whoever is doing the work. One person gathering input, resolving contradictions internally and passing on a single set of comments is considerably more effective than six people sending separate messages. Where views genuinely conflict, surface that explicitly rather than attempting a compromise nobody asked for.

What if a stakeholder objects after something has been agreed?

It depends whether the objection reflects genuinely new information or an opinion that was not offered when it was sought. The first warrants reopening the decision; the second usually does not. Having a written record of what was agreed and by whom makes that conversation considerably easier.

How many rounds of revisions should we expect?

It is worth agreeing a number rather than leaving it open, with a clear purpose for each round — direction first, then refinement, then detail. That is not about limiting input; it is about everyone knowing where a stage ends. Open-ended review tends not to converge on its own.

Who should be involved in a website project?

Anyone whose work the site genuinely affects should be consulted — but consultation and approval are different. A wide group giving input with a small group deciding works well. A large group all holding approval rights rarely does, because any one of them can hold everything up.