It’s not what they wanted?
A plethora of examples of poor selection practices can be pointed to over the past 10-15 years.
Let’s consider a recently scrapped CTRM selection project for an ASEAN Oil, Gas and energy organisation. They spent 3 years and over $30 million before realising “it’s not what they wanted”. This prompted Jason Novobranec, an expert on CTRM IT project failures to ask
“What kind of planning process accepts $30 million dollars of waste?”
Where do requirements come from?
A close friend 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. Massive 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 synthesise 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? Was the board Audit & Risk committee involved?
Sometimes organisations don’t even know what all their current 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. Over half of CTRM 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?
Gut feeling works, doesn’t it?
A key issue is having standardised 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…. Sorry, this is NEVER a good idea.
Jason Novobranec as an expert on CTRM 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 realised. Moreover, political dynamics probably make realising 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 centre mindset
Jason 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 sabotage a ctrm 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 CTRM 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 sabotage 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
A pervasive issue of poor communication creates difficulties throughout the selection process. It starts with requirements, and problems only compound as the project pushes through the evaluation and RFP stages. You need to have a centralised collaborative approach—guiding stakeholders through each step—and allowing all parties to contribute effectively.