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.
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.
posted by Richard Boardman at 2:41 pm
<< Home