Running an ERP Buying Committee Without Losing Stakeholder Buy-In

A mid-size logistics company spent fourteen months evaluating ERP vendors before buying anything. Not because the vendors were bad or the requirements were unusually complex — the shortlist was down to two credible options by month four. It stalled because operations wanted a system built around real-time load tracking, finance wanted a system built around clean multi-entity consolidation, and nobody had established, before the evaluation started, whose requirements would win when they conflicted. Every vendor demo turned into a fresh argument about priorities that should have been settled internally before a single sales call.

Most failed or stalled ERP purchases fail at this stage, not the implementation stage. The internal buying process — who's in the room, who has veto power, how requirements get weighted — determines whether a purchase happens in four months or fourteen, more than the vendor shortlist does.

Build the committee around decision rights, not department representation

The instinct is to put one representative from every department that touches the system on the buying committee — finance, ops, sales, IT, HR — so everyone feels heard. That's how you get the logistics company's fourteen-month stall. A large committee without clear decision rights doesn't produce a well-balanced decision; it produces gridlock, because every department can veto by withholding enthusiasm indefinitely without ever explicitly saying no.

A better structure: a small core group of 3-4 people with actual decision authority, plus a wider group of 8-12 stakeholders who provide input at defined checkpoints but don't hold veto power. The core group should include the executive sponsor (usually the CFO or COO, whoever controls the budget), the person who will own the system operationally after go-live, and someone from IT who can assess technical fit. That's it. Everyone else gets structured input sessions, not a permanent seat.

Weight requirements before you see a single demo

The reason vendor demos become political battlegrounds is that requirements get gathered as an unweighted wish list — a spreadsheet where finance's "must have multi-entity consolidation" sits next to sales' "must have a mobile quote-builder" with no signal of which one actually matters more to the business. Every stakeholder assumes their item carries equal weight, and every vendor demo becomes a proxy fight over whose priorities the company takes seriously.

Fix this before the RFP goes out. Score each requirement 1-5 on business impact (not "how much would this help my department" but "how much does this affect revenue, cost, or compliance risk") and get the executive sponsor to approve the weighted list before any vendor is contacted. This single step — assigning and publishing weights before evaluation starts — is the difference between a demo where stakeholders evaluate fit against agreed criteria and a demo where stakeholders each root for the vendor that happens to favor their department.

Structure the RFP to expose real gaps, not vendor sales pitches

A generic RFP inviting vendors to "describe how your solution meets our needs" produces generic answers, because it lets vendors describe their product in the abstract instead of against your actual operations. Two changes make the RFP responses far more useful:

• Ask for responses against specific scenarios, not feature lists. Instead of "does your system support multi-currency consolidation," describe an actual scenario: "we have a US parent entity and a Canadian subsidiary; walk through exactly how a Canadian AP invoice flows into consolidated US-dollar financials, including what happens at month-end FX revaluation." Vendors who can answer this in specific, screenshot-backed detail understand your problem. Vendors who answer with marketing language don't.
• Require a reference customer of similar size and industry, and actually call them. Ask that reference customer specifically what went wrong during implementation, not just what's gone well since — every reference call defaults to positive unless you ask a pointed question that invites a real answer.

Set the sign-off sequence before you're inside a negotiation

Decide in advance exactly who signs off at each stage — shortlist, finalist selection, contract terms, final budget approval — and get that sequence agreed to before vendor negotiations start. Without this, you end up negotiating final terms with a vendor while simultaneously discovering that someone with informal veto power (a department head who wasn't in the core group but has the CEO's ear) has late-stage objections that could have surfaced in month one.

This is also where budget conversations belong. Before finalist negotiations, get the core group to agree on a maximum acceptable total cost of ownership, not just a license price — implementation, training, ongoing support, and realistic customization cost. Running finalist quotes through a TCO calculator at this stage, using real numbers from the RFP responses, keeps the negotiation grounded in an actual budget ceiling rather than whatever number the vendor's proposal happens to land on.

Political failure modes worth watching for specifically

Beyond the structural fixes above, a few specific behavior patterns show up repeatedly in stalled ERP purchases, and recognizing them early lets a sponsor intervene before they take over the process:

• The silent veto. A stakeholder who never explicitly objects but consistently finds a reason a vendor "isn't quite right" — a minor feature gap, a UI preference, a reference call that "didn't feel great" — without ever stating the actual underlying objection. This usually means the real issue is something they're uncomfortable raising directly, often a fear about how a new system will change their role or visibility into their department's numbers. Naming this directly in a private conversation, rather than letting it play out across three more vendor rounds, resolves it far faster.
• Scope creep disguised as due diligence. A committee member who keeps adding "just one more" evaluation criterion or "just one more" vendor to the shortlist late in the process. Occasionally legitimate, but often a delay tactic from someone who isn't ready to commit and would rather extend the process indefinitely than say so.
• The department champion who oversells internally. Someone who's personally sold on a specific vendor — sometimes because of a prior relationship at a previous employer — and downplays real gaps when reporting back to the committee. This is why requiring RFP responses against specific documented scenarios matters: it makes the vendor's actual capability visible to the whole committee rather than filtered through one enthusiastic advocate's summary.
• Budget ambiguity used as a stalling tool. A finance stakeholder who never gives a firm number for what's actually approved, which lets every vendor conversation restart from "we're not sure what we can spend." Getting a real budget ceiling approved and documented before RFP responses come back removes this excuse entirely.

How to unstick a decision that's already stalled

If a purchase is already six-plus months in with no resolution, which describes a large share of stalled ERP decisions, the fix usually isn't more information. It's almost always a decision-rights problem discovered too late. A few concrete steps recover a stalled process faster than restarting the evaluation from scratch: first, get the executive sponsor to explicitly restate, in writing to the full stakeholder group, who has final decision authority and by what date a decision will be made regardless of remaining disagreement. Second, take the disagreement that's actually stalling things (usually one specific unresolved conflict, not a vague sense of stuckness) and force it into a direct conversation between the two parties who disagree, with the sponsor present to make the final call if they can't resolve it themselves within that meeting. Third, set a hard decision date and communicate that after that date, the sponsor decides unilaterally using the already-weighted criteria, with or without full consensus. The logistics company that took fourteen months eventually closed the decision in three weeks once the COO set exactly this kind of deadline and stated plainly that consensus was no longer required, only input.

A rough timeline for a company under 200 employees

Phase	Realistic duration
Requirements gathering and weighting	3-4 weeks
RFP drafted and sent to 4-6 vendors	2 weeks
Vendor responses and initial scoring	3-4 weeks
Demos and reference calls, shortlist to 2	4-6 weeks
Finalist negotiation and sign-off	3-5 weeks

That's roughly four months end to end, which is achievable specifically because the decision rights, weighting, and sign-off sequence were settled before the process started, not negotiated in real time as disagreements came up. The logistics company's fourteen-month timeline wasn't caused by a hard decision — the two finalist vendors were both credible. It was caused by never deciding, up front, how the decision itself would get made.