We've sat in the room for a lot of launches, government and private sector alike. The projects that struggle almost never fail for one big dramatic reason. They fail for the same five small, avoidable ones, over and over again. Here's what we see most often, and what we tell clients to do instead.

1. Skipping User Research

This is the one that causes the most damage, because it's invisible until launch day. A team assumes it knows what users want, builds against that assumption, and finds out too late that the assumption was wrong. By then the budget is spent and the fix means rebuilding, not tweaking.

What we do instead: research starts before a single wireframe gets drawn. Interviews, observation, and real data on how people currently behave, not how the organisation hopes they'll behave. It's the cheapest step in the whole project, and the one most likely to get cut when time is short. It shouldn't be.

2. Ignoring Stakeholder Feedback

Stakeholders, frontline staff, delivery partners, internal teams, often raise the exact problem that later sinks the launch. The feedback gets logged, sometimes even acknowledged in a meeting, and then quietly dropped because it's inconvenient or doesn't fit the timeline.

What we do instead: feedback gets tracked the same way a risk would be, with an owner and a decision, not just a note in a document nobody reopens. If a stakeholder's concern isn't going to be addressed, we make sure someone tells them why, rather than letting it disappear.

3. Poor Communication

A new service can be well designed and still fail if nobody explains it properly, to the people who'll use it or the people who'll deliver it. Staff find out about a new process the same week it goes live. Users get a confusing email and give up before they even try the new system.

What we do instead: communication gets planned with the same rigour as the build itself, who needs to know what, and when, so that launch day isn't the first time anyone hears about the change.

4. Lack of Testing

Testing often gets squeezed when a deadline is tight, because it's the step at the end of the schedule and the easiest one to shorten. The result is a service that technically works in a demo, and breaks the moment a real person with a real, messy situation tries to use it.

What we do instead: testing happens with real users, on real devices, well before launch, not just internally, and not just once. Small issues caught early are cheap. The same issues found by the public after launch are expensive, and much harder to fix quietly.

5. No Clear Success Metrics

Without a clear definition of success before launch, teams end up arguing about whether the project worked using whatever number happens to look good afterwards. That's not evaluation, it's storytelling, and it makes it almost impossible to actually improve the service over time.

What we do instead: success gets defined before the project starts, in plain, measurable terms, so everyone agrees in advance what “it worked” actually means, and there's a clear way to check.

The Pattern Behind All Five

Every one of these mistakes comes from the same root cause: moving fast in a direction nobody actually checked. None of the fixes are complicated. They just take discipline, and a willingness to slow down at the start so the rest of the project doesn't have to pay for it later.

This is the work we do at BlueBow on every engagement: the research, the stakeholder tracking, the communication planning, the testing, and the metrics, before a service ever reaches the public. It's rarely the most exciting part of a project. It's almost always the part that decides whether the project succeeds.