Robbing Hood...

There was an interesting article in the 5th December edition of BusinessWeek entitled ‘Shaking up Oxford’. It detailed the major challenges faced by John Hood, the new vice chancellor, in shaking up Oxford University to improve its standing in the global league of top universities. Echoing the entry I made about our fragile faith in technology, one paragraph particularly caught my eye:

‘Well before Hood arrived, they [Oxford faculty members] had developed an antipathy toward the central administration because of a bungled financial management system and other pratfalls.’

It’s a point I think I’ve made before, but the price of failed IT projects goes far beyond their immediate cost. That failure can programme itself into an organisation’s DNA and prejudice attitudes towards adopting information technology in future projects. More importantly it can erode faith and respect in the leadership team itself, even, as in the Oxford case, future management teams, undermining management’s ability to steer the business in the direction it wants.

Moral – if you are going to undertake IT projects, plan carefully, the price of failure can be larger than it might first appear.

Fragile Faith

I met with a client a couple of weeks ago. Four years previously they had invested a decent six figure sum in an implementation of CRM technology. As time passed the system steadily fell into disuse, and the company wanted to review the best way forward. The software they had originally purchased was still one of the most functional in the marketplace, and the most economic option seemed to be to re-implement the latest version. The client felt however, that problems with the initial implementation of the system had sufficiently soured user perceptions, that it would not be viable to re-introduce the technology. They chose instead the significantly more expensive route of buying and implementing new software.

This situation illustrates one of the fundamental tenets of CRM implementation – you only get one bite at the cherry. As a general rule, users have a fragile faith in information technology. In their hearts they don’t really expect it to work. If you are lucky they will give you the benefit of doubt – but only once. Which is why, if you want a successful system, effective management of user perceptions is paramount. Too many companies cut corners in a rush to hit unrealistic live dates, end up using user training sessions as part of the testing process, and going live with bug-ridden software that fails to meet the real needs of the user. They can always re-implement of course, but it’s a costly exercise, particularly if you’ve got to purchase a new software application as well.

A smooth transition...

Interesting conversation last week. One of our clients had recently lost a couple of key sales staff. Since they don’t have a big sales team, this represented a reasonable proportion of their sales capacity, and had the potential to be highly disruptive in the countdown to their year end. When I asked their sales director how this was impacting them, he pointed out that they had actually managed to increase sales over the effected trading period. One of the key reasons was the depth of up to date data they had built up in the CRM system about customers, prospective customers, and the related sales opportunities, meant the time to get new staff up to speed was minimal – the new recruits were closing business within a week of joining. It wasn’t a benefit area we had focused on when we helped the client formulate the business case for the system, but one they were nonetheless pleased to have.

The light is better there...

Reading through a book called ‘Peopleware – Productive Projects and Teams’ by Tom DeMarco and Timothy Lister I came across the following quote:

‘If you find yourself concentrating on the technology rather than the sociology, you’re like the vaudeville character who loses his keys on a dark street and looks for them on the adjacent street because, as he explains, ‘the light is better there.’’

The point they make is that projects rarely fail for technology reasons, but for sociological ones. In other words it’s the people dimension that represents the primary fault line. While DeMarco and Lister were referring to technology projects in general rather than CRM projects in particular, their analysis highlights one of the major barriers to effective CRM implementations, namely our obsession with the software element, and our lack of focus on user adoption – the people side.

The heart of the problem is a pervasive perception that CRM is a one dimensional technology challenge. Choose the right software, install it, turn it on and the benefits will flow. The reality of course is that without due attention to people and process, CRM will achieve very little. You can have the greatest technology in the world but if you can’t persuade people to use it in a consistent and systematic way, then you create no value.

Of course the notion that effective CRM implementation is a more complex three dimensional puzzle isn’t a hugely appealing message and is likely to remain drowned out by the siren song of ‘easy to use, fast to deploy, quick results, just £50 per month’ – for some time to come. But if you do want a high pay back project you could do a lot worse than obsessing on the people and the process rather than the technology.

If you don't know where you are going...

One of the things that has struck me over the years is how few organisations spend any great time defining and documenting their requirements for a CRM system before plunging into the frenzy of vendor selection. I don’t think it’s a coincidence that the same organisations have struggled to realise high returns from their software investment. To my mind effective requirements definition is the foundation of successful projects and long term high return systems, and here’s a few reasons why –

Firstly, it’s nigh on impossible to select appropriate software if you are unclear what it is you are trying to achieve, and what functionality is required to achieve it. As Lewis Carroll noted - ‘if you don’t know where you are going, any road will take you there’. Which is why, all too often, CRM technology will get purchased for fairly superficial reasons, like ‘the software looked easy to use’, rather than a reasoned assessment of functional fit. Which, in turn, is why a lot of organisations realise, post having made a hefty investment in technology, and now finally having worked out their requirements, that it doesn’t actually do what they want it to.

Second, it’s nigh on impossible to make a pricing comparison when your needs are vague because the vendor is only able to ‘estimate’ the service element of a project, so you never get to a situation of being able to compare apples with apples, and leave yourself completely open to a vendor proposing a low ball price knowing full well, that once in receipt of your order, their more ‘considered’ review of your requirements will double their estimate.

Thirdly, if you wait until you’ve raised the purchase order before defining requirements, you are likely to find that the accumulated list of ‘must have’ features and functions does not sit well with the limitations of the budget – which leaves the potentially painful options of chopping back requirements (often, in my experience, to the point that the project is effectively emasculated), or a visit to the board for more money.

Fourthly – It’s a lot cheaper to get the requirements well defined up front, then start implementation, rather than the other way round. The clearer the requirements are, the less time (and money) the vendor has to spend defining them, and the less time they have to spend on re-work of functionality which they imagined you would want in the absence of a detailed specification.

Fifthly (and finally) – It’s better to go through the time-consuming activities of effective requirements analysis before you’ve paid out for the software, then after, which of course is when everyone is pushing for a rapid live date, and the pressure’s on to cut corners to deliver quick results.

It may not be the glamorous part of a CRM project, but effective requirements gathering is to my mind what separates the high from the non-performing projects.