Databases > Implementing A Database, Choosing A Database, Planning A Database
Software > Contact Management
Why Do Most CRM Implementations Fail?
Intermediate
By Peter Flory
In this 2-part article, illustrated with real-life examples, Peter Flory examines why many Client Relationship Management (CRM) database project fail through system selection or implementation errors – and some tips on how to get it right.
IT Project Success Rates
It is a very sad fact that most CRM implementations fail. The Standish Group publish their “Chaos Report” every year which charts the success (or otherwise) rates of IT projects. This shows that project success rates were 16% in 1995 and had improved to 37% in 2011. This might seem to be encouraging as things are definitely moving in the right direction BUT it still means that you are almost twice as likely to fail as to succeed!
Note that the Standish Group define “Failure” as the fact that the project was abandoned and never implemented and they define “Challenged” as the project cost more than expected, took longer than expected or did not meet all of its functional objectives. Therefore in terms of whether or not it eventually achieves its objectives, the picture is undoubtedly somewhat better. However, it is also worth noting that some other organisations which produce these sorts of statistics put the failure rate of CRM projects in particular as high as 80%.
Failure occurs either at the system selection stage resulting in an inappropriate system being purchased or during the implementation of the system resulting in a system that doesn’t work or doesn’t work as expected.
System Selection Failures
The purchase and implementation of a CRM system (or a series of linked systems) will be very, very expensive both in terms of time and money. You cannot afford to get it wrong! Choosing the wrong system usually comes down to one of four things, namely a lack of; knowledge, staff involvement, a formal selection process or detailed requirements.
Lack of knowledge
There is a bewildering array of systems available and a significant amount of research is required in order to identify potential candidates for your particular organisation. One charity signed a fixed price contract for a bespoke development at £24,000 because there was nothing on the market that covered everything they did (there was, actually). They spent £90,000 and then ended up buying one of the usual suspects which itself didn’t cover the full range of their activities! Another charity fell in love with product X because it “looked nice” and the salesman made a good case (i.e. he had a neat line of patter). The organisation was warned not to buy it, they bought it anyway and then product X supplier went out of business before it was fully implemented.
Lack of staff involvement
The industry abounds with stories of organisations where the staff had the system chosen for them either by a trustee or a director or a consultant. Staff that use the system on a day to day basis must be involved in the entire process from inception through selection and implementation. They are the ones who really know what is required. Sometimes they need some help from experts to make them aware of the possibilities afforded by modern software but they are the only ones who can judge whether a feature will be useful or not. One organisation went through a formal selection process involving all the staff, and then the chief executive made the final choice. The staff didn’t agree and the system fell into disuse almost immediately. Consensus is essential.
Lack of a formal selection process
There are many different ways of selecting a system and the different methodologies will not be discussed here. Suffice to say that a formal method must be adopted. One small charity bought product Y for £20,000 plus £3,000 annual support (because that was what the charity down the road was using) when all they needed was product Z at £2,000 plus £750 annual support. When a process is adopted it must be rigorous. Another organisation went through a formal selection process, and then on day 2 of a 30 day free trial (that the supplier agreed to with great reluctance) they decided that it just wouldn’t work for them. This might be seen as a success for the process but the problems should really have been picked up during the demonstration / real-life scenarios stage.
Lack of a detailed requirements specification
You cannot build a system without detailed requirements nor can you choose a packaged system without specifying requirements in detail. All suppliers can genuinely answer “Yes” to vague requirements. One very large organisation spent many millions on a bespoke development because they thought their requirements were unique (they weren’t!) and then finally bought one of the usual suspects! With respect to packaged systems, how many times have you heard “I thought it would do X and Y but it doesn’t”. But did they specify that they wanted it to do X and Y?
How to succeed
Some golden rules for success are:
- Involve as many staff as possible – throughout the entire process
- Define your objectives – and write them down
- Define your requirements – and allocate priorities
- Define your selection criteria – and stick to them
- Check suppliers carefully – and beware of salesmen
- Take up references – and see the system in action
- Plan, budget and monitor – and look ahead five years
- Ensure system continuity – and retain knowledge
- Have someone who understands – and obtain independent advice
- Obtain a consensus decision – and try before you buy
Copyright © 2012 Peter Flory
