Choosing a CRM is easier than choosing a TV…..

or maybe it should follow just the same set of thought processes. It certainly should not be overly onerous. This blog suggests why….

Advertisements

I blame it on “Game Of Thrones”. If it wasn’t for the fervour created in our household by the imminent arrival of the latest instalment of the annoyingly addictive GoT, I may not have found myself in the HiFi store in the first place. I mean, we do have a “spare” TV and it’s not as if we watch a lot of TV. But she who must be obeyed (my wife, not the Mother of Dragons) insisted on us having to replace the TV in time for Jon Snows latest escapades.

So there I was in JB Hifi surrounded by wall upon wall of TV’s showing the same identical Disney movie, hearing the same soundtrack in a barrage of echoes, thinking this “should” be easy. I mean, we just need a TV. I have helped procure and, turning gamekeeper into poacher, sell complex enterprise CRM systems. These systems can cost thousands, if not millions of dollars in terms of software, services and support. It can take months to go through an evaluation and procurement exercise so surely buying a TV cannot be that hard, can it?

However, very soon I was being pummelled by an enthusiastic young “Audio Specialist” asking seemingly stupid questions such as “What do you use your TV for?”. I felt like saying “doing the washing up” but before I had chance, he bombarded me with a plethora of use cases “downloading films, watching YouTube, gaming etc”. Whilst I was scratching my head thinking, he was telling me about features such as HD, UHD, SUHD in fact any other acronym with HD would have seen me thinking he being sarcastic. There is 3D, Curved, Super size (more like a cinema screen), 4Hz and the mesmerising list goes on. The result was that I got to thinking about how people choose a CRM and that perhaps it can get over complicated in a similar way.

First and foremost, there is a budget for everything. I did not want to spend $7000 on a TV so the one that made an IMAX theatre look conservative was never going to be an option.

Secondly, there was my needs. What did I need it for? All CRM’s do the basics but the nuances come in whether you are looking for a Sales, Service or Marketing oriented system. Of course, you will need a decent set of functional and technical (non functional) requirements but to me it is pointless saying that a CRM must be able to add an email address to a Contact. That’s like asking whether a TV has an on/off button.

Then there was the “look” to consider. Believe it or not, the TV’s were not all identical! Similarly, the look and feel of a CRM must be intuitive and user friendly. This “User Experience” has become an increasingly important factor in choosing CRM software due to the lowering of training costs and the need for users to adopt the system, which is far more likely if they find it easy to use.

Once I had gone through this thought process, I had quickly narrowed down my choice to two TV’s. Now to seal the deal, I needed to differentiate based on things like Warranty, Installation and Availability. These will also come into play when selecting a CRM Implementation partner, although availability in IT terms means something different than “is it in stock”. Focus on a partner with proven expertise in the selected technology. You would not take a Mercedes to a Ford garage would you?

So when I got to thinking about it, I wondered whether sometimes people over complicate the buying process. Organisations can “try before they buy” with “Proof Of Concept” and Pilot implementations commonplace. In today’s Agile world, projects often commence on the basis that the end destination is not clearly defined, reserving the right to change direction and innovate as the project evolves.

Choosing a CRM should be pretty simple. Be clear about what your desired outcomes and user expectations are, what your budget is (don’t forget, its all about the TCO- Total Cost of Ownership) whilst considering the broader picture (refer to my previous article suggesting that the choice of CRM is not the single biggest success factor).

Although I have always been technology agnostic, I have recently become very excited by the development of Microsofts Dynamics CRM. It has evolved immeasurably over the last few years and the latest release, Dynamics365 is very good indeed. It will not be for every organisation just as my choice of a TV will not be the brand that you may have chosen. However, I do believe that Dynamics should be on most organisations shortlist not just because of the breadth of capability but simply because it just works with all of the other Microsoft software seamlessly. It is that ease of use that makes it a formidable solution and why, these days, I now work for an organisation that specialises in Dynamics365.

Buying a CRM system? Top 10 tips

Buying a CRM system? These tpis from an Independant CRM Specialist can give you food for thought before you start the procurement process. As a Vendor and Purchaser of CRM, Nick provides some tips based on years of experience to help mitigate risk, reduce cost and make a quality decision.

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!