Sometimes it does go wrong…

I was presenting at a seminar this week and made the observation that in terms of mid-sized CRM deployments the vast majority make it through to live – albeit with varying degrees of angst and heartache along the way (and ultimate return on investment). Then I recalled that the last time I made the same observation was in a seminar almost two years to the day previously. There were two gentlemen on the front row, who I later got chatting to, who had just issued a purchase order for a reasonably substantial system. The alarm bells had rung a little because their ambitions for the system seemed significantly out of proportion to their anticipated budgets.

Roll on twenty one months and I came to be chatting to a rather dispirited CRM project manager whose tale of woe I suddenly realized related to the same project. Nearly two years after the original purchase order had been placed, no system had been delivered and vendor and client were now consulting their lawyers. It was a classic example of a mismatch of expectations, which is perfectly illustrated in Steve McConnell’s book ‘Rapid Development’ which shows a cartoon in which two men are looking at a plot of land planning a development. The client has a thought bubble emanating from his head showing a building rather reminiscent of the Taj Mahal, and the builder with a bubble depicting a considerably more modest residence. Both men are happy based on a completely different concept of the deliverables.

While outright project failures are a relative rarity these days, the more common manifestation of the expectation mismatch are project delays, budget overruns, and delivered systems that don’t actually generate much value. The cause is generally still the same, a tendency towards what might be termed ‘bullet-point’ requirements. These are high level requirements that present plenty of scope for misinterpretation. In this particular case it looks as the bullet points hid the detail of what both parties were anticipating in the way of integration between systems. The client envisaged a rather involved real-time two way integration between the CRM and several other key systems, the vendor saw this as a rather more simplistic batch upload.

I know it’s a point I tend to make ad nauseam, however effective requirement gathering and documentation is the foundation for a successful CRM project. It facilitates a number of desirable things:

It lets you select software in the light of a detailed understanding of requirements allowing you to choose the most appropriate package and avoid being committed to an option that doesn’t meet your needs. It allows you to select a vendor based on firm pricing proposals rather than guess/estimates, considerably improving the basis for comparison and the client’s negotiating position. It avoids a ‘hostage’ situation when detailed requirements are constructed post purchase of the software when it’s in the vendor’s interest to ‘grow’ the scale of the project, and the client is locked in. It reduces the risk of budget and project overruns through limiting scope creep, when ‘new’ requirements keep emerging during the implementation process

And if things go really badly it can avoid a lot of pain, recriminations, and lawyers fees as well.

ShareThis