Nobody plans for this part, so when it arrives it gets handled emotionally. The project is four months late, the last two updates were vague, and somebody senior asks whether we should just find someone else. That question is reasonable and it is being asked too early.
What switching actually costs
Worth pricing before it becomes the default answer, because it is consistently underestimated.
Three to six months of effectively no progress is a fair planning assumption, and that is the good version where handover happens and you own the code and infrastructure. If you do not, which is worth checking now rather than then, read what you should own when a build ends first.
None of which means never switch. It means switching has to beat the alternative by more than most people assume when they raise it.
Diagnose first: late, wrong, or silent
Late but right is the most common and the most recoverable. Estimates were optimistic, or scope grew a feature at a time without anyone re-baselining. Both are fixable in a room with the original scope document open. The general mechanics are in why software projects run over budget.
On time but wrong is a communication failure, and the uncomfortable part is that it usually implicates both sides. Requirements were interpreted differently, and nobody found out for six weeks because the review cycle was six weeks long. Shortening the loop fixes more of this than changing supplier does.
Silent is the serious one. When you cannot get a straight answer about where things stand, there are two possibilities and both need immediate action: something is going wrong that is being managed rather than reported, or the supplier genuinely does not know either. The second is more common and, oddly, more worrying.
Check your own side before the difficult meeting
This is the section people skip, and it is the one that changes outcomes. A large share of failing engagements have a significant cause on the client side, and if you switch supplier without fixing it you will reproduce the problem with a more expensive team.
- How long do we take to answer a question? Track it for two weeks. Decision latency is the largest schedule cost on most projects and it sits entirely on your side of the table.
- Has the scope changed, and did we re-baseline? Ten small additions that each felt free are not free, and if the plan was never updated then the plan is not late, it is fictional.
- Is there one decision-maker? If three stakeholders give conflicting feedback, the supplier is not failing to deliver, they are failing to reconcile your organisation, which is not something you hired them for.
- Did we give them what they asked for? Access, test data, environments, the person who knows how the old system works. Blocked work looks identical to slow work from the outside.
- Was the brief specific enough to build from? Ambiguity gets priced or discovered, and discovery happens in the middle of a build.
- Are we reviewing, or approving? Sign-off without real examination moves the problem later and makes it more expensive.
Doing this genuinely, rather than as a box-tick, also changes the conversation you are about to have. Arriving with “here is what we have got wrong, and here is what we need from you” produces a different response than arriving with a complaint.
The meeting to have
Not a demo. Demos are built to reassure, and by this stage reassurance is the problem. Ask for three written things, in advance, in a document:
- The original scope, against current status, item by item. Done, in progress, not started, descoped. No narrative.
- Everything added or changed since, with who requested it. This is usually where the missing months are, and both sides are frequently surprised.
- The specific blockers, named, with who owns each one. A list where everything is blocked on the client tells you something. So does a list with no blockers on a project that is four months late.
How a supplier responds to that request is itself diagnostic. A team in trouble but being straight will produce it, and it will be uncomfortable reading. A team producing more narrative, or another demo, has answered you.
One request belongs in the same message and should not be negotiable: access to the repository, the environments and the deployment pipeline, now. Not a zip file. If you do not already have this, that is a finding in itself, and getting it is both a genuine diagnostic and the thing that preserves your options. A supplier who resists has told you what to plan for.
What a reset looks like
If the diagnosis is recoverable, do not carry on with a vague promise to improve. Reset explicitly:
- A short milestone, four to six weeks, with a small scope everyone signs. Long enough to be real, short enough that failure is cheap.
- A named decision-maker on each side, with an agreed response time for questions. Put the number in writing, and hold your own side to it.
- Weekly written status in the format above. Not a call. Writing forces specificity.
- A stated decision point at the end. Everybody knows the milestone is the test, which is fairer than a quiet re-evaluation nobody was told about.
- Handover artifacts produced regardless, documentation and credentials, as part of the milestone. If the reset works you needed those anyway, and if it does not you are ready.
That last item is the one to insist on, because it costs nothing if things improve and saves months if they do not.
When to actually leave
Three signals justify ending it, and the third is different in kind from the others.
- A missed reset. You agreed a small scope and a date with a named owner, and it was missed without early warning. One missed estimate is normal. Missing the milestone that existed specifically to test the relationship is information.
- Continued refusal of access. To the repository, the environments, the deployment process. There is no legitimate version of this on a project you are paying for.
- You discover you do not own what you assumed. Infrastructure in their account, no IP assignment, third-party licences in their name. This is not a performance problem, it is a leverage problem, and it usually means negotiating an exit rather than announcing one.
If you do leave, leave properly. The exit is worth more than the argument: a clean handover with an overlap period, documentation, credentials and a bounded support tail preserves months of value, and how to get one is in handing over a software project without losing momentum.
Resist the urge to brief the incoming supplier purely on how bad the last one was. It feels natural and it produces a worse outcome, because the new team then attributes everything they find to the predecessor rather than examining it, and because a client whose opening story is about a failed relationship gets priced with a risk premium. Give them the codebase, the real requirements and an honest account of what went wrong on both sides.
Preventing the next one
Most of what is written above is a symptom of decisions made before the contract. Specifically: a brief too vague to build from, no named decision-maker, no short first milestone to test the working relationship, and no exit terms agreed while everybody still liked each other.
The prevention is unglamorous and cheap: choose deliberately, write a brief that can be priced, structure the contract so there is a natural decision point early, and settle ownership and exit at the start when you have leverage rather than at the end when you have none.
We are sometimes the second supplier on a project, and the first thing we do is read the code rather than agree that the last team were idiots. Occasionally the answer is that the existing relationship is fixable and we say so. If you are in this situation and want an outside read, describe what is happening.
Common questions
Should I switch software development suppliers?
Rarely as a first move. Switching costs a handover, months of ramp-up on an unfamiliar system, a repeat of the requirements conversation, and the rediscovery of everything the first team learned the hard way. Three to six months of effectively no progress is a fair assumption, and that is the good version where you own the code and infrastructure. Diagnose whether the problem is lateness, wrong output or lack of visibility first, because the first two are usually fixable without changing supplier.
How do you tell whether a software project is really in trouble?
Separate three symptoms. Late but delivering correct work usually means estimation or unbaselined scope growth, and is recoverable. On time but wrong usually means a requirements and feedback problem, often partly on the client side, and shortening the review cycle fixes more of it than changing supplier. Being unable to get a straight answer about status is the serious one: it means something is being managed rather than reported, or nobody knows, and it justifies immediate escalation.
What should I ask a supplier when a project is going badly?
Three things in writing, in advance, not a demo: the original scope against current status item by item with no narrative, everything added or changed since with who requested it, and the specific blockers with an owner for each. Ask in the same message for access to the repository, environments and deployment pipeline. How a supplier responds to that request is itself the most useful piece of information you will get.
How much of a failing project is usually the client’s fault?
More than most clients expect. The recurring causes are slow decisions, scope that grew without the plan being re-baselined, multiple stakeholders giving conflicting feedback with no single decision-maker, and access or test data the supplier asked for and never received. None of that excuses poor delivery, but changing supplier without fixing it reproduces the same outcome with a more expensive team.
Note on sources
This article is drawn from delivery practice rather than published research, including from being the incoming supplier on projects that had gone wrong. There is no reliable public dataset on why client and supplier relationships fail, and we have not invented percentages to imply one.
Where it touches material that is measured, the underlying figures sit in the linked articles: overrun data in why software projects run over budget, and the post-handover output dip in handing over a software project without losing momentum.
Written September 2026.
