Buying and Implementing CRM Software – CRM Requirements Gathering

Image courtesy of Ivan Walsh

This post is part of the serialisation of the ‘An Industry Insider’s survival guide to everything you should know about buying and implementing CRM software’ e-guide, and covers how to gather and document your requirements for a CRM system:

Why’s it so important?

Getting requirements defined correctly is probably the single biggest determinant of CRM success, for the following reasons: 

It helps ensure the project receives the funding, resources, and management attention required to succeed because there is clarity about how the system will benefit the organisation. A lot of CRM projects fail to be adequately resourced because no sufficiently compelling outcomes and means of achieving them are defined.

It reduces the risk of purchasing an inappropriate technology because the detailed functional requirements are understood before the technology is selected rather than after.

It allows organisations to reduce costs, because vendors can provide firm quotations in a competitive environment against your detailed specification. In contrast, where requirements are poorly defined, the best a vendor can provide is an estimate to be confirmed at a later point. The ‘later point’ is a poor position to negotiate from, because by that stage you are generally heavily committed to the supplier.

It speeds up delivery of the project, because a detailed specification means that the implementation phase is quicker.

It improves cash flow, because the requirements gathering phase – one of the most time-consuming parts of the project – is completed before you start spending money on software.

It reduces the risk of cost and time overruns, because there is less likelihood of new requirements appearing as the implementation progresses (often referred to as scope-creep), and because there is less likelihood of your selected vendor ‘discovering’ more complexity as they understand your needs better. 

It gives you more flexibility in managing the project, because it’s easier to reprioritise work should the need arise.

It accelerates adoption, because users better understand why they are being asked to use the system. Users tend to adopt technology considerably better if they can identify desirable outcomes if the system is a success. 

It increases the return on investment because there is a clearly defined business objective and means of achieving it.  

If you can get the requirements gathering stage right, then this makes everything else that follows considerably easier. Unfortunately, people tend to struggle with this phase, and this generates a lot of unnecessary issues downstream.

The mystery of the missing process

One of the most common issues with the requirements documents I get to see on my travels is that most are just bullet-point lists of required functionality. There isn’t any mention of the processes that the technology will support. This is a potential problem for a number of reasons:

• It makes it very difficult for prospective suppliers to accurately assess the cost of customising the system because there’s insufficient detail for them to do so
• It can cause lengthy delays during the implementation stage while processes are finalised
• If the processes aren’t finalised, then effective user adoption will be impacted because there’s no common understanding of how the system is to be used.
• It increases the risk of selecting a technology that’s inappropriate to the purchasers needs because the detailed needs aren’t fully understood.

It’s also something of a tell-tail sign that the prospective purchaser hasn’t fully understood that CRM technology is a tool and will not generate any value unless it’s used to achieve well defined objectives.

The starting point is to begin with the desired outcomes for the project and then work backwards to identify the processes required to achieve those objectives. For example, if the goal was to increase the frequency and quality of communications to prospects and customers, then it would be appropriate to consider processes such as initial data capture, marketing campaign tracking and management, data segmentation, maintaining and improving data quality, managing opt outs and ‘gone aways’, lead and enquiry tracking, response and return on investment tracking, reporting, and the synchronising of data changes with other systems.

As you look at each of these processes in detail, and work out how you would want them to be supported, you will get a much clearer understanding of what fields you will need to track in the system, the associated functional needs, as well as the initial data migration and ongoing integration requirements.

In essence, a process oriented approach to requirements definition will help you flush out the detailed functional needs, which in turn will allow you to get a firmer fix on costs, better identify suitable technologies, as well as provide a route map to reach your end destination with less risk of expensive detours.

Documenting your requirements

In terms of structuring your requirements document, I’ve found the following approach seems to work well: 

An overview of the current situation, the problems you are looking to solve, and a statement of the desired outcomes. This should be as specific as possible.

A detailed definition of the business processes necessary to achieve the objectives, and how these will be supported in the system. I tend to break these into two parts: a narrative describing each process, and a flow-chart representation which includes a commentary as to who is updating what in order to facilitate the process.

The supporting functional requirements. I tend to start with a detailed description of each entity (for example people, organisation, lead, opportunity, and case records) within the system. This will include a detailed breakdown of what fields will appear on each entity and any related functionality. It’s also worth adding mock up screen shots which can be quickly created using something like Microsoft Visio, as this visual depiction allows people to more easily review the document. Any remaining functional requirements that don’t relate directly to an entity, such as the often overlooked areas of reporting, administration, and security, should be listed under separate headings 

The details of all data integrations to, and migrations from, other systems. There’s a tendency, in the CRM requirements specifications I see, towards broad-bush statements such as ‘the system will integrate into system x’ with little information about what ‘system x’ is or what information is to be integrated, in which direction, or in what form (for example in real-time, overnight batch loads, or as a data view). It’s virtually impossible for a prospective vendor to gauge the complexity and cost of integration unless you can provide the supporting detail.

The resulting output should be a substantial and comprehensive document that will facilitate effective technology and vendor selection, and drive the implementation process forward in a controlled way.