In my recent series on requirements gathering, I noted the need to document the phasing of a CRM implementation. I’ve come to the conclusion over the years that phasing is one of the most critical aspects of implementing a CRM system successfully, and so figured this might merit some further elaboration.
Perhaps the starting point is to explain what I mean by phasing. Phasing relates to how you go live with a project. Whether you go live with everything in one go – often known as a big bang approach – or whether you break the project down into a series of go-lives over time.
Generally projects are phased based on or a combination of: organisation structure – the Birmingham office will go live in March and the Manchester office in April; process area – we will go live initially with contact and sales pipeline management, then lead management; or functionality – the integration with the finance system to support customer management will be in phase two.
The timing between phases may be relatively brief, perhaps days or weeks, or there may be long gaps between the different stages of the project.
The reasons for phasing a project include the following:
Budgetary considerations – there’s not enough funding to implement all the defined requirements in the short term
To avoid disruption – to reduce the impact on business as usual activities
To road test – to test and refine a system with a smaller unit before it’s rolled out to all staff
To assist with change management – it takes a lot of time and resources to get users adopting a system in a consistent and structured way, and reducing the amount of change makes it easier to embrace new technology and avoids overwhelming internal resources
Some of the factors to consider when planning the phasing of a CRM project are:
Priority – this should generally be focused on the areas of greatest need. What are the main pain points? Where can technology make the biggest difference? Doing something meaningful in the first phases is key to garnering the commitment to a project over the long term.
How much change can users embrace? – there’s a big difference between replacing an existing system and staff using a CRM application for the first time. Understanding how quickly users can embrace a new system is a critical aspect of phasing.
Resourcing – realistically, how much can the people we have available support at one time? Given that user adoption can be surprisingly challenging, this may be less than you think.
Metrics – what metrics will we judge progress on? There’s no point moving to phase two if phase one hasn’t been successful. Defining how we determine ‘success’ is key. Project staff need to be carefully monitoring adoption to determine if staff are using the system, and if it’s producing the desired results. The roll out schedule needs to reflect what’s happening on the ground and be adapted if necessary.
Learning – One of the keys to speeding deployments up is to learn from every phase. Analysing each one and looking to improve how it’s deployed and supported can make a big difference to the time it takes to fully roll out a system.
Maintaining momentum – when a project is phased it’s critical to maintain the momentum across all phases. There’s a natural desire, having gone through the arduous process of gathering requirements, selecting a vendor, development, and testing, and getting the first users live, to want to rest up for a while. It’s easy however for momentum to be lost at this stage, so having a clearly understood plan as to what is happening, and when, is key to keeping things moving forward.
Most projects can and should be phased. Organisations commonly underestimate how long it can take and how much is involved in getting users to use the system consistently. Trying to do too much too soon invariably results in an investment in technology that does very little. The focus needs to be on ensuring the system achieves meaningful operational goals, not on ticking the box that the project is complete.