How to Know If Your Mobile Problem Is Large Enough to Justify a New Vendor

Not every mobile delivery problem is a vendor problem. Some are process problems - ambiguous requirements, unclear success criteria, insufficient review cycles - that would produce the same outcome with any vendor. Some are team problems - specific engineers who are underperforming - that a good vendor can address without a full change. And some are genuine vendor problems: a team that is fundamentally not capable of delivering what the business requires.

The cost of switching vendors unnecessarily is four to twelve weeks of transition overhead. The cost of staying with the wrong vendor is the continued underdelivery. Getting the diagnosis right before making the decision saves either cost.

Vendor problem vs. process problem

Before evaluating alternatives, diagnose the source of the underperformance. The diagnostic question is: if this same team were working on a different project with clearer requirements and better internal support, would they perform differently?

A vendor problem is a capability or character issue that would produce the same outcome regardless of the client's process quality. An engineering team that does not have the technical skills to deliver the features on the roadmap is a vendor problem. A team that communicates reactively rather than proactively - only surfacing problems after they become delays - is a vendor problem. A team that delivers on technical quality but misses every deadline is a vendor problem.

A process problem is one where the vendor is working against ambiguous requirements, insufficient review cycles, or unclear success criteria. These would produce underperformance with most vendors. Switching vendors does not fix a process problem - it just gives you a new team to work against the same obstacles.

The five signals that point to vendor

Consistent underperformance across multiple projects. A vendor who has delivered late on three successive projects with different teams and different requirements has a pattern, not a project-specific issue. One late project might be process or bad luck. Three consecutive late projects is a delivery model problem.

Technical quality problems after the defect report cycle. A vendor who ships with consistently high defect rates - above 10 to 15 percent of acceptance criteria requiring rework after delivery - has a quality process that is not working. This is a vendor problem, not a scoping problem.

Communication that is reactive rather than proactive. A vendor who reports status only when asked, who surfaces problems only after they have become delays, and who does not flag risks in advance has a communication culture that will not change without a culture change. That is not a quick fix.

Team composition mismatches that the vendor does not address. If the engineers on the project do not have the skills required for the work, and the vendor has not corrected this after it was raised, the vendor is either unable to staff the right team or unwilling to acknowledge the gap.

Inability to deliver AI features that are now required. If the board mandate requires AI delivery and the vendor has demonstrated they cannot do it - a failed proof-of-concept, a stalled AI feature, a team that lacks AI delivery experience - this is a capability gap that a process improvement cannot close.

The signals that point to process

The same problem has appeared with previous vendors. If you switched vendors once already for similar reasons, the source of the problem may be in the client's process. Requirements that are ambiguous, review cycles that are too slow, or success criteria that are not defined are problems that travel with the client.

The vendor performs well on well-defined work and struggles on ambiguous work. A team that delivers exactly what is specified but struggles when requirements are unclear is working against an ambiguity problem. Define the requirements better before evaluating a vendor change.

The problem is specific to one project or one engagement manager. A vendor who has delivered well on previous projects and is underperforming on this one has a project-specific issue that may be addressable within the current relationship.

The cost threshold test

The switch decision should be evaluated against a cost threshold. Calculate the current cost of the underperformance: delayed features, rework cost, missed deadlines, and the business impact of each. Calculate the cost of the transition: four to eight weeks of reduced productivity at the current billing rate.

If the annual cost of the underperformance is more than three times the transition cost, the switch is economically justified even without accounting for the improvement the new vendor produces. If the annual cost of the underperformance is less than the transition cost, the economics favor fixing the current relationship.

This calculation does not settle the question for cases where the problem is a capability gap - a vendor who cannot deliver AI features will not improve regardless of process changes. But it prevents switches that are driven by frustration rather than economics.

What a vendor conversation looks like

Before starting a formal evaluation of alternatives, have a direct conversation with the current vendor. Name the specific problem: "Our last three releases have been an average of three weeks late. The defect rate on the last two features was above 20 percent. This is not the delivery pattern we need."

Set a specific expectation with a timeline: "We need to see the next release delivered on time and with a defect rate below 10 percent. We will review this in four weeks."

A vendor who responds to this conversation with a credible plan and a course correction within four weeks has the character to fix the problem. A vendor who minimizes it, attributes it to external factors, or fails to course-correct within the window has given you the data you need.