Top Ten Secrets to a Successful CRM Deployment: Part One–People

I recently gave a talk for MS Dynamics World on “Secrets to a Successful CRM Deployment”. In the talk I gave 30 tips on maximising the chance of success for CRM projects, broken down into three categories (people, process and technology), making it a top ten list for each.

This month I will go through these three top ten lists and highlight some examples where I have seen CRM project flourish or come unstuck because of these factors. This article focuses on the people aspects of a CRM project.

1. Recognition of a Problem

In a 12-step program, the first step is recognising there is a problem. So too with CRM implementations. If the people whose destiny is to use the CRM system see no value in implementing it, they will protect what is familiar to them and frustrate the implementation of the new system.

Sometimes this resistance is a force of one and sometimes it is the entire user base. On one project I did a few years ago, the resistance was the brains behind the old system who refused to admit their system, cobbled together, piece by piece, over a decade, was no longer appropriate for the business. While a key stakeholder in the implementation of the new system, he slowed the process down significantly through constant challenging of the new system and trying to find reasons to stay with the old system. His challenges had to be addressed and absorbed significant time in workshops, meetings and emails.

While challenging a consultant’s design is healthy, the ultimate goal for everyone is solving the problems of the business. Pretending there are no problems to protect one’s ego or to maintain the status quo is a poor foundation for a successful project.

2. Definition of Success

A key part of a successful CRM implementation is recognising what success is. This needs to be defined early and documented for reference. I usually define it as part of the introduction to the project’s functional specification.

Without a clear, documented definition of success, by the time the CRM project is implemented (which can be months later), the issues which seemed insurmountable in the old system are a thing of the past and additional goals emerge which may not be as easily addressed. Clients then focus on the new goals and get frustrated when it proves difficult to address these within the scope of the existing project.

No one wins. The client feels cheated, the consultant feels unappreciated and the system risks not being adopted.

One project I worked on was introducing Dynamics CRM and a web portal to an organisation. The key driver for the project was stakeholder/activity management. This was very difficult with their incumbent BONA system. Dynamics CRM, with its Outlook integration was exactly what the customer needed. However, their web server setup was a nightmare and getting the portal to work was a slow process, delaying the project.

Success was not defined early and, after the system went live, it was the problems with the portal which was at the front of mind of the client, not the great leaps they had made at managing their customers.

3. Buy-In By the Executive

Change is modelled from the top so if the executive are not behind the initiative, even if there are advocates elsewhere in the business, the culture the executives preside over will prevail. Lip service is not enough. The senior project sponsors must demonstrate their support in strong, symbolic ways. Examples I have seen include promoting a naming competition for the new system or ordering bright t-shirts for the trial users to wear. It can even be as simple as attending and participating in the CRM design workshops. After all, their time is important so if they are willing to sacrifice half a day or a day in a workshop, the initiative must be important.

4. Use the Workshop to Generate Buy-In at the Coalface

Officially we do workshops to gather requirements and understand the needs of the business. If this is the case, why not do it via a questionnaire? Other than the fact that every question generates at least two others, design workshops are powerful tools in ensuring the success of an implementation.

Design workshops need to be done with a demo system at hand for full effect. This has multiple benefits. The people in the workshop, often the trial users, gain familiarity with the system. Also, if there are specific doubts about whether the system will be able to meet the needs of the business, these can be addressed directly with a live demonstration.

The workshop participants will see a system modified to suit their needs, and spread the word about the benefits it will bring when they speak to the curious co-workers outside of the workshop. So many times people who walk into a workshop on day one with cynicism and low expectations leave with excitement and optimism at the end of the week.

5. Involve the Dissenters

More often than not, a CRM implementation is a political landscape. We have touched on those blind through self-delusion in point number one but there are many reasons why there may be dissenters on a project:

• People who resent “high-paid” consultants doing a job they are perfectly capable of
• People who know Salesforce/Access/SharePoint is better and Dynamics CRM can offer no real value
• People who fear a loss of power and influence with the removal of old processes and systems

In all of these cases, bringing the dissenters closer into the project is the best approach. For those resenting the consultants, show them that a CRM implementation is more complex than just installing software; that there is a subtlety to designing the system that, if done correctly, requires an intimate knowledge of the product and experience gained through many projects before this one.

For those who see no value in Dynamics CRM, challenge them and work with them. Through the workshops they will see value they had not considered and realise the picture is often a lot bigger than they had anticipated.

For those fearing the loss of power with the change, give them the opportunity to become the new system expert. If people within the business look to them for ad hoc system support, it will be natural for these same people to turn to our would-be dissenter for support in the new CRM system. Let them become that strong advocate and guide.

6. Get a Partner/Consultant Involved

For an unscrupulous CRM consultant there is nothing better than hearing that a company is managing a CRM implementation internally without a CRM specialist. The reason is that in three to six months time that same company will be begging for help and to unwind the damage will cost at least twice the amount if the company had been guided correctly from the start.

Back in my “Upgrade vs Rebuild” blog from a few weeks ago, I spoke of a Dynamics CRM system stuck in version three. What I did not explicitly mention in that article was the system had been an internal implementation. The system was built with internal staff and then left for a decade until it fell apart. If a CRM consultant had been present, even if the initial design had remained the same, as new versions of CRM came out, the client could be encouraged to upgrade and evolve the system as functionality in Dynamics CRM improved. Adopting this approach would result in a system with potentially less unsupported code and better aligned to the contemporary needs of the business.

Without fail, and not because of self interest, no CRM consultant or partner will recommend a customer go through a CRM implementation alone. Even when I am introduced to CRM opportunities and determine the company I work for is a bad fit for the project because, for example, the client is too small to be effectively serviced by a medium-level consultancy, I ensure I introduce the client to someone who can assist them. No one ever thanks you for throwing them under the bus.

7. Make Sure You Have a Functional, Technical, and Implementation Consultant on the Project

While the skills may reside in one person, all three are necessary to ensure a good design for the system. Without a good functional CRM consultant, the project runs the risk of over-engineering. A good CRM developer can make Dynamics CRM do anything. The job of a functional CRM consultant is to make sure they do not need to. Many times a complex interplay of plugins, web pages and entities is proposed to solve a problem when a clever dialog or workflow gets close enough to meet the needs of the business for a fraction of the cost.

Without a good technical CRM consultant (developer) the system is ham-strung. With every new version of Dynamics CRM, there is more that can be achieved through configuration. For example, I am making good use of the new Service Management capabilities of Dynamics CRM on a current project which, a version or two ago, would have needed multiple plugins to achieve a similar outcome. However, there is always a necessary part of any CRM system which configuration cannot achieve. A good developer changes what would otherwise be a manually-intensive process into a button click. A creative developer who considers the cost-benefit of their work is worth their weight in gold.

Finally, there is the implementation consultant. For on-premise implementations, without a consultant with a deep server implementation spike, the project is heading for disaster. Client networks are never perfect so having someone on the project that can navigate Active Directory, set up claims based authentication and cluster servers is essential. For online implementations, the skills are different, focussing on things like Azure and Office 365 knowledge but the necessity for their presence is the same.

I have seen over-engineered projects which cost a fortune and been thrown away because of the developed complexity. I have seen projects with frustrating manual processes because the project did not have a good coder on board to recognise where they could provide delights to the business and, finally, I have seen projects trying to navigate broken authentication, aging, overworked servers and flaky network routers. With the right team, obstacles the size of mountains become gravel on the path.

8. Get the Executive to Tell You What is Important For Reporting

This point, and the next point, talk at the Ying-Yang relationship between the end users and their managers which I talked about four months ago. A key function of a CRM system is to inform the business to help them make improvements. In the project I am on now, we are implementing an enquiry management system built on Dynamics CRM Online and Parature. The manager of the customer service agents has very clear ideas on the kinds of things he wants to monitor.

This is great because, when a consultant knows that the outputs of the system are, he can work to ensure the correct inputs are in place to generate the required information. In this particular project, the manager is keen to know things like:

• Average length of time a Case remains in the queue before being picked up
• Average length of time per day for Case resolution
• Average time a Case remains with each team before being passed on or resolved

Knowing these key parameters means the right fields, charts and dashboards can be added. This will ensure the management get the information they need to guide the business.

9. Make Sure it is Practical for the Users

Setting up all the reports in the world will not help if there are no data going into the system. Therefore it is essential the system is practical for the users.

A project I did quite a number of years ago was my first at a new employer. Being keen to please and being a little less wise than I am today, I fell into a number of pitfalls. Firstly, there was no end users in the workshop. The general manager assured me he knew exactly what the end users needed and the workshop would be me and him. In fact, the general manager knew exactly the 200 fields he needed to generate the reports from his sales funnel and assumed the end users would have no issue filling in the virtual paperwork. He was wrong.

The system went in and only a small fraction of the fields were ever populated, much to the general manager’s frustration. The system was not well-liked because of the busy forms and languished for quite a while. Thankfully, the client eventually upgraded the system which provided an opportunity to revisit the design and, this time, end users were involved leading to a much better system.

10. Training is Essential

When presented with the CRM project Gantt chart and a large associated cost, a common focus for a client is to look for creative ways to cut the costs. The first place is often training, followed closely by the design workshops. While workshop questions can be tackled offline (see point four for why this may not always be a good idea), it is much harder to train effectively via email.

A sure-fire way to cripple user adoption is to not show the end users how to use the system effectively and efficiently. It is guaranteed that users will return to old systems or do the least possible in the new system as everything is just a little harder than it should be.

This is so common it is hard to think of a single example but, often in pre-sales meetings, if the client has an existing implementation of Dynamics CRM and they acknowledge that no one really uses it, the root cause is a lack of user training.

Conclusions

I am sure other people-related issues come to mind as you read my top ten, and feel free to add them to the comments, but what should be clear is that a CRM implementation is much more than a software implementation. The success of a CRM project is strongly dependent on the people involved, on both the client and consultant side and how they engage with each other. Regardless of how great Dynamics CRM is, without careful consideration of the people engaged in the project, a project has a strong risk of being another cautionary tale in someone’s blog.