The following is the first in a sequence of posts entitled ‘What a CRM Consultant would tell you about buying CRM software’. My plan is to highlight key aspects of an effective purchase strategy for CRM, and, when the series is complete, I’ll try and edit it into a hopefully coherent single article for download. The first area I’m focusing on is the need to define requirements clearly before proceeding too far down the purchase process.
There’s a doomsday scenario that I see replicated time and time again when organizations purchase CRM software, and it goes something like this: Someone somewhere in the organization determines that a CRM system would be a good idea. Usually someone else gets delegated the task of gathering requirements for said system. They dutifully tour the business asking what potential users feel they need. The potential users are able to outline their broad requirements, but, not having used CRM technology before, struggle to articulate their needs in detail.
The resulting two page requirements document is circulated to a range of CRM vendors as part of a request for proposal. The requirements, not being terribly demanding, seem to be fully met by every vendor response, though at wildly different price points. The organization tries to fathom why vendor pricing estimates range from £10,000 to £1 million, for software that appears to perform the same task. In order to investigate further, a short list is drawn up and the preferred vendors are invited to demonstrate their wares. A selection committee is established, and the vendors drop by to present their offerings. In the absence of any detailed criteria by which to compare offerings the vendor who put together the slickest sales presentation is deemed to be the winning bid.
As a result an order is placed for the software and services, and the vendor begins a detailed scoping exercise in order to clarify the initially sketchy requirements. The output of which indicates that the work required to complete the project is considerably higher than were first estimated. Already committed to the project, the organization has no choice but to go back to the board to secure further funding. As the project progresses the users see the software for the first time and start to identify further ‘must have’ requirements. It also becomes apparent that a couple of key pieces of functionality which weren’t picked up in the original requirements gathering will require extensive customization to deliver. The project is now very over budget and running considerably late.
To try and make up time, the project team decides to fast-track the user acceptance testing and cut back on initial training. Due to the lack of testing, and exacerbated by the amount of customization work required, the early iterations of the application are heavily bug-ridden, and it takes the project team several months to sort them out. By now the users have lost interest in the software, and can’t remember the brief training they had anyway, so user adoption is negligible. At this point, either the recriminations begin, or more commonly the system is left to tick away quietly in a corner, where, while it doesn’t actually contribute to the business, neither is it deemed a complete failure, should the board inconveniently enquire how their investment in CRM is coming along.
So the first piece of advice a CRM consultant would give you would be to document your CRM requirements in considerable detail before you even think about going out to tender. This should cover a number of key areas: 1) The objectives for the project, in other words what benefits you wish the CRM system to deliver for the organization. 2) The identification of the key supporting business processes that will drive achievement of the objectives. 3) The detailed data and functional requirements necessary to drive the defined business processes.
Done properly the will result in a not insubstantial document. While this means a reasonable amount of work up front, the document provides the foundation for a successful project and facilitates the following:
· The ability to compare different software options based on a clear and detailed understanding of your specific requirements, avoiding the ‘when you don’t know where you are going, any road leads there’ syndrome that many organizations find themselves in.
· An unambiguous basis on which to solicit firm pricing proposals, facilitating more effective vendor comparison, and avoiding the potential for vendors to provide low-ball estimates, which can later be upwardly revised when you are committed to the project.
· A limitation of the potential for implementation ‘scope creep’ as new requirements impact costs and delivery times.
· A reduction in implementation costs by removing the requirement for extensive vendor requirements gathering work.
The second aspect of an effective vendor selection process, will be published in a forthcoming post…
