Over the years, I have been both a Vendor and Purchaser of CRM systems. I have always maintained that choosing the right CRM system is not one of the critical success factors for an Organisation wishing to gain benefits from a CRM initiative. It is , however, the subject of many long hours and a lot of the program costs.
It is also highly emotive as many stakeholders will wish to have a say and influence the eventual procurement decision.
However, a lot of time and money can be saved by establishing some ground rules and a strategy up front. Without wishing to patronise Procurement Specialists, I argue that by considering a few simple tips, a decision can be reached more quickly, cost effectively and lead to better outcomes.
Therefore, this blog highlights a few suggestions aimed at helping Organisations wishing to buy or upgrade their existing systems. These tips are based on experience, not theory and is certainly not an exhaustive list. Neither is the list in any particular order of priority!
Tip #1. Do not buy “generic” requirements
Many Organisations put together a RFP (Request For Proposal) by compiling or acquiring an exhaustive list of generic features or functionality and then score vendor responses against “weighted” values such as Highly Desirable, Desirable and Very Highly Desirable, even Mandatory. The challenge of this approach is that business users are often lulled into stating system attributes or features that may bear little or no difference to their future “To Be” process. It becomes more of a “wish list”, rather like a child compiling a list for Santa having visited the Toy Shop. A better approach is to take the requirements to a higher level and then determine which group of functions is likely to be important for the future. Lists of generic “functionality” or requirements can be bought on the Internet. These lists are very thorough and detailed, often drilling down to a level where the relevance of each function may not be understood. Keep it simple and just use the groupings or categories to give vendors a good idea of what you are looking for. Another reason for doing this is to be fair to the vendors who could have overly high opportunity costs to fully respond to 2648 questions (as I saw recently) where the RFP had gone to 15 vendors. In that example, I decided that the effort to respond was not worth the small chance and we chose not to respond. The sad thing is that we might have had the best solution.
Tip #2. Apply weightings carefully
Getting the weightings right to score the responses and presentations is critical.
Start at the highest level: What weightings should be applied to different aspects of the Procurement? Price, Functional Fit, Non Functional Requirements etc? Often the Business users will wish for a higher percentage on Functionality, I.T will push for Non Functional with Finance and Procurement keen on Price or Value For Money. I cannot say how you should do it but I will stress that the overall weightings will greatly affect the decision you eventually reach. The weightings are then cascaded down through to the requirements and open questions. My suggestion is to keep in mind that what the system does is not the main success factor. Compromises may have to be made in order to get, for example, broader integration versus deeper functionality. The irony is that the impact of the weighting decisions (often made before issuing the RFP) is not really understood until you start the short listing process. That is the time when earlier weighting decisions may be regretted. Spend a little longer to get this right and the quality of the final decision may be much better.
Tip #3. It’s not the software, it’s the process
We have all heard of examples where the “software was poor” yet subsequently changed (at great expense) for something just as bad. The irony is that the same “poor”software is being used elsewhere and delivering value. Every software vendor has customer reference sites and customer horror stories. The difference is therefore not the software. It is the people and the processes. I cannot stress enough but to become truly customer centric, you must regard CRM as a transformational journey and ensure that people are willing and able to change to adapt to the new world enabled by the software change. Similarly, the software must enable great processes that deliver internal and external benefits. We have all experienced ringing a Call Centre to be routed around the organisation before finally reaching the right person. It may be great technology employed but you cannot hide a bad process. Implementing cRM with poor processes is like putting lipstick on a pig.
Therefore when buying CRM software, make sure the business representatives are change agents who are not bound by what they have always done. Similarly, stretch the vendors by testing their industry understanding to propose new processes and practices, rather than just reimplement what you do today.
Tip #4. The Integrator and the Integration
So you are buying new software. Who will implement it?
The Vendor? A Systems Integrator? A Shared Service provider? Maybe your own I.T department?
The answer to this question should drive part of the assessment. What skills are required to administer the system? How will Knowledge Transfer be managed and assured? What training is available, where and how often? Again, there is not a prescribed answer to this but the overall strategy is hugely influenced by the direction your Organisation chooses to take. The implementation is (in my opinion) more important than the software being deployed. Make sure the implementation is considered aspart of the decision with at least the same importance as the choice of software.
Tip #5. The role of I.T and alignment to architectural direction
Your IT department should be the facilitators to the process by providing an Organisational strategy and Architectural direction to which the solution should comply and conform. Decisions such as Cloud, Integration, Database and other Enterprise considerations should be informed by I.T and help the procurement. This direction should be reflected in both the weightings and evaluation team composition. However, be wary of the situation where IT chooses a solution on behalf of business users. In CRM, the importance of adoption and acceptance by the end users is probably more acute than in many other types of software selection. The trade off between IT and the Business is often as necessary as it is emotive but without trade off, time and costs escalate and the “losing party” often starts to undermine the chances of future success.
Tip#6. Composition of Evaluation team
The size of the Evaluation team will vary by Organisation but I tend to find that the larger the Organisation, the more likely it is to have an unnecessarily large evaluation team. It goes without saying that the larger the team, the higher the cost and the slower the process. Does it lead to better decision making? I don’t think so because the internal politics are then brought into the Evaluation team. Surely it is more important to create a lean and empowered team who can represent the interests of multiple departments without feeling the need to follow a particular political directive? This may sound like a Utopian state but it should be the objective of the overall Owner to create the optimal team to represent the best interests of the Organisation (not department). One other consideration is to empower a panel representative of differing levels of seniority. It is often a mistake for Managers to buy a system for their staff to use and vice versa. Ensure staff from the most junior to the most senior are represented on the assessment panel and decision making.
Tip#7. The value of the business scenario
If you want to really test (and differentiate) your shortlisted vendors, develop some typical business scenario’s that require a product demonstration requiring flexibility and creativity. Do not ask for what you do today. Imagine a future state and a desirable outcome. For example, imagine you are a traditional retailer. Create a scenario asking the vendor to demonstrate how their solution could utilize new channels and media to identify and acquire new customers whilst measuring the impact and effectiveness of each channel? That scenario is not prescriptive or specific. It allows the vendor to demonstrate potential value of their solution whilst offering you a glimpse into their understanding of your business and industry. A good vendor will have researched your needs, your weaknesses and gained a good idea into the potential opportunities their software might provide you. Give them a scenario whereby this can be demonstrated. In saying that the scenarios should not be too prescriptive, it must obviously cover your requirements as highlighted by the categories described in Tip#1.
Tip#8. Mandatory or not
If you make a requirement “Mandatory”, it has the potential to eliminate solutions that may have been a strong fit otherwise. Therefore think very carefully about what should be mandatory and use it as an initial screening process. For example, imagine you are an international business and believe that your solution must be multilingual. If you make “Multilingual” a Mandatory requirement, you will eliminate a large number of solutions that may currently only have one or two languages. Is that requirement truly a “Showstopper” or is it just simply very highly desirable? By making it a “Very Highly Desirable” requirement, you can assess these solutions without them being rejected as non compliant. Usually, the first pass of assessments eliminates vendors who are non compliant. Therefore only make requirements that you simply cannot operate without the only ones that are mandatory. This tip may not sit well with many but, in my experience, it is easier to seek compromises than it is to live with the implications of the wrong choice.
Tip#9. The after sale strategy
One of the often hidden and unforeseen aspects of procurement surrounds the strategy once the solution has been deployed.
Who will provide Support? Is it required 24/7? What is the Upgrade strategy and frequency? What is the future product roadmap and vision?
Often Evaluation Teams can be caught up in what the solution can do today rather than thinking about the future state. One can never predict the future but mitigation should be considered for different scenarios and be managed within the procurement process. As a former General Manager responsible for the CRM Product of a Software vendor, I was often asked to make commitments to future development but was rarely asked to commit to this new functionality contractually. Why not? I would have been happy to had I been asked but without the contractual need, the client has no assurance of that future capability which increases their future risk and exposure. Even if software companies cannot commit to future development, this could be used as a bargaining chip in negotiating price. There is a big difference between intention and committment, especially to Software providers!
Tip#10. Benefit realisation
How will you measure whether you made the right choice? It will be whether your business case was justified. Therefore a win/win scenario whereby your vendor helps develop and is incentivized to help you realise genuine benefits (and thereby justify your business case) is compelling. These benefits must be quantifiable and the inter dependencies (people, process etc) understood and managed. However, wouldn’t it be nice to select a vendor that is motivated to help you realise benefits rather than simply deploying software for a set price?
This may again sound utopian but it is the way things are moving in our customer centric universe and is worthy of consideration.
Of course, these tips are only suggestions and you may get great outcomes even if you ignore them. However, I do believe that these can only add value to you and hope that they do help in some small way. Good luck!