Software projects rarely fail all at once. They fail gradually, then suddenly—a string of small warning signs that get explained away until the budget is gone, the deadline has slipped, and everyone is asking how it got this bad.
The good news is that troubled projects are remarkably consistent in how they announce themselves. If you know what to watch for, you can catch the slide early, while correcting course is still cheap. Over the years we’ve been brought in to help with our share of these, and the patterns repeat. They aren’t unique to us, either. When IEEE Spectrum looked back across a decade of high-profile IT failures, it found the underlying risk factors had scarcely changed from one disaster to the next—the same short list of problems, again and again. The signs are well known. Projects keep dying on them anyway.
Here are eight of the most reliable warning signs—and what to do about each one.
1. “We’re 90% done”—and have been for two months
This is the classic. Status reports stay optimistic, but the finish line never arrives. Usually it’s because the remaining “10%” is the integration, the edge cases, and the hardening that nobody scoped—the genuinely hard part dressed up as a rounding error.
What to do: Stop measuring progress by activity and start measuring it by working, demonstrable software. Ask for a live demo of a complete, end-to-end slice—not a percentage on a slide. If no one can show you one, that’s your real completion number.
2. There’s no real architecture—or the one you have doesn’t fit the problem
This comes in two flavors: sometimes there’s no deliberate foundation at all, and “the architecture” is just whatever the code happens to do today; other times one was chosen, but for the wrong problem—a real-time need built on batch-oriented plumbing, or a sprawl of microservices where a single solid application would have done. Either way the tell is the same: every new requirement feels disproportionately hard, and the team fights the foundation instead of building on it. And the mismatch usually isn’t about what the system does—that part often works fine. It’s about the requirements around the edges: how much load it carries, how fast it responds, how it keeps data safe, how it’s expected to change.
What to do: Make the architecture explicit and hold it up against the real requirements, especially the ones about scale, performance, security, and evolution. If no one can explain why the system is shaped the way it is, that’s the gap to close first. Correcting a foundation early is manageable; discovering at go-live that it can’t carry the load is not.
3. Requirements keep shifting, but the plan doesn’t
Some change is healthy; software that can’t adapt to what you learn along the way isn’t worth much. The danger sign is when new requirements arrive continuously while the budget, timeline, and team stay fixed. That’s the silent recipe for a death march.
What to do: Make the trade-offs visible. Every “small addition” should be logged against scope, cost, or date. You don’t have to say no to change—you have to stop pretending it’s free.
4. The business and the developers have stopped really talking
Status meetings still happen, but they’ve become theater. Updates flow up, questions don’t flow down, and the people who understand the problem aren’t actually talking to the people building the solution.
What to do: Get a domain expert and a builder in the same room—or on the same call—on a regular basis, with explicit permission to disagree. Most failing projects aren’t failing on technology. They’re failing on a shared understanding of what’s being built and why.
5. Bugs are outpacing features
Each release fixes two things and breaks three. The team spends more time firefighting than building. This is almost always accumulated technical debt and missing test coverage coming due, with interest.
What to do: Track the ratio of defect work to feature work over time. If it’s climbing, that’s a signal to pause new features and invest in stabilization—tests, refactoring, the unglamorous infrastructure. It feels like slowing down. It’s actually how you start moving again.
6. Deployments are scary
If releasing to production is a high-stress, all-hands, late-night event that people dread, the project has a fragility problem—and it will only get worse as the system grows. Fear of deploying is fear of the software itself.
What to do: Make releases boring. Automate the build and deployment pipeline so shipping becomes a routine, low-drama act rather than a heroic one. The goal is to deploy small and often, not rarely and at great personal cost.
7. The people who know how it works are leaving—or are the only ones who know
Key developers burning out, going quiet, or quitting is a leading indicator, not a lagging one. A close cousin is a “bus factor” of one: a single person holding critical knowledge entirely in their head. Either way, you’re one bad week away from a crisis.
What to do: Treat concentrated knowledge as a risk to manage now, not a problem to discover after someone walks out the door. Pair people up, document the load-bearing decisions, and take morale signals seriously. They’re far cheaper to address early.
8. No one will give you a straight answer on status
When questions about timeline or budget get hedged, deflected, or buried in qualifiers, it usually means the honest answer is bad and no one wants to be the one to say it out loud.
What to do: Make it safe to deliver bad news. Reward the person who surfaces a problem early instead of punishing the messenger. A project that can’t tell the truth to itself can’t course-correct.
The pattern underneath
Read back through the list and you’ll notice something: most of these are management and communication failures wearing a technical costume. Even the architecture problem is usually less about a bad technical decision than about no one stopping to ask whether the foundation still fits the problem. The technology is rarely what sinks a project. What sinks it is the slow erosion of honesty, feedback, and a shared understanding of the goal. Researchers landed on the same conclusion long ago: MIT Sloan Management Review has noted there is near-universal agreement that large-scale IT failures happen for managerial reasons, not technical ones.
That’s also why these signs are so easy to miss from the inside. Each one, on its own day, has a reasonable-sounding explanation. It takes a bit of distance—and usually a few scars from past projects—to see them adding up.
If any of these feel a little too familiar, the encouraging news is that recognizing the pattern is most of the battle. Caught early, every one of them is fixable. Caught late, they’re expensive. The difference is almost always how soon someone was willing to look honestly at what the project was telling them.
Sources: Decades of experience; Robert N. Charette, “Why Software Fails,” IEEE Spectrum (2005), and the magazine’s decade-later retrospective on IT project failures; “When Too Much IT Knowledge Is a Dangerous Thing,” MIT Sloan Management Review.
Facing this yourself? See our related service →