A more successful approach to CRM requirements specification

Earlier in the year I wrote a series of posts entitled ‘Why Bob got fired’ which was meant to culminate in a piece about how to write a business and functional requirements specification for a CRM system – something I’ve seen people consistently struggle with over the years. Anyway somewhere along the line I got distracted and didn’t finish the series, so I thought I’d revisit CRM requirements specification and try and set out in as simple and clear a way as I possibly can my thoughts on the best way of approaching it.

Perhaps the best starting point is to give some definition to what I mean by CRM requirements documentation. I will cover this in more detail in the coming weeks, but in short a requirements specification does three things: it sets out the problems we are trying to fix or the desirable outcomes we are looking to achieve, it defines how those problems will be solved or outcomes achieved, and identifies the required supporting functionality.

I will also add that in my view a CRM requirements specification is a detailed piece of work more in line with a set of architect’s plans, rather than the high level list of functional bullet points that are often produced. It is created before technology is purchased rather than after, and by the user of the CRM system, not the CRM vendor.

I will talk more about how you might approach requirements gathering and best way to document them in later posts, but today I just wanted to set out why getting a good set of requirements is important, and that comes down to the following reasons:

• It helps ensure the project receives the funding, resources, and management attention necessary for success 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 are defined.
• It improves user 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 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. Where high level requirements are provided, 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 committed to a single vendor.
• It speeds up delivery of the project, because a detailed specification means that developers can work more quickly.
• 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 with the vendor.
• It reduces the risk of cost and time overruns, because there is less likelihood of new requirements appearing as the implementation process 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 increases the return on investment for the system because there is a clearly defined business objective.

To my mind effective requirements gathering is the foundation of a successful project, and alongside defining a well thought out user adoption strategy, is one of the key activities which determines success or failure. If you can get it right, every other part of the project flows more easily, and, as an added bonus, it allows you to achieve more, at less cost, and with less risk.

Having set out why it’s important, next week I’ll set out my thoughts on what makes for a successful CRM requirements gathering approach.