Blog article

1. Why Sandy got fired? The Real CRM Story
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. Sandy in 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

2. ‘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.

3. 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 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.