Why Technology Projects Fail Before They Start
The post-mortem is a fixture of failed technology projects. Teams gather, timelines get reconstructed, and someone produces a list of what went wrong. Requirements were unclear. Stakeholders weren't aligned. The scope expanded. The vendor underdelivered.
These are real problems. They are also the wrong place to look.
By the time a technology project has a timeline and a vendor, the conditions for its failure are usually already in place. The post-mortem examines what happened during delivery. The failure happened before the first meeting.
The Brief Is Where Expensive Decisions Get Made Invisibly
Every technology project begins with a brief, even when no one calls it that. It might be a slide deck presented to the board. A requirements document written by the IT team. An email thread that eventually becomes a statement of work. Whatever form it takes, it answers the same question: what are we building and why?
The problem is that most briefs answer the wrong version of that question.
"We need a new platform" is not a brief. It is a conclusion. The problem it is supposedly solving — inefficiency, poor visibility, manual processes — has already been filtered through a proposed solution before anyone has examined whether that solution addresses the actual constraint. The decision to build a new platform was made somewhere upstream, in a conversation that probably did not include the people who will use it, maintain it, or depend on it to make decisions.
This is what solution-first thinking looks like in practice. The organisation identifies a symptom, jumps to a remedy, and then builds a project around delivering that remedy. By the time external partners arrive, the solution is already assumed. The brief contains requirements for the thing that will be built, not a description of the problem that needs to be solved.
The consequence is not immediately visible. The project gets underway, work begins, progress is reported. It is only later — when the platform is delivered and the underlying problem persists — that the brief's failure becomes apparent. At that point, the tendency is to blame execution. The real cause was framing.
What a Problem-First Brief Looks Like
A brief that is built around the problem rather than the solution starts from a different place. Instead of describing what will be built, it describes what the organisation is trying to change.
The difference is easier to illustrate than to define. Consider a company that is losing customers to a competitor with a better digital experience. The solution-first brief says: "We need to rebuild our customer portal." The problem-first brief says: "Customers who interact with us through digital channels are completing fewer transactions and escalating more frequently to phone support. We need to understand why and change it."
These are not the same starting point. The first locks the project into a build. The second opens it to diagnosis. The portal may need rebuilding. It may need better content. The problem may be entirely on the backend, invisible to the customer until something fails. The problem-first brief creates the conditions to find out. The solution-first brief assumes the answer and organises an expensive programme of work around delivering it.
In our experience, the moment a brief can be reframed from "we need to build X" to "we need to change Y," the project becomes more honest. Scope becomes easier to set. Priorities become easier to agree on. And the people doing the work have a clearer signal for what actually counts as done.
The Vendor Who Accepts a Bad Brief Is Not Helping You
There is a dynamic in technology procurement that works against the client's interests, and it is so common that it has become invisible.
When an organisation goes to market with a brief that specifies a solution, vendors respond to what they are asked. They scope the work, price the delivery, and submit a proposal. None of this requires them to ask whether the brief is correct. It is usually not in their commercial interest to do so — a vendor who challenges the brief risks losing the work to a competitor who simply agrees to deliver what was asked.
This creates a structural problem. The organisation that most needs its brief to be challenged is the least likely to receive that challenge from the people responding to it.
A technology partner who reads a solution-first brief and does not ask what problem it is solving is not being helpful. They are transferring risk. When the project delivers the specified solution and the underlying problem remains, the contract will have been met. The organisation will have received what it asked for. It will not have received what it needed.
This is not a criticism of vendors in general. It is a description of how incentives are structured. The responsibility for a good brief ultimately lies with the organisation commissioning the work — and with whoever they trust to help them think through it before the work begins.
Three Questions Before Any Project Starts
There is no formula for a perfect brief, and the idea that sufficient upfront planning can eliminate uncertainty from a technology project is a fantasy. Complexity is inherent. Requirements change. New information surfaces during delivery that could not have been anticipated.
What can be eliminated is the specific failure mode that comes from committing to a solution before the problem is understood. Three questions create the conditions for this:
What decision are we trying to enable? Technology that does not connect to a decision is decoration. If the system being built will not change how the organisation makes a specific choice — about customers, about operations, about risk — the case for building it is weak. The answer to this question should be concrete: not "we want better visibility" but "we need to know within 24 hours when a shipment is at risk of missing a deadline so we can reroute it."
What does success look like in operational terms? Not technical terms. Not delivery terms. The question is what will be different in how the organisation functions once this project is complete. If the answer is vague — "the process will be more efficient," "the team will have better tools" — the project is not yet defined well enough to start. Efficiency is not a measure. Response time is. Error rate is. The number of people required to complete a process is.
What are we prepared to change? Technology projects that assume nothing about the organisation will need to change almost always fail to deliver their promised value. The new system gets built around existing processes rather than the processes being redesigned to take advantage of the new system. Asking this question before the project starts does not guarantee good change management. It does force a confrontation with reality about what the project will actually require from the people it affects.
None of this is complicated. All of it is skipped more often than not — not because organisations are careless, but because there is always pressure to move quickly, and the brief is treated as a formality rather than the most consequential document the project will produce.
What This Has to Do With the Partner You Choose
The value of a technology partner is not in their ability to deliver what you ask for. Plenty of firms can do that. The value is in their ability to tell you when what you are asking for is the wrong thing — and to help you work out what the right thing is.
This requires a particular kind of early engagement. Not a sales process, and not a scoping exercise. A diagnostic conversation in which the brief itself is examined, the problem is tested against the proposed solution, and the questions above are worked through before any commitment is made.
Organisations that have this conversation before they commission work spend less, deliver more, and encounter fewer of the surprises that dominate the post-mortems. The ones that skip it tend to discover its value later — usually in the middle of a project that was never going to succeed, working back from a brief that was wrong from the start.