Why software projects fail

What abandoned software projects have in common is rarely technical. The six causes below are the ones we see most often in the projects we inherit.

1. The problem was never defined

The project starts with "we need a CRM." Nobody asks which job it is supposed to make easier. Six months later there is a CRM and nobody uses it, because the old way is still faster.

Prevention: Before starting, write the problem you are solving in one sentence. If you cannot write it, you are not ready. "Sales spends about 15 minutes finding quote history" is a good sentence. "We want to go digital" is not.

2. Everything was crammed into version one

The scope list starts with 60 items, all of them essential. Eight months later none of them are finished.

Prevention: Decide what will not be in the first release. That is harder and more important than deciding what will be. Make the one thing a user will do on day one work properly, and leave the rest for later.

3. Nobody talked to the person who will use it

A manager describes the system; someone else uses it in the field. After launch it turns out the real workflow is nothing like the description.

Prevention: Talk to the person who actually does the work during discovery. What a manager describes is usually how the process should work; the person in the field describes how it does work.

4. Nothing was visible for months

The project starts, four months of silence, then a demo. The demo shows something different from what was expected, and four months are gone.

Prevention: Ask for something working every two weeks. Not slides, something clickable. A wrong direction should cost you two weeks, not four months.

5. There is no single decision-maker

Three people want different things and none of them can settle it. Development changes course at every meeting.

Prevention: Name one decision-maker. Others give input, that person decides. They also need to be available, because in software projects it is waiting on decisions that burns the most time.

6. Launch was mistaken for the finish line

The system goes live and the team disperses. Nobody is left to handle the issues that surface in real use, and users go back to their old habits.

Prevention: Treat the first month after launch as part of the project. Real usage always reveals new things, and if nobody responds at that moment, the system gets abandoned.

Early warning signs

A project does not fail overnight. It signals months in advance. If two of the following are true at once, it is time to change course.

The same topic keeps coming back in meetings. That means a decision was made but never written down. An unwritten decision counts as not made.

Someone says "let us add this too" more than once a week. Scope is growing without control.

Demo dates keep slipping. If there is no working piece to show, there is no progress either.

Nobody on the team uses the system for their own work. If the team will not use what it builds, neither will the customer.

Questions go unanswered. If a developer waits a week for an answer, the project did not move that week.

Can a stalled project be recovered?

Usually yes, but not by continuing to build.

The approach that works goes in this order:

1. Stop. Stop adding features. In a stalled project the most expensive thing is every additional week spent going the wrong way.
2. Write down what exists. Which parts work, which are half-finished, which were never started? This list is almost always different from what everyone assumed.
3. Pick one job. Make the system do one job end to end. One working flow is worth more than ten half-built ones.
4. Put it in front of a real user. Every decision made about an unused system is a guess.

After those four steps a clear answer usually emerges: either the project is recoverable and you continue, or continuing costs more than rewriting.

When it is the second, saying so is uncomfortable but correct. In some of the projects we inherited our advice was to keep the existing system; in others it was to stop building on that code. Both come out of the same review.

The common signal in the projects we inherit

When we examine a half-finished system, the first thing we look at is not the code. It is whether anyone wrote down who decided what, and when. If the reasoning behind architectural decisions was never recorded, everyone who inherits that system re-runs the same arguments from scratch.

That is why every project we deliver comes with the reasoning behind its decisions in writing. Code can be read; why it was written that way can only be guessed.

---

If you have a stalled project, we can assess where it stands. Our approach is on the custom software development page.