A senior leader sees missed dates, unstable releases, rising costs and growing frustration. The vendor looks like the obvious problem.
It may be. It may also be working inside a system where priorities keep moving, decisions wait for an unavailable executive, or an old process makes progress hard to see. Replacing the supplier can change the people in the meetings while leaving the cause untouched.
The difficult task is attribution. Which part of the result belongs to the vendor, which to the client, and which was produced by the way the work was organised?
The answer matters because the remedies differ. A weak vendor may need to go. Slow internal decisions need fixing on the client side. An obsolete delivery process needs changing. More than one can be true.
Poor results are evidence, not yet a diagnosis
A bad outcome should not be explained away. If delivery keeps missing what the business needs, the executive responsible for it must respond even when an external company does the work.
But the result alone does not identify its cause.
Take a delayed release. The vendor may have estimated badly or assigned people without the required capability. The product owner may have changed priorities while holding the date fixed. An internal security team may control an approval that was absent from the plan. Two suppliers may each finish their component while nobody takes responsibility for the integration.
These are competing explanations, not excuses of equal merit. They require different evidence and different action.
The opposite mistake is to let shared responsibility cover for a supplier that avoids commitments, reports activity instead of progress, or waits while a known risk grows. Complexity does not remove the need to identify who failed to do what.
Measurement gets harder when control is divided
“Define clear KPIs” sounds sensible until several organisations contribute to the same result.
Useful vendor KPIs are difficult to define and measure in mixed teams. A release date may depend on a client product decision, vendor implementation and another supplier’s integration. Defect counts can reflect code quality, testing practice or the boundary between teams. Velocity may say more about a team’s estimating convention than about business progress.
No single number resolves this. A large dashboard can hide the ambiguity as easily as no dashboard.
Start instead with a commitment and its boundary. What did the vendor agree to produce? Which inputs did it need? Which decisions could it make, and which dependencies could it influence without controlling? If a dependency failed, what had the supplier agreed to do about it?
This will not produce a universal set of vendor KPIs. It gives the available evidence a fairer meaning. A missed commitment is different when the supplier had the required access and authority than when work waited on a client decision.
Waiting is not an acquittal. A capable vendor should surface the block early, explain the consequence and offer workable options. The relevant evidence therefore often sits at the boundary: when the problem became known, who could resolve it, what each side did, and whether the plan changed honestly.
Those facts still may not make attribution easy. They make it less arbitrary.
Examine the conditions the client created
Some organisations are hostile to vendors without describing themselves that way. They delay access, exclude suppliers from decisions that affect their work, then expect full responsibility for the result. They ask for challenge but punish disagreement. Procurement buys capacity while the executive sponsor expects the supplier to own an outcome.
Resentment builds in that arrangement. The client sees a defensive vendor; the vendor sees a client it cannot satisfy. Each incident reinforces the conclusion already forming on both sides.
That does not make the client responsible whenever a vendor struggles. A supplier should identify conditions that prevent delivery rather than quietly accept them and keep billing. It should state what is blocked, what it needs and what happens if nothing changes. Silence and vague escalation are evidence about the vendor too.
The executive sponsor should inspect whether the client supplied promised information, gave somebody authority to make product and technical decisions, and let that person accept difficult compromises. They should also ask whether bad news brings attention or punishment.
A supplier cannot fairly be judged for decisions it was never allowed to make. Limited authority is not a defence for failures within its control.
Judge the misses, not the mood
Instead of debating whether the relationship feels good or bad, review a few misses that mattered. For each one: what was agreed, what changed, who knew, who could decide, and what did each party do next?
If the vendor controlled the work, had the required inputs and still failed without early warning or a credible response, the case for replacement strengthens.
If work repeatedly stops at client decisions or unmanaged dependencies, changing the vendor alone is unlikely to fix delivery.
If commitments and boundaries were never clear enough to separate responsibility, the company may still have chosen a poor supplier, but it does not yet have enough evidence to know. If the relationship is still recoverable, the next step is a fair test: make the expected result, decision rights, dependencies and response to another miss explicit.
That test costs time and money if replacement was already the right answer. Replacing too soon also has a cost: transition, lost context and the risk of putting the next supplier into the same conditions.
The responsible executive has to choose which uncertainty the business can bear. Outsourcing the work does not remove that decision.
When this matters
How can a senior leader tell whether a software vendor is underperforming?
Execution, not consulting.
If you are looking for another strategy deck, Safyron is probably not the right fit. If you need someone who will still be there when the difficult work starts, read how Safyron operates.