Why do technology projects fail in small businesses?

Almost never because the technology did not work. Small business technology projects fail for four reasons, in roughly this order: nobody owned it, the outcome was never defined, people were not trained properly, and nothing was measured afterwards. All four are management problems wearing a technical costume.

This is worth saying because the usual conclusion after a disappointing project is that the software was wrong, which leads to buying different software and repeating the experience. Occasionally the product genuinely is a poor fit. Far more often the same product is working well for a comparable business down the road, and the difference is entirely in how it was introduced.

The most common failure is no owner. A project needs one person inside the business who wants it to succeed and has the authority to make decisions, and in small businesses that role is often left implicitly with the provider, who cannot make anyone change how they work. When the owner is nobody, decisions wait, scope drifts, and the project quietly becomes a piece of software that exists rather than a change that happened.

The second is an undefined outcome. Implement a new job-management system is not an outcome; it is an activity. Quotes go out the same day rather than the following week is an outcome, because you can tell whether it happened. Projects without a written, measurable outcome cannot be finished, since there is no moment at which everyone agrees it is done, so they fade instead, which is why so many end without anyone declaring either success or failure.

The third is training, which is consistently the first thing cut when a timeline slips. An hour of demonstration at go-live is not training, because people cannot absorb a new system before they have tried to do their actual job in it. The pattern that works is a short session at launch and a second one a fortnight later, when everyone has hit real problems and has real questions. That second session is inexpensive, almost always skipped, and largely determines whether people adopt the system or build workarounds.

The fourth is no measurement. Without a before-and-after number, nobody can say whether the project worked, which has two consequences. Improvements that did work go unrecognised, so the next proposal is harder to fund. And changes that did not work persist, because admitting it feels like admitting a mistake rather than reading a number. Measure two things before you start and the same two afterwards, and both problems disappear.

There is a fifth cause specific to small businesses and worth naming: the project competes with the day job. The person best placed to lead it is usually the busiest, and technology work loses to whatever is urgent this morning, every morning. The fix is scheduling rather than willpower, meaning a recurring block that is treated as immovable and a scope small enough to fit inside it. Projects that require someone to find time never finish.

The pattern that works at this scale is unglamorous. One named owner. One sentence describing the outcome and how it will be measured. A scope small enough to complete in weeks rather than quarters. A weekly check-in that reports honestly, including when something has slipped. Training at launch and again a fortnight later. And a defined end, with the numbers compared and the result stated out loud. Our own onboarding runs as a PRINCE2-managed four-week programme with weekly updates for precisely these reasons.

There is a sixth cause worth naming because it is the most avoidable: scope that grows while the project runs. Every added requirement is individually reasonable and collectively fatal, because the finish line keeps moving and the team stops believing the project will ever end. Write the scope down, agree that additions go on a list for afterwards rather than into the current work, and be willing to finish something imperfect on time rather than something complete eventually.

The honest caveat is that a provider cannot supply the owner or the decision, and any provider claiming otherwise is overselling. We can run the project properly, report honestly and do the technical work well. Whether the business decides the job will now be done differently is the part that belongs to you, and it is the part that determines the outcome. If you want a project run with those four things in place, call 1800 456 567.