11 ways to limit CRM implementation risk – part 2

October 4, 2009 Richard Boardman

So you’ve been given a CRM project to deliver. How do you manage the risks associated with managing an implementation on time and on budget that also delivers value to your organisation? Part Two (Part One here).

Break the project into bite size pieces. There’s only so much resource that a project team has available for an implementation, and there’s only so much change users can absorb at any one time. It often surprises people how restrictive these bandwidth considerations can prove to be, so it pays to be very careful how you phase a project. Striking a balance between something that adds genuine value to the business without overwhelming your ability to deliver can be a tough call. It’s generally better to err on the side of caution as long as what you deliver is seen to make a real difference. I’ve seen as many promising projects fail because the initial foray into CRM technology was too timid as I have through trying to be too ambitious.

Get a commit on costs up front. As I mentioned in the last post, I recommend getting as detailed a set of business and functional requirements specified as you possibly can. Ideally there should be no ambiguity as to what you are looking to achieve and the vendor should be able to give you a firm price for the work involved. If this is not the case, then agree what the vendor needs to do before they can provide a fixed price. Depending on the complexity of the project they may do this without charge, but the key here is to get a fixed price without making a major commitment. If, as many organisations do, you make a major investment in software and services before costs are confirmed, then you leave limited room for manoeuvre later should your selected vendor decide their initial estimates were short of the mark.

Manage the vendor. One of the areas people often overlook is the composition of the vendor implementation team. Most CRM purchase decisions rely heavily on the perception of the vendor salesperson, who in my experience invariably disappears off on an exotic holiday once the implementation work begins. The vendor staff who will actually perform the work, and with whom you will be working closely for the next several months, are generally first seen when the ink is well and truly dried on the contract. To avoid nasty surprises it pays to make an assessment of the vendor’s proposed team as part of your initial purchase decision in order to ensure the assigned team are experienced and capable, and, perhaps most of all, are people you’re comfortable working with for the duration of the project.

One thing that should ring alarm bells is if your vendor has a large number of people swapping in and out of your project. This approach tends to help vendors increase billable time because they can charge for staff who might otherwise have been kicking around the office, but, because of the learning curve on any project, staff involved for short periods of time are unlikely to produce value for money and tend to generate a disproportionate number of quality issues. It’s generally better to insist on a small multi-skilled team who are available for the duration of the project. I’m also strongly of the opinion, though this isn’t always practical, that vendor implementation staff work at your site, where you can reassure yourself that they are fully focused on your, rather than someone else’s project. As a final point, I’d recommend that payments to vendors are made on reaching agreed milestones rather than on the more commonly used time and materials basis. This tends to concentrate minds on delivery rather than billing.

Identify the key risk points. Understanding what’s likely to go wrong in an implementation and having a plan to deal with if it does, is a key component of effective risk management. The problem is that some of the risk areas aren’t so obvious. Data migration and integration are well known problem areas, as is anything involving heavy customisation or development work, because of the potential to have multiple cycles of user acceptance testing. However issues can also arise from seemingly trivial sources such as third party add-on products, which software vendors frequently use to plug gaps in their functionality. I’ve seen several projects jeopardised because of short-falls in capability or performance from supposedly bolt-on applications. The other major risk area is where you need to involve other parties who have little skin in the game. A prime example might be an existing supplier whose system is being replaced as part of the implementation, but who you are relying on their help to extract the data. They have an important role, but no compelling interest in making it a success.

Don’t underestimate the challenge of changing people’s behaviour. Of all the risks that you will face when implementing CRM technology, the greatest is that people just won’t use it, at least in a way that will generate any value for your organisation. The standard approach to the user adoption is to load users up with software, give them half a day’s training, and expect them to start using the technology in a consistent and systematic fashion. This does not work. You have to expect that the average user will be very slow to adjust to a new way of doing things, and it requires a considerable input of energy and resources to ensure that change happens. The dimensions of effective user adoption are too wide-ranging to cover off in this post – I’ll try and cover them at another time – but suffice to say this has been a huge point of failure for most deployments of CRM technology, and developing an effective strategy is critical to your success.

Treat CRM as a programme not a project. So, you’ve delivered a great project and you’ve broken the back of the user adoption challenge. In principle now should be the moment to sit back and enjoy the accolades. However, CRM systems are delicate flowers they need to be nurtured over the long term, and it’s over the long term that the value of the investment in CRM technology will be realised. Amongst the key challenges will be ensuring usage remains consistent, as people leave and join the organisation, and that the system adapts to changes in strategy and circumstances. This is no minor undertaking, given the rapidly changing world in which we live, but is an essential requirement if the system is going to deliver long term value.

As a parting point the risk management considerations outlined both above and in my previous post apply regardless of whether you take a SAAS/hosted approach or run the system ‘on premise’. Contrary to some market mythology, I see no material difference in project complexity
and inherent risk between the two deployment options. While I’ve picked eleven key risk areas, if you can define a compelling outcome for your project, develop a comprehensive supporting requirements specification, and can deploy an effective strategy for user adoption, you’ll be a long way towards being successful in your endeavours. Perhaps the best starting point though is to realise that, while it’s not rocket science, there’s more to implementing CRM technology successfully than meets the eye.