3 min read
Why custom software projects fall apart.
Projects rarely fail because the work was hard. They fail on decisions nobody makes, and three signs show up long before it's too late.
When a software project goes wrong, the story told afterwards is almost always technical: it got complicated, it was harder than it looked, the supplier couldn't keep up.
Industry research says otherwise. The Standish Group's CHAOS report (opens in a new tab) lists incomplete requirements and a lack of user involvement as the main causes, not technical difficulty. Projects don't fall apart because the work is hard. They fall apart on decisions nobody makes. The hard part gets solved; the definition left hanging for three weeks is what sinks it.
The good news is that it announces itself. There are signs that show up long before the end, and they're easy to spot once you know what to look for.
Sign 1: "we'll define that later"
The most common and the most expensive.
A question comes up with no answer yet — what happens when a customer pays half, who approves a discount, what to do with old orders — and it gets postponed so as not to slow things down.
The trouble is the work doesn't stop: it gets built around the gap. When the decision finally lands, three weeks later, three parts already assume the opposite. Redoing that isn't an adjustment, it's throwing away work you paid for.
What to do: no open definition without a date. If it can't be decided today, decide it provisionally and write down that it's provisional. An explicit provisional decision costs far less than a hole.
Sign 2: every demo looks like the last one
Every couple of weeks you see something, and every couple of weeks it looks a lot like last month. A screen was added, something moved, but it doesn't feel closer.
That happens when a project is growing sideways instead of forward. Detail piles onto what already exists because the new parts depend on a definition that isn't there. It's sign 1, a month on.
What to do: before starting, agree on what has to be working at the halfway point. Not a list of screens: one complete path, end to end, even if it's ugly. If you can't genuinely use anything by the middle, something drifted.
Sign 3: the person who decides is never in the room
Meetings happen with people who then have to "check with someone". Every definition takes a week to come back, and sometimes comes back changed.
This is the quietest of the three, because everything looks professional: there are meetings, there are notes, there's progress. But the project moves at the speed of the person who isn't there.
What to do: from day one, name who can say "do it this way" without checking. It doesn't have to be the owner. It has to be someone, and they have to show up.
My side of it
It would be comfortable to stop here, as if the supplier only suffered these signs. That's not true.
On the building side, the equivalent failure is not calling a halt in time. It's comfortable to keep invoicing weeks while open questions pile up: the work is real, the hours are real. Stopping to say "this doesn't move until that gets decided" is awkward, and it gets postponed.
If a supplier has never put the brakes on you, that isn't proof your project is healthy. It may mean nobody is protecting it.
What a healthy project looks like
Less dramatic than you'd imagine.
Few things are open and all of them have dates. Every delivery does something that couldn't be done before, however small. Someone on your side decides same-day. And when a problem appears, it gets raised the week it appears, not the week before the deadline.
None of those four things is technical. Which is why a project can have an excellent team and still go badly.
If you're about to start one and want to check these points before you sign with anyone, that conversation is free. Even if we don't end up working together.