How to document requirements for a CRM system – part 2

November 16, 2014May 30, 2015 Richard Boardman

In last week’s post I covered some of the common problems with specifying CRM requirements. In this post I want cover purpose. In other words what are we trying to achieve with a CRM specification. In this respect, I believe there are five key objectives:

1. Identify suitable technologies – by setting out the functional needs we should be able to identify which CRM software products meet our needs and which don’t.

2. Allow prospective vendors to quote accurately – from the document we want vendors to be able to provide realistic costs for implementing the system. The aim is to avoid purchase decisions being made based on estimates that later prove unreliable.

3. Facilitate internal agreement – the document should forge a common internal understanding of the shape and function of the system, so it’s clear to all which areas of the organisation will be impacted by the system and how.

4. Secure appropriate funding and resources – the specification should allow organisations to identify and secure the necessary budget and resources to deliver the system. This might appear to duplicate point two above, but there’s generally a much broader range of costs associated with implementing a system than just those provided by the selected vendor, for example infrastructure costs and the allocation of staff time to the project.

5. Smooth out the implementation process – a clear definition of the requirements up front, shortens the implementation phase, and reduces the likelihood of discovering new requirements which lead to project delays or cost overruns.

Perhaps the key takeaway from the above is that the CRM requirements document serves a much broader purpose than technology selection alone.

However, most of the requirements specifications I come across are largely just lists of functional requirements – often a few pages of bullet-points stating the system must/should/or could do X,Y, or Z. While this may assist with technology selection, it has little value in terms of achieving the other objectives listed above.

So if listing out functional requirements is insufficient, what should a requirements document contain? I will cover that in the next post…

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