Over 22 years in enterprise technology — at Schlumberger, E.ON, Saga, Loomis, and others — I’ve seen hundreds of technology projects. The ones that fail share remarkably similar patterns, and almost none of them are about the technology itself. They’re about people, process, and decisions.
Now that I work with UK SMEs as a fractional CTO, I see the same patterns repeated — often at a scale where the business genuinely can’t afford the failure. A failed £50,000 project at a 50-person company hits differently than a failed £5 million project at a corporation. The corporation absorbs it. The SME might not recover.
Here are the six reasons I see most often, and the concrete fix for each.
1. No technical leadership in the room
This is the root cause behind most of the other problems on this list. The managing director makes technology decisions because nobody else can. They choose vendors based on sales presentations rather than technical merit. They approve architectures they don’t understand. They sign contracts with no exit clauses because the agency said it was standard.
I worked with a recruitment firm in Berkshire that spent £85,000 on a custom CRM built by a local agency. After 14 months, they had a half-finished system that couldn’t handle their actual workflow. The managing director had approved every milestone because the demos looked impressive. But nobody with technical expertise had reviewed the architecture, the database design, or whether the requirements actually matched what was being built.
The fix:You don’t need a full-time CTO. You need someone with genuine technical depth involved in key decisions — vendor selection, architecture review, contract negotiation, and milestone acceptance. Two to four days a month is enough for most SMEs. The cost of a fractional CTO is a rounding error compared to the cost of a failed project.
2. Requirements that live in someone’s head
The conversation usually goes like this. The business owner describes what they want in broad terms. The agency nods enthusiastically and says they can build it. Work begins. Three months later, the owner sees the first demo and says: that’s not what I meant. The agency points to the proposal the owner signed. Both are right and both are wrong.
Requirements don’t need to be a 200-page specification document. For most SME projects, a 5 to 15-page document that describes what the system must do, who uses it, and what success looks like is sufficient. The critical thing is that it exists in writing before development starts, and that both sides agree on it.
The fix:Before engaging any vendor, write a requirements brief. List every user role. Describe every workflow step by step. Define what “done” looks like for each feature. If you can’t write it clearly, you can’t build it clearly. A technology health check often reveals that the biggest gap isn’t technology — it’s clarity about what the business actually needs.
3. Choosing the wrong vendor
SMEs typically choose technology vendors through one of three paths: a recommendation from a friend, the cheapest quote, or the most impressive pitch. None of these reliably predict success.
The friend’s recommendation might be perfect for a different type of project. The cheapest quote often means the vendor doesn’t understand the scope (or plans to charge for everything as extras). The impressive pitch means they’re good at sales, not necessarily at delivery.
I wrote a detailed guide on how to evaluate technology vendors that covers the full process, but the short version is this: ask for references from businesses your size and industry. Request a technical architecture proposal before signing. Check who actually owns the code and hosting. And get an independent technical review of their proposal before committing.
The fix:Never evaluate vendors alone if technology isn’t your expertise. An independent advisor costs a fraction of the project and can spot red flags that save you the entire budget. I’ve talked clients out of bad vendor choices three times in the past year alone — saving them collectively over £200,000.
4. Scope creep without consequences
The project starts with a clear objective: build an online booking system. Two months in, someone suggests adding a loyalty programme. Then a referral system. Then integration with a marketing platform that the sales director saw at a conference. Each addition seems small. Together, they double the timeline and triple the complexity.
Scope creep kills projects because it doesn’t feel dangerous until it’s too late. Each individual request is reasonable. But nobody is tracking the cumulative impact on the timeline, budget, and technical architecture. Features that are easy to describe are often hard to build, and without technical oversight, nobody raises the alarm.
The fix:Every project needs a change control process, even a simple one. Any new feature request gets written down, estimated for time and cost, and approved or deferred. If the project has a defined scope and budget, new features either replace something in the current scope or go into a Phase 2 backlog. This isn’t bureaucracy — it’s the difference between delivering something and delivering nothing.
5. Building custom when off-the-shelf works
A property management company I worked with spent £120,000 building a custom tenant portal. It took 18 months. When I reviewed it, I found that three off-the-shelf products could do 90% of what they needed at £200 to £500 per month. The remaining 10% — a custom reporting dashboard — could have been built for £8,000.
The instinct to build custom comes from a good place. Business owners want something that fits their workflow perfectly. But custom software is expensive to build, expensive to maintain, and creates a dependency on the team or agency that built it. Unless your requirements are genuinely unique, an off-the-shelf solution with some configuration is almost always the better starting point.
The fix:Before building anything custom, spend a week evaluating existing solutions. Try three to five products. If none of them handle your core workflow, then custom development is justified. If they handle 80% and you’re building custom for the remaining 20%, question whether that 20% is really worth the cost. The hidden cost of technical debt makes custom software even more expensive over time than most owners realise.
6. Ignoring technical debt until it’s too late
Technical debt is what accumulates when you take shortcuts to ship faster. Every business has some. But when nobody is managing it, it compounds. The codebase becomes harder to change. New features take longer. Bugs become more frequent. Eventually, the team spends more time fighting the existing system than building new capabilities.
I’ve seen businesses reach a point where their developers say the system needs to be completely rebuilt — a project that costs six figures and takes a year. In almost every case, the rebuild could have been avoided if someone had been managing the technical debt along the way: refactoring the worst parts, updating dependencies, and making small architectural improvements quarter by quarter.
The fix:Allocate 15 to 20% of your development capacity to technical debt reduction. Not as a separate project, but as a standing allocation in every sprint or development cycle. And have someone with technical authority decide which debt to address first — not all technical debt is equal, and some is worth carrying.
How to protect your next technology project
The pattern across all six failure modes is the same: decisions being made without sufficient technical expertise. You don’t need to become technical yourself. You need someone in your corner who is.
Before your next project starts, get an independent review of the requirements, the vendor proposals, and the technical architecture. During the project, have someone review progress against the actual deliverables — not just the milestone presentations. After the project, get an honest assessment of what was delivered versus what was promised.
The businesses I work with that get this right don’t spend more on technology. They spend it better. And they stop paying the hidden tax of failed projects, wasted licenses, and systems that don’t do what they were supposed to.