How to document requirements for a CRM system – part 4

November 30, 2014May 30, 2015 Richard Boardman

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 process. This helps ensure that the approach was thorough and comprehensive and that any gaps in coverage can be identified.

Overview

The overview gives a high level description of the new system, and will cover who will be using it, and what they will be using it for.

Phasing

For many organisations, making all functionality for all users available on day one is impractical. The phasing section set out how the deployment will be broken down and how these will be prioritised. For a more detailed discussion of project phasing see this post.

Business objectives

For me this is one of the most important parts of the requirements specification. It describes why you’re undertaking the project in the first place: What are the problems you’re trying to solve? What beneficial outcomes do you expect the the system will produce? This should be as specific and detailed as possible.

As I’ve touched on in previous posts, a CRM system needs to be set up and used with specific goals in mind. If these can’t be properly articulated, it’s unlikely that the project will be a success.

Defining clear business objectives also has an important role in securing appropriate funding and resources, as well as helping prioritise requirements based on business need.

Supporting processes

The role of this section is to specify how the system will support the business processes necessary to achieve the agreed business objectives.

For example, if a key objective was to grow sales by improving lead conversion rates, from say 10% to 15%, then this section would communicate how the processes from initial lead capture through to order will be managed within the system, and describe how the improvements will be realised.

A sensible approach to this is to describe both the current ‘as is’ situation, highlighting known issues and inefficiencies, and then the ‘to be’ processes. I tend to cover these processes in both a written narrative, as well as a series of flowcharts. The flowcharts for the ‘to be’ describe in detail what’s being updated in the system by the user for each step in the process.

Most organisations neglect this area when defining their requirements, but it plays a key role in helping determine the fit with the ‘out of the box’ capabilities of the various CRM software options, and helps prospective vendors more accurately cost out any associated customisation and development required to bridge any gaps.

Entities

This section describes the main types of records managed by the system. For example, this might include information about people, organisations, sales opportunities, leads, and activities, but also may include new entities that need to be added to support an organisation’s processes. I generally start with a diagram of these entities, and how they relate to one another, and then describe each in detail, setting out what fields will be tracked within each.

This might seem like a lot of work up front, but it saves valuable time later during the implementation phase.

Functional requirements

This part of the specification describes all the supporting functional requirements. I tend to break this down into specific functionality required to support each business process, and more general supporting requirements such as administration, security, or access related functionality. In a future post I will endeavour to provide a functional requirements check-list which hopefully should help in this area.

Data migration and integration requirements

Data migration and integration requirements can have a huge bearing on the cost of implementing the system. It’s therefore important to document in as much detail as possible needs in this area. A clear definition of what data is moving between which systems, is essential, and, in terms of integration, whether the requirement is for real time or more periodic integration.

Reporting

This area should ideally identify what management information you’re looking to get out of the system. Detailing out reporting requirements, not only helps speed up the implementation, but can be a very effective way of validating that the processes have been modelled correctly and that the associated data capture is correct.

Systems replaced

Finally, the systems replaced section confirms which existing systems and data sources will be decommissioned as part of the roll out of the system. This helps remove any ambiguity as to how the post-live world will look.

As you can see there’s a lot more to a CRM requirements document than just a list of required functionality. While there’s more work involved, the benefits of approaching it this way are significant. I will explain why in the next post.

Footnote – this series of posts is available as an ebook which can be downloaded from here.