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?
Understand there is complexity. A lot of money has been invested by the CRM software industry in promoting the idea that CRM is straightforward. If people didn’t believe implementing CRM systems was easy, they wouldn’t buy much software, and that’s not what the software industry wants. While it’s by no means rocket science, there is considerably more complexity involved than people appreciate. If you get lulled into seeing this just a technology selection issue, you’ll get tripped up.
Write a tight and detailed requirements specification. A tight specification of requirements is the foundation for a well controlled project. The key word here though is detailed. It’s not hard to wander round the building asking people what they want from the system and in the process accumulate a reasonable number of bullet points, but this sort of list is not going to help you manage a project. A requirements document should thoroughly address:
• What problems are we looking to solve?• What are the business processes required to solve the problems?
• How will the processes work within the technology?
• What are the supporting functional requirements?
Ideally you should be creating a detailed design for the system well in advance of selecting any technology. This enables you to:
• Reduce the risk of purchasing an inappropriate technology
• Get a firm price upfront from potential vendors allowing you to purchase competitively and reduce the likelihood of unexpected costs downstream
• Reduce the risk of ‘scope creep’ where new requirements keep being added during the implementation phase causing delays and budget overruns
Create a sensible project plan. This isn’t as simple as it might seem. It’s human nature that while we may have been contemplating deploying CRM for many years, once the decision is made to progress there’s a desire for instant results. Consequently it’s easy to be hurried into an unrealistic project plan. In principle you should be able to look to the vendors for sensible guidance in this respect, but in 14 years in the industry I’ve seen remarkably few realistic plans. As a rule of thumb take the time-lines the vendor gives you, add 50%, and you shouldn’t be too far away.
Choose your vendor carefully. Technology and vendor selection may not be the most important constituent of a successful project, but it’s still important. Good requirements definition will help you understand what you need from your software, but it’s also important to assess the longevity of the options on offer. There’s plenty of vendors I can think of that I don’t expect to see around in a few years time, either because they are new and will struggle to get traction in the market or because they are at the end of their project lifecycle and are milking the last out of a cash cow product.
The other dimension of this is that many CRM technologies are sold through a network of implementation partners. These tend to be smaller businesses, with an even higher mortality rate, so due diligence here is just as essential. The last thing you want to be doing is abandoning a perfectly good system after eighteen months because your chosen vendor got bought out and the new owner pulled support of the technology, or through some similar doomsday scenario. You can’t remove all risks, but I strongly recommend sticking to established, successful technologies unless there is a compelling reason to do otherwise.
Ensure you have the resources in place. CRM projects are time-consuming. People have day jobs. The two things don’t sit well together. You need to understand the resource intensive aspects of the project. Activities such as project management, data preparation, system configuration, testing, and training are often more resource intensive than people expect. It is also particularly important that senior management have the bandwidth to support the project, because the project is unlikely to succeed without their active backing. By examining the resourcing needs carefully you can head off potential bottlenecks that can considerably delay a project.
11 ways to limit CRM implementation risk is concluded in the next post…
Hello Richard,
I think there is one most important question to ask before you even think of writing a requirement document:
What is the outcome that the business needs?
Solving problems sounds great, but usually the problems hinder the company fro achieving the outcomes they desire. It is not the problems that need solving, but the desired outcomes that need to be met.
This is not just one holistic question to the companies leadership-team, it is the same question one should ask all stakeholders and users of the new CRM-system. In most implementations I’ve seen closely (I haven’t done any myself btw) the first question that comes up is: what functionality do you need and how do you want it to work. This sets off an entire trail of so-called wishes and demands that usually have little to do with the outcomes that are desired. By the time the system is implemented and working, most people start wondering: It may do what I want, but why is it not delivering what I need?
When you understand the outcomes that are desired you can design the processes and functions needed to deliver just that. From my perspective anything else results in a waste of time and money..