Failed software projects have consistent failure signatures. The symptoms vary — missed deadlines, scope creep, budget overruns, regressions on every release — but the underlying causes are limited in number and, once correctly identified, addressable.
The problem is that by the time leadership recognizes a project is failing, the diagnosis is usually wrong. The vendor or internal team presents a confident narrative about why things are behind and why the next sprint will be different. Without independent technical assessment, there is no reliable way to evaluate that narrative.
This is the diagnostic framework Anubis uses when engaged to assess a project in distress.
1. Establish the Actual Completion Percentage
The first task is to establish ground truth about how complete the project actually is — not according to project management reports, but according to the working software. We review the original specification, the current codebase, and the remaining gap.
Projects frequently appear to be 80% complete based on task boards but are 40% complete when evaluated against the full specification. The "remaining 20%" is almost always the hardest 20%: edge cases, performance under load, integration testing, and deployment infrastructure.
Task completion percentage and software completion percentage are not the same number. Establish the latter from the codebase, not the project management tool.
2. Identify Whether the Failure Is Personnel, Process, or Architecture
Almost all software project failures trace back to one of three root causes: the wrong people in the wrong roles (personnel), an engineering process that does not produce reliable, testable software (process), or a foundational design that cannot be built on the original timeline (architecture).
Each requires a different intervention. Replacing personnel without fixing a broken architecture does not work. Fixing the process when the problem is architectural is equally futile.
3. Determine Whether the Project Is Salvageable
Not every failing project should be rescued. Some projects are based on architectural premises that are fundamentally wrong and cannot be salvaged without a complete restart. The honest assessment is whether the effort required to rescue the current codebase exceeds the effort of starting over with better decisions.
This is the question that internal stakeholders — who have sunk significant capital into the current approach — are structurally incapable of answering honestly. It requires an independent perspective.
4. Define the Minimum Viable Recovery
If the project is salvageable, the recovery plan must identify the minimum viable path: which scope can be cut, which technical debt can be deferred, and what must be rebuilt to create a stable foundation.
Recovery plans that attempt to salvage everything and add more features simultaneously almost always fail. A triage-first approach — stabilize, cut, ship a reduced scope — has a significantly higher success rate.
The most expensive moment in a failing software project is the decision not to get an independent assessment. Every week of continued investment in a project with a misdiagnosed root cause is capital destroyed. The cost of an independent triage engagement is almost always a fraction of what would be spent without one.
Facing this decision? Anubis can independently assess the system, establish the technical facts, and give you a decision-ready recommendation.