Hospital vendor management without running their project

Six weeks into a platform implementation at a large hospital group, I realised I was running the vendor’s project. I was maintaining the task list they should have maintained. I was chasing their developer for a build they had committed to. I was the one telling their account manager what their own team had said on Monday. The vendor was being paid to deliver and I was doing the coordination they had quoted for.

It did not happen through negligence. It happened because the implementation was slipping, the unit was waiting, and the fastest way to unblock any single item was to do it myself. Forty small rational decisions later, I had transferred accountability from them to me — and once that transfer happens, you cannot reverse it inside the same project. You have become the reason it is late.

This is the central risk in vendor management inside a hospital, and it is made worse by the environment. Your stakeholders are clinicians and unit heads with no patience for supplier excuses, the systems you are touching are operationally critical from seven in the morning, and the vendor knows that you will not let a booking flow stay broken for a week to make a contractual point.

Most vendor failure is decided before the contract

By the time you are arguing about delivery, the outcome is usually already determined by how vaguely you scoped.

Four things must be settled before a statement of work can be written, and in my experience teams skip at least two.

Which decisions are yours and which are theirs. Write the list. Who decides the booking rules when a consultant’s slot pattern is irregular? Who decides what a patient sees when no slot is available? These look like configuration questions and they are policy questions, and if they surface mid-build they become change requests.
What exists today, accurately. Vendors scope against what you told them. If your doctor master has duplicates, if three units use different specialty nomenclature, if the hospital information system has fields that are populated inconsistently — that is where the timeline dies. Do your own data audit before they do theirs, and share the ugly version.
Who on your side must sign off, and when they are available. Clinical sign-off cycles, medical administration, IT security review, NABH documentation requirements. A vendor who discovers in week ten that three clinical reviews are needed will, legitimately, reset the schedule.
What happens at a live unit on day one. Which unit, which shift, who is on the floor, what the fallback is when something fails during morning OPD. If this is not in the scope, it will be done by your team at seven in the morning while the vendor is asleep.

The statement of work that prevents the argument

A good statement of work is not a longer document. It is a document that makes disagreement resolvable without goodwill.

The clauses that have earned their place, for me, are these.

Named people, with a substitution clause. The strongest engineer is on your project for the first month and then quietly moved to a new sale. Name the individuals, specify minimum notice for substitution, and require that a replacement shadows for a defined period at the vendor’s cost.
Acceptance criteria written as scenarios, not features. Not “appointment booking module”. Instead: a patient books a paediatric slot at a named unit on a Sunday, the consultant’s leave has been applied that morning, and the confirmation reaches the patient in a regional language. Scenarios are testable. Features are arguable.
Defined response obligations in operational hours. For anything patient-facing, the clock that matters starts before the OPD does. Specify it in your hours, not in generic business hours.
Change request pricing fixed at signature. A day rate for changes, agreed at the start, removes the most common mid-project power shift. Without it, every change is a negotiation you will lose because you are the one under time pressure.
Ownership of accounts and credentials, stated explicitly. Domain, DNS, analytics, advertising accounts, map listings, platform administration, the data. All in the group’s name, with the vendor holding access rather than ownership. This single clause has saved more pain than anything else on this list.
Documentation as a deliverable with payment attached. Not a promise. A payment milestone.
Data handling and deletion obligations, given that patient data is involved and your obligations under Indian data protection requirements do not transfer to a supplier just because the work does.

One addition I now insist on: a clause requiring the vendor to maintain the project plan and send it weekly in an agreed format. It sounds trivial. It is how you keep the coordination work on their side of the table, contractually.

How to stay out of their project

Discipline here is behavioural, not contractual.

Hold one weekly meeting. Require the vendor to present, from their plan, against their commitments. Your team asks questions and records decisions; your team does not bring the status update. If the vendor arrives without a plan, end the meeting early and escalate. Ending a meeting early is uncomfortable once and effective for months.

Keep a single risk and decision log on your side — not a task list. Tasks are theirs. Decisions and risks are yours, because you are the only party who will still be here in three years.

And resist the reflex to solve their internal problems. When a vendor’s developer and their business analyst disagree, that is not your meeting. Every time you mediate inside their team, you take on a little more of their accountability and they learn that you will.

The exception is genuine: when a patient-facing system is broken, you fix it by whatever means necessary and conduct the accountability conversation afterwards. Have that conversation, though. The failure mode is the emergency that becomes the new normal and is never reviewed.

The escalation ladder

Escalation works when it is defined at signature and boring to use. It fails when it is an expression of anger.

Three rungs are enough.

Delivery level. Your project lead and their project manager, resolving within a stated number of working days.
Sponsor level. You and their account or delivery head, with a written summary of what was attempted below. Monthly cadence, whether or not there is a problem, so the relationship exists before you need it.
Commercial level. Your procurement or finance counterpart and their leadership, with payment milestones and contractual remedies on the table.

Two rules I follow. Never skip a rung, because skipping teaches their team that the real channel is above their heads and your project lead loses all authority. And always escalate in writing with dates and facts, never in a phone call — not for aggression, but because a written escalation is the artefact that makes the third rung possible if you ever need it.

A useful signal: if you have never escalated to the second rung, you are probably absorbing problems rather than managing them. Healthy vendor relationships have occasional, low-temperature escalations.

Knowledge transfer is not a phase

Knowledge transfer scheduled for the end of a project does not happen. The project is late, the vendor’s best people have moved, and your team is busy with go-live.

Make it continuous and structural instead.

Someone from your team sits in every build review from the start, even when they contribute nothing.
Configuration changes are done by your team, with the vendor watching, from the second month. Slower, and the only thing that actually transfers capability.
Documentation is reviewed monthly against what was built, not assembled at the end. Tie a payment milestone to each review.
Require the vendor to train two of your people, named, and test them by having them run a change unsupervised before final payment.
Insist on an exportable copy of your data in a documented format, tested at least once during the project rather than at exit.

The test of whether knowledge transfer worked: if this vendor disappeared tomorrow, could your team keep the system running for ninety days? If the honest answer is no, you do not have a supplier, you have a dependency.

Exit clauses you will actually use

Most exit clauses are written to satisfy legal review and are useless in practice, because they assume a clean break that never happens in a live hospital environment.

The ones that matter are operational.

A transition period with defined obligations and a rate already agreed. You will need the outgoing vendor for several weeks after you decide to leave. Price that now, while they want your business.
Data export in a documented, tested format, with a deadline measured in days.
Credential handover list, enumerated, with the confirmation that nothing remains solely in their possession.
Termination for repeated minor failure, not only material breach. Vendors rarely fail catastrophically. They fail by missing eleven small commitments in a quarter. Define a threshold for that pattern.
No exclusivity on your own historical work product — creatives, content, configuration — so a successor can build on it.

Telling a struggling partner from a bad one

This judgement is the heart of the job, and getting it wrong in either direction is expensive. Replace a struggling partner and you restart a nine-month clock. Keep a bad one and you lose the year anyway, plus your credibility with the units.

The distinction, in my experience, is not competence. It is disclosure.

A struggling partner tells you they are behind before you find out. They bring a revised plan with the bad news. They over-commit resources at their own cost to recover. Their people give you consistent answers when you ask them separately. The problems are concentrated in a hard technical area, usually the integration with your hospital systems, which is where genuine difficulty lives.

A bad partner is discovered. Status is green until it is catastrophic. The answers change depending on who you ask. Escalation produces apology and a new account manager rather than a different plan. Named people have quietly been replaced. And the problems are everywhere, including in the easy parts, which tells you the issue is their delivery capability rather than your environment.

When you see the second pattern, act faster than feels comfortable. I have never regretted ending a vendor relationship too early. I have twice regretted waiting a quarter for a recovery plan that everybody in the room knew was not going to work.

If you’re signing something next quarter

Do your own data and process audit before the vendor scopes. Share the unflattering version.
Write the decision-rights list and the day-one-at-a-live-unit plan into the scope.
Fix the change request rate, named resources with substitution notice, and account ownership at signature.
Write acceptance criteria as scenarios at your actual units, in the languages your patients use.
Make the vendor own the plan and present it weekly. Keep only risks and decisions on your side.
Define the three-rung escalation ladder with names and timeframes, and use the second rung at least once early on something small.
Start knowledge transfer in month two by having your team make changes while they watch.
Test the data export and the documentation before the final milestone, not at exit.

If you are the person who knows the most about how your vendor’s project is going, you are not managing the vendor. You work for them.

Questions people ask

How does a hospital digital head end up running the vendor’s project?

Not through negligence. The implementation slips, the unit is waiting, and the fastest way to unblock any single item is to do it yourself — maintain their task list, chase their developer, brief their account manager on what their own team said. Forty small rational decisions later, accountability has moved from them to you, and it cannot be reversed inside the same project. You have become the reason it is late.

What has to be settled before a hospital signs a vendor statement of work?

Four things, and most teams skip two. Which decisions are yours and which are theirs — booking rules for irregular consultant slots are policy questions, not configuration. What exists today, accurately: duplicate doctor masters and inconsistent specialty nomenclature across units are where timelines die, so audit your own data first and share the ugly version. Who must sign off and when they are available, including clinical and NABH reviews. And what happens at a live unit on day one.

Which contract clauses matter most in a hospital technology vendor agreement?

Named people with a substitution clause and shadowing at the vendor’s cost. Acceptance criteria written as scenarios at your actual units, not features. Response obligations in your operational hours, which start before OPD. Change request pricing fixed at signature. Ownership of domain, DNS, analytics, ad accounts, listings and data in the group’s name. Documentation as a paid milestone. Data handling and deletion obligations. And a clause requiring the vendor to maintain the plan and send it weekly.

Why should acceptance criteria be written as scenarios rather than features?

Because scenarios are testable and features are arguable. Not an appointment booking module, but: a patient books a paediatric slot at a named unit on a Sunday, the consultant’s leave was applied that morning, and the confirmation reaches the patient in a regional language. Written that way, disagreement about whether something is done can be resolved without goodwill. Write them at your real units, in the languages your patients actually use.

How do you stay out of a vendor’s project once it has started?

Hold one weekly meeting where the vendor presents from their plan against their commitments; your team asks questions and records decisions. If they arrive without a plan, end the meeting early and escalate. Keep a single risk and decision log on your side, not a task list — tasks are theirs. Do not mediate disagreements inside their team. The exception is a broken patient-facing system: fix it by any means, then have the accountability conversation afterwards.

What does a good escalation ladder look like for hospital vendor management?

Three rungs, defined at signature and boring to use. Delivery level: your project lead and their project manager, resolving within stated working days. Sponsor level: you and their delivery head, monthly whether or not there is a problem, so the relationship exists before you need it. Commercial level: procurement or finance with payment milestones and remedies on the table. Never skip a rung, always escalate in writing with dates and facts, and use the second rung early on something small.

How do you make knowledge transfer from a vendor actually happen?

Make it continuous, not a phase at the end, because the end-of-project version never happens. Someone from your team sits in every build review from the start. From month two your team makes configuration changes with the vendor watching. Documentation is reviewed monthly against what was built, with a payment milestone attached. Two named people are trained and tested by running a change unsupervised before final payment. The test: could your team keep it running for ninety days if the vendor vanished?

What exit clauses will a hospital actually use with a technology vendor?

Operational ones, not the clean-break clauses written for legal review. A transition period with obligations and a rate agreed now, while they still want your business. Data export in a documented, tested format with a deadline in days. An enumerated credential handover list. Termination for repeated minor failure, not only material breach, because vendors fail by missing eleven small commitments in a quarter. And no exclusivity on your own creatives, content and configuration, so a successor can build on them.

How do you tell a struggling vendor from a bad one?

The difference is disclosure, not competence. A struggling partner tells you they are behind before you find out, brings a revised plan with the bad news, over-commits resources at their own cost, and gives consistent answers when you ask their people separately; the problems cluster in genuinely hard areas like hospital system integration. A bad partner is discovered: status is green until catastrophic, answers change by who you ask, escalation produces a new account manager, and problems are everywhere including the easy parts.

When should a hospital end a vendor relationship?

Faster than feels comfortable, once you see the bad-partner pattern. Replacing a struggling partner restarts a nine-month clock, which is costly. Keeping a bad one loses the year anyway plus your credibility with the units. I have never regretted ending a vendor relationship too early. I have twice regretted waiting a quarter for a recovery plan that everybody in the room knew was not going to work.

What should IT insist on regarding accounts, data and DPDP obligations with a vendor?

That every account — domain, DNS, analytics, advertising, map listings, platform administration and the data itself — is in the group’s name, with the vendor holding access rather than ownership. That patient data handling and deletion obligations are written into the contract, because your obligations under Indian data protection requirements do not transfer to a supplier just because the work does. And that an exportable copy of your data in a documented format is tested during the project, not at exit.

What does a good vendor need from the hospital to deliver on time?

An honest data audit before scoping, because vendors scope against what you told them. A written list of decision rights so policy questions do not surface mid-build as change requests. Clear sign-off owners with real availability, including clinical review and IT security. A day-one plan for the live unit with fallback for morning OPD. And a client that keeps the plan on the vendor’s side of the table and escalates in writing, calmly, rather than absorbing problems until they explode.

Does this vendor management approach apply to a single hospital with a small team?

It applies more, because a small team has less capacity to absorb a vendor’s coordination work without stalling everything else. The essentials are cheap: fix the change request rate and account ownership at signature, write acceptance scenarios at your unit, make the vendor present the plan weekly, and start your own people making configuration changes in month two. A single hospital with no procurement function should still define the third escalation rung, even if it is the CEO.