This post is part of the serialisation of the ‘An Industry Insider’s survival guide to everything you should know about buying and implementing CRM software’ e-guide, and is the second and final installment of the planning process in which I cover phasing, costs, and executive support:
Avoiding the big bang
As part of the planning process thought should also be given to how the project is phased. Doing too much in one go is a recipe for failure. The following are a few key things to bear in mind when considering phasing:
Do the minimal amount that gets results – it’s easy to over-engineer CRM systems, so it’s generally better to implement something reasonably simple which generates quick results, and then build on it. This approach reduces the risk of spending a lot of time and money creating capabilities that later prove to be white elephants.
The first phase must be value generating – whatever you do in phase one must create compelling value. If it doesn’t, you will struggle to get resources for later phases. I see a lot of vendors promoting the ‘suck it and see’ approach, where customers are encouraged to buy some CRM software and then ‘sort of experiment’. This might be good for short term software revenues, but rarely produces systems that clients want to continue to invest in.
Resources dictate phasing – getting people to use a system in a consistent and structured fashion is one of the key challenges of CRM deployment. User adoption requires people on the ground winning hearts and minds, and this tends to be resource hungry. Therefore one of the key determinants of phasing is the amount of available resources. Try and do too much in one go and the implementation team can quickly become overwhelmed.
User micro-phasing to maximize adoption – there’s only so much change that users can embrace at one time, so breaking down a single phase into a series of smaller releases over the period of, say several months, can be an effective way of addressing the user adoption bottle-neck.
Schedule subsequent phases in advance – if your CRM project is to be phased, it generally makes sense to ensure that the timing, content, benefits, and costs of future phases are broadly defined up front. This helps ensure resources are available when you need them, and avoids the need to go through a lengthy capital allocation exercise for each subsequent phase.
Reporting must be phase one – for reasons that I explained here previously, CRM vendors seem to discourage users from worrying too much about reporting in the early phases of a project. Since reports are the key way for the management team to ensure that the processes that the system supports are being followed, relegating them to the ‘manyana’ file virtually guarantees system obsolescence.
How much will it really cost?
Once you’re clear on the objectives and the phasing, the feasibility of the project should be considered by estimating the costs of realising them. Vendor quotations can be fairly readily obtained, but these are unlikely to be more than ball-park estimates at this stage, and, because vendors tend to underestimate (they generally don’t want to scare potential buyers off), they should be treated with some caution. There are also a lot of costs that generally won’t appear in these quotations, but which also need to be considered. These potentially include:
- Server hardware costs
- Database software costs
- IT infrastructure changes such as required upgrades to hardware, software, and networks
- Project team costs – the additional real or opportunity costs associated with people involved in the project being taken away from their ‘day-jobs’
- Third party project resources
- Ongoing system administration costs
It’s also wise to validate costs by speaking to people who have been involved in similar projects, and also to include a high degree of additional contingency – perhaps 50 to 100% more costs than your initial estimates suggest, is probably a reasonable rule of thumb.
Is everyone on board?
Assuming the project makes commercial sense, then the final step is to ensure the potential project has strong backing from all levels of the organization. There is a fundamental point here: if the management team is not prepared to use and manage the business through the CRM system, CRM will not produce any meaningful value.
I will make the point again (and underline it for additional effect) because it’s so critical: if the management team is not prepared to use and manage the business through the CRM system, CRM will not produce any meaningful value.
So even if the business case is strong, and there’s an obvious return on investment, if the management team are not committed to it, then it’s better either to wait until the planets are more favourably aligned, or look at undertaking the project in a different way. This might involve finding a smaller part of the organisation, perhaps a team, function, subsidiary, or office, who fully buy into your ideas, with whom you could prove the concept, and build support for a wider deployment in due course.
You will note that I haven’t talked about buying any software at this stage. A lot of organisations rush to do this and regret it later. If you are happy that the plan makes sense, and you have the required support for it, the next step is to define the requirements for the project in considerably more detail.