Rethinking enterprise software selection: Beyond checklists to real organisational fit

Enterprise software selection too often begins with a tidy checklist and ends with a decision that feels more certain than it is.

That, at least, is the argument from Sudhakar Shivaraju, vice-president for global real estate systems at JPMorgan Chase, in a guest post for CIO Dive. Drawing on two formal vendor evaluations he has led in different sectors and at different points in his career, he says the biggest danger is not simply choosing the wrong supplier. The greater risk i...

s assessing the wrong factors, or assigning the wrong importance to the right ones, for the realities of the organisation in question.

His central point is that CIOs should stop treating vendor comparisons as a box-ticking exercise built around generic product features. Instead, they should judge systems through functional domains that mirror how the software will actually be used. Those domains include security and compliance, integration and API design, user experience and adoption, vendor support and roadmap clarity, AI capability, and total cost of ownership, including implementation and migration risk.

That approach, Shivaraju argues, produces a more truthful comparison because it shifts attention away from what appears on a sales sheet and towards what will matter once the software is live. It also forces leaders to decide what really counts in their own environment. A highly regulated multinational, for example, will place far more emphasis on data residency, compliance and security than a smaller business operating in a single market.

The weighting, he says, is itself a strategic choice. A vendor that performs well in one area may still be the wrong fit if the organisation has concentrated risks elsewhere. Likewise, support responsiveness can be critical for a company that depends on rapid issue resolution at scale, but much less important where internal teams can absorb more of the operational burden.

Shivaraju also argues that roadmap discussions deserve more seriousness than they often receive. Vendor conferences, product briefings and direct conversations with senior leadership can provide genuinely useful evidence, including confirmed launch dates, features under development and commitments that matter more than marketing claims. But he warns against blending what is already available with what is merely promised. A scorecard that treats future capability as though it already exists, he suggests, is built on optimism rather than evidence.

That caution extends to artificial intelligence, which he says should be assessed as a distinct category rather than a single line item. Nearly every supplier now claims some form of AI functionality, but that does not mean the capability is mature, production-ready or suitable for a regulated environment. Questions should include whether the feature uses the organisation’s own data or a generic layer, how information is handled once AI is involved, and whether the function is genuinely live or still a roadmap ambition presented too early in the sales cycle.

The article also stresses a factor many buying teams underplay: switching costs. Data migration, staff retraining, workflow redesign and re-establishing integrations can be expensive and disruptive, even when they are difficult to quantify. According to Shivaraju, those hidden costs should be built into total cost of ownership from the outset rather than left as an afterthought. In some cases, that calculation may make an incumbent vendor with clear weaknesses the most rational choice.

Related guidance from AI vendor-selection frameworks makes the same broader point. Industry checklists and evaluation models increasingly argue that companies should look well beyond licence fees and consider implementation, onboarding, training, maintenance, scaling, infrastructure, exit costs and contract terms over a multi-year horizon. The common thread is that a strong shortlist depends less on vendor presentation than on a disciplined scoring structure that separates actual capability from aspirational claims.

Shivaraju’s conclusion is blunt: a loose evaluation process can produce a persuasive answer that collapses once the software is in use. A rigorous one, built around real constraints and honest trade-offs, is more likely to stand up long after procurement is complete. For technology leaders, he says, the hard part is not comparing vendors. It is designing an evaluation framework honest enough to trust.

Source: Noah Wire Services