Talking CRM requirements gathering…

June 23, 2008 Richard Boardman

Strangely I spent a fair proportion of the weekend talking requirements gathering. An old friend of mine is a senior IT manager at a global 500 company, and we were stuck in the car together for much of the weekend travelling to and from a mutual friend’s stag do. So in between pondering on the complexities of delivering a best man’s speech in two languages, one of which I don’t speak, we got to compare notes on what we believe constitutes good requirements gathering practice. There was – surprisingly perhaps – considerable consensus on what we felt was important. The following are the key points – those that I remember at least:

Good requirements gathering is fundamental to the success of any CRM project. Get this right and you are 70% of the way there.

Most organisations do not do a good job of it. Which partially explains why most CRM projects produce at best marginal results.

The starting point for any requirements gathering is to define the vision as to what issues are being addressed or improvements are sought.

The vision has to be defined by senior executive sponsors. No senior executive sponsors, no project.

Senior executives are unlikely to be able to define the vision on their own, they invariably need to supplement their knowledge of the business with what’s achievable through technology. Education plays a key role in requirements definition.

Not all visions require a technology solution; sometimes the answer solely lies in the area of people and process.

Even if the vision requires a technology solution, the dimensions of people and process are vital (though in the main are generally ignored).

Requirements gathering increases in detail over time as the vision is refined and developed. The vision has to be supported by the detail of the processes and associated functionality required to achieve it.

The requirements gathering process is not a 5 minute exercise, done properly it will occupy a substantial proportion of the project.

Requirements should be continually challenged to ensure that they are key to achieving the vision.

Requirements need to be gathered in context to what’s available from technology otherwise potential opportunities may be missed, or there may be excessive elaboration of requirements where the costs clearly outweigh the benefits.

It’s dangerous to define requirements too narrowly; the benefits of implementing technology can often be wider than is immediately apparent. It’s also important to take account what other systems will impact or by impacted by the project.

Phasing is vital – there’s often opportunity to generate considerable value through a relatively simple initial deployment, and then add capabilities over time.

That said beware the ‘let’s go out of the box’ mode of thinking; any effective system has to be tuned to ensure it encapsulates the business processes required to deliver the vision, and that almost always requires some modicum of change.