Contents
The Hidden Cost of Choosing the Wrong System
Selecting the wrong business system is one of the more expensive mistakes an organisation can make — and one of the more common ones. A poorly chosen ERP system, CRM platform, or operational software can cost significantly more than the initial licence and implementation fee. The real costs come later: the productivity lost during a failed or prolonged implementation, the integration challenges that drag on for months, the workarounds that become permanent, and eventually the cost of switching to something else.
What is notable about most technology selection disasters is how avoidable they were. In the majority of cases, the failure was not caused by the technology itself — it was caused by the selection process. The wrong platform was chosen because the business did not clearly define its requirements, because the evaluation was led by IT without sufficient input from the business, or because the decision was made too quickly under commercial pressure from a persuasive vendor.
A structured approach to vendor selection does not guarantee a perfect outcome. But it substantially reduces the risk of the most common and costly mistakes.
The Most Common Reasons Technology Selection Goes Wrong
Starting With a Solution Instead of a Problem
Many technology selection processes begin with a shortlist of vendors rather than a clear definition of the business problem. A senior leader has seen a demonstration, a colleague from another company has recommended a platform, or the incumbent system has become so frustrating that any alternative looks attractive.
The result is a selection process that is essentially a rationalisation exercise — finding reasons to choose a platform that was effectively pre-selected, rather than genuinely evaluating which option best fits the organisation’s needs.
Requirements That Are Too Vague or Too Detailed
Requirements gathered too quickly tend to be either vague (“we need a system that improves our customer management”) or overwhelmingly detailed — a hundred-page specification document that no vendor can fully meet and that took three months to produce.
The sweet spot is a structured set of requirements that captures the genuinely critical functionality (must-haves), the important but not essential functionality (should-haves), and the desirable but lower-priority functionality (nice-to-haves). This distinction matters enormously during evaluation.
Evaluating on Features Instead of Fit
Vendor demonstrations are designed to impress. They showcase the platform’s capabilities in the most favourable conditions, typically using prepared data and experienced demonstrators. The result is that most enterprise software looks genuinely impressive in a demo.
The real question is not “does this platform have impressive features?” but “does this platform fit how our business actually works, and can we successfully implement and adopt it?” Those are very different questions, and answering them requires more than a standard sales presentation.
Underestimating Total Cost of Ownership
The licence or subscription fee is typically the smallest component of total cost. Implementation costs — which include data migration, system configuration, integration with existing systems, testing, training, and change management — often amount to three to five times the annual licence fee for complex systems.
Ongoing costs are also frequently underestimated: maintenance, support, upgrades, and the internal resource required to manage the system once it is live. A total cost of ownership model that covers five years gives a much more accurate picture of the actual investment than a headline price comparison.
Neglecting the Vendor as a Business Partner
A technology system is not just a software product — it is a relationship with a vendor that may last five to ten years. The vendor’s financial stability, their approach to support and product development, their responsiveness to issues, and the quality of their implementation capability all matter as much as the functionality of the platform itself.
Evaluating the vendor as a long-term business partner — not just the product they are selling — is a critical and often neglected part of the selection process.
A Structured Approach to Vendor Selection
Phase 1: Define the Problem and Desired Outcomes
Before approaching any vendors, invest time in clearly defining what the new system needs to solve. This means identifying the specific business problems or inefficiencies that the current situation creates, and defining what success looks like in measurable terms.
For example: “Our current CRM system is not integrated with our finance system, which means our sales team spends approximately four hours per week on manual data reconciliation, and our customer data is frequently inaccurate.” That is a precise, solvable problem — far more useful than “our CRM system is not fit for purpose.”
Phase 2: Gather Structured Requirements
Requirements should be gathered with input from all major stakeholder groups — not just IT and not just the leadership team. The people who use the system daily have critical insight into what works, what does not, and what they genuinely need.
Organise requirements into three tiers:
- Must-have — non-negotiable. Any system that cannot meet these requirements is automatically eliminated.
- Should-have — important, but a workaround may be acceptable.
- Nice-to-have — desirable, but not a deciding factor.
Must-haves should be genuinely critical — not wishful thinking. If a requirement is listed as must-have but the organisation could function without it, it probably should not be on that list.
Phase 3: Long-List to Short-List
Use the must-have requirements to screen the market and produce a long list of platforms that could potentially meet the organisation’s core needs. Then apply a more structured evaluation to reduce this to a short list of typically two to four vendors.
At this stage, a Request for Information (RFI) is a useful tool — a structured questionnaire sent to vendors to understand their capability, approach, and experience with similar organisations. The responses give early insight into how vendors communicate and how seriously they take the engagement.
Phase 4: Structured Demonstrations and Scoring
Request demonstrations from short-listed vendors. But rather than allowing vendors to present whatever they choose, provide a scripted scenario — a set of business cases and workflows that reflect how the system would actually be used in your organisation. This ensures that all vendors are evaluated on the same basis and that the demonstrations remain relevant to the real requirements.
Score each demonstration against your requirements framework, ideally using a cross-functional evaluation team so that perspectives from IT, operations, finance, and the end-user community are all represented.
Phase 5: Reference Checks and Due Diligence
Speak to organisations that are currently using the vendor’s system — ideally organisations of similar size and complexity, in a similar sector if possible. Ask specific questions: What did implementation actually cost and take? What problems did you encounter? How responsive is the vendor’s support? Knowing what you know now, would you make the same decision?
Also conduct financial and operational due diligence on the vendor itself. A platform acquired by a private equity firm, or a vendor whose product is being deprecated in favour of a new offering, carries risks that are worth understanding before signing a multi-year contract.
Phase 6: Negotiation and Contracting
Contract negotiation is where organisations often leave significant value on the table. Licence fees, implementation costs, support terms, upgrade rights, data portability provisions, and exit clauses are all negotiable — and the time to negotiate is before the contract is signed, not after.
It is worth involving someone with commercial negotiation experience at this stage, even if the technical and business evaluation was handled internally. The difference between a poorly negotiated and a well-negotiated technology contract over a five-year term can be substantial.
The Decision Framework: A Practical Tool
A weighted scoring model is a useful tool for making the final decision more objective. Assign weights to the main evaluation criteria — reflecting their relative importance to your business — and score each vendor against those criteria. The resulting scores give a structured basis for the decision, reduce the influence of individual bias, and make the decision-making rationale clear and documentable.
The criteria typically include: functional fit with requirements, total cost of ownership over five years, implementation approach and timeline, vendor financial stability and product roadmap, quality of references, and ease of integration with existing systems.
The model should inform the decision, not make it automatically. The structured scores sometimes surface unexpected results — a vendor with a lower functional score but a significantly lower total cost of ownership may represent better value than the technically superior option.
A Note on Independent Advice
Vendors have a strong interest in being selected. Their sales teams are skilled at building relationships, creating urgency, and making their platform look like the obvious choice. This is not a criticism — it is simply how enterprise technology sales works.
Independent advisors who are not remunerated by vendors can provide a genuinely neutral perspective during the selection process. They bring market knowledge (which vendors are genuinely appropriate for a given type of requirement?), experience with what implementations actually involve versus what vendors claim, and the ability to challenge vendor claims without a conflict of interest.
This kind of independent support is not always necessary, particularly for less complex technology decisions. But for significant investments — ERP systems, core operational platforms, major CRM implementations — independent advice during the selection phase typically pays for itself many times over.
Conclusion
Technology selection is a business decision, not a technical one. The right platform is the one that best fits the organisation’s actual needs, that the organisation can successfully implement and adopt, and that delivers genuine business value over the medium term.
Getting there requires clarity about the problem, discipline in gathering and applying requirements, rigour in evaluating options, and honesty about total cost. None of these require advanced technical expertise. They require structured thinking and the patience to do the process properly.
The organisations that invest in a proper selection process almost always make better decisions than those that move quickly, trust vendor demonstrations, and discover the real picture during implementation.
If you are planning a technology selection and would like to discuss a structured approach, feel free to get in touch via the Contact page. I would be happy to hear about your situation.
Frequently Asked Questions
How long should a technology vendor selection process take?
For significant technology decisions — ERP, CRM, core operational systems — a well-structured process typically takes eight to sixteen weeks. This includes requirements gathering, long-listing, short-listing, structured demonstrations, reference checks, and contracting. Rushing this process is one of the most common causes of poor technology decisions.
Should IT lead the technology selection process?
IT should be a central participant, but not the sole owner. Technology selection decisions have significant business implications — operational, financial, and organisational. Business stakeholders, including the functions that will use the system most heavily, should play an equally important role in the requirements gathering and evaluation stages.
What is a Request for Proposal (RFP) and when should you use one?
A Request for Proposal is a formal document sent to vendors asking them to respond to a structured set of requirements and questions. RFPs are useful for complex technology decisions where you need detailed, comparable responses from multiple vendors. For simpler purchases, a less formal process is usually sufficient.
How do you evaluate a vendor’s long-term viability?
Look at the vendor’s financial position (publicly available for listed companies; less transparent for private ones), their product roadmap and investment in R&D, their market position and customer base, and whether recent ownership changes (acquisitions, private equity) could affect their focus or direction.
Is it worth using an independent consultant for technology selection?
For significant investments — particularly core operational systems — independent advice typically adds more value than it costs. The key word is “independent”: advisors who receive fees from vendors have an inherent conflict of interest. Look for advisors who are paid by you and have no commercial relationship with the vendors on your shortlist.
