Vendor Management in Banking Data Programmes: From Contract Oversight to Delivery Control
Oversight tells you a vendor is late; control is the reason they are not.
The Comfortable Illusion of Oversight
There is a version of vendor management that looks entirely respectable from a distance and controls almost nothing. It has a contract, carefully negotiated. It has a monthly service review with a deck of green, amber and red indicators. It has a change-request process, an issues log, and a relationship owner who takes the account director to lunch. It produces status. What it does not produce, in the multi-vendor data programmes I have seen, is delivery.
The pattern that recurs is this: the more vendors a programme depends on — a platform provider here, a systems integrator there, a specialist migration partner, a cloud engineering firm — the more vendor management quietly collapses into administration. The programme manager becomes a clearing house for reports written by the vendors about themselves, adjudicating between competing RAG statuses that never quite add up to the truth. Everyone is green until, suddenly, the integration everyone assumed someone else owned is three months late and no single party feels responsible.
The distinction I want to draw is between oversight and control, because programmes routinely mistake the first for the second.
Oversight is watching a vendor report on their own delivery. Control is being close enough to that delivery to change its trajectory before the report is written.
Why Oversight Fails in a Multi-Vendor Programme
Oversight works reasonably well when a single vendor owns a self-contained outcome: they succeed or fail on their own terms, and a monthly review is enough to know which. It breaks down precisely where modern bank data programmes live — in the seams between vendors.
A data programme of any scale is a chain of dependencies that cross organisational boundaries. The migration partner cannot test until the platform provider has stood up the environment. The engineering firm cannot build the feeds until the source-system definitions are frozen, which depends on an internal team that is itself waiting on a vendor. Value is created — and destroyed — at the handovers. Yet each vendor reports only on its own scope, and each reports it as green right up to the boundary of its responsibility. The RAG status is honest within the box and blind at the edges. Oversight aggregates a set of individually true reports into a collectively false picture of health.
There is a second failure. In a regulated context, the programme carries obligations — for data quality, for lineage, for control evidence — that no individual vendor contract fully captures, because the obligation is a property of the whole, not of any part. A vendor can meet its contractual acceptance criteria to the letter and still deliver something that fails the programme’s regulatory standard, simply because the standard was never decomposed into the vendor’s terms. Oversight checks the contract. Control checks the outcome the contract was supposed to serve.
“Oversight tells you a vendor is late; control is the reason they are not.”
What Delivery Control Actually Governs
If oversight watches status, control governs six things that status reports systematically obscure.
Outcomes, not activity. A vendor reporting eighty per cent of tasks complete is telling you about effort. Control asks what working, accepted, quality-assured capability exists — what a regulator or a business user could actually rely on today. The unit of control is the outcome, defined in the programme’s terms, not the vendor’s task list.
Dependencies across the seams. The programme — not the vendors — must own the integrated plan and, in particular, the critical dependencies that cross vendor boundaries. Every handover between two parties needs a named owner on the programme side who is accountable for the seam neither vendor owns. This is the single highest-leverage act of control in a multi-vendor programme, and the one most often left to chance.
Quality as a first-class term. Quality has to be defined by the programme and asserted at each handover, not left to each vendor’s internal standard. Otherwise the migration partner accepts what the engineering firm produced, the programme accepts what the migration partner produced, and defects accumulate untraced until they surface at the reporting layer where they are most expensive to fix.
Commercial leverage, held and used deliberately. The contract is not just a description of what was agreed; it is a set of levers — milestone-linked payments, service credits, acceptance rights, the ability to withhold. Oversight files the contract. Control keeps the commercial levers live and is willing to use them, calmly, when delivery slips. A vendor that knows acceptance is genuinely conditional behaves differently from one that knows payment will flow regardless.
Escalation that reaches decisions, not just visibility. Most escalation processes surface a problem to a forum that notes it. Control means escalation resolves something — a decision on scope, a reallocation of resource, a commercial conversation — within a timeframe that still matters to the delivery. An escalation path that only produces awareness is oversight wearing a more urgent expression.
Integration of vendors with internal teams. The programmes that control their vendors treat them as part of one delivery organisation, not as external suppliers held at arm’s length. Shared plans, joint stand-ups across platform, engineering, migration and cloud, common definitions of done, one issues log rather than four. Arm’s-length management is what produces the blind seams; integration is what closes them.
The Practices That Separate Control From Oversight
The difference between the two is not attitude or diligence. It is a small number of concrete practices that a programme either has or does not.
- One integrated plan, owned by the programme. Not a folder of vendor plans stapled together, but a single dependency-linked plan where the cross-vendor handovers are explicit and owned. If the vendors’ plans have never been reconciled into one, no one is controlling the whole.
- Acceptance criteria defined by the programme, in the programme’s terms. Including the regulatory obligations — quality thresholds, lineage evidence, control artefacts — decomposed into what each vendor must actually deliver. Acceptance is where control bites; a vendor deliverable accepted on the vendor’s own criteria is not controlled.
- Direct access to the work, not just the reports. The programme’s people close enough to the delivery — in the environments, in the test results, in the code and the migration runs — to form an independent view of health rather than relying on the vendor’s self-assessment.
- Commercial and delivery management joined up. The person managing the relationship and the person holding the contract levers must be working from the same picture. When commercial management is severed from delivery reality, leverage is never applied at the moment it would matter.
- A single view of quality and dependencies across all vendors. One place where the true, programme-level status lives — assembled by the programme from evidence, not aggregated from vendor claims.
None of these is exotic. What makes them rare is that each costs something at the front — more programme-side effort, more friction with vendors who prefer to be managed by report, more willingness to hold an uncomfortable commercial line. Oversight is cheaper and more comfortable, right up to the point where the programme discovers it was never in control at all.
The Test
Here is the test I apply. Ask a programme a simple question: if your largest vendor’s monthly report says green, do you know, independently, whether that is true? If the honest answer is that you would have to trust them, you have oversight. If the answer is that you could show, from your own view of the outcomes, the dependencies and the quality, why it is green — or why it is not — you have control.
In a regulated data programme, where the firm cannot outsource its accountability to a supplier however carefully the contract is drafted, only the second answer is safe. The contract manages the vendor. Controlling the delivery is a different discipline, and it is the programme’s job, not the vendor’s.