Why Sandy got fired? The Real CRM StoryDears,The title looks little Bizarre, Isn’t. Well I can tell you that the most critical stage of any crm project isrequirement gathering stage. If you mess up with that and for sure you will get to know soon what’sin store for you in the near future.The conventional wisdom has it that that CRM requirements gathering consists of assimilating listsof functional requirements and then prioritizing and ranking them. On the surface this all seemsvery logical, but in practical terms it doesn’t work. Since this is the approach that mostorganizations take, I thought I’d take a few posts to explain why this approach is fundamentallyflawed, and to outline a significantly better alternative. Before I get too far into solutions I’d like touse this post to illustrate the sorts of things that happen when people adopt the ‘functionality first’approach and it goes something like this:MERRYGO Widgets Ltd decides a CRM system is a very good idea. Sandy in IT is given the task ofvisiting users to discuss what they might require from the system. Over the course of a few weeksSandy’s builds up a surprisingly short list of functional needs. Unfortunately most of theinterviewees have not used CRM technology previously, and aren’t able to provide much in the wayof feedback. Sandy conducts some research on the internet and finds half a dozen potential CRMsuppliers and invites them to review the requirements and provide a pricing proposal based ontheir offerings.The proposals that are received all seem to meet the published requirements, but come in at a widerange of price points. MERRYGO invites three of the vendors to come and demonstrate theirproducts to the project team. One of the vendors stands out; the salesperson is smartly dressed,professional, and the team really take a shine to her. Their proposal is also one of the cheapest andticks all the boxes on the required list of functionality. The order is placed and the implementationbegins.The chosen vendor embarks on some initial scoping work. After a few weeks the vendor reportsback that the requirement is actually significantly more involved than they had understood fromthe requirements. MERRYGO are far from happy with the extra costs, and consider their optionscarefully, but conclude as they’ve already paid for the software and the initial scoping, they don’thave much choice but to carry on.A month or two passes, and it becomes clear that things aren’t going to fall apart. Several newrequirements have arisen as staff become exposed to the technology and start to realize thepotential of it. There’s also a problem with the security functionality on the selected product. Thesecurity requirements were not defined in the original specification list, and it’s clear the out of thebox functionality exposes MERRYGO to too much risk. To bypass this MERRYGO have to authorizecustom development work to add new security capabilities.The implementation work being undertaken by the vendor is now way outside the originalproposal figure and the project appears out of control. The MERRYGO Managing Director, nowsomewhat alarmed at the spiraling costs, finds herself increasingly involved in the project and has aseries of crisis calls with the MD of the CRM vendor. Under the threat of the technology being
‘thrown out’ the CRM vendor agrees to cap the price of further development work. The CRM vendormitigates the risk of having to perform substantial free of charge work, by ‘dumbing-down’ therequirement, so that, while broadly meeting the specification, many of the functions require moremouse clicks than was originally envisaged, and are far from intuitive.The project is now very late. The MD had promised the system would be live months ago. In orderto try and get things back on track she orders the project team to cut back the user acceptancetesting phase, and begin user training. Unfortunately, in a bid to reduce costs, the CRM vendor hasalso cut back on its in-house testing programme. There are a consequently a lot of bugs in thesystem and these are not even close to being resolved when user training begins.The users exposed to a system that plainly isn’t working immediately lose interest in the newsystem. It’s several months before all the bugs are ironed out, and by the time the system goesproperly live most users have long forgotten the original training. Six months on, few people areusing the system, and it’s unclear what value the system has added. The company asks Sandy toleave, and the MD is having huge difficulty getting the board to sanction a major investment in e-commerce technology that the company desperately needs to remain competitive. The ‘failed’project has plainly damaged staff morale and there has been higher staff turnover than normal,including a couple of the company’s star salespeople……Anyway you get the picture. While this may all seem like a rather far fetched ‘perfect storm’, thestory is based on real world events that I see played out every day. Most CRM projects suffer someor all of the issues highlighted in my fictional (?) story. Much of the fault lies is in the functionalityled approach to requirements gathering.The ‘big’ point in terms of this post is that you need to be clear about what problems you are tryingto solve or what compelling outcomes you are looking to achieve. This may sound fairly obvious,but I see a lot of CRM requirements documents, and very few of them have clearly stated businessgoals. There are three reasons why I think being explicit about your outcomes is important. Firstly,it acknowledges that you understand that technology is a tool. It won’t produce value on its own. Itneeds to be used in a coordinated way to produce results, and there are many and varied ways inwhich CRM technology may benefit your business. Secondly, without a clear objective to guide yourproject from the outset it’s unlikely it will essentially generate value. Thirdly, unless you can conveythe benefits of the project in a compelling way it’s unlikely you will secure the necessary financialinvestment or, perhaps more importantly, the necessary injection of internal attention andresources required for success.In terms of starting to define the desirable outcomes for the project, it’s worth noting that there aretwo broad ways that CRM technology may improve the operation of your business:Process automation – where you take what you do currently and improve things through bettersupporting technology. For example, you might have excellent processes in terms of how youattract, develop and retain customers, but these may be supported through a range of Excelspreadsheets, standalone systems and databases. CRM technology might create new efficiencies byreplacing disparate silos of information, with a central system which allows customer informationto be better shared and more beneficially used. In this case your underlying business processes maybe adapted to CRM technology, but they are not fundamentally changed.
Process development – where the business processes themselves are re-engineered, or entirelynew processes are created. For example, you might adopt a different strategy in terms of how youmanage sales leads, or streamline the order management process, or change the way you handlecustomer issues and complaints. In this case existing processes may change radically, and CRMtechnology plays a key role in their successful adoption by the business.In practice most CRM implementations tend to focus on process automation. While processautomation projects can produce a high pay-back, in general the greater returns on investment areachieved through the process development approach – looking to improve and add to existingprocesses and use CRM technology as the means to support those changes.In terms of finding process automation benefits, a sensible starting point is to analyse anddocument how business processes are currently performed and how they are currently supportedby technology. By reviewing these in context of how they might operate when supported by CRMtechnology you should be able to flush out potential efficiencies and benefits. This does require aworking knowledge of CRM technology that you may not currently have. However, as many CRMtechnologies are available to evaluate free of charge, and that the general concepts and capabilitiesof different products are similar, it is not an unduly time-consuming task to gain the necessaryknowledge by reviewing some of the mainstream packages.As I touched on earlier though, the greater rewards generally spring from improving the processesthemselves. The act of documenting existing business processes often produces a few surprises interms of how things are actually done as opposed to how it was believed they were done, which mayin turn move a project away from process automation to process development. It should be notedthough that improving existing processes and adding new best practices is a more challenging andtime consuming activity than simply automating what you do already. There’s no single way to goabout doing this, and can be a product of internal brainstorming, consulting with your customers,researching how top-performing companies perform the same processes, and accessing theknowledge of domain experts.The output from these exercises should be some clear statements regarding the beneficialoutcomes. For example: ‘By streamlining and automating the order process, we expect to reducethe time to fulfil orders by two weeks, and reduce the cost of processing them by 40%.’Once you areclear on the objectives, it’s normally worth undertaking an initial assessment of project feasibilitybefore going too much further. By matching the identified beneficial outcomes of the project withan estimate of costs, you should be able to assess whether the investment makes commercial senseof not. Assuming it does, then it’s time to move to the next stage in the requirements definitionprocess which I will cover in my future post.