The vendor management trap:
when the PM wears too many hats

The conversation nobody wants to have

On a clinical system replacement I ran, the vendor started pulling levers to isolate the project. The project had put governance and quality controls around their deliverables: acceptance criteria, defect management, milestone conditions. The vendor's response wasn't to meet the criteria.

It was to undermine the project's credibility through quiet conversations with the customer executive. They dropped hints that the project team didn't know what they were doing. "Everything's fine from our side," implying the problems were manufactured by the PM, not caused by the vendor's delivery.

The customer executive had an existing relationship with the vendor and limited visibility into the delivery detail. That narrative travelled upward. By the time it reached the steering committee, the conversation was about the PM's approach, not the vendor's performance against the specification.

I was raising defects against acceptance criteria we had agreed together. I was rejecting deliverables that didn't meet the specification. I was escalating vendor performance to a governance structure that was hearing a different story. And I was doing all of this while being told to "maintain the relationship."

That's the trap. And if you've managed vendor delivery, you've probably been in some version of it. You recognise it because you've lived it before. That recognition, knowing the shape of the problem before it fully forms, is what experience actually buys you.

Three hats, one head

When a PM runs a vendor delivery project, they typically absorb three distinct authority domains:

1. Delivery authority covers scope, schedule, quality, and dependencies. This is legitimately the PM's domain. You own the plan, you manage the risks, you hold people to their commitments.
2. Technical authority covers solution design, defect management, integration, and testing. Depending on the project, this sits with the PM or a technical lead, but on smaller projects, it often consolidates upward.
3. Commercial authority covers contract terms, milestone payments, vendor performance management, and relationship escalation. This is actually two distinct functions bundled into one hat: the commercial mechanics (contract compliance, payments, variations, performance notices) and the business relationship (strategic partnership, trust, future work). They need different skills, different temperaments, and ideally different people. I've written separately about why these must be separated.

The problem starts when all of these converge on one person. Not because the PM seized the commercial authority, but because nobody else stepped into it. The executives who will own the vendor relationship long after the project is done refuse to engage during delivery. They find vendor meetings tedious, the technical detail opaque, and the interpersonal dynamics uncomfortable. So the PM absorbs it. Not by design, but by default.

Why this is structurally impossible

Separation of concerns exists as a principle for a reason. When one person is both the quality enforcer and the relationship holder, you create an irreconcilable tension:

• The PM recommends withholding a milestone payment because the deliverable doesn't meet acceptance criteria. That's delivery evidence driving a commercial recommendation, and it's legitimate.
• The PM raises defects against the vendor's software. That's technical authority. Legitimate.
• The PM rejects a deliverable and tells the vendor to redo it. That's quality enforcement. Legitimate.
• The PM is also supposed to maintain a productive vendor relationship. That's commercial authority, and it contradicts everything above.

You cannot enforce consequences and maintain rapport at the same time, not with the same person. The roles need to be separated, or at minimum, the enforcement role needs visible executive backing.

The vendor play

Vendors know this dynamic. The good ones work through it professionally, and the others exploit it. When one person holds all three hats, the vendor has a straightforward play: isolate the project and undermine its credibility. This works because:

1. The PM is the only face enforcing quality. Every hard conversation, every rejected deliverable, every recommendation to withhold payment: all come from the same person. That makes it easy to reframe governance as interpersonal conflict.
2. The vendor has relationships the PM doesn't control. The customer executive, the business owner, the directors on the steering committee: the vendor can influence the narrative through channels that bypass the project's governance entirely. "Everything's fine from our side" is devastating when the PM is the only one saying otherwise.
3. The path of least resistance is replacing the PM, not fixing the delivery. Swapping the PM is cheaper and faster than addressing the systemic vendor performance issues. It also makes the vendor happy, which feels like progress.

I've seen this pattern on three separate engagements now. The specifics vary, but the structure is always the same. You find a disengaged executive, an over-burdened PM holding all three hats, and a vendor who has learned that complaining is easier than delivering to specification.

The third time, I saw it forming in week two, not because I'm unusually perceptive, but because I'd been through it twice before. Experience doesn't give you invulnerability, but it does give you pattern recognition. You can name the thing before it has a name in the room. And naming it early is the only way to fix it before the governance gap becomes permanent.

What good looks like

The fix isn't complicated. It's a governance design decision that most projects skip because it feels like overhead until it's too late.

Separate the roles

At minimum, delivery authority and commercial authority need different people, or the same person with visible executive backing for the enforcement role. Technical authority stays with the PM or a dedicated technical lead, depending on project scale. The critical separation is between the person enforcing quality and the person managing the commercial relationship.

Not every engagement needs a formal role split. When the vendor relationship is straightforward, the contract value is low, and the executive is genuinely engaged, the PM can manage commercial mechanics alongside delivery without creating the trap, provided the executive remains the decision-maker who authorises commercial actions. The collapsed model reduces the number of people involved, not the governance principle. The formal split becomes essential when the contract is large enough to create competing incentives, typically when milestone payments, formal performance management, or contract variations are in play.

What matters is that the arrangement is explicit. When roles are collapsed, it should be a deliberate decision documented at project setup, not something the PM absorbs by default because nobody else stepped in. A role-to-position mapping records who holds which authority on this engagement and what the escalation triggers are. Without that mapping, assumptions creep in. The PM starts making commercial decisions without realising they were never formally delegated that authority, and nobody notices until the vendor exploits the gap.

The table below shows common ways to distribute authority across positions. It separates commercial authority into its two underlying functions (contract mechanics and business relationship) because they need different people, as described in the contract management gap.

In the first two models, the contract manager or PM recommends commercial actions (withhold payment, issue notice). The executive sponsor authorises them. In the third, the executive holds both functions. That distinction matters: where the roles are split, the person preparing the evidence is not the person making the commercial decision.

* Listed for completeness. This model collapses the recommend/authorise separation and is an anti-pattern on any engagement with competing incentives.

Combinations to avoid:

• Commercial authority + quality enforcement in one person with no executive backing. This is the trap.
• Business relationship + commercial enforcement in one person. The person maintaining rapport cannot also issue performance notices. See the contract management gap for why.
• All three domains in the PM with a disengaged executive. The PM becomes the sole enforcement face with no corroborating authority.

On larger engagements, the target model has three distinct roles: PM (delivery and technical), contract manager (commercial mechanics), and executive sponsor (business relationship and commercial decisions). Most organisations skip the contract manager, and that gap is often where the trap originates.

Make the escalation path explicit

Before the first vendor meeting, establish which decisions belong to the PM and which need to be escalated. This isn't bureaucracy. It's a contract between the PM and the steering committee.

This split does two things. It gives the PM clear authority to enforce quality without overstepping into commercial territory. And it forces the executive to engage when commercial decisions need to be made, because the PM will escalate, and they need to be ready to act.

Document everything as quality, not conflict

When the vendor reframes your quality enforcement as a personality problem, your documentation is your defence. Every rejection should reference the specific acceptance criterion. Every defect should cite the agreed specification. Every payment recommendation should trace to a contractual milestone condition.

The language matters. "The deliverable does not meet acceptance criterion 4.2.3" is a quality statement. "The vendor keeps delivering substandard work" is an opinion that can be dismissed as interpersonal friction.

One survives escalation. The other doesn't.

The vendor can't run a personality narrative against documentation that references contract clauses and acceptance criteria. Make every hard conversation traceable to the specification.

Escalation is governance, not failure

Many PMs feel that escalating means they've failed, that a good PM should be able to handle the vendor relationship without dragging executives into it. I spent years believing this, and it was wrong.

Escalation is a governance mechanism. It exists specifically for decisions that exceed the PM's delegated authority.

Withholding a milestone payment is a commercial decision. Issuing a vendor performance notice is a contractual decision. These decisions have financial and legal implications that belong at the executive level.

When you absorb these decisions because nobody else will make them, you're not being a strong PM. You're compensating for a governance gap. And the longer you compensate, the harder it becomes to fix, because the executives have learned they don't need to engage.

Frame it as risk, not complaint. Document the gap, present the options, and force the decision upward. That isn't political. It's governance.

Warning signs

If you recognise three or more of these, the trap is already forming:

1. You're the only person the vendor talks to. No executive, no contract manager, no commercial authority attends vendor meetings. Every hard conversation lands on you.
2. You're approving (or withholding) payments. Milestone payment decisions should involve someone with commercial delegation. If you're the one signing off, you've absorbed commercial authority.
3. The vendor complains about you, not the requirements. When the vendor's escalation language shifts from "the requirements are unclear" to "the PM is difficult," they're running the personality play.
4. Executives ask you to "work on the relationship." This sounds reasonable. It isn't. The relationship problem is structural, not interpersonal. Telling the PM to be nicer doesn't fix a delivery gap.
5. You're writing emails at 10pm trying to manage the vendor relationship. That emotional labour is a symptom. You're carrying a weight that should be distributed across the governance structure.

Build your evidence base from day one

These four habits will not prevent the vendor play, but they make it significantly harder to execute.

Never attend a vendor meeting alone. Always have at least two people from your side in the room. This is not about intimidation. It is about having a corroborating witness when the vendor later claims something different was agreed. A solo PM in a vendor meeting is a PM whose version of events can be disputed.

Put everything in writing. Every discussion, every decision, every commitment should be followed up with a written summary. "As discussed today, we agreed that..." is the most important sentence in vendor management. If it is not in an email, it did not happen.

Know your legal counsel early. Find out who your organisation's legal team is before you need them. On any non-trivial contract (anything over a million dollars), brief them in early. When you start seeing the warning signs described in this article, you want legal already across the issues, not starting from scratch.

Align executives to the post-project reality. Start the contract management conversation with your executive sponsor early. The question they need to understand is: how will unresolved issues be managed after project completion? Executives who engage during delivery can resolve vendor disputes while the project governance still exists. Those who disengage inherit the disputes in BAU without the team, the structure, or the leverage.

When the trap has already closed

If you're reading this and recognising your current situation, the governance fix is harder to implement mid-project, but it is not impossible. Start by building your evidence base. The documentation discipline described above gives you the foundation.

Then have the governance conversation. Your framing shouldn't be "the vendor is the problem" or "I need more support."

It should be: "The current governance structure has the PM making commercial decisions without appropriate delegation. Here's the risk. Here are the options for restructuring."

You're not asking for help. You're identifying a governance gap and proposing a fix. That is your job. And if the executive won't engage even after you've framed it that way, document that decision too.

When the vendor play escalates (and it will), your paper trail needs to show that you raised the structural issue and it was not addressed.

When the structure will not change

Sometimes the governance conversation fails. The executive will not engage, the organisation will not fund a contract manager, and you are still the only person holding the vendor to account. This is where most advice articles stop. Here is what you can do anyway.

No contract manager? Become the contract literate PM. Read the contract yourself. Know the milestone conditions, the remediation clauses, and the variation mechanisms.

When you raise an issue with the executive, frame it as "under clause 7.3, we are entitled to withhold payment until the defect is resolved." That is harder for an executive to dismiss than "the vendor hasn't fixed the bug."

Executive disengaged? Make the cost of disengagement visible. Executives respond to risk, not operational detail. Frame every escalation in terms they care about: financial exposure, timeline impact, reputational risk.

"If we accept this deliverable without the defects resolved, we inherit a $200K remediation liability in BAU" gets attention. "The vendor hasn't met acceptance criteria" does not.

Vendor already running the personality play? Request that the executive attend one vendor meeting. Just one. Most executives who see the dynamic firsthand shift their position.

If they will not attend, send them a written summary of each meeting within 24 hours. Make the executive's inbox the record of what is happening, not the vendor's version of events.

No one will own post-project issues? Raise it as a risk item in the steering committee. The question is simple: who owns unresolved vendor issues after the project closes?

If the answer is "nobody has been assigned," that is a governance gap the steering committee needs to resolve while the project governance still exists. Executives who engage now avoid inheriting vendor disputes in BAU without the team, the structure, or the leverage to resolve them.

The principle

Vendor management on delivery projects isn't a relationship problem. It's a governance design problem. When one person holds delivery, technical, and commercial authority, the vendor can reframe legitimate enforcement as personality. Separate the roles. Make the escalation path explicit. Document quality decisions against the specification. Fix the structure, not the PM.

And if you're hiring a PM for a vendor delivery engagement, understand what you're actually buying. You're not buying someone who will keep the vendor happy. You're buying scar tissue: the pattern recognition that comes from having been through this before and the discipline to separate the roles before the trap forms. That is what experience is worth.

This article contributes risks V1-V4, G1-G4, G8-G10, S1-S2, S6, C4, K4, and CO4 to the practitioner's risk taxonomy.