It makes the project about software, not the business
Traditional selection consultants build massive requirements matrices, sometimes containing 500 to 1,000 line items of functionality. The entire project becomes an exercise in determining whether the software can do X, Y, and Z. What gets lost is the fundamental question: what business outcomes are you trying to achieve, and what needs to change in your organization to get there?
A manufacturer struggling with 68% on-time delivery does not have a software problem. They have an operational problem that the right technology, combined with the right process changes, can solve. But if the selection project is built around functionality checklists, nobody is asking what organizational changes need to accompany the technology to actually move that number.
It prevents vendors from being partners
In the traditional model, ERP vendors are treated as commodities to be evaluated, not partners to collaborate with. They are handed a rigid script, told to demo specific functions in a specific order, and given little room to show creative solutions to the client’s actual business problems.
The vendor who could propose a transformative approach to the client’s quoting process or production scheduling is instead spending their demo time proving they can generate a purchase order. This arms-length approach robs the client of the very insight they need most: which vendor truly understands my business and can help me think differently about my operations?
It forces premature pricing without context
Traditional consultants routinely ask vendors to submit pricing early in the process, often before the vendor has had a single meaningful conversation with the client about their challenges. The vendor is estimating scope without understanding whether the client’s pain points stem from a systemic operational issue, a training gap, or a fundamental process design flaw.
This leads to inaccurate proposals, scope mismatches during implementation, and change orders that erode trust and inflate costs.
It sets up implementations to underdeliver
Perhaps the most damaging consequence of the traditional approach is what happens after the selection. Because the entire project was built around software functionality, the resulting Statement of Work for implementation is focused on implementing software, not on achieving outcomes.
The SOW says “configure Advanced Planning and Scheduling” instead of “improve on-time delivery from 68% to 92%.” When the implementation team has no target outcome, the project becomes a technical exercise that may go live on time and on budget but leaves the organization wondering why nothing actually feels different.