The Real Cost of a Bad Software Decision
Every experienced technology leader has a story about an enterprise software procurement that went wrong. An ERP that took three times as long to implement as promised. A CRM that the sales team refused to use. A platform that hit performance limits eighteen months after go-live. A vendor that was acquired and discontinued the product two years after contract signing. These are not rare edge cases — they are common outcomes when procurement decisions are made without a rigorous framework.
The direct cost of bad enterprise software is easy to quantify: licence fees, implementation costs, wasted integration work. The indirect costs are far larger: lost productivity during a painful implementation, decisions made on unreliable data, the erosion of employee trust in technology leadership, and the opportunity cost of a two-year delay in the capabilities you needed.
Defining Requirements Before Evaluating Vendors
Functional Requirements
Before speaking to any vendor, define what the software must do. Involve the actual users — not just managers who think they know what users need, but the people who will use the system every day. Document functional requirements in two tiers: must-have requirements without which the software cannot meet its primary purpose, and nice-to-have requirements that improve the solution but are not essential. This distinction prevents vendors from dazzling you with features you will never use while glossing over gaps in must-have functionality.
Non-Functional Requirements
Non-functional requirements define how the software must perform, not what it must do. For enterprise software, these typically include:
- Performance: Maximum acceptable response time for key operations under expected load (e.g., dashboard loads in under 2 seconds for 500 concurrent users)
- Availability: Minimum uptime requirement, maintenance window constraints
- Security: Data classification requirements, compliance certifications required (PCI DSS, ISO 27001, SOC 2)
- Scalability: Expected data and user growth over three to five years
- Integration: Systems the software must integrate with and the required integration depth
- Data residency: Whether data must reside in Nigeria or specific regions
Vendor Evaluation Framework
Build vs. Buy vs. Configure
Before evaluating specific vendors, answer the strategic question: should you build custom software, buy a packaged solution, or buy a configurable platform? Custom builds maximise fit to your specific processes but require sustained engineering investment and create long-term maintenance obligations. Packaged solutions are faster to deploy but require your processes to adapt to the software's assumptions. Configurable platforms offer a middle path — standard functionality that can be extensively customised without custom code. Match the strategy to the problem.
Vendor Viability Assessment
Enterprise software is a long-term relationship. The vendor you choose today must be capable of supporting you five to ten years from now. Evaluate:
- Financial health: Revenue trajectory, funding status, profitability. A vendor burning cash without a clear path to sustainability is a risk.
- Customer concentration: If one customer represents more than 30% of a vendor's revenue, their departure could threaten the vendor's viability.
- Reference customers: Speak with at least three reference customers in your industry and size range. Ask specifically about support quality, upgrade experiences, and whether they would choose the vendor again.
- Product roadmap: Assess whether the vendor's development priorities align with your direction. A vendor heavily investing in markets or use cases that are not yours will not serve your needs well over time.
Proof of Concept
For high-value procurements, require a structured proof of concept before contracting. Define specific scenarios that the POC must demonstrate — scenarios that test your most critical requirements, including edge cases and failure modes. Evaluate the POC with the actual users who will use the system, not just technical evaluators. A system that impresses in a vendor demo but confuses users in a POC is a system that will not be adopted.
Contract Negotiation Essentials
Service Level Agreements
Negotiate SLAs that have teeth. An SLA that promises 99.9% uptime with a remedy of one month's service credit for non-compliance is largely cosmetic — the financial exposure to the vendor is trivial. Negotiate SLAs with meaningful financial consequences, clear measurement methodologies, and dispute resolution processes.
Data Rights and Exit Provisions
Ensure your contract clearly states: you own your data, you can export it in standard formats at any time, upon contract termination you receive a complete data export within a defined timeframe, and the vendor will not hold your data hostage to extract additional payment. These provisions are especially critical for cloud-hosted SaaS applications where the vendor physically controls your data.
Escrow for Proprietary Software
If you are procuring proprietary on-premise software, negotiate source code escrow with a qualified third party. If the vendor goes bankrupt or is acquired and the software is discontinued, escrow ensures you have access to the source code to maintain the software or engage another vendor to support it.
Implementation Planning
The majority of enterprise software failures happen in implementation, not selection. Require a detailed implementation plan from your vendor before contract signing — one that specifies deliverables, timelines, responsibilities, testing procedures, and go-live criteria. Establish a joint steering committee with vendor and customer leadership to govern the implementation and resolve escalations. Define what success looks like before implementation begins, and measure against that definition at go-live.
Conclusion
Enterprise software procurement is too consequential to be treated as a purchasing process. It is a strategic decision with multi-year implications for your organisation's capability, competitiveness, and operational efficiency. CTOs who invest in rigorous requirements definition, structured vendor evaluation, careful contract negotiation, and disciplined implementation governance consistently deliver better outcomes and avoid the costly failures that make for cautionary tales at industry conferences.
