The process of purchasing and implementing a CRM system can be tricky at the best of times. But you can start off on the wrong foot if you fall foul of some of the mistakes commonly made during the requirements gathering process.
The process of requirements gathering is all-important, as it enables your organisation to be clear about what it is you want to achieve with a CRM system (such as the business problems you need it to solve and the processes it needs to support) and the support you require from a vendor (such as data integration/migration, and training and education on the system).
Yet organisations frequently find it to be an uphill struggle and fraught with challenges. With this in mind, let’s take a look at some of the most common mistakes that businesses make when conducting requirements gathering to ensure that you can avoid these perilous pitfalls.
1. Treating it like a shopping list
“I think there’s a tendency to think that requirements gathering is just asking people what they want and listing out all the resulting features,” says Richard Boardman, founder of Mareeba. “They miss that it’s a much more involved and analytical exercise than that. What tends to end up being written is a bulletpoint list of functional needs, but nothing that describes what the system is going to do for them or allows potential implementers to properly estimate how much work is involved. This can result in organisations spending a lot of money on expensive systems that don’t actually generate a great deal of operational value.”
2. Focusing purely on feature requirements
“The most common mistake is talking about features, not business outcomes,” says John Cheney, CEO of Workbooks. “If we understand that it is key to improve your customer services, because you are losing clients and it is impacting revenues we can help you more quickly and efficiently. Tell us the 'Why' and we can help you deliver the 'How'.”
“Often they are just viewed as solutions providers, but actually in most cases they are able to offer valuable business counsel,” adds Daryn Mason, senior director, CX applications at Oracle. “A big mistake is not considering how vendors can help tackle the cultural and organisational changes required for digital transformation.”
Content seriesView full content series
3. Going into too much detail
“The documents with the most shortcomings are often the ones with the most detail; because if they’re focusing on the detail, the chances are they have missed the point of producing the document in the first place,” says Andrew Ardron, managing director of ProspectSoft.
“The best documents are concise and make vendors work hard to understand the business and produce detailed proposals that provide solutions to the business’s issues. After this, organisations can work collaboratively with a vendor to produce a more detailed requirements document before committing to purchasing a system.”
4. Being over-prescriptive
“Writing requirements that are overly prescriptive in terms of how they should be achieved is a big mistake,” says Tom Nickalls, product manager at Jadu Continuum CXM. “These requirements might be achievable in a different, better way by the vendor but on paper the vendor cannot say ‘yes’ to the requirement in front of them.
“It’s better to understand the key elements: does the solution meet the essential requirements? Have I followed up references that I choose (and not the vendor)? Is the vendor a good cultural fit? Can I maintain and afford the solution in the long term?”
“Requirements should be specific, but customers should be open to the many ways in which those requirements could be met,” adds Mason. “They shouldn’t close doors to potential solutions by getting ahead of themselves in how their requirements should be met.”
5. Failing to tie requirements back to your broader strategy
“The biggest mistake is not aligning requirements with strategic business goals,” warns Mike Restivo, chief revenue officer at Bullhorn. “Purchasing a CRM isn’t necessarily a straightforward process: it can fail simply because you haven’t defined your top-level strategy.”