How to sabotage a CTRM software selection project
We expect to be able to buy things without making mistakes. Choose what you want and reach for the blank cheque!
We are blithely optimistic when it comes to buying a new fridge or washing machine —it’s going to work as expected, maybe better. Even for larger purchases like a new car or house, juggling requirements like space, performance, and the price is not a brainbuster—and can actually be fun.
Buying commodity trading technology for your company is completely different
We seem to approach the ctrm software selection process with the same casual mindset. Statistics show an alarming (and persistent) level of problems with information technology purchases—Gartner along with our own research at Implementary cite up to 75% failure rates for CTRM and parallel integration requirement implementations as examples.
Organisational pain and cost related to poor technology selection have become so normal it’s almost blasé to talk about it.
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.
How can we help?
Talk to us about how we can help your organisation bridge the gap towards CTRM program success. Making it real is what we do.
How can you connect with us?
We’d love to hear about your journey. Did reflecting on CTRM Technology Delivery Assurance help?
About the Author
Jason Novobranec is Implementary’s Chief Operating Officer.
With over 20 years of Consulting, Program Management & Senior Leadership experience, Jason has delivered initiatives for large multi-national / multi-regional organisations as well as SME’s and is an expert in shaping solutions to fit a customer’s project needs.
“CBH has engaged Jason Novobranec of Implementary as a consultant on our Commodity Trading and Risk Management project. He has returned great value with his breadth of knowledge in the area and his experience in working with many of the prospective providers.
We have found his approach to be thorough, forthright and definitive while respecting the views and approach of his client.”
IT Application Services Manager | CBH Group