A more successful approach to CRM requirements gathering - part 2

Last week I described why I felt a detailed set of business and functional requirements was essential to a high pay-back CRM project. Over the course of the next few posts I intend to set out some thoughts on how you can go about creating them.

The ‘big’ point in terms of this post is that you need to be clear about what problems you are trying to solve or what compelling outcomes you are looking to achieve. This may sound fairly obvious, but I see a lot of CRM requirements documents in my travels, and very few of them have clearly stated business goals.

There are three reasons why I think being explicit about your outcomes is important. Firstly, it acknowledges that you understand that technology is a tool. It won’t produce value on its own. It needs to be used in a coordinated way to produce results, and there are many and varied ways in which CRM technology may benefit your business.

Secondly, without a clear objective to guide your project from the outset it’s unlikely it will unintentially generate value. Thirdly, unless you can convey the benefits of the project in a compelling way it’s unlikely you will secure the necessary financial investment or, perhaps more importantly, the necessary injection of internal attention and resources required for success.

In terms of starting to define the desirable outcomes for the project, it’s worth noting that there are two broad ways that CRM technology may improve the operation of your business:

Process automation – where you take what you do currently and improve things through better supporting technology. For example, you might have excellent processes in terms of how you attract, develop and retain customers, but these may be supported through a range of Excel spreadsheets, standalone systems and databases. CRM technology might create new efficiencies by replacing disparate silos of information, with a central system which allows customer information to be better shared and more beneficially used. In this case your underlying business processes may be adapted to CRM technology, but they are not fundamentally changed.

Process development – where the business processes themselves are re-engineered, or entirely new processes are created. For example, you might adopt a different strategy in terms of how you manage sales leads, or streamline the order management process, or change the way you handle customer issues and complaints. In this case existing processes may change radically, and CRM technology plays a key role in their successful adoption by the business.

In practice most CRM implementations tend to focus on process automation. While process automation projects can produce a high pay-back, in general the greater returns on investment are achieved through the process development approach – looking to improve and add to existing processes and use CRM technology as the means to support those changes. As I noted in my ‘Notes from the Camp Nou’ post, the organisations that use technologies the most effectively tend to focus on achieving process ‘best practice’ and use systems like CRM to drive those best practices through the business.

In terms of finding process automation benefits, a sensible starting point is to analyse and document how business processes are currently performed and how they are currently supported by technology. By reviewing these in context of how they might operate when supported by CRM technology you should be able to flush out potential efficiencies and benefits. This does require a working knowledge of CRM technology that you may not currently have. However, as many CRM technologies are available to evaluate free of charge, and that the general concepts and capabilities of different products are similar, it is not an unduly time-consuming task to gain the necessary knowledge by reviewing some of the mainstream packages.

As I touched on earlier though, the greater rewards generally spring from improving the processes themselves. The act of documenting existing business processes often produces a few surprises in terms of how things are actually done as opposed to how it was believed they were done, which may in turn move a project away from process automation to process development.

It should be noted though that improving existing processes and adding new best practices is a more challenging and time consuming activity than simply automating what you do already. There’s no single way to go about doing this, and can be a product of internal brainstorming, consulting with your customers, researching how top-performing companies perform the same processes, and accessing the knowledge of domain experts.

The output from these exercises should be some clear statements regarding the beneficial outcomes. For example: ‘By streamlining and automating the order process, we expect to reduce the time to fulfil orders by two weeks, and reduce the cost of processing them by 40%.’

Once you are clear on the objectives, it’s normally worth undertaking an initial assessment of project feasibility before going too much further. By matching the identified beneficial outcomes of the project with an estimate of costs, you should be able to assess whether the investment makes commercial sense of not. Assuming it does, then it’s time to move to the next stage in the requirements definition process which I will cover in my next post.