The process of requirements gathering is an important step on the path to implementing a CRM system into the organisation. In fact, CRM consultant and blogger Richard Boardman has even suggested that it is “probably the single biggest determinant of CRM success”.
Yet despite this, many organisations still find the requirements gathering process to be an arduous and difficult task, which sadly often results in problems further down the line.
With this in mind, the following article will be exploring some all-important best practices to adhere to during this most critical of processes.
Traditionally, requirements gathering would take place fairly late in the CRM purchasing process. The typical sequence of events involves the buyer undertaking a round of vendor demos, then making a decision on a CRM solution, and only defining the CRM requirements after the purchase has been made, in order to guide the vendor.
But it is increasingly acknowledged that the better sequence is to define detailed requirements before a commitment to a specific vendor has been made.
Richard Boardman, founder of Mareeba, explains: “Firstly, understanding requirements up front means there’s less risk of selecting an inappropriate technology platform. Secondly, it also makes procurement more efficient because detailed requirements allow vendors to provide firm pricing up front in a competitive environment which generally means you can purchase more cost-effectively. If you don’t have requirements well defined you’re often committed to the vendor before the true costs are known which is a situation vendors can easily manipulate. Thirdly, it makes for a quicker implementation, with much less risk of scope creep where new requirements arise part way through the project.”
Ardron adds: "The most effective time to define detailed CRM requirements is before committing to a specific CRM vendor, but after going through the round of vendor demos. Produce the brief any earlier and the business decision maker runs the risk of focussing on just a small fraction of what could potentially be on offer, while too late and they miss gaining the consultative expertise from multiple sources.”
Other benefits of conducting the requirements gathering earlier in the process include helping to secure the funding, resources and buy-in necessary to succeed, by demonstrating upfront how it will benefit the organisation, and improving user adoption because they understand why they are required to use it and how it benefits them.
Appointing responsibility
Organisations also have to consider who is going to take responsibility for the requirements gathering process, and whether this will be a single individual or a project team.
“Most organisations leave it solely to the sales or marketing director, but that’s a mistake as it could result in silos of business information rather than fully integrated processes,” warns Andrew Ardron, managing director, at ProspectSoft. “For a CRM system to work well, it has to integrate into and benefit all areas of the business, and so each division should be represented when it comes to compiling CRM requirements.”
David Curtis, one of the senior members of the CRM team at DMC Software, agrees. He adds: “For CRM success it is important to establish a project team, with each area of the business represented. Not only will this enable you to capture a full list of requirements it will ensure you have project champions across the business. CRM adoption is one of the main reasons implementations fail, by involving everyone from the start it is more likely the value will be realised and the solution adopted.”
“It is generally best to give the entire organisation a voice, so involve key stakeholders in different departments. We would recommend a mix of leadership stakeholders and operational stakeholders,” says John Cheney, CEO of Workbooks. “Then someone should consolidate that into a single list - we don't need "outlook integration' listed for each department.”
What requirements?
When it comes to detailing CRM requirements, there are a number of do’s and don’ts to bear in mind.
A common mistake is to get bogged down in feature requirements, at the detriment of everything else.
“The danger of just producing a list of requirements is that parts of it risk becoming siloed and disjointed,” says Tom Nickalls, product manager at Jadu Continuum CXM. “There’s also the risk of missing more efficient and productive ways of doing things by bolting things on, instead of addressing the fundamental approach.”
The danger of just producing a list of requirements is that parts of it risk becoming siloed and disjointed.
Cheney adds: “In reality, most CRM vendors have similar features, so making an investment decision based purely on features and functions is a high risk strategy. It's like buying a car for the first time - you first need someone to teach you how to drive. You may buy a car because it has Air-con and a great sound system, but if you can't drive, it is a waste of money. The features become irrelevant. You have made a big investment for it to sit on your driveway.”
So what should be factored into your plans when building the detailed requirements list?
Business challenges
“Identify the business challenges you want to address by implementing a new CRM solution,” recommends Curtis. "If you start with features, you are prescribing the solution which may not be the most effective resolution. Once you have a list of challenges, the vendors you speak to will be able to recommend the best solution for your needs and budget.”
Business objectives
“The main consideration for an organisation should be its business objectives,” says Ardron. “Take a list of these to three or four different CRM vendors instead and three or four proposals will be returned that specifically set out to meet each one. For example, it could be that the business must grow turnover by 50% without substantially increasing sales overheads. The question should then be posed - how are you, as a vendor, going to help me increase my sales by 50%? Organisations should be challenging potential vendors to answer this type of question as a result, they’ll receive the expertise of the vendor in providing the right solution to business-specific issues and objectives.”
Processes
“The focus should be on the process,” advises Boardman. “What processes are we looking to embed and how should they be supported by the system? When you do this, the feature requirements tend to drop out pretty easily. Listing features without clarity on what you’re looking to achieve with the system and how you’re going to achieve it is pretty pointless.”
Functional requirements
Boardman notes: “I think people tend to overlook the ‘behind the scenes’ stuff such as the administration and development capabilities. Integration and data migration requirements are also commonly poorly defined or thought through.”
Boardman has detailed a variety of items that are routinely forgotten about during the requirements listing process, but that could be important:
- Customisation capabilities - most systems will require at least some tailoring in order to meet an organisation’s specific needs.
- Compatibility with existing infrastructure – if there are standards you need a vendor to adhere to, it is vital that these are noted up front.
- Different views for different users – could be useful if you have users accessing the system for a wide range of reasons.
- UAT and training versions – when you are testing changes to your CRM or training users, you ideally don’t want to be doing it on your main live system because of the potential to damage data and functionality.
- Security –CRM projects can grind to a halt if the client’s security requirements don’t fit with the selected CRM’s out-of-the-box capabilities.
- De-duplication – data quality is crucial, so the ability to identify duplicates, both when a record is being entered, as well by scanning the system to find potential matches, is important. As is the means to merge identified duplicates.
- Offline access – despite the ubiquity of internet access, there are situations where you may need users to be able to operate offline.
- Language and currency – if an organisation has international operations, the ability to support local character sets, translate field names and pick lists, and track and report on transactions in different currencies, may well be key requirements.
Implementation
Cheney advises: “Make sure your requirements include how the implementation will be handled and how the vendor will support you, not only in the first phase of deployment but in two years’ time, when your business is growing and you need ongoing support/guidance to get the most from your system.
“Review what you want to undertake yourselves (if anything) and where you need help and clearly define that as part of your requirements. Consider what resources and budget will be required to support the implementation and ensure it meets your needs. Do you need help with the project design and implementation? To what extent? How will you migrate data from your legacy system(s)?
“You need to understand how much focus and support you are likely to get from your CRM provider. Ask yourself which partner will best accompany you on your CRM journey and help you the most in transforming your business. Make your selection based on technology, processes and people as all of these will impact your ROI.”
Education
“Another requirement relates to support, education and ease of use,” adds Daryn Mason, senior director, CX applications at Oracle. “Company culture can be an obstacle to successful roll-outs, so organisations should ensure their chosen partner is there to help drive understanding across the business and help communicate the benefits of the technology and the immediate improvements it will bring to people’s roles. Company culture can eat strategy for breakfast and unless a business has a culture where everyone is engaged and feels part of the transformation taking place, investments may not deliver the changes a business wants to see.”
Presenting the requirements
A final point to consider is how you will present the information once it has been gathered. While there is no perfect way of presenting a requirements document, because it will vary from organisation to organisation, there are some tips to consider.
“It’s a good idea to present the document in a similar way to a college or university application. Instead of one long, continuous body of text, the document should be divided into clear, logical sections focusing on areas such as features, functionality, goals, and execution,” advises Mike Restivo, chief revenue officer at Bullhorn.
A lot of organisations are unaware of appropriate formats and structure for their requirements documents.
“The document should also contain a mixture of quantitative and qualitative information. In a section on features, you may find it more effective use rating scales or checklists, while in a section on execution, you may use prose in the form of case studies, for example.
“A lot of organisations are unaware of appropriate formats and structure for their requirements documents, mainly because they don’t need to produce them very often. In these circumstances, it can be a good idea to ask vendors to provide examples of requests for proposals (RFPs) to be used as a guideline. This is a great way to determine which vendors are more mature – not to mention a great way to get the conversation started between the buyer and vendor.”
In his ebook on building requirements gathering documents (which can be downloaded here), Boardman recommends that organisations adhere to the following structure:
- Business objectives.
- Supporting processes – ‘as is’ and ‘to be’ and how they will be supported by the system.
- Entity model of system record types and how they relate to each other.
- Functional requirements.
- Data migration and integration requirements.
- Reporting requirements.
Additionally, David Curtis advises that organisations should include supporting documentation that provides:
- A workflow diagram for each department.
- An organisation chart.
- Example reports/templates.
- Existing architecture/systems.
