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

November 25, 2009September 6, 2015 Richard Boardman

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.

Footnote – we recently published a free ebook which goes into a lot more detail about how to approach the CRM requirements gathering process and how to document the outputs. The ebook can be downloaded from here.