How to document requirements for a CRM system – part 3

November 23, 2014May 30, 2015 Richard Boardman

I promised in last week’s post that this week I’d set out my views on what should be included in a CRM requirements specification. However, I’m going to put that on hold for a week. I realised there were some points that merit some articulation first. So, to help set the scene, here are a few things we hold to be true that shape our approach:

CRM software does nothing on its own – you don’t buy or sign up for a CRM application and it somehow miraculously transforms your business. CRM is a tool kit. Decisions have to be made as to what you are looking to improve and the system set up to achieve that objective. A lot of organisations get wrapped up in deciding what functionality they need, but give little thought as to how they’re going to beneficially use it.

People will not just tell you their requirements – this is where a lot of people get into trouble. They see requirements specification as simply about interviewing staff and taking notes. They expect them to be able to fully articulate what they need from a CRM system. In reality this rarely works. For a number of reasons:

Firstly, their knowledge of CRM technology may not be up to the job. They may never have used CRM software before, or their views may be rooted in an application they used many years previously. Their input can often be backward looking and may take little account of what’s possible with the latest technologies. Secondly, because users are often only able to describe a narrow set of needs directly related to their role, they generally miss the bigger picture. For example, I can’t remember that last time a user was able to describe key administration and security requirements. The point isn’t that staff input isn’t valuable – it’s essential – but it’s generally insufficient on its own to create a useful set of CRM requirements.

This isn’t something you an leave to the vendor – so the line of thinking sometimes goes: all I need to do is select a technology and then the CRM vendor or implementation partner will help me work out how to get value from it. While there’s a certain logic to this approach, there are also a few potential gotchas, given that selecting a technology first may leave you with a product that doesn’t meet your needs when the full requirements become apparent, and that being committed along a certain path undermines your negotiating position – a situation that some suppliers are only too happy to exploit.

However the biggest issue is that, as a rule of thumb (and I acknowledge there are exceptions), vendors/implementation partner just aren’t very good at working out how to apply CRM technology beneficially. This is slightly counter-intuitive, and you may simply have to take my word for it, but while they (generally) know the technology inside out, the – rather important – bit that trips them up, is working out how to apply it in a way that benefits the client.

So to wrap up, the nub of the preceding section is:

• Spelling out how you are going to beneficially use the technology is at least as important as working out the functional requirements

• Requirements definition is much more involved than simply asking the question ‘what do you need?’

• This is not a stage you can easily skip and expect your selected supplier that doesn’t really understand your business to do in your place

Anyway that concludes things for this week, next time out I’ll outline my thoughts on the content of a specification.

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