Software success: Controlling procurement and minimizing sales bias

When it comes to software, management too frequently underestimates the complexity of the selection component. Too often, they approach selection with the view that it’s an administrative project that’s easily completed. This approach, unfortunately, couldn’t be more misguided.

According to our 2011 ERP benchmark survey of manufacturing and distribution leaders, a mere 32 percent of all ERP selection projects succeeded. This means that 68 percent of all ERP projects were doomed to fail before implementation even started. One interpretation of these statistics is that that the majority of business leaders underestimate the complexity of ERP selection – and arguably software selection, in general.

Minimizing sales bias risks

According to the survey results and my interviews with business executives, most leaders understand that enterprise software projects are, at their core, business improvement projects. However, a big problem is that most leaders don’t do a good enough job of ensuring that their business’ requirements drive the software procurement process. By failing to do so, buyers give the vendors an opportunity to turn the purchase process into a sales process. And, once the vendors are given a chance to set the agenda, they have an opportunity to influence the outcome.

This type of vendor-driven influence is called sales bias. It manifests itself when there’s uncertainty about what the buyer needs and how it intends to satisfy its needs. There’s nothing inappropriate about sales bias – it’s how good sales people succeed at selling.

Though a biased sales process is good for the seller, it’s usually not good for the buyer. A buyer doesn’t want to purchase a particular system because he’s somehow been influenced. Rather, he wants to buy a system because it’s the right fit – and fit is far more difficult to achieve than most companies realize.

Regardless of how standard a company thinks its requirements might be, it’s unlikely that an arbitrarily chosen system will be able to handle them. The point I’m driving at is that it’s very dangerous to make an assumption about fit based on a perception of one’s own requirements. Fit is like a puzzle – no matter how simple the piece may be, the puzzle can’t be completed without the right connector.

What a software buyer has to do, therefore, is first understand the shape of the company’s puzzle piece before looking for a solution. Once buyers understand their business requirements, they’ll have put themselves in a position to control the procurement process from both procedural and substantive perspectives.

Setting the purchase agenda

Software selection procedures are very important to a buyer’s decision-making process. They enable the buyer to control the flow and content of the information they’ll be required to evaluate.

Defining the procedures also allows the buyer to establish an authoritative – or psychological – advantage over the seller. In many ways, the buyers use procedures to send a message that they are in control of the purchase process because 1) they know their own requirements, and 2) they know how best to evaluate proposed solutions.

To establish effective procedures, it’s important for the buyer to elicit meaningful participation from vendors. Usually, this involves giving the vendors enough time to prepare useful responses. It also usually involves giving the vendors insight into the evaluation process. Our experience is that procedural transparency can yield better responses.

Benchmarking against actual business needs

Proper procedures are only part of an effective procurement process. It’s also important for buyers to define meaningful substantive requirements. The buyers use these to inform the vendors what a successful solution should be capable of accomplishing. They should also use these requirements as benchmarks to evaluate proposed solutions.

The requirements should be clear and unambiguous. Since ERP, for example, is intended to manage a company’s informational flows and transactions at the business process level, it’s important that the requirements be defined at that same level. (An example of a process-level requirement is that an ERP system be capable of tracking and valuing work-in-process throughout the manufacturing cycle.)

A final point worth discussing is the importance of user participation. No one knows their department’s business processes and requirements better than the users themselves. This puts them in the best position to help define the requirements and evaluate the systems against them. Involving the users also acts as an important change management tool. By giving users a sense of ownership over a portion of the project, they are more likely to buy into the system during and following implementation.

Considering oft-ignored, but critical substantive requirements

It’s important to highlight a few additional substantive areas that a software buyer should evaluate.

The first is implementation. In many respects, the assessment of software functionality represents the evaluation of the potential for benefit. However, it’s the implementation component that translates that potential benefit into an actual benefit.

When assessing implementation capabilities, it’s important for management to remember that people – not firms – implement systems. Thus, management should ensure that they are evaluating the proposed consultants, including their experiences and capabilities.

Finally, a company should take steps to do its due diligence from the perspective that software is intended to be a long-term investment (e.g., 10 years is the average for ERP software). Management will want to take steps to ensure that the software will be capable of meeting the company’s future needs. To that end, they should evaluate the vendor’s commitment to long-term product development and support. As a corollary, they should also assess the vendor’s viability, since the product’s future is tied to the vendor’s future.

To conclude, successful software selection partly depends on management’s ability to avoid falling into the potentially fatal sales bias trap. To do so, they need to assert control over the selection project by defining appropriate procedural and substantive requirements. This will help to ensure that their business needs drive their purchase decision, as opposed to a vendor’s sales agenda.

Jonathan Gross is vice-president of Pemeco, Inc., a consulting firm specializing in ERP selection and implementation. He can be reached at jonathang@pemeco.com.

This article originally appeared in the September 2011 issue of Manufacturing AUTOMATION.