Six pieces of CRM implementation advice...

I had the pleasure of going on a CRM site visit during the week. It’s always interesting to discuss other people’s experiences of implementing CRM systems. I always ask what advice they would offer to others about to undertake an implementation, and thought it might be refreshing to pass on some thoughts that weren’t mine for a change. So six pieces of advice for those implementing a CRM system:

1. Be aware that the implementation of new technology also provides a temporary window for more far reaching business change. Use it or lose it.

2. Don’t underestimate the internal resources that CRM projects soak up.

3. It’s easy for key implementation activities such as testing, documentation and training to get crunched at the end of a project as deadlines loom. Make sure these are not compromised.

4. Make sure you engage key users early, this has a big impact on how quickly and effectively the technology is adopted.

5. Don’t try and do too much – phase it.

6. Find the right vendor.

Late and over budget – the hidden traps of implementing CRM systems…

While the instances of outright failure are few and far between these days, CRM technology implementation projects continue to be a source of pain and frustration. Recent research relating to IT projects in general indicated that the average project came in 56% over budget and 84% later than expected. While I’ve no figures for CRM specifically, I’d hazard a guess that that the performance of the sector was even worse.

So what catches organisations out? Before I try and answer that, I’ll make the point that I’m referring to the meaningful use of CRM technology; technology deployed in a way that will deliver significantly beneficial results. It’s easy to throw some software on a server, or sign up for a hosted provider, however high pay-back CRM systems generally require considerable work in setting up these technologies in order to generate results.

Here are the six aspects of CRM deployment that tend to ambush the unwary:

Poorly defined requirements – many organisations initiate CRM implementations with only a hazy notion of what they are trying to achieve, or what the final solution will look like. As a consequence requirements tend to change as the project progresses, and new requirements emerge, which puts pressure on resources, schedules and budgets.

The availability of internal staff – CRM projects are hungry on the use of internal resources. For example users will be involved in requirements definition activities and training, the IT team in project management, key users and sponsors as part of the project team, and senior management in overseeing the project. When fully mapped out, the demands on internal staff can be considerable, and, as most will have ‘day jobs’, projects often suffer disruption as staff struggle to balance their day to day activities with the demands of the project.

Sign offs – as the project progresses there are generally a series of sign off points at key milestones. It’s common that sign offs will involve a range of individuals in the organisation as well as senior executives making up the project board. The logistics of coordinating sign offs can be complex. The simple act of diarising review meetings that all required parties can attend can add months to a project, and is a phenomenon that isn’t well catered for in many project plans.

Data – good systems require good data, and, if the new system is to be populated with existing data, it’s important that the quality of that data is high. Many organisations are surprised at how many data sources they possess and how poor the data quality is. The cleansing of data and reconciliation of different versions of the same record in multiple data sources can be very time-consuming. While there are tools that can help, this process tends to be very manual, and is not something that can be fully outsourced as it requires considerable input from the data owners.

User acceptance testing – once the customisations and configurations to the software are complete, there’s generally a phase of user acceptance testing to ensure that the requirements will be met. This can be a surprisingly extended process as many members of staff representing each functional area may be involved. The process is also highly iterative in that bugs and issues detected in the first round of testing will require re-testing, and it’s not uncommon for ‘fixes’ to prove not to be, or break other previously working areas of the system. It’s not unusual to have to go through several rounds of testing. This is also at this stage that additional requirements emerge particularly if the original requirements were lightly specified.

User adoption – an effective system requires consistent and systematic usage. The system can be ‘live’ but not generating the desired returns. Organisations generally underestimate what’s involved in achieving comprehensive user adoption and often put too much faith in the value of classroom training. Classroom training has its place but adoption demands a host of proactive measures such as targeted training and interventions for reticent or struggling users. It’s not uncommon for user adoption programmes to take many months of sustained efforts before the new habits and practices become ingrained.

While effective requirements definition will go a long way towards addressing budget and cost overruns (though the importance of this should not be underestimated), for many aspects of CRM deployment there are no easy short-cuts. The key is to be realistic about the demands these projects will place on the organisation and manage expectations accordingly. Too often CRM projects are deemed failures because they failed to meet impossibly demanding and often self-inflicted deadlines. A better review of what’s involved and a more analytical appraisal of the availability of resources to meet those demands will go a long way to ensure project success.

Removing the c from rm...

As I’ve mentioned in previous posts, I’ve always been a bit uneasy about the ‘Customer’ in CRM. I prefer to view the deployment of CRM technology as a means of bringing about process efficiencies which may, or may not impact the customer. So a good example of a ‘may not’ might be using CRM technology to improve the effectiveness of salespeople. i.e. an organisation might have invested in the latest sales methodology and wants to ensure that the benefits are maintained when the original training is but a distant memory, and encompasses the new working practices within the CRM system. The salespeople are more effective as a result and the company hopefully more profitable, but the customer is unlikely to feel much direct benefit themselves.

In practice most process efficiencies have both customer and non-customer benefits. We have a system going live currently where we’ve spent a lot of time automating and streamlining a range of order management and fulfilment processes. These processes were previously handled by a range of Excel spreadsheets, Access databases and hard copy files, and were time consuming and lengthy. The changes we’ve implemented should improve fulfilment quality, reduce lead times, and require less resource, which should lead to a desirable win/win. The customer gets a higher quality product delivered in less time, and the organisation deploying the technology lowers its costs of fulfilling orders.

I don’t want to dwell on it, and of course it’s not going to change any time soon, but in my line of work I see a lot of people delay introducing potentially highly beneficial technology because they want to get their ‘customer’ strategy sorted first. If we removed the c from rm then perhaps, more people would understand the wider potential of the technology.

If Warren Buffett ran a CRM company...

If you ever want an object lesson in candour and taking an objective long term view then look no further than Warren Buffett’s annual shareholders letter. Observing on the mayhem in the financial markets in his 2007 letter he notes ‘You only learn who has been swimming naked when the tide goes – and what we are witnessing at some of our largest institutions is an ugly sight’.

Whether or not it involves lending money to people who can’t pay it back, short-termism is a hazardous practice, and one that’s rife in the CRM market. There are two key manifestations of this in my view. Firstly there’s an undue focus on initial project profitability at the expense of customer satisfaction. While I have no issue with vendors looking to make money on the work they do, I think there’s a tendency to obsess on protecting margin, generally through the heavy handed use of change requests, rather than concern as to whether they will have a customer who wants to retain their services at the end of the implementation process.

Secondly the emphasis tends to be on getting the project ‘done’ and moving on to the next one regardless of whether the system is generating any genuine business value for the customer. Partly this is a question of capability – CRM vendors ‘know’ the technology, but few have an understanding of how to apply it, and partly because it’s easier not to: injecting the inconvenient reality that there’s more to achieving CRM success than buying technology and plugging it in, introduces the sort of uncertainty that can distract from the fundamental objective of selling software.

If Warren Buffett were to suddenly find himself running a CRM company, I’d imagine it would become a rather profitable one, because Mr Buffett, unencumbered with a background in the IT industry, would quickly deduce two things 1) unhappy customers are unlikely to make you very rich, and 2) the greater value you can generate for your customers the more they are likely to invest in your products and services. Sadly there aren’t many Warren Buffetts out there, rather fortunately for the CRM industry I suspect.