Dears,
The title looks little Bizarre, Isn’t. Well I can tell you that the most critical stage of any crm project is requirement gathering stage. If you mess up with that and for sure you will get to know soon what’s in store for you in the near future.
The conventional wisdom has it that that CRM requirements gathering consists of assimilating lists of functional requirements and then prioritizing and ranking them. On the surface this all seems very logical, but in practical terms it doesn’t work. Since this is the approach that most organizations take, I thought I’d take a few posts to explain why this approach is fundamentally flawed, and to outline a significantly better alternative. Before I get too far into solutions I’d like to use 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. Mr.Sandy , Snr Manager in Group IT is given the task of visiting users to discuss what they might require from the system. Over the course of a few weeks Sandy’s builds up a surprisingly short list of functional needs. Unfortunately most of the interviewees have not used CRM technology previously, and aren’t able to provide much in the way of feedback. Sandy conducts some research on the internet and finds half a dozen potential CRM suppliers and invites them to review the requirements and provide a pricing proposal based on their offerings.
The proposals that are received all seem to meet the published requirements, but come in at a wide range of price points. MERRYGO invites three of the vendors to come and demonstrate their products 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 and ticks all the boxes on the required list of functionality. The order is placed and the implementation begins.
The chosen vendor embarks on some initial scoping work. After a few weeks the vendor reports back that the requirement is actually significantly more involved than they had understood from the requirements. MERRYGO are far from happy with the extra costs, and consider their options carefully, but conclude as they’ve already paid for the software and the initial scoping, they don’t have much choice but to carry on.
A month or two passes, and it becomes clear that things aren’t going to fall apart. Several new requirements have arisen as staff become exposed to the technology and start to realize the potential of it. There’s also a problem with the security functionality on the selected product. The security requirements were not defined in the original specification list, and it’s clear the out of the box functionality exposes MERRYGO to too much risk. To bypass this MERRYGO have to authorize custom development work to add new security capabilities.
The implementation work being undertaken by the vendor is now way outside the original proposal figure and the project appears out of control. The MERRYGO Managing Director, now somewhat alarmed at the spiraling costs, finds herself increasingly involved in the project and has a series 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 vendor mitigates the risk of having to perform substantial free of charge work, by ‘dumbing-down’ the requirement, so that, while broadly meeting the specification, many of the functions require more mouse 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 order to try and get things back on track she orders the project team to cut back the user acceptance testing phase, and begin user training. Unfortunately, in a bid to reduce costs, the CRM vendor has also cut back on its in-house testing programme. There are a consequently a lot of bugs in the system 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 new system. It’s several months before all the bugs are ironed out, and by the time the system goes properly live most users have long forgotten the original training. Six months on, few people are using the system, and it’s unclear what value the system has added. The company asks Sandy to leave, 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’, the story is based on real world events that I see played out every day. Most CRM projects suffer some or all of the issues highlighted in my fictional (?) story. Much of the fault lies is in the functionality led approach to requirements gathering.
The ‘big’ point in terms of this post is that you need to be clear about what problems you are trying to 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 business goals. 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. It needs to be used in a coordinated way to produce results, and there are many and varied ways in which CRM technology may benefit your business. Secondly, without a clear objective to guide your project from the outset it’s unlikely it will essentially generate value. Thirdly, unless you can convey the benefits of the project in a compelling way it’s unlikely you will secure the necessary financial investment or, perhaps more importantly, the necessary injection of internal attention and resources required for success.
In terms of starting to define the desirable outcomes for the project, it’s worth noting that there are two 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 better supporting technology. For example, you might have excellent processes in terms of how you attract, develop and retain customers, but these may be supported through a range of Excel spreadsheets, standalone systems and databases. CRM technology might create new efficiencies by replacing disparate silos of information, with a central system which allows customer information to be better shared and more beneficially used. In this case your underlying business processes may be adapted to CRM technology, but they are not fundamentally changed.
Process development – where the business processes themselves are re-engineered, or entirely new processes are created. For example, you might adopt a different strategy in terms of how you manage sales leads, or streamline the order management process, or change the way you handle customer issues and complaints. In this case existing processes may change radically, and CRM technology plays a key role in their successful adoption by the business.
In practice most CRM implementations tend to focus on process automation. While process automation projects can produce a high pay-back, in general the greater returns on investment are achieved through the process development approach – looking to improve and add to existing processes and use CRM technology as the means to support those changes.
In practice most CRM implementations tend to focus on process automation. While process automation projects can produce a high pay-back, in general the greater returns on investment are achieved through the process development approach – looking to improve and add to existing processes 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 and document how business processes are currently performed and how they are currently supported by technology. By reviewing these in context of how they might operate when supported by CRM technology you should be able to flush out potential efficiencies and benefits. This does require a working knowledge of CRM technology that you may not currently have. However, as many CRM technologies are available to evaluate free of charge, and that the general concepts and capabilities of different products are similar, it is not an unduly time-consuming task to gain the necessary knowledge by reviewing some of the mainstream packages.
As I touched on earlier though, the greater rewards generally spring from improving the processes themselves. The act of documenting existing business processes often produces a few surprises in terms of how things are actually done as opposed to how it was believed they were done, which may in turn move a project away from process automation to process development. It should be noted though that improving existing processes and adding new best practices is a more challenging and time consuming activity than simply automating what you do already. There’s no single way to go about 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 the knowledge of domain experts.
The output from these exercises should be some clear statements regarding the beneficial outcomes. For example: ‘By streamlining and automating the order process, we expect to reduce the time to fulfil orders by two weeks, and reduce the cost of processing them by 40%.’Once you are clear on the objectives, it’s normally worth undertaking an initial assessment of project feasibility before going too much further. By matching the identified beneficial outcomes of the project with an estimate of costs, you should be able to assess whether the investment makes commercial sense of not. Assuming it does, then it’s time to move to the next stage in the requirements definition process which I will cover in my future post.
DC*
No comments:
Post a Comment