Why Bob got fired and why the conventional wisdom on CRM requirements specification doesn't work...part two

Once upon a time in my career any sentence containing the word ‘business process’ would reduce me to a near catatonic state. I assume many others feel the same way, because the concept of business processes virtually never features in the many CRM business requirements documents I get to read. This is odd for a number of reasons:

Assuming our objective for the system is to be more than a play thing for the sales team to dip in and out of as they feel inclined, the only way for a CRM system to deliver the objectives we talked about in episode two of this series, is to use it in a consistent repeatable way in order to achieve our desired outcomes i.e. it needs to incorporate a set of business processes. So unless you get the processes right you don’t get the benefits.

Because the way you run your business is pretty much unique in at least some respects, CRM technology isn’t going to work for you straight out of the box. Therefore even if the technology you select has a standard way of doing things (i.e. its own business processes) these will not map precisely to how you do business. They may require a little change or they may require a lot, but somewhere along the line you’ll need to figure out how you want the system to support the way you do business and adapt it.

Let’s say you wanted to cook lasagna. You’ve never cooked lasagna before so your first step is to go to the supermarket to buy some ingredients. It would be pretty difficult to do this without reading the recipe first. You’re wandering around thinking ‘mmm, now when I had it before there was definitely some mince, and oh yes, cheese, not sure which type though, and herbs, yeah, there were definitely some of those….’. Chances are that while you’re going to get some ingredients right, you’re getting to get some wrong, and plain miss others.

CRM requirements gathering isn’t much different; until you fully understand the processes (recipe) it’s very difficult to work out the supporting functional requirements (ingredients). And, to torture the analogy some more, without the recipe it’s difficult to guess the time involved to prepare and cook your lasagna, and so with CRM, without understanding the detail of the processes, it’s very difficult to estimate how much work (and hence cost) will be involved in adapting the system to meet your needs. In other words it’s only with a detailed understanding of the desired business processes that you can flush out the functionality you need and the cost of customization.

Finally, business process definition can be surprisingly time-consuming. You may have robust existing processes which can be quickly mapped into a CRM system. You may not. I’ve seen managers reduced to near gibbering wrecks when I’ve walked them through how their existing processes actually work on the front-line. The implementation of CRM technology is often the trigger for existing processes to be re-evaluated and engineered, and entirely new processes introduced. While process development isn’t necessarily immensely time consuming, it generally is.

The functionality led approach to CRM requirements gathering pays little attention to the above considerations and therefore creates a number of the problems the likes of which led to Bob being fired:

The functionality led approach fosters a belief that all we need do is purchase the right CRM software throw it on a server and we’re ready to go, which is the equivalent of spreading the lasagna ingredients on the table and saying we’ve got a lovely home-cooked meal. Technology is a tool. It won’t produce results on its own. It requires business processes or it doesn’t generate results.

The full functional needs fail to get flushed out and so the risk increases of getting landed with an inappropriate technology.

Without a full understand of how much the out of the box system will need to be customized to support the yet to be specified business processes, vendor pricing proposals can only be estimates. This has several implications:

1. We can’t easily compare pricing estimates because one vendor may estimate cautiously another may game the system by putting in a low ball estimate, therefore we can’t compare apples with apples.

2. It’s virtually impossible to negotiate on a substantial part of the system purchase costs because they aren’t known at the time of purchase.

3. We won’t know the full extent of the requirements and costs until after we’re committed to a vendor. The fox now has the run of the hen house, and we can expect to pay on average around 50% more for the implementation.

Finally, because process development can be time-consuming, when this isn’t undertaken until after the vendor has been selected, there can be a big gap between initial outlay on software and services. This isn’t great from a cash flow perspective, but also fosters situations in which managers can make rash decisions to speed up a necessarily lengthy process, such as cutting back on user acceptance testing.

Next time around on why the functionality led approach to requirements gathering is fundamentally flawed, I’ll cover the problem of the unknown, unknowns.

An open letter to CRM software start-ups...

Curiously, I had three companies contact me this week about CRM software they were launching. One part of me wants to applaud anyone who has the gumption to invest their time and money in developing software, the other, my independent CRM consultant side, is about as receptive as the lady impatiently trying to fill out the customer satisfaction survey I mentioned yesterday.

This isn’t because I think all CRM vendors are rogues. I do - though some are more loveable ones than others. It’s because if you’re promoting new CRM software to someone who’s been who’s been around the market for a while, they know the life expectancy of a new entrant to the market, and they know – because they’ve helped companies go through it - the expense and pain of replacing a product because the vendor hasn’t got the resources or inclination to develop it anymore, or files for bankruptcy as Entellium did in December. So we – or maybe it’s just me – as a risk averse group of battle-scarred veterans, who see one of their basic roles as managing risk for clients, just aren’t going to be pointing clients to products fresh out of beta.

But OK, let’s say the product’s been around a little while; the initial bugs have been ironed out, you’ve started to build a client base, would we work with you then? Well maybe, and really this is the reason for the post – when would we work with a new on the block vendor? It comes down to one simple question: ‘what do you do better than established vendors?’ because all things being equal I’m going to stay with the tried and trusted. Why? Because I see my role as delivering a game-changing CRM system, a system that can really enhance the client’s business, but with minimum risk. I don’t see my role as implementing the hottest, new technology.

Which brings me to my main concern (and the reason for writing this post) - when I put this question to new vendors the response is generally on the lines of it being easy to use, and at that point my heart sinks. While I understand where this originates from – vendors recognize that there are big issues with user adoption of CRM systems and see technology ease of use as the answer (wrongly I would argue, but let’s leave that for another day) – the problem is that virtually every vendor entering the market in the last 10 years has been ploughing the ease of use furrow, and so even if your product is genuinely, ground-breakingly, earth-shatteringly easy to use I see it as extremely difficult for a new entrant to get traction when everyone is yelling the same thing. (Please see ‘Positioning; The Battle for Your Mind’ by Trout and Reis for a more thorough examination of why.)

So how does a new vendor get traction? I think it comes down to basic strategy: focus on the needs of one sector of the market as Interaction did with the legal market, or differentiate (but not on ease of use) as Salesforce.com did with their ‘no software’ positioning, or be the cheapest as Sugar have looked to do through their ‘commercial open source’ approach.

But whatever you do, to gain our attention at least, it has to offer something overwhelmingly different than the things on offer from the established ‘lower risk’ options, and the ease of use thing isn’t going to cut it; super aggressive pricing, functionality not available elsewhere, a laser focus on the needs of an underserved market, well maybe. Which is not to say that just because this is what we look for, you won’t be successful selling your software, it’s just to explain why we might not bubble over with enthusiasm when presented with something brand new.

Can't get no satisfaction...

‘So how would you rate the service you received on a scale of one to five, five being highly satisfied and one being highly dissatisfied’ said the lady conducting a satisfaction survey on behalf of the company who’d recently replaced my windscreen.

‘Well that depends, the call centre were great when I first called, I mean really helpful. The local branch were OK, but absolutely insisted on doing the replacement on Boxing Day, and then the operative didn’t actually turn up, and no-one called me to re-arrange, but actually the lady at the call centre did a great job of sorting things out, then the local centre called and weren’t sure the guy they were sending out was really qualified to do the job, but then the chap who did turn up was really friendly and did a great job, other than remarking my car was a little dirty, but hey it was sparkling clean on Boxing Day when I got up early – feeling a little under the weather it should be noted - to wash it when I thought someone was going to turn up’ – I said helpfully.

‘So how would you rate the service you received on a scale of one to five, five being highly satisfied and one be highly dissatisfied’ the lady conducting a satisfaction survey on behalf of the company who had recently replaced my windscreen said testily.

‘Mmm, well a three I guess…..but…’

‘Question two’ the lady interrupted with increasing irritation.

And so it went on. Rather inconveniently my experience didn’t fit very well with the satisfaction survey. I suspect the outcome was that the operative who didn’t turn up probably got a bonus, and the call centre team got taken to task. But it raises the question why bother do a survey if you don’t actually want any feedback? It seems the ultimate irony if the customer satisfaction survey itself becomes a source of dissatisfaction. I mean try it for yourself, wander over to the nearest person, ask them an interesting question, and when they start to answer, put your fingers in your ears, and start yelling ‘la, la, la, la, la, I can’t hear you, la, la, la…….’

Anyway, I wasn’t the only one thinking along these lines – very nice post on the topic from Seth Godin.

The employee experience has never been so important too...

Heavily mired in CRM system design work over the last few weeks I initially missed the post from InsideCRM regarding Salesforce.com losing three executives, which in turn draws on a post from DestinationCRM. I mention this not because it might be early evidence my suggestion that the CRM market may not prove immune to the state of the economy, but it struck me reading the coverage how social networking is going to impact the coverage that these changes receive. Once upon a time, unless it was a star CEO, staff members were anonymous. We knew little about them and even less about how they felt about moving on. Now they may well have visible history – they’re in LinkedIn and Facebook – and they may have a voice – through Twitter or a blog. I’ve touched on the need for companies to better manage the customer experience, but the employee experience has never been more important too, because current and former employees have never before been so well positioned to get their opinions heard.

Why Bob got fired and why the conventional wisdom on CRM requirements gathering doesn't work...

Okay, so last week Bob got fired. The conventional wisdom on how to gather CRM requirements resulted in a substantial project overrun, a system that added no value, a board squeamish about further investment in IT, and Bob becoming a convenient scapegoat. But why doesn’t the conventional functionality led approach to CRM requirements gathering work? I think there are a number of reasons (which I’ll cover in a series of posts):

Lack of focus on compelling objectives

I’ve seen a lot of CRM requirements documents over the years, and remarkably few seem to pay much attention to why CRM technology is being introduced in the first place. There seems to be a perception that if we buy some CRM technology it will, as a direct output, improve our lives. CRM though is a tool, and a tool is only effective if we use it for a specific purpose. When people ask me the main reason CRM projects fail my answer is simple: people tend to see success as choosing the right CRM technology, rather than working out how to use it to generate value.

I suspect the heart of the problem is that we’re used to software that does a certain thing: Word to create documents; Sage to manage accounts; Firefox for browsing, Google for search. We know what these types of applications do and we can make our software selections based on the features and functions, or the brand we like, at the price we want to pay. We’re also used to software that in the main does what we want ‘out of the box’ and where we don’t have any significant associated implementation costs.

CRM technology is a little different. It can be used in lots of different ways to achieve lots of different things. I’ve seen similar companies, working in the same market, with similar strategies, implement CRM technology in completely different, but equally successful, ways. The challenge with CRM technology is often working out how to use it in a way that generates maximum returns. The ways to beneficially implement CRM technology are often far from obvious, and the extent of the value these systems can create is often underestimated.

The functionality led approach focuses on developing lists of features, and either misses out defining the desired outcomes from the investment altogether, or sets it out in vague and unspecific terms such as ‘increased productivity’ or ‘improved customer service’. The failure to define clear, specific, detailed and, importantly, exciting outcomes results in the following issues:

The return on investment is likely to be very low because the technology – being as we’ve said a tool - won’t be set up to do anything of value.

The project is likely to be under resourced in time and money because the outcomes aren’t seen to be compelling.

The risks of selecting an inappropriate CRM technology are increased on the basis of the maxim ‘if you don’t know where you are going any road leads there’.

Next time, I’ll discuss another point of failure in the functionality led approach: not thinking in terms of business processes (and trust me, I’ll try and make it a more interesting post than it sounds).

Why conventional CRM requirements gathering is fundamentally flawed...

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:

ABC Widgets Ltd decides a CRM system is a very good idea. Bob 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 Bobs 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. Bob 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. ABC 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. ABC 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 plan. 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 ABC to too much risk. To bypass this ABC 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 ABC 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 XZY 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 Bob 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. I’ll explain why in the next post.