Why projects fail
Why software projects fail
Small business software projects rarely fail for technical reasons. They fail because nobody wrote down what done meant, because the person who needed it was not the person specifying it, or because the build was priced on a guess that nobody revisited once reality arrived. The earliest reliable warning sign is a project where you have not seen the software working in several weeks.
The patterns
- No written definition of done, so every conversation moves the finish line and nobody is lying about it.
- The specification came from a manager and the software is for the shop floor, who will quietly keep using the spreadsheet.
- A fixed price built on an unexamined guess, which turns every later discovery into an argument.
- Long silences. Software you cannot see is not progress you can verify.
What to insist on
- Something working that you can open yourself, every two weeks, however small.
- A written scope that says what is not included as clearly as what is.
- One named person who can decide, on your side and theirs.
- Your code and your data in your own accounts, from day one.
Common questions
- Is fixed price or day rate safer?
- Fixed price is safer when the scope is genuinely known, and actively dangerous when it is not, because the pressure lands on quality. For unclear work, a short paid discovery that produces a written scope is cheaper than either.