After twenty years in digital, I can tell you this with complete confidence: I have never seen a project delivered on time, on budget, and at the quality promised. Not one. The old saying (“on time, good quality, in budget: pick two”) still holds. And I suspect it always will.
But here’s the thing. When I look back at the projects that hurt the most, the ones that really stung, the failure rarely came down to a missed deadline or a cost overrun. Those are painful but recoverable. The failures that stay with you are the ones where you built the wrong thing entirely.
A three-month build the users never wanted
Let me tell you about one.
We spent three months building a digital interactive tool for a client. Good team, solid brief, proper build. Everyone was across it. Then we did user testing: actual users, real sessions, proper outcomes document, full presentation to the business.
The room went quiet.
What the users wanted wasn’t an interactive digital tool. What they wanted was PDF reporting. A PDF plug-in. Something that would have taken a few hours and cost almost nothing.
The business’s response? The users were wrong.
I’ve seen this pattern more times than I can count. Once you’ve gone far enough down a road, almost nobody will own the misdirection and take the knock on the chin. The sunk cost becomes a reason to keep going rather than a reason to stop. So you end up defending a bad decision instead of fixing it. And the project limps to delivery, gets quietly shelved six months later, and becomes one of those things nobody brings up in the post-mortem.
The three things that have to be in balance
There are three things that have to be in balance for a digital project to work. Three, not two:
Expertise. The technical and design knowledge to actually build something well.
User requirements. What the people who’ll actually use it need it to do for them.
Business requirements. What the organisation needs it to achieve.
Miss any one of these and you’re not going to arrive at a brilliant solution. You’re going to get lucky at best.
The earliest warning sign I know, the one that tells me a project is already in trouble before a single line of code has been written, is a senior person in the room saying: “I know what users want.”
They might broadly understand the need. That’s different from knowing how it needs to be realised. And if what gets built doesn’t make things genuinely more convenient and more useful for the people using it, they won’t use it. It really is that simple.
Whose job is it to speak up?
So whose job is it to say something?
Everyone’s. Every single person on the project team, including the consultant. This isn’t the project manager’s responsibility or the UX researcher’s responsibility or the CTO’s responsibility alone. It’s a collective one. Every person in that room has both the standing and the obligation to call it when something feels wrong. The earlier the better. The longer you wait, the quieter the room gets.
What to do differently before your next project
If there’s one thing I’d ask any business to do differently before their next digital project, it’s this:
Make sure you’re answering the right question.
A requirement is not a specification. It’s an investigation, then a specification. Leave users out of either of those two parts and you’re running a serious risk: not of going over budget, but of spending the whole budget on the wrong thing.
That conversation (the one that happens before the brief, before the agency pitch, before anyone opens a project management tool) is the most valuable one most businesses never have.
It doesn’t take long. It just takes someone willing to ask the right questions before the build starts.
Garth Shoebridge is a digital problem-solver with 25 years of experience helping South African businesses think clearly before they build. If you’re about to start a digital project, or you’re mid-project and something feels off, start with a conversation.