How to document requirements for a CRM system – part 6

January 4, 2015May 30, 2015 Richard Boardman

In a previous post in this series I set out my thoughts on the content and structure of a CRM requirements specification. In this post I want to cover how to go about gathering them.

The starting point, if you’re not reasonably familiar with CRM technology, is to do some initial research. It’s very difficult to develop a set of requirements if you’re not comfortable with what CRM software is and does.

Fortunately lack of knowledge or experience is not an insurmountable obstacle. Most software vendors offer free trials, and getting hands-on with a package is a great way to explore its potential. It’s also worth asking a range of vendors to demonstrate their offerings as a way of showcasing what’s available. Shows and events can be another way to get up to speed with the market, and looking at how other organisations, particularly those in a similar field, use CRM software can be very insightful.

I add one brief note of caution though, and that’s to remember this is a preparation phase, and to avoid getting rushed into a software purchase before the requirements are fully defined, no matter how attractive the offer or persuasive the pitch.

Having now acquired a decent working knowledge of CRM software the next step is to work out how it can be applied to your organisation. People are frequently surprised how broadly CRM technology can be used, and there are often very powerful applications outside the traditional domains of sales and marketing. So the starting point is to work out which areas of the business might potentially benefit. It’s generally worth casting the net fairly wide at this stage and then focusing in on the more attractive areas in due course.

With a broad scope defined, the next step is to perform some initial business analysis. Talk to each area of the organisation and identify the business processes that each manage. For a sales team this might include contact management, sales pipeline management, quoting, forecasting, and managing orders. Look at how each is process is currently performed and how it’s supported by technology, and start to identify areas of ‘friction’ – where the process isn’t working as well as it could.

For example, a review of the lead management process might reveal that incoming leads are recorded into an Excel spreadsheet, then assigned to individual sales people. The marketing team consequently have no means of easily tracking whether a lead has been followed up and if it resulted in a sale. This means that marketing are unclear which of the campaigns it runs generates business and which don’t, and can’t allocate it’s budgets to maximum effect, and there’s a concern that lead conversion rates are lower than they should be because there’s no system to manage longer term leads.

While it’s important to note any requirements that users highlight during this analysis stage, the main aim is to understand the processes and related issues.

Once a full set of ‘as is’ business processes has been created, and the associated friction documented, decisions will need to be made on which areas will be supported by the new system, at least in the shorter-term. Priority will generally be based on addressing the issues that are impacting the organisation most, and where an investment in technology is going to yield the greatest returns.

Having determined what the system will support, the next step is to develop the ‘to be’ processes. This will generally be a case of reframing how the existing business processes will operate in the new environment so that they deliver the desired benefits.

However, in some cases, the process itself may require more significant reengineering. For example, going back to our lead management example earlier, it may be viewed that the whole process of allocating and tracking leads needs to be revisited to avoid the potential pitfall of automating an already flawed process.

In addition, the introduction of a new system may well require processes that weren’t needed previously, for example to help maintain data quality. In both these cases the necessary steps will need to be taken to develop these processes before the requirements can be finalised.

Once complete, consideration will need to be given as to how they will work within a new CRM platform. This will build on the knowledge picked up in the initial research stage. I tend to do this by writing both a narrative to describe each major process and how the new system will support it, but I also create process maps which contain a commentary about what’s being updated in the system for each step. This is illustrated below:

This may sound time-consuming, but it’s worth undertaking because it helps flush out functional requirements that may not otherwise have come to light. For example, in a recent project, when we mapped out the ‘to be’ processes, it became apparent that a third party service provider would be entering data directly into the system, which threw up a whole range of new security requirements that previously hadn’t been identified.

Documenting processes in both story form as well as graphically tends to be very effective in helping users identify whether you’ve understood and modelled their processes accurately, and, as a result, this phase tends to be fairly iterative.

Even if you’re not confident enough with CRM technology to fully define how the processes will be supported by the new software, just getting the processes documented is a huge step forward in its own right, as this will allow prospective suppliers to much more accurately assess implementation costs.

The next step is to work out what information you wish to capture in the system. This will be driven by the ‘to be’ processes you’ve already mapped out. I tend to draw out the different record types and how they relate to one another, and then record the fields that will be required for each one, per the diagrams below:

With the first cut of the data capture complete, the data integration and migration requirements for the system should be finalised. As these can have a significant impact on the complexity and cost of the project, it’s important these are defined in detail. This will involve working closely with the staff members who know these sources best. Not only should each source be catalogued, but it’s useful to record at field level what data will populate the CRM system, or, in the case of integration, pass from CRM to other systems.

The same attention to detail should also be applied to determining the reporting requirements, because, as with data migration and integration, these will help validate whether the data capture needs have been correctly defined. You can’t report on data that you aren’t recording, so creating detailed mock ups of the reports you expect to run from the system can be very helpful.

Finally, work through the supporting functional requirements. To a large extent these will flow from the ‘to be’ processes, so in our previous example of the lead management process, a key requirement might be to automatically email the salesperson when a new lead has been assigned to them.

Defining more generic requirements, for example around security or administrative needs can be more demanding if you’re not familiar with CRM software, which is one of the reasons that the first research step is so important. I will provide a check-list of areas for consideration in a later post, which may be helpful in this respect.

Once the requirements are documented, it’s important that these are fully reviewed by the user community before you move on to procuring software. This is likely to be an iterative process, but it’s critical that the requirements are understood and accepted before you proceed too far, in order to limit the potential for scope creep, where ‘new’ requirements extend the implementation phase.

Anyway, that largely concludes this series about how to go about CRM requirements gathering. As I mentioned earlier, in a forthcoming post I will wrap things up with a check-list of areas to consider when defining functional requirements. In the meantime, if you have any questions about what’s been covered, please feel very free to comment or make contact.

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