Why Bob got fired and why the conventional wisdom on CRM requirements gathering doesn't work...

Okay, so last week Bob got fired. The conventional wisdom on how to gather CRM requirements resulted in a substantial project overrun, a system that added no value, a board squeamish about further investment in IT, and Bob becoming a convenient scapegoat. But why doesn’t the conventional functionality led approach to CRM requirements gathering work? I think there are a number of reasons (which I’ll cover in a series of posts):

Lack of focus on compelling objectives

I’ve seen a lot of CRM requirements documents over the years, and remarkably few seem to pay much attention to why CRM technology is being introduced in the first place. There seems to be a perception that if we buy some CRM technology it will, as a direct output, improve our lives. CRM though is a tool, and a tool is only effective if we use it for a specific purpose. When people ask me the main reason CRM projects fail my answer is simple: people tend to see success as choosing the right CRM technology, rather than working out how to use it to generate value.

I suspect the heart of the problem is that we’re used to software that does a certain thing: Word to create documents; Sage to manage accounts; Firefox for browsing, Google for search. We know what these types of applications do and we can make our software selections based on the features and functions, or the brand we like, at the price we want to pay. We’re also used to software that in the main does what we want ‘out of the box’ and where we don’t have any significant associated implementation costs.

CRM technology is a little different. It can be used in lots of different ways to achieve lots of different things. I’ve seen similar companies, working in the same market, with similar strategies, implement CRM technology in completely different, but equally successful, ways. The challenge with CRM technology is often working out how to use it in a way that generates maximum returns. The ways to beneficially implement CRM technology are often far from obvious, and the extent of the value these systems can create is often underestimated.

The functionality led approach focuses on developing lists of features, and either misses out defining the desired outcomes from the investment altogether, or sets it out in vague and unspecific terms such as ‘increased productivity’ or ‘improved customer service’. The failure to define clear, specific, detailed and, importantly, exciting outcomes results in the following issues:

The return on investment is likely to be very low because the technology – being as we’ve said a tool - won’t be set up to do anything of value.

The project is likely to be under resourced in time and money because the outcomes aren’t seen to be compelling.

The risks of selecting an inappropriate CRM technology are increased on the basis of the maxim ‘if you don’t know where you are going any road leads there’.

Next time, I’ll discuss another point of failure in the functionality led approach: not thinking in terms of business processes (and trust me, I’ll try and make it a more interesting post than it sounds).