The hardest position in a software project is the one where you are fairly sure something is wrong and cannot yet say what. The reports are green. The vendor is responsive. The team is busy and the meetings are civil. But the date has moved twice, nobody outside the project has used anything, and the answers to your questions have started to arrive as reassurance rather than as evidence. That gap between instinct and proof is where most of the money is lost, because a sponsor who cannot prove a problem will usually wait one more cycle. This page is about closing that gap in days rather than quarters.
The signals that are actually diagnostic
Plenty of things look alarming and are not. Missed sprint commitments, defect counts, turnover of a junior engineer, and a tense retrospective are all noise in any real project. A small number of signals are different, because they cannot occur in a healthy project regardless of methodology, team size, or domain.
- There is no working software in an environment you can reach. Not a prototype, not a recorded video, not a build on a laptop. If eight weeks or more have passed and you cannot open a URL and use the thing, that is the finding.
- Every demo shows the same path. The same customer record, the same order, the same three clicks. When you ask to see a different record, or an error case, or what happens on a phone, the answer is that it is not wired up yet.
- The project has been "90% done" for more than one reporting period. Percentages that stop moving while the team stays busy mean the remaining work was never sized, not that it is nearly finished.
- Progress is reported as velocity, story points, or tickets closed rather than as capabilities a person can use. Internal engineering metrics are useful to a team and meaningless to a sponsor; when they become the headline, something is being substituted for outcomes.
- The vendor controls all access to the source code, the cloud accounts, and the deployment pipeline, and requests for access are met with process rather than credentials. Whatever the reason given, the effect is that you cannot verify anything independently.
- Nobody will name a date for the first production use by a real user, only dates for internal milestones such as code complete or QA handoff.
The last one deserves particular weight. Access is what turns a delivery problem into a negotiating problem. A vendor holding the only copy of the repository knows that replacing them costs you the work, and a vendor who knows that has little incentive to surface bad news early.
Establish ground truth before you escalate
Do not open with an accusation, and do not commission a three-month audit. Both defer the moment where you look at the actual system. Most of the factual picture can be assembled in under a week by someone technical you trust who is not on the project.
- 1
Get a copy of the repository. Not a report about the repository, but a clone you keep. If your contract entitles you to it, exercise that right in writing; if it does not, that is the first fact you have learned.
- 2
Have someone build and run it from a clean machine using only the written instructions. How long that takes, and how much undocumented knowledge it requires, tells you more about the state of the project than any status deck.
- 3
Read the commit and deployment history. Look at when code was written, by whom, and how often anything reached a real environment. A repository with a burst of activity before each demo and quiet weeks between them describes the project accurately.
- 4
Look for tests, error handling, and configuration. You are not grading elegance. You are checking whether the parts that make software survive contact with users exist at all.
- 5
Talk to the engineers directly, without the account manager or delivery lead in the room. Ask what worries them, what they would cut, and what they have raised that went nowhere. Engineers rarely misrepresent the state of a system when asked plainly.
- 6
Ask one question of every stakeholder separately: what will this system let the business do that it cannot do today? Collect the answers verbatim and compare them.
That last step is not a formality. If the answers are incompatible with each other, you have not found a delivery problem. You have found an unresolved decision that the project has been absorbing on your behalf, and no change of vendor or methodology will fix it.
Signal, meaning, next move
| Signal | What it usually means | What to do next |
|---|---|---|
| No working software in a reachable environment after eight weeks | Integration and deployment have been deferred to the end, so nothing is truly finished | Require one narrow workflow deployed to a real environment within two weeks, with no new features started until it is |
| Demos always show the same happy path | The demo is built for the demo; error cases, permissions, and real data are untouched | Ask to drive the demo yourself with a record you choose, and treat refusal as the answer |
| "90% done" across multiple reporting periods | The remaining work (migration, permissions, reporting, integrations) was never estimated | Ask for a written list of everything not yet started, then re-estimate from that list rather than the original plan |
| Progress reported as velocity or tickets closed | Activity is being reported because outcomes cannot be | Change the reporting unit to capabilities in production, and accept a worse-looking chart |
| Vendor holds all code, cloud, and pipeline access | Your ability to verify or exit is constrained, deliberately or by neglect | Take ownership of the accounts and a repository copy now; raise the contract terms with your counsel |
| Stakeholders describe the goal in incompatible ways | An internal decision has not been made and the team is guessing at it weekly | Pause the build and force a written decision on scope and ownership before spending more |
| Senior engineers have left and been replaced quietly | The people who understood the domain are gone; remaining knowledge is thin | Assess what is documented, and price the risk of continuing with the current team honestly |
Three root causes, three different remedies
Once you have facts, the useful question is which of three things is actually wrong. They present almost identically from the outside and the remedies do not overlap, which is why so many rescue attempts fail: the sponsor applies the wrong fix confidently.
Scope and sequencing
The team is competent and the goal is clear, but the plan front-loads breadth and defers everything hard. Nothing is releasable because every part is half-built, and the work that determines feasibility (data migration, permissions, the integration nobody owns) sits at the end. This is the most common cause and the most recoverable. The fix is to stop all in-flight work, pick one workflow that a real user can complete end to end, and ship it into production, including the unglamorous parts. If the team can do that in a few weeks, the project was never failing in a structural sense.
Capability
The work is genuinely beyond the team, usually because the engagement was sold by people more senior than the ones delivering it. The signature is code that works in the demonstrated case and falls apart at the edges, no meaningful test coverage, and an inability to explain design decisions when asked. Scope resets do not fix this; the same team will produce the same result on a smaller surface. This is the case where changing who does the work is the only remedy that matters, and delaying it is expensive because every additional week adds code that will eventually be rewritten.
An unresolved internal decision
Two executives disagree about direction and neither will arbitrate, so requirements arrive contradictory from equally legitimate authorities. Engineering builds the ambiguity into the system, and the project becomes a proxy for an argument nobody is having out loud. No vendor can fix this, and any vendor who says they can is selling you months. The remedy is organizational: name a single decision-maker for scope, get the decision in writing, and only then restart delivery. Sponsors resist this because it makes an internal problem visible, which is exactly why it works.
The four options
Whatever the cause, the decision reduces to four choices. Most sponsors consider two of them.
- Reset scope. Keep the team and the contract, cut the target to one workflow that reaches production quickly, and treat the next four to six weeks as a test of whether delivery is possible at all. Appropriate when the cause is scope and sequencing.
- Change the contract and the operating model. Move from fixed-bid to incremental funding tied to delivered capability, take ownership of code and infrastructure, and set reporting on outcomes. Appropriate when the relationship is salvageable but the incentives are pointed the wrong way. Terms and exit rights are a matter for your counsel, not for the vendor's standard agreement.
- Replace the vendor. Assume a transition cost (someone has to take over an unfamiliar codebase) and budget for a short assessment before any new build starts. Appropriate when the cause is capability, or when access has been withheld.
- Stop. Write off the work, keep whatever is genuinely useful, and redirect the budget. Appropriate when nobody can articulate what the system will let the business do, or when the honest re-estimate exceeds the value of the outcome.
Stopping is treated as a career risk, which is why it is chosen too rarely and too late. In practice the sponsor who halts a project at $400,000 with a clear written rationale is in a far better position than the one who reaches $1.4M defending a decision made a year earlier. Write the rationale down at the time. It is the difference between a judgment call and a failure.
The first ten days
If you take nothing else from this: get the code, get the cloud accounts, run the software yourself, and require one narrow workflow in production within two weeks. Those four actions cost almost nothing, are reasonable to ask of any vendor operating in good faith, and produce more signal than another quarter of status meetings. A team that meets them was probably recoverable. A team that cannot has told you what you needed to know while the decision is still cheap.
Common questions
- How do I raise this without blowing up the relationship?
- Ask for artifacts rather than opinions. Requesting a repository copy, environment access, and one workflow deployed to production are normal asks in any healthy engagement, and framing them as standard practice keeps the conversation factual. A vendor operating in good faith will treat them as reasonable; one that resists has given you information you did not have before.
- The vendor says the code cannot be shared for security or IP reasons. Is that normal?
- It is common and it is usually a negotiating position rather than a constraint. Work you are paying to have built is ordinarily work you should be able to inspect, and access can be handled with the same controls the vendor's own engineers work under. What you can require depends on what you signed, so take the specific terms to your counsel rather than arguing them yourself.
- How long should a rescue assessment take?
- Two to four weeks for a project of meaningful size. That is enough to build and run the system, review the code and deployment history, interview the team, and produce a costed recommendation. Anything longer usually means the assessment has turned into the next phase of the project, which defeats the purpose of running one.
- Can any of the existing work be salvaged?
- Often more than the sponsor expects, though rarely the parts they assume. Domain modeling, data mapping, and integration work usually retain value even when the application code does not, because the expensive knowledge is in understanding the business rules rather than in the implementation. Decide this after someone has read the code, not during the conversation about whether to continue.
- What if the project is failing because of our own people, not the vendor?
- That is a real and reasonably common outcome, usually taking the form of unavailable decision-makers, requirements that change monthly, or two executives who disagree about direction. Changing vendors in that situation reproduces the failure with a new logo and a new transition cost. Fix the decision structure first, then restart delivery with whoever is best placed to execute.
- Is it worth finishing something we no longer need just to have something to show?
- No. Completing software nobody will use converts a loss into a larger loss and adds a system somebody has to maintain. If part of the work has standalone value, extract that part deliberately and retire the rest, with a written record of why. That record is what protects the decision later.