We expect to buy things without screwing up. Just select what you want and pull out your wallet (ahem). Maybe next week. We are blithely optimistic when it comes to buying a new washing machine, or toaster—it’s going to work as expected, maybe better. Even for larger purchases like a new vehicle, juggling requirements like space, performance, and price is not a brain buster—and can actually be fun.
Select the Right Software with the Free Lean Selection Book
Buying technology for your company is completely different.
But we seem to approach the software selection process with the same casual mindset. Statistics show an alarming (and persistent) level of problems with information technology purchases—Gartner and others cite up to 75% failure rates for ERP implementations for example. Organizational pain and cost related to poor technology selection has become so normal it’s almost blasé to talk about it.
Why all the failure?
IAG Consulting states that the single largest factor, accounting for 70% of project failures, is poor requirements. Other studies show that as a project grows in complexity—with more departments and stakeholders—failure rates rise. The already feeble business and software requirements process breaks down as the scale is increased.
It’s not what they wanted?
A cornucopia of examples of poor selection practices can be found in government. I know, I know. This is like shooting fish in a barrel. But let’s consider the recently scrapped ERP selection project for the US Air Force. They spent 10 years and over $1 billion before realizing “it’s not what they wanted”. This prompted Michael Krigsman, an expert on IT project failures from Asuret to ask “What kind of planning process accepts a billion dollars of waste?”
Where do requirements come from?
My wife works at a midsized energy company that recently selected an enterprise wide system to manage transactions. The system will dramatically change the way people work in at least a dozen departments.
Very few actual users were interviewed for requirements elicitation or invited into the selection process.
But top company executives were tied up for many months in the process of requirements gathering, vendor evaluations and negotiations. Humongous stacks of paper were printed (and reprinted) outlining disparate requirements and how the shortlisted vendors would support the company’s business processes.
Sounds crazy doesn’t it? Who is able to synthesize such gargantuan piles of data—all in documents, emails, and spreadsheets—and come up with a logical decision? They often can’t.
Even if they could, it’s highly likely that the source information is faulty. Did they understand and properly account for departmental priorities—including key stakeholder feedback from piles of paper? Do requirements support long-term business goals, and is there an effective system of functional and technical validation?
Sometimes organizations don’t even know what all their software does. Over a period of time, across multiple upgrades and personnel changes, it is easy to lose track of current capabilities.
It’s not unusual for consultants to get hired for a new software selection project only to find out that the client’s current software already does all the things they require. It just wasn’t properly implemented or adequately understood.
Why is it so hard for companies to understand what they need?
Market confusion seems to be a major component of project failure. According to OOF, over half of ERP decision makers struggle to understand the range of solutions available—and don’t have an effective way to compare— apples to apples. There’s a general sense that the vendor evaluation process lacks clarity in regards to how systems will actually support the company’s processes. So, how do they choose?
Select the Right Software with the Free Lean Selection Book
Gut feeling works, doesn’t it?
A key issue is having standardized language in requirements, translated into the final RFP, that is universally understood by the vendors—and can be validated by the selection team. With a lack of clarity on vendor solutions and a fuzzy set of requirements, companies often fall back on vendor supplied information and “gut feel” to make final decisions. This is rarely a good idea.
Robin Goldsmith, an expert in IT return on investment (ROI) says, “While gut feel surely does sometimes turn out right, intuitive decisions in fact are likely to be ill-advised far more often than realized. Moreover, political dynamics probably make realizing a high-level decision’s weaknesses exceedingly unlikely. Often the person making a questionable decision is the one charged with judging the decision’s worthiness”.
Battling the shopping center mindset
Goldsmith says mistakes happen when buyers miss critical technology acquisition concepts, “Most buyers describe what they want to purchase in terms of a presumed product/system design, rather than in terms of their REAL business requirements that the product/system must satisfy in order to provide value. This mistake is aggravated when buyers focus on what the vendor is selling rather than what they, the buyers, actually need”.
Everything comes back to REQUIREMENTS
How come requirements are “the best way” to screw up a software selection project? Because without requirements, there is no project. If requirements are poorly gathered and managed, your project will suffer at every stage. And in a technology selection, all processes (product evaluations, budgets, contracts, and implementation) must pass the test of “does it meet our stated requirements”.
Some other good ways to screw up your selection project include:
- Improper alignment of business goals with the project
- Not evaluating current system capabilities
- No easy way to measure or track ROI
- Not having the right team
- Executive support lacking
- End users not involved
- Overemphasis on vendor supplied information
- Change management deficiencies
- Faulty contracts
Select the Right Software with the Free Lean Selection Book
We’ve got an app for that!
A pervasive issue of poor communications creates difficulties throughout the selection process, says Venkat Devraj of SelectHub. It starts with requirements, and problems only compound as the project pushes through evaluation and RFP stages. That’s why SelectHub centralizes the whole process on a collaborative platform—guiding stakeholders through each step—and allowing all parties to contribute effectively.