The early warning signs your software project is in trouble

A software project almost never fails in one dramatic moment. There is no single day when it breaks. Instead it falls behind, one small delay at a time, and every delay comes with a reasonable explanation. The demo moved because someone was sick. The feature is almost done because the last bug is difficult. The team is quiet because they are focused. Each excuse is believable on its own, which is exactly the problem. By the time the excuses have added up to something nobody can deny, months have passed and most of the budget is gone. The failure was visible the whole time. It just did not look like failure yet.

We have joined many projects while they were already running, often after they were already in trouble, and the early signs are almost always the same. Here they are, and what to do about each one while doing something still helps.

The demo keeps getting delayed

The scheduled demo gets delayed. Then it gets delayed again. Each time there is a good reason, and each reason is believable. The trouble is what a repeated delay usually means: the team does not have working software to show, and moving the date is a way to get more time and hope the situation improves before you look.

Real progress can always show something. It might be rough, half-finished, ugly, with obvious missing parts, but a team that is genuinely building can put something on the screen. When a demo moves a second and third time, stop accepting the reschedule. Ask to see whatever exists right now, in whatever state it is in. A healthy team will happily show you messy unfinished work and explain what works and what does not. A team in trouble will find another reason to wait. The willingness to show unfinished work is the sign to watch, not how finished the work looks.

"Almost done" for weeks

You ask how it is going, and the answer is "almost done." You ask again the next week, and it is still "almost done." Nothing has reached users in between. This is one of the most reliable warning signs there is, and it means one of two things, both bad.

Either the last ten percent is hiding the hardest ninety percent of the work, which happens constantly in software because the final part is where all the messy real-world details are, or the team genuinely does not know how close they are and "almost done" is a hopeful guess presented as a status. You can show real progress. It is released, or it runs, or a user tries it. If the status stays "almost done" for weeks with nothing becoming something you can use, the honest conclusion is that nobody knows how much work is actually left, which means the deadline is not real. The fix is to stop accepting "almost done" as an answer and ask instead: what can I use today, and what specific work remains before the next thing a user can try?

There is no working software you can use

This is the most important sign, and it is the cause of the first two. Working software is the only reliable evidence of progress. Everything else can look healthy while the actual product does not run. The plan can be detailed, the status reports positive, the meetings productive, the documents thorough, and none of it tells you whether the thing works, because documents and slides cannot fail the way running software can.

So the question that answers all of it is simple: can I open the product right now and use it? If weeks have gone by and the answer is still no, that is the clearest sign of trouble, no matter how good everything else looks. The strongest teams produce working software early and keep producing it, because they know it is the only honest measure. This is not just our opinion. The long-running DORA research on how software teams actually perform keeps finding that teams releasing in small, frequent increments have lower failure rates than teams that release rarely in big batches. Frequent working software is both how good teams work and how you, as the buyer, make sure they report truthfully. If there is no working software to show, nothing else on the status report is trustworthy.

Scope is growing without anyone deciding

This one is hard to notice, which makes it dangerous. The project slowly gets bigger than what was agreed, but nobody ever made a decision to make it bigger. A feature gets added because it seemed obviously needed. An unusual case gets handled because someone thought of it. A "small" extra flow gets built because it felt wrong to leave it out. Each addition is small and reasonable on its own. Together they turn the project into something much larger than the plan and the deadline were built for.

The reason this hurts so much is that the project falls behind for a reason nobody chose on purpose. If you had decided to double the scope, you would have moved the deadline and the budget to match. Instead the scope doubled by accident, in pieces too small to notice, while the deadline stayed the same. The fix is to make scope changes visible and deliberate. Every time something new gets added, someone should say out loud that it is new and decide whether it is worth the time it costs. This is closely tied to keeping the build small in the first place, which we wrote about in build vs buy: when custom software is actually worth it: the bigger the project grows, the more places it has to go wrong, and unmanaged scope creep, meaning work that grows without anyone deciding to add it, is how small projects slowly become big risky ones.

Communication goes quiet

Notice when the updates change. They get vaguer, or slower, or they stop coming without you having to chase them. It is tempting to read silence as focus, as if the team is concentrating and working hard. Sometimes that is true. Often it is not.

Teams that are doing well tend to share, because they are proud of what they are making and they want you to see it. When communication goes quiet, or turns into reassurance with no specifics, it frequently means there is bad news that nobody wants to be the one to deliver. Treat silence as information, not as a sign of hard work. Ask direct questions and do not settle for "it's going well." Ask to see the working software, ask what is not working, ask what they are worried about. A healthy team answers plainly, including the bad parts. A team in trouble avoids the question, reassures, and changes the subject. If you feel something is wrong and the words say everything is fine, trust the pattern over the reassurance. We list more of these warnings about the working relationship in warning signs when hiring a software development agency.

The one habit that catches almost all of it

If you read back over these five signs, they share one cause, and so does the fix. Demos that slip, endless "almost done," no usable product, invisible scope creep, and quiet communication are all ways of hiding the same thing: a difference between what people say about the project and its reality. The single habit that removes that difference is small, frequent releases of working software you can actually open and use, every week or two, from the very start.

That one practice exposes almost every warning sign automatically. A team that has to show something real every week cannot hide a lack of progress behind a status report. Scope creep shows up immediately, because the extra work delays the next visible release. "Almost done" becomes "here, use it." And communication stays honest, because there is a real thing to talk about every week instead of a plan on paper. None of these signs is a final decision. They are early warnings, and if you act on them when you first notice them, most projects can still be brought back to the plan: shrink the scope, demand working software, and have the direct conversation you have been avoiding. The projects that fail are rarely the ones that showed a warning sign. They are the ones where everyone kept explaining the warning signs away until the money ran out.

The warning sign that looks like success

Add one to the list, because it does not resemble any of the others.

Every warning sign above shows up as visible slowness. This one shows up as visible speed. Changes are released quickly, demos go well, the board is happy, and at the same time a large amount of code has entered the system that no human has read closely. The team's understanding of its own product is falling behind the product.

You can test for it in one meeting. Pick a change from the last two weeks and ask who read it and what it does. If the answer is confident and specific, you are fine. If the answer is that the tests passed, you have found the problem, and the reason it is dangerous is that nothing on your dashboard is going to tell you.

Sources

• DORA, Accelerate State of DevOps research: https://dora.dev/research/