I’ve written a lot over the years about the importance of requirements gathering when implementing CRM systems. For me, the CRM requirements specification is the foundation of a CRM project, and I don’t believe there’s any other element that has as much influence on ultimate success or failure.

What’s surprising however is that there’s so little readily available material out there to help would-be implementers of CRM go about requirements gathering.

Which is perhaps why so many specifications end up as bullet-point lists of functional requirements that do little to help would-be buyers select the right technology, or implement it in a way that makes a genuine difference to the performance of their organisations. And why this has been such a common topic in the blog.

But our own approach to requirements specification has evolved since I first started writing on the subject nearly ten years ago, so I began a series of update posts late last year, with the promise that when they were finished I would edit them into a free ebook to make them a little more consumable.

That free, no-sign up required, ebook can now be found here.

Content includes:

  • Common mistakes
  • The five key objectives of a specification
  • The three most dangerous requirements gathering myths – including why users won’t tell you what they need from a system
  • The content and structure of a specification
  • A step by step approach
  • Why effective requirements gathering is so fundamental to success
ShareThis
[Facebook] [Google] [LinkedIn] [Twitter] [Pinterest]

{ 0 comments }

The zombie CRM apocalypse and ways to avoid it

by Richard Boardman on April 6, 2015

In October last year I passed the ten year milestone as an independent CRM consultant, and at some point in 2015, all being well, I’ll pass the twenty year mark of working in the CRM industry.

I mention this because back in the early days tales of CRM project failures abounded. Perhaps this reflected the relative inflexibility of the technology at that time, or the inexperience of the implementers.

In more recent times there’s considerably less talk of ‘failure’, but that doesn’t mean all is well. It seems to me there’s a significant, but largely unarticulated issue of ‘zombie’ CRM.

Zombie systems, are those that while technically operative, contribute little or nothing to the organisations that implemented them. They may be used, but not in a sufficiently consistent or structured way as to add value.

Here are some of the common reasons that systems become zombified (and what to do about them):

Unclear objectives and supporting processes – CRM technology can be used in a lot of different ways to achieve a lot of different objectives. Too often these objectives and how the system will be used to achieve them aren’t clearly defined. As a result the system achieves very little.

Solution – take the time to identify up front what the business objectives are and define in detail how the supporting processes will work in the system

Friction with the implementation partner – friction between the CRM buyer and the implementation partner is surprisingly common. While this rarely results in a full breakdown during the implementation phase, it often manifests itself in a reluctance to engage with the implementer once the system goes live, which means the system doesn’t get vital the support it needs.

Solution – take your time and take great care in selecting implementation partners. Look for a company that you can work with for the long term

User adoption – no matter how good the system you develop, if the users don’t use it as was intended it won’t produce results.

Solution – place as much, if not more, emphasis and resourcing on the user adoption stage of a project as the pre-live stage. Too many organisations go live and use the opportunity to rest. Live is when the work really starts.

Lack of management support – too many senior managers distance themselves from the CRM system. They often don’t use, or perhaps really understand the system, and are the last to know they may have a zombie on their hands.

Solution – the management team need to be users of the system or at the very least the outputs from the system. They need to understand the central role that technology can play, and resource it accordingly.

Not managing for the long term – once a system is live and the user adoption is in place, there’s a raft of maintenance activities that need to implemented. Neglect these and a system can rapidly become obsolete.

Solution – pay careful attention to areas such as maintaining data quality, on-boarding new users, checking usage patterns, and adapting the system to meet changing needs. Ensure there’s ongoing investment in the system and people to support it.

The zombification of CRM systems might not be talked about much, but it’s a real and present danger. The five points highlighted above are just some of the potential causes, but they’re not the only ones. The key thing is that would-be implementers of CRM technology need to be aware that just because we’re no longer talking about CRM failure, doesn’t remove the need for caution. There are some things worse than failing, and zombies are rather more common-place than people realise.

ShareThis
[Facebook] [Google] [LinkedIn] [Twitter] [Pinterest]

{ 4 comments }

Getting people to use CRM software – two key foundations

March 15, 2015

It doesn’t matter how successful you may have been in selecting the right CRM technology for your organisation and customising it to fit your specific needs, if you can’t get people to use it in a consistent and structured way, then it’s not going to generate much value. Despite the progress that’s been made with [...]

Read the full article →

Specifying CRM functional requirements – twelve things that often get missed

March 3, 2015

In the ‘how to document CRM requirements’ series (part one, if you missed it, can be found here) I noted that there were a lot of areas that people tended to miss when setting out their functional requirements for a CRM system. So the following is a list of twelve items that commonly don’t get [...]

Read the full article →

Waterfall V Agile for CRM projects – why the choice of implementation approach matters

March 2, 2015

If you’re implementing a new CRM system and have been talking to potential vendors about how they would approach a project, I suspect the word ‘agile’ features strongly in their presentations. Go back a few short years though and you would have been hard-pressed to hear the word ‘agile’ being used in many conversations about [...]

Read the full article →

A guide to phasing a CRM project

January 11, 2015

In my recent series on requirements gathering, I noted the need to document the phasing of a CRM implementation. I’ve come to the conclusion over the years that phasing is one of the most critical aspects of implementing a CRM system successfully, and so figured this might merit some further elaboration. Perhaps the starting point [...]

Read the full article →

How to document requirements for a CRM system – part 6

January 4, 2015

In a previous post in this series I set out my thoughts on the content and structure of a CRM requirements specification. In this post I want to cover how to go about gathering them. The starting point, if you’re not reasonably familiar with CRM technology, is to do some initial research. It’s very difficult [...]

Read the full article →

How to document requirements for a CRM system – part 5

December 13, 2014

Last time out I described what I’d expect to see in a decent CRM requirements specification. Putting this sort of document together isn’t a trivial exercise, but the payback from the time invested can be huge. Here are some of the key benefits of this sort of approach: Increased return on investment – the focus [...]

Read the full article →

How to document requirements for a CRM system – part 4

November 30, 2014

In the fourth of this series of posts about CRM requirements gathering, I wanted to cover content. So what needs to be included in a CRM requirements document? The following covers the main areas I’d hope to see: Approach This section sets out how the requirements were gathered, and, importantly, who was involved in the [...]

Read the full article →

How to document requirements for a CRM system – part 3

November 23, 2014

I promised in last week’s post that this week I’d set out my views on what should be included in a CRM requirements specification. However, I’m going to put that on hold for a week. I realised there were some points that merit some articulation first. So, to help set the scene, here are a [...]

Read the full article →