When an ERP project fails, the implementation phase is often thought to be at fault, when in retrospect these projects are doomed to fail years before the contract is even signed. Buyers are throwing millions at a product they don’t fully understand – a gamble which creates a huge risk to their business.
Let’s re-evaluate how procurement typically works by considering the common pitfalls.
Stages of procurement
Usually an IT procurement process involves three phases: market analysis, a documented requirement and a software demonstration. This established process seems like the safe option – but how often do we evaluate each step in this journey?
Starting off with overall market analysis, this typically sees a business employing the use of an industry analyst – and, subsequently, a list of somewhere between five to ten appropriate software vendors is produced. While this process gives some useful information, buyers should be vigilant when reviewing the results, given that the analysis is typically driven and paid for by the vendors under review.
The what vs the how
A documented requirements process sees us bring in Request For Proposal (RFP) and/or Information (RFI), Invitation To Tender (ITT) documents and so on. All of which are generally 90 percent focused on software capability (the what) and just 10 percent on the overall approach (the how). The aim of these documents is to assess the differentiating factors between the different software options and the vendors implementing them.
The first mistake is spending the majority of the process on spotting the difference between the software products – commonly, they will be extremely similar. An additional problem to note is the issue of eloquence vs expertise. A well written RFP does not prove an understanding of the product, its capabilities nor the best practices for implementation.
Demonstrably differentiated demos
The strongest proposals are then invited to run a software demo. The vendors provide demonstrations including specific requirements to a mixed audience, ranging from decision-makers and general users to IT specialists.
To put it simply, the decision-makers just want to know if it will work, the general users want to see how it will work day-to-day and the IT specialists want to understand how it works. How can one demo meet all these needs without compromising another, while still keeping it short and simple?
Many of those involved in voting and scoring only have a passing understanding of the solution and the processes required, making a meaningful comparison of vendors difficult. Here we encounter the same issue of the capabilities of the presenter being judged over the quality of what is being presented.
Cards on the table
Once these three phases have been navigated, negotiations will begin. But commercial negotiations and specifications are written in confusing, advanced technical terms.
Ultimately the end results are unpredictable. Sometimes the approach is effective and the project works well, but frequently the outcome is not what either party wanted. The buyers spend too long trying to select software, thinking technology is the answer – which it is, partly – but an average solution implemented well will outperform a good solution implemented badly.
So, what is the right way to do this?
The industry has to change – it needs more educated buyers and for people to stop trying to buy complex change programs as if they are hardware or stationery. This is where we are starting to get into the topic of potential solutions and alternatives to these highly-risky, expensive and time-consuming processes – but let’s save that discussion for another story on another day.
This is a guest post for ERP Today written by Colin Hennis in his capacity as director at Delaware United Kingdom – a company that delivers advanced IT solutions and services, guiding organizations through their business and digital transformations.
