The main phases of a CRM project and typical timelines

February 4, 2018 Richard Boardman

A couple of weeks back I wrote a piece about what I saw as the key roles in a CRM project. In this article, to help anyone planning a project, I’m going to outline what I see as the key phases. So, largely in sequential order:

Initial planning and feasibility

The aim of this stage is to establish the operational rationale for undertaking the project and to ensure that the resources are there to support it. So, it will typically set out high level business and functional requirements, the business case, anticipated costs and resources, and estimated timelines. The aim is to facilitate a balanced judgement as to the viability of a project without too big a commitment of resources. This phase will generally be performed by a business analyst or a third party independent CRM consultant.

CRM Requirements definition

Assuming the project gets the green light, the next stage is typically to detail out the business and functional requirements for the system. I’ve written extensively in this blog on the minutiae of gathering and documenting CRM requirements (for example in this guide), but, in essence, it’s about defining which processes the system will support, how they’re currently supported – in other words the ‘as is’, and how we envisage them being support in the new system – the ‘to be’.

The specification will identify the key functional requirements needed to facilitate the ‘to be’, and detail out other key areas such as data migrations and integrations with other systems. Again, this will often be developed by a business analyst or independent consultant.

Procurement

The procurement phase involves the activities involved in identifying and contracting a suitable technology and implementation partner. This is generally made a lot easier, the more comprehensive the requirements specification developed in the previous stage, as it gives potential suppliers a firm base on which to bid, and avoids estimates that may prove unreliable once work gets underway.

Key steps within the procurement phase often include the generation and dissemination of request for proposal documentation, assessment of responses, short list presentations, due diligence activities, and the negotiation of pricing and contractual terms.

CRM system design

Design is typically the first step in which the system implementer is involved and covers the translation of the requirements into a blueprint that the implementer then uses as the basis to customise the system. As with procurement, the better the requirements specification the less the work involved in this step. This stage will also generally involve detailed mapping of any data migrations or integrations with other systems.

System build

As the name suggests, the implementer will typically build the system and the data migration and integration scripts. Ideally this should be a fairly iterative approach with end users having visibility of the build at an early stage in order to validate that the design is correct – something that can be difficult for users to do based on documentation alone. 

Creation of usage documentation

The usage documentation sets out exactly how the system is to be used to support the business processes that the system is designed to manage. This is an important phase that often gets missed, but, ultimately, it’s the bible that will guide the successful adoption of the system. Importantly it also supports the testing of the system and user training.

Testing

Testing typically breaks down into three areas: Firstly, there’s the testing the implementer does before the system is passed over to the customer for review. Secondly, there’s the testing the core project team do to ensure the system meets the requirement, and, thirdly, there’s the testing the wider user community undertake to sign off the system meets their needs.

Testing will largely be driven by test plans that will be based on the usage documentation. After each round of testing, potential issues will be assessed and those that require fixing will be passed back to the developer, and then retested – which all means that testing can be surprisingly time-consuming, particularly if the quality of what’s initially passed over from the implementer is poor.

Training

While the bulk of training usually takes place just prior to the system going live, users involved in the testing programme will be trained prior to the start of that phase. The focus of user training should be on how the system supports each process, rather than just on the raw functionality, as the aim is to get users using the system in line with the usage manual. In practice this generally means that different training sessions will need to be run for each type of user, rather than a one size fits all approach.

Specialist training will also be delivered for those responsible for the administration and further development of the system.

Go live

The go live marks the cut over from using the old system to using the new. In practice go-live is often a sequence of live dates broken down by business, process area, or phase. This is to avoid internal resources being overwhelmed by the demands of large number of staff trying to get to grips with a new system.

Post live iteration

As users start using the new system, a series of potential tweaks and enhancements are often identified. It generally helps with user adoption if these can be addressed quickly, so there will generally be additional phases of requirements gathering, build, testing, and deployment rapidly following the initial go-live.

Post live user adoption

There’s often a false assumption that users, off the back of their initial training, will use the system in a consistent and systematic way – which is what’s required to achieve the operational objectives for the project. This is rarely the case in practice, and a lot of effort needs to be invested in establishing the desired usage patterns. The post-live adoption phase involves proactively monitoring usage to check it’s in line with the documented procedures, and taking remedial action, whether that’s additional help and training, or escalation to their line manager.

 

Where this all potentially gets more interesting is when we overlay typical timelines for main phases of work. If we took as an indicator a 50 seat CRM project with perhaps medium level of complexity in terms of customisation of the system and/or data migration/integration, the following are what I’d consider the average elapsed time for each:

Initial planning and feasibility – 2 months

CRM requirements definition – 2 months

Procurement – 2 months

System design – 1 month

System build – 2 months

Testing – 2 months

Go live and user adoption – 4 months

 

So, 15 months on average from start to finish – which may seem surprising.

Please note these figures are elapsed time, rather than the actual man days to perform the work. This reflects the reality that a lot of people involved on a CRM project do so on a part-time basis and have their business as usual roles to work around.

And that’s not to be said things can’t be done quicker. It’s generally possible to implement a system considerably faster if the will and resources are available.

Perhaps the key take-away from the above is how relatively small the system design and build phases are compared to the rest of the project. In the example above, 3 months out of 15 months in total, or just 20%. It’s the softer activities that bookend this work that take the time, but these, particularly the requirements definition and user adoption phases, are also the ones that have the biggest impact on success.