Ole Martin leads project delivery at Frontkom. He has been responsible for projects of all sizes and sees the same missteps repeating regardless of industry or budget.
There are plenty of myths about why digital projects go wrong. The technology was the wrong choice. The supplier was poor. The budget was too small. The timeline was unrealistic.
Sometimes that is true. But most often the root cause is something else: ambiguity. Ambiguity about what is actually being delivered. Ambiguity about who decides what. Ambiguity about what success looks like.
Three reasons projects go off track
Requirements are unclear at the start. Everyone believes they agree on what is being built. But when building begins, it turns out the client and the supplier had different pictures in their heads. What looks like a small misunderstanding early on becomes a costly conflict halfway through the project.
Decision-making is too slow. A button missing copy can halt progress for two weeks because nobody owns the decision. Meanwhile the budget keeps ticking and the team is waiting. Very few projects fail because of poor work. Many fail because the waiting days add up.
Nobody owns the whole. Developers work in their lane, design in theirs, the content team in theirs. Nobody sees that the three lanes are not converging. It is discovered when it is too late to change course without significant cost.
Clarity problems early in a project become cost problems late. That is not an observation. It is a law.
What Frontkom does differently
The Frontkom method is built around one insight: it is cheaper to invest extra time in clarity at the start than to untangle misunderstandings once half the budget is spent.
That means we invest disproportionate time in the early phases: clarifying goals, dependencies, success criteria and who decides what. We establish a simple decision matrix early on. We set up regular status cadences. And we identify who on the client side needs to be involved to keep things moving when it matters.
It feels slow at the start. It is not. It is what allows the build phase to move faster and with fewer surprises.
What we measure on
We do not measure success in deliverables. We measure it in business impact.
A website delivered on time but not used by its intended audience is not a successful delivery. A system that is two weeks late but genuinely solves the problem the client had, is.
That requires us as a supplier to understand what the client is actually trying to achieve, not just what they ordered. It is a more demanding role, but it is the one that delivers lasting effect.
A practical example
We recently had a project where the client came to us wanting to build a new intranet. It was a clear request. But after a thorough first phase it became apparent that the root cause of the problems they wanted to solve was not a missing intranet, but that information flow between departments was unclear and the existing system was not being used because nobody had received training.
We recommended a different approach from what they had ordered. It was a harder conversation. But it produced far better results.
Do you have an upcoming project where you want a partner who asks the right questions before building begins? Get in touch.