It’s just a phase …

Dan Lockeretz, Purple Vision Project Delivery Director shares his experience of delivering CRM implementation projects – something he’s done quite a lot of in the years he’s been a Purple Vision, and even before that in his previous life charity-side.  This is the second in a series from Dan explaining projet delivery issues. 

Turns out your family is pretty much right. About everything.  Darn it.

Remember ‘don’t bite off more than you can chew’ or ‘you’ll never manage all that’. They were right.  Not about your ability to eat the whole Christmas selection box (just me then?).  Same as they were right when they said “it’s just a phase”.

Not about your excellent taste in hairdos and clothing (just me again, then?).

But if they’d been talking about CRM implementation, they would have been absolutely bang on.

A phased approach

When considering how to blend the right CRM implementation approach for your organisation, we very much encourage a phased approach.

We advise that you start with the very minimum you need to, and then build on all the additional functionality in phased stages after that.  This is known as implementing the ‘Minimum Viable Product’ (MVP) – “a product with just enough features to gather validated learning about the product and its continued development

In the real world of CRM implementation, the MVP means delivering the system with the only the very essential feature in the first instance.

Moscow?! 

As part of any Discovery Phase, and during the collation of user stories, we would typically conduct a priority rating using the MoSCoW system.

  • Must have – essential features for success
  • Should have – should are essential features but not necessary to be delivered as immediately – they could be delivered as a second phase
  • Could have – typically these would be features that improve user experience or user satisfaction but aren’t functionally essential. If the budget will stretch to it
  • Won’t have / Would like (but probably won’t get!) – the key stakeholders agree that these are not part of the process because they are lowest payback, not immediately essential or perhaps more appropriate for a further development stage of the system (eg in a years’ time at review).

This begins the process of ascertaining what the MVP is that could be launched at the point of go-live.

This reduces the length of the initial phase, brings users on to the system as early as possible so they can actually see it and understand it, and it ensures a low priority requirement does not eat up time and budget in the first phase.

Add integrations … 

Similarly, with system integration, it is unlikely that all systems will need to be integrated in phase 1, so the process of prioritising the ‘Must Have’ points of integration applies here also.   We therefore recommend a phased approach to bringing in the different points of integration.

The downside to this approach is that it may not be completely understood how each area will be integrated or developed from the first point of go-live.

he risk therefore is that subsequent changes, additional costs, or difficult issues come up after the point at which the system is being used live.

This risk can be mitigated through thorough discovery and business analysis across all areas, so the understanding of those areas and requirements are well understood from the outset and the project team have less chance of being faced with a surprise requirement.