A more successful approach to CRM requirements definition - the wrap up

In the last few posts I touched on why effective CRM requirements specification was important, and how to approach it. This week I want to wrap up this series by suggesting how this can be brought together in the final CRM requirements document.

Given that the structure of your document should be driven by its end purpose, it’s worth being clear about what it will be used for, which I believe comes down to the following:

• To facilitate agreement internally as to what you are trying to achieve and how you are planning to achieve it, ensuring a common understanding and that the initiative is adequately resourced.
  

• To define what functionality you will need to achieve your objectives to avoid choosing CRM software inappropriate to your needs.
  

• To allow vendors to provide accurate, rather than indicative pricing.
  

• To control and accelerate the implementation phase.

As such, I suggest a simple structure as follows:

Firstly, an analysis 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.

Secondly, a statement 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 statement as to who is updating what within the system in order to facilitate the process.

And finally, 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.

All integrations into other systems will be fully set out. 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 i.e. real-time, batch, or 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 same level of detail should also be applied to any initial data imports into the system.

Finally, I generally set out the remaining functional requirements that don’t relate directly to individual entities, under separate headings in the document. These include the often overlooked aspects of reporting, administration and security needs.

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

The title for this series has been ‘a more successful approach to requirement definition’, and I believe the approach I’ve outlined differs from the more traditional practices in a number of key ways:

• It places greater emphasis on the business goals

• It recognises the importance of defining the processes necessary to achieve the business goals in detail, which in turn drives out the functional needs
  

• It seeks to complete a complete blue-print of the system before engagement with a CRM vendor

There’s no question that this approach does increase your workload in this phase, but I believe effective requirements management is the biggest single determinant of CRM success, and the benefits of improved negotiating position, greater control of risk, time-lines, and costs, married with the ability to ultimately deliver a real game changing project, should make this a very worthwhile investment.

A more successful approach to CRM requirements definition - part three

As I covered in my last post on CRM requirements gathering, the first goal is to define what sort of problems you are looking to fix, or what sort of beneficial outcomes you are aiming for. The next step, which I will cover in this post, is to define how you will use the CRM system to achieve those objectives.

Most CRM requirements documents that I come across on my travels tend to be a list of required functionality. There is curiously little mention of process – i.e. how the technology will be used.

There are a number of reasons why process is important in CRM requirements gathering. CRM technology is just a tool set, and unless you can define how that tool-set will be used to reach you objective you aren’t going to get there. It’s very much like travelling, you need a destination, but if you are going to get there you need to figure out the route as well.

The second reason that process is important, is that it’s often only when you look at the detail of how your goals will be reached that you will flush out all the data capture, integration and functional requirements that will determine the complexity (and cost) of the project and the most appropriate technology for your needs.

Let’s say you decided that the objective for your project was to increase the life-time value of your customers by increasing the frequency and relevance of the communications you send them. If you look at this purely from a functionality stand-point you may simply conclude that you need marketing campaign management capabilities.

If however you start to look at this from a process stand point, i.e. what are the things you are going to need to do to improve your communication, then all sorts of complexity can start to appear. So you might consider:

How do you want to segment the database to ensure our communications are targeted and relevent? How and when will you capture that information? How do you check the quality of data? How do you ensure that people do want to receive the information you want to send them? How will you handle those that want to opt out? How will you handle ‘gone-aways’ and ‘bounce-backs‘? How do you control changes to the customer data? How will you handle leads and enquiries arising from our communications? How will you maintain data quality over time? How will track the impact your campaigns are having? What reporting will you wish to produce?

As you answer these questions, and work through the processes you need to put into place, then the complexity of the solution often increases. For example you might determine that a key means of targeting your communications will be the products that the customer has previously bought from you. In order to obtain this information it may require a previously unforeseen integration into your financial system.

Looking at things from a process view point is therefore both a key way to check the system will support achievement of your objectives, as well as a means of flushing out the requirements that will determine which CRM software best suits your needs and how much the project is going to cost.

As a bare minimum I would advise you to document and detail all the processes that your system will support. If at all possible I would try and take it a stage further and set out precisely how the technology will support them. I tend to map out the processes and add a detailed commentary on exactly what’s happening in the CRM system. So for each step in the process I indicate who is updating what fields on which entities in the system. This does require a working knowledge of CRM technology, but it allows you to create a more detailed blue-print for the system which in turn gives you much better control of time-lines and budgets.

Next week I will wrap up this series, including my thoughts on a suitable structure for the final requirements document.