A Methodology for Defensible Enterprise Software Selection

Enterprise software selection is among the highest-stakes operational decisions most organizations make. Implementation costs typically run several times the license cost. Switching costs are substantial. Wrong selections affect operations for years. Despite the stakes, most software selection processes are heuristic rather than systematic.

This article presents a methodology for software selection grounded in research on procurement outcomes and implementation success.

The variables that should drive selection

Defensible software selection reflects several variables:

1. Functional fit. Whether the software's capabilities match actual operational requirements. Functional fit is more nuanced than feature checklists suggest; the question is not whether features exist but whether they work in the operational context.

2. Implementation feasibility. The operational, technical, and organizational requirements for successful implementation. Implementation feasibility is often the binding constraint, not functional capability.

3. Total cost of ownership. License cost, implementation cost, ongoing operational cost, training cost, and the inevitable customization and integration costs over a multi-year horizon.

4. Vendor durability. Whether the vendor will exist and maintain product investment over the relevant time horizon.

5. Switching cost. What it would cost to migrate away if the selection proved wrong.

6. Strategic alignment. Whether the software supports broader organizational strategy or merely addresses immediate operational needs.

The systematic selection process

For systematic software selection:

1. Define operational requirements specifically. Not features but operational outcomes. What must operations be able to accomplish that they currently cannot?
2. Identify the realistic candidate set. Generally 3-5 candidates. More than 5 produces decision paralysis; fewer than 3 produces inadequate comparison.
3. Evaluate against weighted criteria. Functional fit, implementation feasibility, TCO, vendor durability, switching cost. Weights should reflect organizational priorities.
4. Conduct structured reference checks. With organizations of similar size, industry, and use case who have completed implementation.
5. Pilot under operational conditions. When feasible, structured pilot in actual operational context rather than vendor demonstrations.
6. Document the selection rationale. Specific reasons for the selection that can be evaluated retrospectively.
7. Plan for the implementation phase. Selection without implementation planning produces predictably poor outcomes.

The functional fit assessment

Functional fit assessment is the most familiar element of software selection but often the least rigorously done. The common approach — feature checklists provided by vendors — produces poor functional fit assessment because vendors tend to claim capability liberally and because feature presence does not equate to operational utility.

Effective functional fit assessment requires:

• Use cases defined by the buyer, not the vendor. Specific scenarios reflecting actual operational needs.
• Demonstration of use cases, not features. Vendor demonstrations should show the buyer's use cases working end-to-end, not feature highlights.
• Hands-on evaluation by actual users. Decision-maker evaluation of demonstrations is poor proxy for actual user experience.
• Edge case examination. The handling of edge cases often reveals whether functional capability is real or superficial.

Functional fit assessment grounded in actual use cases produces substantially more accurate selection than checklist-based evaluation.

The implementation feasibility assessment

Implementation feasibility is the most consequential and most undermanaged element of software selection. The research on enterprise software implementation suggests that 30-50% of implementations fail to achieve stated objectives, and most failures are implementation failures rather than software failures.

Implementation feasibility factors:

• Organizational readiness. Whether the organization has the change management capacity for the implementation.
• Technical environment compatibility. Whether the existing technical environment supports the software.
• Resource availability. Whether internal resources are available for the implementation effort.
• Implementation partner ecosystem. Whether qualified implementation partners are available and affordable.
• Realistic timeline. Whether the implementation can be completed in the available timeframe.

Software with excellent functional fit but poor implementation feasibility for the specific organizational context typically produces worse outcomes than software with adequate functional fit and high implementation feasibility.

The total cost of ownership

License cost is typically 20-40% of total software cost over a five-year horizon. The remainder includes implementation, training, ongoing support, integration, customization, and the operational cost of the changes the software requires.

TCO assessment should include:

• License cost over the relevant horizon
• Implementation cost (typically 1-3x license cost for enterprise software)
• Training cost for affected users
• Integration cost with existing systems
• Ongoing operational cost for support and maintenance
• Customization cost for organization-specific requirements
• Internal resource cost for ongoing administration

Vendor pricing focuses on license cost. Buyer evaluation should focus on TCO. The two often produce different selection conclusions.

Reference check methodology

Structured reference checks are among the highest-value elements of software selection but among the most poorly executed. The common reference check — vendor-provided contacts giving brief positive testimonials — produces minimal useful information.

Effective reference checks require:

• References representative of the buyer's situation. Similar size, industry, complexity, use case.
• Detailed structured discussion rather than testimonial collection. Specific implementation experiences, specific operational outcomes.
• Discussion of what went poorly. Every implementation has problems; references reluctant to discuss problems are less informative than those who will.
• Multiple stakeholder perspectives. IT, operational users, finance, executive sponsors. Each perspective reveals different aspects.
• Independent reference identification. Beyond vendor-provided references, independent identification of similar implementations.

Well-executed reference checks frequently reveal information that changes selection conclusions.

Common selection failures

Several patterns consistently produce poor selection outcomes:

• Feature-driven selection. Selection based on feature comparison without adequate attention to implementation feasibility and TCO.
• Vendor-driven evaluation. Allowing vendors to define the evaluation criteria and process.
• Inadequate stakeholder involvement. Selection by IT or procurement without adequate user input.
• Compressed timeline. Forcing selection within timeframes too short for adequate evaluation.
• Anchoring on incumbent. Disproportionate weight to retaining existing software regardless of fit.
• Anchoring on novel. Disproportionate weight to newer entrants regardless of operational maturity.

The takeaway

Software selection methodology substantially affects implementation outcomes. The framework above provides a structured alternative to heuristic selection.

For organizations experiencing chronic software implementation problems, the diagnosis is often inadequate selection methodology rather than inadequate software. Systematic selection produces both better selections and better implementation outcomes from those selections.

Source notes

Synthesis of published research on enterprise software procurement and implementation outcomes from major analyst firms and academic research, 2018-2024.