CRM project plans - where does it all go wrong?

For those of you currently planning a CRM project, I thought it might be helpful to indentify some of the areas where things tend to go ‘off-piste’, but before I do perhaps it’s a good idea to suggest why we might care in the first place.

If the CRM project team come under time pressure, either through underestimating the time-line or through unforeseeable disruption, the, not unnatural response, is to try and speed things up. Unfortunately, often with limited things that can be sped up, this leads to cutting corners in some form or another. Commonly this manifests itself in dumbing down the requirements, reduced testing, and rushed training, which in turn invariably ends with user adoption issues which may ultimately prove insurmountable.

Therefore understanding which bits of the implementation process are prone to delay is a key way of effectively managing time-line expectations. So the following are my top six areas where people tend to get caught out:

Contract negotiation – you may have selected your CRM vendor quickly enough, but contract negotiation can be a major source of delay. Once matters reach the hands of the respective legal teams things rarely move fast.

System design – translating your requirements into a final design is a problem area. Not so much the design work itself, but, because what you sign off at this stage is what gets built (whether or not it is what you want), this phase is likely to generate much to-ing and fro-ing as the designs are finalised. This can be a particularly extended stage if requirements are ill-defined going into this phase (see here for my thoughts on requirements definition).

In fact at any key sign off point – the simple act of getting signatories together is prone to delay, for the simple reason that most will have other, invariably pressing, work commitments, and the effects of other events such as holidays, illness, maternity, paternity, or, if in the UK this winter, snow.

Data-load – because the point the data load into the system begins is often the point when it’s realised how bad the quality of data actually is. Data preparation is a time consuming piece of work, and is often not started early enough to avoid impacting project time-lines.

User acceptance testing – is the point where you get to check how well the vendor delivered on their design. This phase is commonly underestimated for some reason – probably through misplaced optimism about the number and easy of fixing bugs. It’s generally the iterations of identifying issues, fixing, testing, re-fixing, and potentially breaking other things that previously were working in the process, that make this a potentially delay inducing phase.

User adoption – is nearly always an issue because the amount of effort required to make it happen isn’t generally appreciated. It takes a long time to break old habits and establish new ones, and it can take many months of effort before this is achieved. And this can be many months more effort than was originally allowed for.

Then of course there’s the less foreseeable. In a recent project, pretty much the whole of the vendor project team were made redundant, which was more than mildly disruptive. These situations are not easy to cater for, however making reasonable allowance for the standard phases of an implementation is key to staying away from potentially perilous route of trying to deliver on a project plan that was never achievable in the first place.