Top Ten Secrets to a Successful CRM Deployment: Part Two–Process

Microsoft and Google have done it! Live Writer again talks to Blogger so my migration to WordPress gets a stay of execution. Well done giants of industry, we appreciate your efforts.

This is part two of three ‘top ten’ lists of things which can make or break a CRM deployment. In the first part I talked about people. This time it is about the process.

1. CRM is More Than Sales

In the beginning there was Sales Force Automation but CRM has come a long way since then. CRM now has Service AND Marketing but it is more than that as well. In fact, plenty of CRM systems have nothing to do with any of these. CRM systems manage business processes and are especially good when those processes involve interacting with external parties. I have seen CRM systems which manage employee of the month nominations, floor safety audits, and online auctions.

When implementing a CRM system, think of it as a system to manage processes, well defined or otherwise. Thinking in terms of sales, marketing or service may hinder, rather than help the design and never discount bringing a process into CRM because it does not fall neatly into one of the ‘standard CRM modules’.

2. Process Re-engineering is Inevitable

Dynamics CRM is very flexible, and there are often at least three ways to achieve an outcome, but every piece of packaged software has design limitations or assumptions built in. A classic assumption with most CRM systems (Dynamics CRM included) is a person only works for one company. In the case of the medical industry, this is a very poor assumption with doctors often splitting their time between working at a hospital, running their own practice and perhaps working in a research institute.

Of course these limitations can be worked around, as I have written about in the past, but this may lead to a process which is unfamiliar to the end user or, perhaps, requires a click or two extra than anticipated. Similarly, if CRM is replacing an existing system, processes may be in place which are not ideal but are simply “how things are done”.

CRM implementations are an excellent opportunity to review how things are done and how they can be improved and often the system and the humans meet somewhere in the middle, both adapting to the other.

One recent presales meeting I was in, I explained this very idea that a CRM implementation is an opportunity to assess the business’ processes in light of the technology being brought in. The client immediately saw the possibilities of revitalising the business through the technology catalyst.

3. NEVER Replicate an Old Process in a New System

Similar to the previous example, the idea that you can take an old system and simply imprint it onto CRM is a recipe for disaster. One project I remember in particular moved from CRM partner to CRM partner in Australia, each time ending in a lot of money spent and little to show for it. The problem was the client, a very large sporting association, wanted their old membership system replicated perfectly in CRM. This was a system which had evolved literally over a hundred years with hundreds of business rules hard coded into the back end of it.

Some of these rules related to war time or long-forgotten Sunday trading laws; some rules related to membership levels no longer used in the club or held by any member. Regardless, the client had no interest in reviewing the list, had no interest in reviewing its processes, and wanted CRM to look exactly like the old system.

This approach always fails because it discards all the benefits of a packaged platform system like Dynamics CRM

Dynamics CRM has forms look a certain way and has the layout of the controls work a certain way. This makes it easy to set up and work with. If you want everything to behave in a very specific way, build the system from the ground up. CRM has the advantage of pre-configuring commonly required components such as Outlook integration, role-based security and activity management. If you are not going to take advantage of these or wish them to be completely rebuilt, CRM is not for you.

The other aspect of this is in refusing to review your existing processes, in light of the new system, you run the risk of making a bad process run more efficiently. If you annoyed your customers before through a bad experience, imagine how successful you will be when you do it faster and with the capacity to do it to more people.

4. Bad Data = Bad System

Data cleansing is never easy or pleasant and it is very tempting to ignore the problem. To do the job properly requires a dedicated team of data ninjas working full time for weeks or months. For a CRM system, the best options are either bite the bullet and sort the data out or throw away the majority of it and just bring in the data you know are good. The worst thing you can ever do is bring your bad data into CRM with a view of sorting it out later.

I am ashamed to admit I once did this for a client. As well as the Account and Contact information from the users which, for the most part, was clean, they also had the legacy accounting data, also with Accounts and Contacts. We brought it all into CRM and soon discovered our mistake. The accounting data was a double-up of the user data and also brought in a bunch of old, irrelevant records. There was no clear source of truth and we were heading for disaster. Fortunately we saw the error of our ways and deactivated all of the accounting records before go-live.

While CRM has lots of excellent tools for data management, from a user adoption perspective you have lost the war before the battle has begun if you start with bad data. With multiple data sources, there is never a clear source of truth; no one knows where the correct version of a contact record resides. If you bring all your data sources into CRM without cleansing, all you do is centralise the bad data so there are now three versions of the same record in the one system, all of which are potentially incorrect. Users will learn to mistrust the system and will likely revert to their old systems and processes.

5. Big Bang = Big Failure

I am not a fan of fixed priced projects. One of the reasons for this is because it encourages the client to try and get as much as they can as quickly as possible and, in really bad cases, the project becomes more about scope juggling than about what the business actually needs.

In the worst of cases, the client demands a big bang approach. All areas of the business are going to switch to the system all at once and every possible item on the wish list will be implemented. Cost-benefit considerations are thrown out the window, as are product roadmaps. Everything will be built, even if it takes 18 months and 6-7 figure budgets.

The biggest problem with the big bang approach is most of what is built is obsolete by the time it is finished or was never needed in the first place. Where this is commonly seen is in reporting. With the prospect of a new, centralised system, management start brainstorming every possible report they can extract out of the system. They specify the precise format and, inevitably, the only way the reports can be built to meet the specification is with SQL Server Reporting Services (SSRS). SSRS reports are technical and expensive but are very powerful and flexible. In some cases I have seen literally 100 reports specified even before the first field has been added to a form.

No one sees a bloated system which does everything the business needed a year ago and nothing the business needs today as a success. Budgets are gone and the system is locked in, doomed to become a white elephant. In the case of reporting, the client often discovers they can get the information they need with Excel and Advanced Find with no need for expensive report writers.

6. Keep Things Simple

My position is to implement a good platform that does at least as much as the existing system and removes the severe pain points. Also, I try to keep coding to a minimum. It is very tempting for a junior consultant, especially one with a development background, to say yes to everything the client asks for, knowing it can be built with code. However, while the client may ask for something, if the cost outweighs the benefit, it will never been seen as a success.

While a client may not like that they have to do two clicks instead of one to perform an action and a button on the ribbon could solve this, if the time saving is not there compared to the development cost, “fixing” it should be resisted. I have a friend, also a CRM Architect/Consultant who likes pushing the boundaries. This is not necessarily a bad thing but he will often give the client one thing they want which they may not need because it is something unusual and exciting. Often, to deliver it, requires a bit of unsupported work and a fair amount of expense. Unfortunately, while the intent is good, when things go awry it is that part of the project which the client focuses on and not the rest of the system.

7. Plan For Phase 2, 3, 4…

The better approach to big bang is to phase the implementation. Phasing the implementation means intelligent decisions are made in light of where the product is heading and where the business is heading. Decisions on where limited budgets can make the most impact means CRM is shown in its best light. The phased approach also means the opportunity to work with the client over a longer period of time and to be a key part of their success. I have customers who I have literally worked with for years, solving different problems as priorities dictate and budgets allow. Phasing the project, in my opinion, gives the best possible chance for success.

8. Show the System Early and Often

I mentioned in Part One that using a demo version of the system in the workshop is a good idea. My position is show it off as much as you can. Even in the presales, while a meeting may be a meet and greet, there are times when a prospect I am meeting, tired of PowerPoint and promises, has insisted on seeing something there and then. Always have a demo system ready to go even if you do not intend to use it (it has literally won deals for me in the past). I believe in the product I sell and know that the more the client sees it, the more comfortable they become with it. Often, in the early meetings, their biggest objections get raised so having a system ready to tackle the issue head-on can be very powerful in influencing the decision.

While it is good to give the prospect as much exposure to the product as possible, leaving them alone with a 30 day trial is not. Without training, it is very easy for the prospect to become overwhelmed and feel the system is too complex.

9. Choose the Right Software For You

Despite what you may read on dynamics.com, while Dynamics CRM is a great product, it is not right for everyone. One of the worst reasons I have seen for organisations to select a software package is because someone used it once and liked it. It is a good reason to consider it but no piece of enterprise software lives in a vacuum so it is essential that your CRM plays nicely with the rest of your local ecosystem. Thankfully, most of the projects I have worked on have obeyed this rule; Microsoft shops go with Dynamics CRM and Apple/Google shops go with Salesforce.

A client whose On-Premise CRM system I implemented a couple of years ago is now looking to improve the reporting capabilities of the system by leveraging the power of SQL Server and setting up a data warehouse. I recall at the time of implementation there were stakeholders, familiar with Salesforce, who felt Dynamics CRM was a poor choice for the business. Time has proven Dynamics CRM has done its job and now, as it expands in the business, it can efficiently make use of the business’ Microsoft stack.

10. Build it for the Future

Funnily enough I am in this situation now where I must choose to sacrifice work today to set up the client for the future. I have a client who is implementing CRM and has needs which I know will be addressed directly in the next six to twelve months. The lesser consultant would take the client’s money and build what they know will be obsolete in the near future but this is a poor approach.

The better approach is share what you know (without violating Microsoft NDAs of course) and allow the client to make a reasoned judgement. If the requirement is urgent and waiting will cost the business too much then so be it but, usually, the client can wait and, as a consultant, you gain the trust of your client. Short term consulting dollars at the expense of the client relationship is never worth it.

Conclusions

Just as managing the people in the project is vital for success, so is managing both the implementation process and the business processes which will be impacted by the project. For the implementation, guiding the client appropriately for the long term is vital. For their processes, embrace that change will come and help them manage it.