How to document requirements for a CRM system – part 1

November 10, 2014May 30, 2015 Richard Boardman

As an independent CRM consultant I get to read a lot of CRM requirements documents, and it seems to be an area that most would-be buyers of CRM technology struggle with – probably because there’s little guidance out there about how to approach the exercise successfully.

This would be less of an issue if this was an inconsequential piece of project documentation, but, based on my twenty years in the industry, I’d say it’s, not one of, but the main determinant of CRM success or failure.

In other words, get the specification right and everything becomes a lot easier downstream, but, rush it, or mess it up, and you can be living with the consequences for a very long time.

So what are the main issues? The following are some of the common ones:

There’s not enough detail to select a technology – the functional requirements are too high level, and the buyer is faced with a mass of software options, at vastly different price points, which all seem to meet the requirements. This not only makes the vendor selection process rather fraught, but heightens the risk of selecting and wasting time and money on an inappropriate technology.

Vendors can’t provide reliable guidance on pricing – there’s insufficient detail for a prospective vendor to be able to accurately quote for software and services. This means that organisations have to make purchase decisions based on vendor estimates. These estimates are often only firmed up once the project has started, and may prove to be wildly different from the initial projections, at a time when your negotiating leverage is relatively limited because you’re already committed to some degree along a given path.

I’ve seen would-be purchasers spend months, and in some cases years, undertaking paid for ‘discovery’ exercises with vendors, involving considerable amounts of internal staff time, only to pull out and start the process again when the final costs become apparent.

Asking for something that doesn’t exist – where the stated requirements are – or at least appear – so out of context of what’s available in the market that prospective vendors simply walk away. I’ve seen businesses go out to tender for CRM systems, but get not responses at all, because the vendors didn’t feel they could offer a solution (even though in some cases they had a perfectly valid offering).

Asking for something that doesn’t exist at a price point they are willing to pay – this is a variation on the preceding point, but where the requirements are achievable, just at a price that’s way outside the buyer’s budget.

This can be because buyers of CRM technology aren’t always fully aware of what’s easy or hard to implement, but can also be the result of the use of MoSCoW- style approaches to requirements definition, where requirements are graded (Must, Should, Could, and Won’t in the MoSCoW case). The result can end up as a wall of ‘Musts’, and the odd, token ‘Should’ or ‘Could’, as the various departments and groups involved try and represent their interests as strongly as possible, without necessarily reflecting the operational priorities of the organisation as a whole.

Scope creep – this is where project delays and cost overruns are incurred when additional requirements or complexity is uncovered during the implementation phase, as a result of requirements not being fully or accurately specified up front. This can force the implementation team to seek additional budgets, dumb-down requirements, or take short-cuts that jeopardise the success of the project.

That’s some of the problems that can arise, next time out I will start to set out an approach that we’ve refined over the last ten years, which will help avoid them.

Part 2 can be found here.

Footnote – this series of posts is available as an ebook which can be downloaded from here.