Why Most SME Technology Projects Fail

Every week I speak to a business owner who has just spent twelve months and a significant sum of money on a technology project that didn't deliver what they needed.

The system works. The vendor delivered what was in the contract. But the business isn't better off.

This is the SME technology trap — and it is almost entirely avoidable.

The Brief Is the Problem

The root cause of most failed technology projects is a poor brief. Not a technical failure. Not a vendor failure. A brief failure.

When a business owner says "we need a new CRM" or "we need to automate our invoicing", they're describing a solution, not a problem. The brief goes to a vendor who quotes on the described solution, not on the underlying business need. The vendor delivers what was asked for, and the business realises too late that it wasn't what they actually needed.

This happens because:

• The business hasn't defined the problem clearly. "We need a CRM" is not a problem statement. "Our sales team is losing track of follow-ups and we're missing renewal conversations" is.
• There's no one in the room who bridges business and technology. The business owner understands the business but not the technology. The vendor understands the technology but has no incentive to challenge the brief.
• The success criteria aren't defined upfront. At the end of the project, no one can agree on whether it worked because no one defined what "working" looked like.

What a Good Brief Looks Like

A good technology brief starts with the business outcome, not the solution. It should answer:

1. What is the problem we're solving? Be specific. "Sales team loses track of follow-ups" is better than "we need a CRM."
2. How do we currently handle this? Document the current process, including its workarounds and failure points.
3. What does success look like in twelve months? Define the measurable outcome — not "staff find it easy to use" but "renewal conversations are booked at least 30 days before contract end."
4. What are the constraints? Budget, timeline, existing systems, and non-negotiables.
5. Who owns this? Technology projects without a named internal owner fail. Someone in the business needs to be accountable.

The Vendor Selection Mistake

Most SMEs select technology vendors the same way they buy office supplies — find three quotes, pick the middle one. This approach is fine for a photocopier. It is catastrophic for a business system.

When evaluating vendors, ask these questions:

• What do you need to know about our business before you can quote? A vendor who quotes without asking this question is guessing.
• What have you built for businesses like ours? Relevant experience matters more than technical capability.
• What typically goes wrong with implementations like this? A good vendor will tell you. A bad vendor will tell you nothing goes wrong.
• Who is the single point of contact during the project? If they can't name a person, escalate carefully.

The Implementation Gap

Even with a good brief and a good vendor, projects fail during implementation. The most common reason is the implementation gap — the distance between what was designed and what actually gets used.

Technology projects succeed when the people using the system are involved in designing it. This means:

• User testing before go-live, not after
• Phased rollouts that allow problems to surface before they affect the whole business
• Training that matches the actual workflow, not the theoretical one in the manual
• A defined hypercare period — the first 30 to 60 days after go-live — where issues are treated as urgent

What To Do Before Your Next Project

Before you kick off any technology project, spend time on these three things:

1. Write a one-page problem statement. If you can't explain the problem in one page, you haven't understood it yet.
2. Identify the process owner. The person accountable for the outcome needs to be involved from day one, not informed at go-live.
3. Define your success metrics. Three to five measurable outcomes that you'll assess at three, six, and twelve months.

This isn't complex work. It doesn't require a consultant (though one helps). It requires discipline — taking the time to define the problem properly before you start spending money on the solution.

The businesses that get technology right aren't the ones with the biggest budgets. They're the ones who do the upfront work.

---

Heath McDonald is the founder of NXT Innings Consulting, a strategic consulting firm working with SMEs on technology, operations, and growth. If you're planning a technology project and want a second opinion on your brief, get in touch.