Which in turn...

As someone very sagely noted in a meeting last week - while the initial stages of a CRM implementation pick off the low hanging fruit, the real benefits accumulate over time. To illustrate the point I’ll tell a rambling and probably not very grammatical tale of one of our older clients:

Our initial involvement was to help them implement a CRM system that delivered better customer service metrics, which in turn the client used to improve the quality of support they were offering. However the system also started to provide better insight into the issues that customers were reporting, which in turn led to a series of product improvements, which improved product reliability, further enhanced customer service, but also reduced the number of customer support calls, which alongside productivity improvements meant, over time, that customer service reps weren’t replaced when they left, and staff costs for the unit dropped 30%. Customer service continued to improve despite the reduction in numbers, and became a key point of differentiation in respect to their competitors, which in turn facilitated a series of large contract wins, which in turn put a key competitor – who at one stage had threatened to engulf them - into full retreat, and with this as less of a distraction, and with the increases in revenue and reduced costs to fund the new initiatives the client was able to attack and break into two substantial new markets, which in turn…

…and hopefully you get the picture, so in essence the system, over a period of three years, provided the infrastructure for a fundamental transformation of the business, with one benefit spawning another to create a virtuous circle of improvement over time.

Recognition that the real pay back from CRM takes time is an important insight. Too many CRM implementations are geared around the concept of a one off CRM project rather than recognition of a long term CRM programme, which means the low hanging fruit might get picked but the bigger benefits are never harvested.

CRM chemistry....

I had a call from a reseller on Friday who was interested to know a bit more about what we as independent CRM consultants do. When I explained the vendor selection side of our services, they were interested to know which implementer I recommended for the CRM product they sold. Whether they believed the answer or not, I explained that it wasn’t a simple as product x = reseller y.

There are a number of reasons for this: if a CRM product was sold through business partners (e.g. Microsoft CRM), and if that product was a strong contender, we would almost certainly look to involve more than one reseller. One reason being that we find resellers to be somewhat schizophrenic when it comes the way they price projects. This may reflect project work load, but one time you’ll ask and they’ll come up with something very competitive, the next it can be completely stratospheric.

Secondly, the nature of the project itself and the skills required to make it successful drives the choice of potential vendors, for example a complex implementation might orientate us towards suppliers with a heavy duty implementation methodology, or a client with a tight budget might suggest an up and coming vendor looking to build their customer base.

Lastly we don’t make selections for clients. We see our role as finding highly capable suppliers, but ultimately the final choice will always be the client’s to make. While we will provide commentary and analysis, ultimately chemistry is always going to play a key part – who do they feel most comfortable working with?

Chemistry of course be a very dangerous thing if it’s chemistry between the client and the salesperson – which is they way most CRM purchase decisions get made - because generally they’re not going to be around once they’ve cashed the commission cheque, but as long as it's chemistry with the people that will be implementing and supporting the technology, and it’s a chemistry decision between well qualified vendors, then chemistry’s fine with us.

CRM and lead management...

One of the big benefits of deploying CRM technology can be systemising the handling of leads and enquiries. In his book ‘Lead Generation for the Complex Sale’ Brian Carroll notes that ‘as many as 80 percent of leads are typically lost, ignored or discarded’. Some leads simply don’t get followed up at all, which is rather mystifying but seems to be a fact of life. The bigger problem is when leads get passed to salespeople when the buying decision is not immediate. Salespeople are often poor at managing longer term leads in my experience, being rather more focussed on the here and now. Without effective systems these leads tend not to be recycled, and as I suspect the majority of purchase decisions are not immediate, this can be a big waste.

We’ve had a number of CRM systems go live lately where we are trying to increase revenues through managing leads more effectively. The key has been to define a sales process that ensures that all leads are captured and tracked through the system. This involves defining what constitutes a lead, when the lead should be passed to a salesperson, and, importantly, when they should be passed back for example to a telemarketing team should the opportunity prove longer term. By improving the visibility of the lead within the system, the organisations can ensure that opportunities are followed up effectively, and that the shelf-life of the lead is considerably extended by effective management over the long term.

One of my favourite gripes is that few companies make the most of their CRM systems by failing to invest in the supporting reporting capabilities - a theme I’ll warm to on another occasion. We’ve ensured that the lead management capabilities are supported by powerful business intelligence reports to allow the management team measure progress, and help the marketing team allocate their budgets into the most productive areas. There have already been a few surprises with different types of leads providing very different conversion ratios.

In principle this over time will translate into a big lift in sales. Brian Carroll cites an increase in qualified leads through these lead nurturing programmes between 15 and 200%. It’s early days to provide any meaningful statistics so far, but I’m certain the impact is going to be significant. I’ll report back as things progress…

The cost of CRM project failure...

I get a bit blasé about the importance of selecting the right vendor. MyCustomer.com is due to publish an opinion piece that I wrote about CRM consultants not just being about vendor selection. And I have been known to suggest from time to time that effective requirements definition is actually more important. I think this is partly because we get to work with excellent vendors and avoid the incompetent. And while I’d love to say everything works perfectly all of the time, that would not be entirely true, but we tend to be dealing with hiccups rather than major issues.

However from time to time I’m reminded as to the price organizations pay when they make a misjudged purchase decision. I made a call this week to see how the second phase of a project we’ve been working on had panned out. The client had first involved us a couple of years earlier wanting help turning round a failing project. They had installed a supposedly front/office back office solution which had been partially delivered substantially over budget, considerably late, and with a wealth of missing functionality. The internal project team was working silly hours to make the best out of a bad lot, while having to endure the inevitable finger pointing that only failed IT projects can generate.

The impact of the failing system was widely felt. Not only was senior management embroiled in a time consuming battle to at least get things on an even keel, the lack of a stable IT infrastructure was impacting customer service, and key new product releases were being undermined. Overall the ‘system’ disrupted operations for about two years.

While the temptation was to throw the system out entirely, many of the elements of the system were so bespoke and critical to ongoing business continuity, that this wasn’t a practical option. We helped the company install a mid-market CRM package to take over the front office functions, integrated with those back office functions that worked, and have been steadily helping them steadily migrate functionality from the failing system into the new CRM environment.

The vendor we selected to implement the CRM system has done a great job, and the client’s confidence in using and implementing technology has steadily increased. The fault for the failing project lay exclusively with the ‘rogue’ vendor, but inevitably in these circumstances there’s a tendency to blame yourself as well, and as a result there was a creeping lack of belief within the client as to their ability to implement technology successfully.

Rather coincidentally another client we later worked with had a similar encounter with the same ‘rogue’ vendor. After two years trying to implement a system the client simply gave up and wrote their own solution. The cost of the episode was enormous and the psychological scars are deep.

It’s perhaps the impact on confidence that project failures create that may ultimately be the most damaging aspect. In an era where corporate success and failure will increasingly be determined by an organization’s ability to harness technology, it will be the confident that ultimately prosper.

The ‘rogue’ vendor is still trading and still gaining (and presumably fleecing) new customers. The laws of economics don’t seem to apply well to IT companies perhaps. We seem to tolerate incompetence in IT far more than in any other field of life. For anyone looking to make a major investment in technology I’d strongly advise they perform their due diligence well, the cost of project failure may be bigger than you realize.

The role of the CRM consultant in requirements gathering...

While it’s a significant proportion of the project work we undertake it’s not always obvious why we get involved in the requirements definition phase of a CRM implementation. Before I address that point it’s probably worth summarizing why effective requirements definition as an activity is so important to a project’s ultimate success. In essence trying to implement a revenue generating CRM system without a detailed set of requirements is like undertaking a major construction project without a set of architects plans – ultimately you might pull it off but it’s going to take longer, cost more, and the finished product might not actually be what you want.

The requirements document fulfills a number of key functions:

· It facilitates effective vendor selection
· It facilitates negotiation of pricing and terms against a firm specification
· It provides a blueprint of what will be built

With respect to the first two points the timing of the requirements gathering exercise is all important. The temptation is often to undertake the technology selection first and then work with the selected vendor to produce the detailed set of requirements. The trouble with this approach is that once you get to the detail you may actually find the product that you’re now committed to doesn’t actually fit the newly discovered requirement.

Perhaps more importantly this is the implementation equivalent of publishing your email address and expecting not to get spammed. The job of any self respecting vendor project manager will be to optimize the vendor’s commercial position by expanding the value of the project (or if the implementation budget is set, dumbing down what they will deliver for the money). The customer’s ability to resist the vendor enhancing their commercial position is extremely limited once they get locked in. As a guide I’d estimate that companies pay 50% more for the projects when they define detailed requirements after vendor selection rather than before.

Even when companies commit to producing requirements documentation it invariably falls down in a number of different respects, including:

· Failure to define the business objectives
· Failure to define requirements in terms of business processes
· Failure to define requirements in sufficient detail
· Specification of requirements that can’t be economically met by available technologies

I suspect these issues emanate from one or a combination of the following three factors:

· That the person compiling the requirements has a weak understanding of CRM technology and how it can be beneficially applied.

· That the person compiling the requirements has a poor understanding of the operation of the business, perhaps coming from an IT background for example.

· That the person compiling the requirements is time poor.

In order to be effective at requirements gathering the analyst needs to combine a detailed understanding of the functional capabilities of CRM technology, a great understanding of how businesses work, and a depth of experience of applying CRM technology beneficially. The analyst’s job is to look carefully at the business and identify how the capabilities of the technology can be beneficially applied. The effective analyst works like a doctor, asking the appropriate diagnostic questions, using their knowledge to arrive at a diagnosis, and determining a cure.

The analyst hampered by a lack of technology or business understanding will tend to ask users to ‘self-diagnose’ and simply ask what they want from the system. They don’t have the knowledge to define requirements that the potential user may struggle to articulate or identify issues and needs that the user might not even be aware exist. They are like a doctor who demands the patient diagnoses their own medical condition.

As with many of the things the CRM consultant does, requirements definition may not be the first area you might associate us with. However when you consider that effective requirements definition probably goes 80% of the way to achieving a successful project, (where performed prior to vendor selection) will lower purchase costs by about 50%, but requires considerably more time and knowledge than people often appreciate, it’s perhaps no surprise that this seemingly innocuous activity is where we spend a considerable of our project time.