The fine art of CRM project phasing and why it’s important

June 24, 2018 Richard Boardman

One thing that I don’t think is thought about as often as it should be, and, when it is, isn’t generally done as well as it could be, is the whole concept of phasing a CRM project.

There are a number of reasons that phasing is important.

Firstly, and perhaps most importantly, it’s to support the user adoption process. In most instances user adoption is a hard-fought process and it demands a lot of resources to make it happen. Staff need to train users, walk the floors during go-live, answer questions, address issues, monitor usage patterns, identify additional training needs, and address non-compliance issues.

This generally takes a lot of time if you’re going to be successful, and most CRM project teams don’t have unlimited bandwidth. So, in order to maximise your chances of getting the job done properly, the project is broken down so that you don’t have more users going live at one time than you have capacity to effectively manage (which frankly I think is a lot less than people generally understand).

Secondly, a phased approach gives you the opportunity to tweak, tune, and improve the system, as well as address any problems at an early stage, so that the performance of the system is optimised before the bulk of users are on it.

Thirdly, it potentially gives you the chance to check that the system is delivering on the compelling operational objectives which I discussed last week (and do something about it if it isn’t), by monitoring the metrics that had been identified to validate that they had been met.

Before I go on too much more about phasing, I think it’s important to note that there are circumstances that don’t lend themselves to phasing. For example, if the project is to replace an existing system that’s already heavily used to support key operational processes, or you’re implementing a system which will only work if everybody is using it, you generally have little choice but to go the ‘big bang’ approach and switch over in a single phase.

In the main, however, most projects can be phased, and when looking at how, the biggest consideration is going to be how big a user adoption challenge are you facing. This will vary from project to project.

As I discussed last week, some systems don’t need everyone to use it to be successful, other situations require 100% compliance or the benefits are unachievable.

Users who are already heavily systemised, or have strong management that are fully behind the project, are going to adopt the system quicker and require less support, than those that don’t.

It’s perhaps worth noting that there are situations where you have circumstances that preclude the roll out of a system for long periods of time.

As an example, I was working on a project a few years ago, where we were due to roll out to one of the key teams, but the manager who had helped specify the requirements had moved on. The new interim management clearly had their hands full getting to grips with things, and we had to wait about a year before the team was strong enough successfully support the adoption of the system.

Anyway, having understood the scale of the adoption challenge, the next step is to develop an appropriate adoption plan and work out what resources are required to implement it.

I will write in more detail about adoption plans at some point in the near future, but in essence you will need people who can train users, handhold through the early go-live, monitor usage patterns, and make appropriate interventions where those patterns are at odds with what was intended, until such time as you reach your target compliance levels.

This can be surprisingly time-consuming, so, to avoid the resources you have at your disposal getting swamped, it’s important to work out how many users you can cope with at anyone time and structure the phasing accordingly.

Other key considerations for phasing will be around the time required to identify, document, perform, test and deploy fixes and improvements, if early tuning is a consideration. And, if there’s a requirement to validate that the operational goals are being achieved (and I would suggest there generally should be), how long before this is expected to show up in the metrics.

In practical terms this may mean the ‘go live’ period runs for many months after the first cohorts come on to the system, and as, I mentioned earlier, the timing may be completely wrong for some teams, and they may need to come on to the system at a much later date.

In terms of how phasing impacts the actual development of the system, I’d say it generally (though not always) makes sense to develop as much of the system as you can up front, rather than develop in a more piecemeal approach in line with the phasing.

The reason for this is that it’s generally more cost effective to engage your implementer to deliver a single development, and reduces the risk of you structuring a system that works for the early phases, but not for the subsequent ones.

In summary, my view is that the adoption of systems can be improved significantly by a) having a sensible adoption plan (obvious maybe, but it doesn’t always happen), and b) ensuring that the project is phased so that the resources required to effectively support that plan aren’t swamped.

If we properly take this on board, then a typical go-live looks more like a multi-month, quite possibly a multi-year, programme of activity. And, as such, very different from the ‘get the project done, and move on to the next’ approach that still seems so common in the industry today.