Six common CRM requirements gathering faux pas

June 25, 2011 Richard Boardman

In my last post I gave my thoughts on the most common problems associated with CRM feasibility and planning. This week I want to cover off my take on the main snafu’s in the CRM requirements gathering process:

Lack of clear objectives – I covered this in the last post, but suffice to say CRM technology is a tool-set. Unless you’re clear what you want to use it for it won’t generate value. Too few of the requirements specifications that come across my desk have clearly stated, compelling, value-enhancing objectives.

Inadequate consideration of processes – most requirements documents tend to be bullet-point lists of features. What is missing, in most cases, is any articulation of processes. Only when the operational processes that the technology is required to support are defined, can you determine the functional fit of the various technology offerings and how much time and money you will need to spend to meet your specific needs. In other words, unless process considerations are fully taken into account there’s a risk you’ll choose the wrong technology and get hit with unforeseen costs downstream in the implementation phase.

Feature blinkers – as I mentioned in the previous point, CRM requirements documents tend to be feature-centric. However that feature-focus is often very blinkered to the more exciting parts of the technology. The more mundane aspects, for example security, administration, or flexibility of development often receive little attention, yet these often ignored areas are the ones that catch people out when they start to deploy the system and find it doesn’t support what they are trying to do.

Lack of consideration for data migration and integration – these areas are often overlooked, or summarised in a few lines.  Data migration and integration can however be simple or extremely complex. Lack of specificity and details as to what needs to be done in this area means there is the potential for huge under or over-estimates in implementation costs.

No viable or affordable solution – this occurs when an organisation drafts a set of requirements which is out of context of what’s available in the market or at the price they are willing to pay. In extreme examples I’ve see organisations issue requests for proposals and receive no responses. Another variation is when the word mandatory is overused and viable options are inadvertently discarded. Requirements definition without reference to what’s available in the market can waste time and lead to poor technology selection decisions.

Operating in a silo – too often organisations fail to take account of other things that may be happening that will impact the project. For example, a detailed set of requirements may be developed for a part of the organisation that is about to be restructured, or an integration may be specified to a system that’s due to be replaced. This happens surprisingly commonly and is exacerbated by the fact that organisations frequently underestimate how long the implementation process is likely to take. It’s important that there’s wide visibility of the scope of a CRM project and the associated time-lines in order to avoid duplication of activity or unnecessary work.

In summary, nothing does more to assure the success of a CRM project than effective requirements gathering. Too often though an over emphasis on features rather than objectives and supporting processes, and an unwillingness to specify to the right level of detail, means that the benefits are never realised.