Regaining control of an IT vendor without destroying the relationship

The vendor is not always the problem

When leadership feels it has lost the initiative, the temptation is often twofold: let everything drift out of fatigue, or take everything back abruptly. Both options often make the situation worse. In many cases the point is not to find a culprit. It is to restore a decision frame.

A vendor can be competent while working inside a frame that has become too vague. The client can act in good faith while requesting changes that were never properly prioritised. The budget can drift without anyone intending harm. That is why the frame should be restored early, before the relationship turns into conflict or a suffered dependence.

Regaining control does not mean humiliating, threatening or stopping everything. It means making implicit decisions visible again: what has been delivered, what is missing, what is changing, what it costs, what must be accepted and what must be renegotiated.

Return to decisions, not complaints

The first step is to restate the subject as decisions rather than reproaches. What needs to be accepted, re-prioritised, renegotiated or stopped? That shift immediately changes the level of discussion and avoids an accumulation of frustrations that produces no usable exit.

Leadership can prepare a simple list: points to accept, points to clarify, points to contest, points to postpone. The vendor can then answer on a clearer basis. Conversations become less emotional and more operational. The same work still helps when the relationship is already tense: it separates legitimate disagreement from a misunderstanding of scope, and it avoids confusing poor communication with a genuine quality or competence problem.

Put acceptance criteria back in place

Steering has to distinguish quality, schedule, budget, scope and responsibility. While everything is mixed, nothing is really decided. Acceptance criteria should be visible to both parties. They may concern a feature, a document, a correction, a milestone, an acceptance test, an expected performance or a support duty. What matters is that each side knows how to say: accepted, to be corrected, or out of scope.

Without those criteria, leadership often accepts on feeling. The vendor may consider that it delivered what was planned. That difference in reading creates repeated tension and prepares difficult budget discussions.

Create a shorter rhythm

A vendor relationship rarely recovers through one large monthly committee. It recovers through a simple, readable, regular sequence: open points, decisions taken, named owners, short deadlines, evidence of delivery.

A useful steering meeting is not a round of activity reports. It is a decision space. At the end, leadership should know what was accepted, what remains blocked, what changes in the budget and what must be decided before the next step. A short rhythm also protects the relationship: frustrations do not accumulate for weeks, and corrections can happen earlier, with less drama.

Clarify budget and scope changes

A large share of drift comes from unnamed scope changes. A business request looks small, then it changes the architecture, data recovery, tests or schedule. The vendor then invoices more, while leadership feels it is paying for a result that should have been included.

Isolate new requests. Are they needed now? Are they tied to the core of the project? Can they wait? What is the impact on planning, budget and maintenance? That clarification reduces tension because it turns a vague debate into an explicit trade-off. The same discipline applies to the budget: consumed, still committed, dependent on a change order, or genuinely new. Without that split, leadership discovers the drift too late.

Stay firm without breaking the relationship

Many projects can be recovered if the frame is restored early enough. Firmness should sit on criteria, decisions and responsibilities, not on people. A short reset sequence often helps: a prepared meeting, written questions, a list of expected decisions, a simple record. If the vendor answers clearly, the relationship can restart on better terms. If it avoids answers, that itself is useful information.

A senior lead can go beyond an observation: understand the technical points, clarify ownership, run the trade-offs and follow corrections with the vendor in place. Depending on the mandate, Paulo Castro can take back project leadership, organise tests, secure the architecture and deliver an agreed scope, without imposing a break with the teams.

Reconstructed field situation: an exchange job slows down or fails

In environments that combine business applications, a legacy system and technical vendors, an import flow can become slow or fail while responsibilities are split across several teams. The work is not to repeat “fix the error”. Isolate the operation, collect reproducible observations, clarify available access and logs, and obtain a correction plan with an owner and verification criteria.

The vendor in place may deliver the fix while a technical lead follows resolution, asks for a root-cause analysis, organises tests and secures the next steps. That does not prove that an entire system was rebuilt, nor that the incident never happened again. The situation is reconstructed from professional practice, without a Mahthildis client reference.

When changing vendor becomes an option

Changing vendor can be necessary, but it is not always the first move. Before reaching that point, know what can be recovered, what must be documented, which access must be secured, which data must be exported and what continuity risk exists. A poorly prepared break can cost more than restoring the frame. Staying too long in an opaque relationship can cost more than a change. The decision should be put clearly, with its consequences.

The better exit is the one that restores control to leadership. Sometimes that is a reset of the frame, sometimes a renegotiation, sometimes a transition. In every case, decide on facts rather than accumulated fatigue.

Documents worth requesting

A simple documentary base is enough to regain the initiative: access list, status of deliverables, prioritised backlog, open points, external dependencies, consumed billing, remaining milestones and responsibilities. This is not bureaucracy. It is the minimum material needed to steer.

If those elements do not exist, their absence is already information. It shows that the project runs more on habit and trust than on a controllable frame. That does not automatically condemn the relationship, but it shows where the reset should start.

The role of the business leader

The leader does not need to enter every technical detail. The role is to put the right questions back at the centre: what is being delivered, what remains to be decided, what binds the budget, what creates dependence, and what is the next useful decision?

Steering held by Mahthildis lets leadership stay focused on its trade-offs while a senior counterpart works with business and technical teams to move the project. Independent judgment does not exclude operational responsibility; it avoids decisions dictated only by a supplier's position.

The useful indicator is not the volume of exchanges with the vendor. It is the quality of decisions obtained afterwards. If each meeting produces a clear owner, a next step and a control point, the relationship becomes steerable again. If meetings only produce new explanations, the frame is still insufficient.