In the last few posts I touched on why effective CRM requirements specification was important, and how to approach it. This week I want to wrap up this series by suggesting how this can be brought together in the final CRM requirements document.
Given that the structure of your document should be driven by its end purpose, it’s worth being clear about what it will be used for, which I believe comes down to the following:
- To facilitate agreement internally as to what you are trying to achieve and how you are planning to achieve it, ensuring a common understanding and that the initiative is adequately resourced.
As such, I suggest a simple structure as follows:
Firstly, an analysis of the current situation, the problems you are looking to solve, and a statement of the desired outcomes. This should be as specific as possible.
Secondly, a statement of the business processes necessary to achieve the objectives, and how these will be supported in the system. I tend to break these into two parts: a narrative describing each process, and a flow-chart representation which includes a statement as to who is updating what within the system in order to facilitate the process.
And finally, the supporting functional requirements. I tend to start with a detailed description of each entity (for example people, organisation, lead, opportunity, and case records) within the system. This will include a detailed breakdown of what fields will appear on each entity and any related functionality. It’s also worth adding mock up screen shots which can be quickly created using something like Microsoft Visio, as this visual depiction allows people to more easily review the document.
All integrations into other systems will be fully set out. There’s a tendency, in the CRM requirements specifications I see, towards broad-bush statements such as ‘the system will integrate into system x’ with little information about what ‘system x’ is or what information is to be integrated, in which direction, or in what form i.e. real-time, batch, or a data view. It’s virtually impossible for a prospective vendor to gauge the complexity and cost of integration unless you can provide the supporting detail. The same level of detail should also be applied to any initial data imports into the system.
Finally, I generally set out the remaining functional requirements that don’t relate directly to individual entities, under separate headings in the document. These include the often overlooked aspects of reporting, administration and security needs.
The resulting output should be a substantial and comprehensive document that should facilitate effective technology and vendor selection and drive the implementation process forward in a controlled way.
The title for this series has been ‘a more successful approach to requirement definition’, and I believe the approach I’ve outlined differs from the more traditional practices in a number of key ways:
- It places greater emphasis on the business goals
- It recognises the importance of defining the processes necessary to achieve the business goals in detail, which in turn drives out the functional needs
- It seeks to complete a complete blue-print of the system before engagement with a CRM vendor
There’s no question that this approach does increase your workload in this phase, but I believe effective requirements management is the biggest single determinant of CRM success, and the benefits of improved negotiating position, greater control of risk, time-lines, and costs, married with the ability to ultimately deliver a real game changing project, should make this a very worthwhile investment.
Greetings Richard:
I totally agree with your post and commonly see prospects not doing a very good job in completing a detailed analysis of the customer care solutions they are evaluating.
As they say: “measure twice and cut once,” and the cost of this “lumber” is quite high and can have far-reaching implications to income, expenses and long-term brand perceptions. And to complicate matters further, we all have seen how some of the most subtle and easily forgotten capabilities can make or break the technology’s eventual success. What’s more, people protecting their reputations and the costs of making a change often results in painful and costly laboring with an ill-fitted solution for several months, if not years.
An approach that we find often works well for companies is when they run the software through very specific use cases for administrators, support staff and the internal and external people using the solution. But to be effective, the scenarios must be detailed and precisely executed and evaluated.
People need to realize that: 1. “Market Leading” software may not meet your company’s unique needs; 2. Marketing material is about selling and not informing; 3. Almost all Sales people will only answer questions you ask and have a real hard time saying that it can’t do that or can’t do that well; 4.Analyst’s evaluations are from 30,000 feet (they literally often spend less than a couple hours doing the analysis) and significant conflict of interest exists with the vendors they evaluate since they generally only evaluate vendors that spend sufficient monies with their firms.
In the end, anything less than a comprehensive, detailed and hands-on analysis of needs versus software capabilities is risky at best and a dereliction of responsibilities to company stakeholders at worst.
Chuck Van Court, CEO and founder of Fuze Digital Solutions
http://www.fuze.com
Community insights are a terrible thing to waste
Thanks for the feedback Chuck. Very good point on how long people will live with the consequences. Failed CRM projects will often be kept on ‘life-support’ for years before the climate becomes right to face up to reality.
Richard Boardman
http://www.mareeba.co.uk
Three basic ways to prevent a CRM project from failing are to properly map out how your CRM will handle your business processes, have a game plan for user adoption, and provide ongoing training to your users on a regular basis. Empowered with the necessary information and tools, the whitepaper aims to assist in making the best and most-informed decision. Download it by visiting http://www.intelestream.net/en/lp-10-considerations-before-purchasing-a-CRM.html
Stafford McKay, Jr
Intelestream Inc