Why small business software projects fail

Software projects fail in remarkably similar ways. Having seen a reasonable number of them, including systems I have been brought in to rescue, the causes cluster into a short list. Very few are technical.

This is worth knowing because every item on the list is visible early, if you know what you are looking at.

1. Nobody wrote down how the work actually happens

This is the most common cause by a wide margin. The project starts from how people believe the process works, or how a manual says it should work, rather than what actually happens on a normal day.

The gap between those is always larger than expected. The official process does not include the WhatsApp message that confirms the awkward cases, the informal exception for the largest customer, or the step someone added three years ago that is now load bearing.

Software built on the official version works perfectly in testing and fails in week one of real use, because reality contains all the parts nobody mentioned.

2. The scope was everything, all at once

A specification covering every requirement, a single delivery date many months out, and no usable software until the end. It feels rigorous. It is the highest risk way to run a project.

You find out whether the system fits your business only at the point where changing it is most expensive. Meanwhile the business has moved on from the specification written in month one, so even a perfectly executed build lands slightly wrong.

Staged delivery avoids this, for the reasons covered in how long custom software takes. Something usable in weeks, shaped by real use, beats everything at once every time.

3. The people who use it were never involved

The system is specified by an owner or manager, built, and then presented to the team who will actually operate it. They immediately find a dozen things that do not match how the work is done, because they are the ones who do it.

At that point there are two bad options: pay to change the software, or tell people to adapt. The second usually produces a quiet return to spreadsheets alongside the new system, which is the worst of all outcomes because you now pay for both.

4. The data was worse than anyone admitted

Migration gets treated as a formality until someone opens the spreadsheets properly and finds duplicates, inconsistent formats, and meaning encoded in cell colours.

This derails projects in two ways. It consumes time nobody budgeted, and it forces decisions about data nobody wanted to make, often in the final week before launch when patience is short. Some of the worst launches I have seen were caused entirely by data rather than software. The detail is in moving data off spreadsheets.

5. Nobody owned it after launch

The build finishes, the developer moves on, and the system enters a slow decline. Small issues go unfixed. Nobody has authority to approve changes. Patches are deferred.

Eighteen months later the system technically works but is trusted less each month, and people start keeping their own records again. This is a failure, even though nothing ever broke. What it needed was a named owner and a maintenance arrangement, as covered in what happens after launch.

Warning signs during a project

Each of these is worth raising as soon as you notice it, while it is still cheap to correct.

• You have not seen working software in over a month. Progress described in percentages is not progress you can verify.
• Nobody has asked to watch your team work. A developer who has not observed the actual process is building from assumptions.
• Your data has not been examined yet, but you have a fixed quote. One of those two things is wrong.
• Every question gets an easy yes. Real projects involve trade-offs, and a developer who never mentions one is managing you rather than informing you.
• The people who will use it have not seen it. The longer this remains true, the more expensive the eventual feedback becomes.
• Nobody has discussed what happens after launch. Maintenance, ownership and support should be agreed before you need them.

Projects rarely fail suddenly. They fail slowly, in ways that were visible for months before anyone said so.

What a low risk project looks like

The inverse of the list above is not complicated, and it is worth using as a checklist before you start.

1. 1Somebody spent a day watching how the work actually gets done, including the exceptions.
2. 2The first usable version arrives in weeks, covering one real workflow end to end.
3. 3The people who will use it see it regularly and their reactions change what gets built.
4. 4The data was examined before the estimate, not after the build.
5. 5A named person owns the system after launch, with a maintenance arrangement in place.
6. 6You hold the code, the hosting and the data, so a bad relationship is recoverable.

None of that guarantees success. It does mean that if the project goes wrong, you find out early, while it is still cheap, and you keep something useful either way. That is a much better position than discovering the problem nine months in.