The vendor delivered exactly what the statement of work described. Every deliverable was checked off, every milestone hit, the documentation complete. And the thing still did not work end to end, because the boxes the contract asked them to tick and the outcome the business needed were not the same thing — and when those two diverge, a rational vendor builds to the boxes. They were not negligent. They were doing precisely what they were paid and measured to do.

This is the part of vendor management that goodwill cannot fix: a vendor is an organization optimizing for its contract and its incentives, not for your outcome. That is not cynicism, it is economics. If the contract pays for hours, you will get hours. If it rewards milestones, you will get milestones — whether or not the milestones add up to a working system. The vendor is solving an optimization problem, and the thing being optimized is whatever you wrote down.

So we stopped managing vendors by trust and started managing the incentive they are actually solving for.

If the contract and the goal point in different directions, the contract wins. Every time.

Goodwill is not a control

Good vendors exist, and a strong relationship is worth a great deal. But a relationship is not a control, and "they seemed committed" is not a status. When the program is under pressure and the vendor has to choose between what the contract rewards and what your outcome needs, the relationship bends toward the contract, because the contract is what the vendor's own management is holding them to. Hope is not a mechanism. The mechanism is the definition of done and the incentive attached to it.

And there is a structural gap no single vendor closes: on a multi-vendor program, each one owns its piece and none owns the seam between them. The integration that fails at the boundary fails in the one place no contract assigned. That seam is yours, whether you claimed it or not.

How to manage to the outcome

Managing vendors well is mostly about writing and enforcing the right definition of done:

Managing vendors to outcomes
  • Define done as a business result. Not "interface built" but "orders flow end to end and reconcile." If acceptance can be met without the outcome, acceptance is written wrong.
  • Own the seams. No vendor owns the boundary between vendors. You do. Assign the integration explicitly or it fails in the gap nobody was paid to cover.
  • Make acceptance objective. A test anyone can run, with a pass/fail you don't have to argue about. Subjective acceptance is a negotiation you will lose under deadline.
  • Keep one owner per outcome. One accountable party per result, so "it's the other vendor's fault" is never an available answer.
  • Write the incentive you actually want. Pay for the outcome, not the activity. A vendor solving for a contract that rewards the result is a vendor solving for you.

The throughline is that you don't change vendor behavior by appealing to shared purpose. You change it by making the contract reward the purpose, so that the vendor optimizing for itself is, by construction, optimizing for you.

The cost of managing by trust

Run a multi-vendor program on goodwill and you get contract-compliant failure: everyone delivers their piece, every invoice is justified, and the system doesn't work — and then the finger-pointing starts at exactly the seams nobody owned. Now you are paying to mediate between vendors who are each, correctly, pointing at their own green status. The cost is not just the rework; it is the weeks lost discovering that "done" and "working" were never the same word.

It connects straight to the technical work. The boundary that leaks is usually the same seam where two systems describe one customer, and holding vendors to an outcome is the same discipline as aligning competing interests — make the real goal explicit and attach the commitment to it.

It ties back to the ledger

The program delivers a working system because "done" was defined as the outcome and the contract paid for that, not for the activity that looks like it. Don't hope the vendor shares your goal — most won't, and they don't have to. Write the engagement so that the vendor solving hardest for its own interest is, by design, building exactly the thing you needed. That is what managing a vendor actually means.