7 Steps to CRM success for social purpose organisations

Introduction

Data is everywhere these days. We keep hearing that humanity has created more data in the past few years than in all of history. Suffice to say, there is an unimaginably large amount of data in existence. It’s growing every day and its growth is accelerating.

From this vast mountain of data, not for profit organisations are interested in the slice that relates to Constituents, Partners, Funders, Donors, Volunteers and other Stakeholders.

CRM systems grew out of the need to manage this data, track the relationships between them and log interaction activity. Then give users an easy way to produce reports and dashboards to help them see the wood for the trees and make better decisions.

Every business has a CRM, however basic. It could be a list of Contacts in Outlook, an Excel spreadsheet, an Access database, one of the first generation systems that is beginning to show its age or a bang up to date Cloud based solution. But every business has a CRM. The question is, how do you ensure your CRM is a success?

What is Success and what is Failure?

Type “CRM Failure Statistics” into Google and within a couple of clicks, you will find statistics telling you that the vast majority of CRM implementations fail. The percentage goes as high as 70%.

I don’t think these statistics are helpful. For a start, what does success or failure even mean in the context of a CRM? When were these statistics gathered? The day the CRM was switched on — a month later — a year later? Return on Investment is often cited as the ultimate way of determining whether a CRM implementation has succeeded. I think this is very one dimensional and akin to judging the health of a company based on turnover alone. Measuring success against other performance indicators such as revenue generation, customer satisfaction, cost efficiencies and time savings is equally flimsy.

I would like to propose a different way to define and measure CRM success. Bearing in mind that a CRM is simply a tool that is provided for users to facilitate their day to day activity, my definition of success revolves around them — the users. I define success as follows:

“Success equals users willingly logging into the CRM on a regular basis and using it to accomplish their work”.

Referred to as User Adoption, it is measured by monitoring how often users log into the system, seeing how often they create and edit records and simply asking them if they are happy with the CRM.

It’s that simple. This article examines 7 key elements that play an important role in the successful implementation of a CRM system that will support your users in their day to day work.

Step 1 —  Managing Expectations

Setting user’s expectations from the outset is critical to success. Lots of projects run into difficulty because this simply doesn’t happen. Managing expectations is about being clear where the boundaries are. What the system will do. And what it won’t.

Expectations management is not just about “what” features will be available. Communicating “when” they will be available is just as important.

Asking your users what functionality they expect in the new system can often reveal disconnects between the design team and the user community. This often highlights an optimistic user expectation that the new system will take care of every manual task you can think of — “automatically”.

If you are moving users from a well-established system to a brand new CRM, this is especially crucial since they will expect the new system to replicate the functionality of the old one as well as adding additional features.

If you don’t proactively manage user expectations, you risk the dreaded scope-creep which is deadly to project success.

Step 2 —  Management Support

I’m not going to say a lot about this step. It should be blindingly obvious but often seems to fall by the wayside. If users are going to take the CRM seriously, senior management need to take an active role in promoting and where possible using the system.

Step 3 —  Involving End Users Early On

I have seen many projects run into difficulty during testing and go-live because end users don’t get their hands on the system until very late in the project process.

It’s a mistake to let a small project team exclusively define all the requirements and shape the system during design and build without consulting the wider user community. Of course you can’t include all the users in every workshop throughout the project.

But the more time you spend giving end users early visibility of the system, the better. Coming back to my definition of success, it revolves around the users of the system.

By involving end users early on, you will find that testing and training is much easier since they will already be familiar with the system and its functionality. And of course, tapping into the collective wisdom within your organisation may help you uncover a critical requirement that would otherwise be overlooked.

Step 4 —  Reports Come First

Perhaps not an intuitive place to begin, but thinking about reports should take place early on in the project during the requirements gathering phase. Defining reports is often left out or bolted onto the end of a requirements workshop which only captures cursory details.

After all, the power of a well-designed CRM lies in its ability to provide you with answers to specific questions at the click of a button.

Considering reports early on goes further than simply identifying the individual pieces of information you will store in the system.

Thinking about how to group, summarise and aggregate your information and how to highlight trends and exceptions should feed into the design process and influence how data is organised and inter-connected.

Looking at reports towards the end of the implementation may lead to the solution having to be redesigned and rebuilt which is both time consuming and expensive.

Step 5 —  Terminology

This step may not be obvious but it’s really important. Clarifying terminology can be critical to the success of a project.

If stakeholders, users and consulting partners are using the same words but thinking different things, it is clear that work will progress down the wrong path and the end result can be a solution that does not fulfil its intended function.

For example, what is a Case? For some organisations, this represents a discrete piece of support given to a client. For another organisation, it represents a complaint.  Quite a difference in meaning. And a significant difference in the solution required.

Taking the time to check meaning in the context of the project can make the difference between going down the right path or the wrong one.

Stay alert and listen out for situations where people are talking at cross purposes. Clarify key terminology at an early stage and keep this information up to date. Run through scenarios to check that everyone is using terminology in the same way.

Step 6 —  Small Steps

Breaking up projects into bite sized chunks (ie phases) is a tried and tested way to increase your chances of CRM success. And yet, I have seen lots of requirements gathering workshops used as a brain-storming exercise to dream up as many ideas as possible. These ideas get written down and become deliverables within the specification document.

The result is a comprehensive list of requirements that cannot realistically be achieved and the project can be compromised before it has even started.

Clearly, if you are only delivering a relatively small piece of functionality, you can’t go too far wrong. There are other benefits though.

Firstly, the initial chunk of work serves as an opportunity for the project team to get to know each other and gel. If you are using external resources, bonding as a team is doubly important.

Secondly, as the project progresses, priorities may evolve and new requirements may emerge. Small steps give you the chance to alter direction between phases.

Thirdly, users can start using the system sooner which gives them the opportunity to feedback ideas for further phases.

Step 7 —  Data

Last but certainly not least comes data. Ignore at your peril. Data is a constant bugbear and is a major factor in projects over-running and users finding the system hard to use. To make things worse, problems with data usually comes to light at the end of the project when the data supplied for loading into the new CRM proves to be incompatible.

There are so many reasons why this could be the case — that’s an article in its own right.

To give you a flavour of the “perils of poor data”, here are a few that I’ve seen recently.

  • Data is formatted incorrectly (does 01/03/2013 mean 1st March or 3rd of January?)
  • “+44 20 3397 4870 extn 2” is not a valid phone number
  • “joe@acme.com / sales@acme.com” is not a valid email address
  • joe@acme .com is also not a valid email address (notice the space between acme and .com)
  • Data that is mandatory in the new CRM is not present in the source data
  • Duplicate data
  • Foreign characters coming out garbled in the new CRM

The list goes on.

My advice is simple. Start looking at data on day 1. And however much time you have allowed for data, double it . . . then double it again.

Conclusion

If you want your project to succeed, just stick to these rules:

  • Manage your users’ expectations from the outset
  • Insist on management buy-in
  • Think about the information you want to get out of the system early on
  • Make sure everyone is talking the same language
  • Divide the project into manageable chunks
  • Start looking at your data from day 1
Article by Frazer Lewis : Date posted: 21st November 2016