Herding Cats: How to Align Internal Stakeholders Before Going to Market

Most sourcing projects don’t fail because suppliers are weak—they fail because the business isn’t aligned. A practical, psychology-aware playbook for category managers to map players, run intake properly, and co-create decisions without losing control of the process.

Updated on September 21, 2026 · Herocurement Editorial
Jump to section

The Hook: Why “failed sourcing” is usually an internal alignment problem

When an RFQ goes sideways, the post-mortem often blames “supplier quality” or “market constraints.” In practice, the damage is usually done earlier: unclear outcomes, hidden vetoes, and stakeholders quietly optimizing for their own risk and workload. By the time the RFQ is published, you’re just formalizing disagreements that were never resolved.

A common pattern: procurement runs a clean process, gets competitive bids, and then the business rejects the shortlist with a late-breaking requirement (“it must integrate with our legacy tool,” “legal won’t accept that clause,” “operations can’t change the schedule,” “IT security needs a different hosting model”). None of that is new information. It was simply not surfaced, or it was surfaced and ignored because it sounded like “noise.”

Stakeholders aren’t being difficult for sport. They’re protecting something: uptime, safety, compliance, political capital, their team’s capacity, their own credibility. If you treat stakeholder alignment as a meeting you need to “get through,” you’ll get compliance in the room and resistance after the meeting.

The uncomfortable truth for mid-level category managers: you can’t control people, but you can control the conditions. Your job is to make the decision safe enough, clear enough, and structured enough that stakeholders stop playing defense with last-minute objections.

The Stakeholder Matrix: Map players by influence and interest (and don’t stop there)

The classic influence/interest matrix is useful, but only if you treat it as a prediction tool: who can block, who will care, and who will disappear until something goes wrong. Build the map before you build the RFQ.

Step 1: Identify four roles, not just job titles

  • Economic owner: owns the budget or the P&L impact (may not be the requester).

  • Process owner: lives with the operational outcome (often operations, IT, facilities, clinical, etc.).

  • Risk owner: signs for compliance, security, safety, legal exposure, or audit outcomes.

  • Hidden influencer: the person everyone listens to even without formal authority (a senior engineer, an EA, a plant manager, a long-tenured admin).

If you can’t name the risk owner, you’re not ready to go to market. They will appear later, usually at the worst moment, with a non-negotiable constraint.

Step 2: Plot influence and interest, then add “stance”

Influence and interest tell you where to spend time. Stance tells you how hard the conversation will be. Tag each stakeholder as: supportive, neutral, skeptical, or opposed. Then write one sentence on why. “Opposed because they fear service disruption,” is actionable. “Opposed because difficult,” is not.

Step 3: Surface veto points explicitly

Vetoes are often informal: “IT won’t allow that,” “legal will never sign,” “the site will refuse.” Ask directly: what decision rights do you believe you have, and what decision rights do you believe others have? Misaligned beliefs about authority create rework more reliably than any supplier issue.

  • Who can stop the project?

  • Who can slow it down by withholding inputs?

  • Who can create operational non-adoption after award?

  • Who is accountable if the solution fails in production?

A pragmatic note: don’t try to convert every skeptic into a fan. Aim for “no surprises” and “clear trade-offs.” Some stakeholders only need to feel heard and protected—not enthusiastic.

The Intake Strategy: Extract real requirements (not preferred suppliers)

Many intake meetings turn into a procurement-hosted sales pitch for a stakeholder’s favorite vendor. The stakeholder may genuinely believe they’re being helpful. They’re also trying to reduce their own risk: choosing what they already know feels safer than choosing what’s best on paper.

Start with outcomes and constraints, not vendors

When someone says, “We need Supplier X,” translate it into a requirement. Ask: what problem does Supplier X solve that others failed to solve? What would success look like in 90 days after go-live? What would be unacceptable? Keep pulling until you have measurable outcomes and hard constraints.

  • Outcome questions: “What changes for your team if this works?” “What KPI moves?” “What’s the cost of doing nothing for six months?”

  • Constraint questions: “What can’t change?” “What policies must be met?” “What integrations are mandatory?” “What is the maximum acceptable downtime?”

  • Evidence questions: “What happened last time?” “What incidents are you protecting against?” “What data do we have, even if imperfect?”

Use the “Three Buckets” method to stop requirement creep

Stakeholders often add requirements as they remember pain points. That’s normal. The mistake is treating every new idea as a must-have. Split requirements into three buckets and force explicit choices.

  • Non-negotiables (must): regulatory, safety, security, or operational constraints that genuinely block adoption.

  • Value drivers (should): items that differentiate suppliers and matter to outcomes (e.g., response times, implementation support, reporting).

  • Preferences (could): nice-to-haves that can be traded for cost, speed, or simplicity.

If everything is a “must,” your RFQ becomes a custom-build wish list and you’ll either get no bids or overpriced bids. Being firm here is not procurement being stubborn; it’s procurement protecting the project from itself.

Pre-wire the hard conversations before the group meeting

Group intake sessions reward confident speakers and punish nuance. If you already know legal is going to push back on liability caps, or IT security will reject a hosting model, talk to them one-on-one first. Bring the constraint into the room as a fact, not as a surprise. Stakeholders can handle bad news; they react badly to ambushes.

Write the requirement document like it will be used against you—because it will

A vague requirement (“intuitive UI,” “strong support”) creates scoring debates and post-award disappointment. Replace adjectives with observable behaviors: training hours included, support hours and channels, max response times, implementation milestones, service credits. If you can’t describe how you’ll verify it, it’s not a requirement yet.

The Co-Creation Strategy: Give stakeholders a real voice while procurement keeps control

Stakeholders support what they help build—but co-creation doesn’t mean handing over the steering wheel. Your goal is structured participation: clear roles, clear decision rights, and a process that prevents late-stage re-litigation.

Build an evaluation committee with defined jobs (not a crowd)

Too many committees create performative meetings and slow decisions. Too few voices create rebellion after award. A workable committee is small, cross-functional, and anchored by the people who will live with the outcome.

  • Chair (Procurement): owns timeline, process integrity, and documentation.

  • Business lead (Requester/Economic owner): owns the outcome and signs off on value trade-offs.

  • Technical/risk reviewers (IT, security, legal, HSE, QA—only what’s relevant): own pass/fail gates and risk scoring.

  • Operational representative(s): validates usability, implementation reality, and adoption risks.

Be explicit: reviewers don’t get to add new criteria after bids are opened. If something is missing, it becomes a lesson learned for the next event, not a midstream rule change.

Separate “gates” from “scores” to reduce political fights

Not every criterion should be a weighted score. Some items are pass/fail gates: compliance certifications, security controls, mandatory technical compatibility, required insurances. Put those in a gate checklist. Then use scoring for differentiators: service model, implementation plan quality, commercial terms, innovation, total cost drivers.

This structure stops the common argument where someone tries to “outvote” a real risk by giving a supplier high points elsewhere. Gates protect the organization; scoring helps choose between safe options.

Design workshops that force trade-offs instead of opinions

If you ask, “What’s important?” you’ll get everything. If you ask, “What would you give up to get a 10% cost reduction?” you’ll get priorities. Run a short session where the committee must choose: faster implementation vs. customization, lower price vs. higher service levels, standard terms vs. aggressive liability positions. Capture decisions as trade-offs, not as preferences.

Control the process with a few non-negotiables (and say them out loud)

  • Single source of truth: one requirements document, one scoring model, one decision log.

  • No side deals: all supplier communications go through the defined channel.

  • Decision rights are named: who recommends, who decides, who signs.

  • Timeline discipline: late inputs shift scope, not deadlines, unless the sponsor approves a replan.

This is the “firm” part of diplomatic procurement: you’re not policing adults, you’re protecting fairness, auditability, and speed. Stakeholders usually accept structure when you explain what chaos costs them—rework, delays, and a solution no one wants to own.

Handle the sticky moment: when a powerful stakeholder wants their preferred supplier

Don’t shame them, and don’t pretend it isn’t happening. Acknowledge the underlying need (“You’ve had reliability with them and you don’t want outages”). Then offer a fair path: include the supplier if they meet the gates, and bake the stakeholder’s real concerns into the evaluation (e.g., reference checks focused on uptime, implementation staffing, escalation paths). If the stakeholder refuses any competitive process, escalate early with a simple question to the sponsor: are we sole-sourcing, and if so, what’s the documented rationale and negotiation plan?

Alignment isn’t a warm feeling. It’s a set of decisions made early, written down clearly, and defended calmly when pressure shows up. Do that work before the RFQ, and the market event becomes what it should be: a comparison of suppliers, not a referendum on internal politics.