Overcoming the Feared ERP and CRM Implementation “Analysis Paralysis”

Let’s get one thing clear: implementing an ERP (Enterprises Resource Planning) or CRM (Customer Relationship Management) system is a big undertaking for any organization – big or small.

Just reaching consensus internally on what your current struggles and wish list items are – and whether your challenges can even be overcome by a software solution at all – can be a process that leads to more questions than answers.

Then factor in the cost, time commitments required of stakeholders, the potential disruption to your staff, customers and partners, and the idea of embarking on such a project can be overwhelming.

Given this backdrop – it is easy to understand why companies can spin their wheels gathering user requirements, validating them against industry best practices, researching available packages, and getting expert opinion and product demos from vendors.

Then, the process can be put on hold when the economy sputters or when some external factor changes that leads them to doubt any of this research.

Through the years, having been associated with “projects” such as (in quotes – because projects by definition should have a start and end date; which these often don’t), I’ve seen well-meaning ERP / CRM evaluations fizzle and die, simply because of an organizational fear of the immensity of the task. When hesitant to make a final decision the decision becomes one of non-decision.

This series – entitled “Overcoming ERP and CRM Analysis Paralysis”, offers some guidance through the perils and pitfalls of the ERP / CRM evaluation process, and some helpful insights on how to approach your search from a place of confident conviction. 

Ultimately, you’ll have confidence to know you are doing the right diligence and asking the right questions, and the conviction to see the process through to a successful conclusion.

  

First – Beware of the Law of Diminishing Returns

Definition: “as more investment is made, overall return on that investment continues at a declining rate.”

This law can be applied to so many areas of personal, financial and professional life. More and more deliberating does not necessarily mean your decision gets easier or more qualified. 

ERP / CRM evaluation projects are often no different. I’ve seen organizations experience this law first-hand when attempting to involve an ever-widening group of stakeholders, over a longer period of time. 

• Often, the impact of a widening group of stakeholders and individual involvement not only is diffused, but can even have a reversal effect on your evaluation progress
• Further, the more detailed and specific your ERP and CRM requirements become (which they do when more opinions are offered), the fewer viable options you will be left with to meet those requirements 
• Worse, you may ‘unintentionally’ eliminate some excellent ERP and CRM packages from consideration, simply because they did not seem to address a few minor items on your wish list

To illustrate this point, the following is an example of a cycle I’ve seen and the ease in which it can sabotage your evaluation process.

ABC Inc. forms an ERP / CRM evaluation committee that is comprised of the Director of IT, the Controller, a couple of experienced mid-level managers, a regular user, and a business analyst. Through their own experiences and from feedback received from their own subordinates and colleagues, they bring to the table many well-reasoned ideas for what the new system needs to provide.

 

As a group, they debate, revise, and compile this list into a User Requirements Document that summarizes these items well. They’ve also taken the time to think through their long-term business objectives for growth and ensured the document represents today’s needs, as well as predicted needs for the future.

 

The evaluation committee then does their industry research, and finally invites vendors of a short-list of software solutions to demonstrate how well their respective solutions meet the needs they’ve articulated. 

The demonstrations happen, and three of the solutions emerge as favourites – meeting approximately 90% of their requirements “out-of-the-box”. With some effort, they are told, most of the remaining requirements should be able to be satisfied, since the platforms are very customizable.

 

Apprehensive about this 10%, the evaluation committee decides to involve a couple people from their accounting team, a payroll clerk, and an IT person that “knows a lot about these things”. 

Each one of these new contributors brings with them valuable insights, but also a bucket list of their suggestions, pains, and preconceptions for what the new system should do. The IT person also brings a personal bias against one of the ERP or CRM products, on some technical basis that nobody else on the committee understands.

 

Eleven new items are added to the User Requirements Document. The evaluation committee returns to the vendor with these new requirements, asking how they’d address the new “needs”. 

This eliminates one of the products from consideration, and for the remaining two vendors there are a couple that may require some further investigation and likely, they are told, some customization.

 

Hesitant to make a final selection when they still have unresolved requirements, ABC Inc. enlists the advice of an independent consulting company. This company, eager to prove their worth as subject matter experts, offer additional criteria that ABC Inc. hadn’t thought to consider in their evaluations.

 

This back and forth process between internal consultation and vendor validation of the requirements repeats itself a couple more times with consistently the same result (most needs will be met, a few won’t). 

Now six months in, and becoming less confident that a ‘perfect product’ exists that will meet their unique needs, they begin to explore whether having a system custom-built would be the right approach. 

They soon realize that, rather than living with the 10% of desired functionality the packaged solution was lacking, with the custom-built approach they will have to start at the beginning and validate the other 90%.

  

You can see from this little analogy how the details can result in having a bigger hole they they started with. The evaluation committee not only had misguided expectations that a 100% solution existed, but also ended up wasting much time in analysis of their requirements.

Once they widened the circle of involvement to those that hadn’t been through the initial exercise of developing a clear requirements list – the process started to lose control. 

At the risk of sounding self-serving as a partner who sells ERP & CRM solutions and works through these sales cycles with customers, it is still important to point out the following to note when developing requirements:

• Commit to one of the three solutions that captures the vast majority of your requirements; think more strategically not as much tactically at this point
• Ensure that the solution can be customized to meet the other needs and has the appropriate technology foundations
• Use the substantial outlay of time and resources that might be used in continued deliberation to be directed to making the desired customizations