The CRM Consultant

Getting to the CRM software short-list...

2010-09-04T11:45:00.002Z

Excellent long post from Chris Bucholtz on his excellent Forecasting Clouds blog about selecting CRM software. He's distilled a lot of input from a lot of industry commentators - including yours truly - into a well structured, coherent analysis on what people need to be aware of when selecting CRM software.

Killer misconceptions - 8 common misunderstandings about buying and implementing CRM software...

2010-08-03T08:16:00.004Z

The following is a piece I wrote for Conspectus Magazine recently:

I recently put together an e-book, well, probably to be fair, an e-guide, on how to buy and implement CRM software; which was a roll up of a lot of the content I’d posted to ‘The CRM Consultant’ blog over the years. In the process it was apparent that there are popular misconceptions about many aspects of purchasing and implementing CRM technology – and perhaps for that matter many other types of technology. It struck me that the sooner we dispelled these myths, then the sooner we can better harvest CRM’s potential, so what follows are what I consider to be the key areas of misunderstanding:

That CRM is about choosing the right software – while technology selection is important, it’s not as important as people think. We’re blessed to live in an age where there are a host of flexible, highly functional, low-cost CRM technologies available for purchase. Yes, you need to exercise caution, but there’s considerably less scope to get things wrong as there was five years ago.

The problem is that many buyers see the selection of the technology as the entirety of the challenge rather than a step in the process, and that if they get the right package benefits are going to miraculously accrue. They miss a key point that CRM technology is a tool-set, it doesn’t do anything on its own; it needs to be used in the pursuit of well defined objectives if it’s going to generate any value.

This might be less of a consideration if CRM technology did one thing, but the reality is that CRM can be deployed in a myriad of different ways. Even similar businesses, in the same market, with similar strategies, might use CRM software to achieve vastly different objectives. While I wouldn’t go so far as to say it was unimportant – technology and, in particular implementation partner selection, still trips many – it’s the relatively easy bit. Working out what you want to achieve, how to achieve it with technology, and how to get people to use it are the tough challenges.

That the CRM vendor or implementation partner will resolve this issue – if you accept my previous point then you might suggest that the software vendor themselves, or an implementation partner, should be able to help you. That’s not my experience, and I’ve been round the block a few times. Vendors tend to be focused on the technology not on the solution. If you asked them how to get their product to do x,y,z, they can help, but ask them to really explain how their technology can grow your business then I suspect you will find they come up short. The nub here is that if you are unclear on how CRM technology should be beneficially used for your organisation, don’t look for the vendor to fill in the blanks. You will either have to work it out for yourself or use other sources such as third party consultants.

That your requirements document is a three page list of bullet points – in my experience a solid requirements document forms the foundation of a successful CRM project, but all too often it’s a skimpy list of functional requirements that don’t facilitate cost effective vendor selection. More importantly, as I touched on earlier, they generally fail to articulate a compelling vision for the project, and completely ignore the process dimension of how the system will be used. A good set of requirements in my opinion encompasses the following key areas:

· What problem you are looking to solve or beneficial outcome you are trying to achieve?
· What are the processes that will be used to solve the problems, or achieve the beneficial outcomes, and how exactly will these work within the technology?
· What is the supporting functionality that will be required to support the processes?
· What data integration and migration will need to happen to facilitate the above?

While it’s a crude estimate, a good CRM requirements document that follows the above approach will weigh in at fifty to a hundred pages for the average CRM project. This means that a lot of work gets done before the vendor selection phase, but the benefit is that vastly more value is more predictably generated, with less risk, and at lower cost.

That vendor pricing is logical and predictable – in my experience nothing could be farther from the truth. It’s not uncommon for us to ask for bids from four or five prospective implementation partners, all of whom offer the same CRM software platform, and see quotes coming through with wild variations in price - and that’s when bidding to a detailed specification. This variation not only occurs between implementation partners, but even with the same implementation partner bidding on similar projects.

This phenomenon means that if you are not careful you can significantly over-pay for a system or dispense with an otherwise attractive technology, if the bidding vendor happen to be in the wrong mood when they put the pricing together. The answer is to keep you options open, even if this means several suppliers bidding the same technology. By following this approach, using the front-loaded requirements gathering approach outlined above, combined with smart negotiation, means, in my experience, you should be able to purchase your system 30-40% cheaper than otherwise would be the case.

That system configuration and development is the time consuming phase – given the flexibility of most CRM technologies, configuring and customising systems is a relatively brief affair. This contrasts directly with other core activities which people dramatically underestimate. For example, requirements definition, system design, user acceptance testing, and user adoption, are often significantly longer processes than most people appreciate. Misconceptions around the duration of a CRM project and its constituent parts are potentially fatal from a project standpoint, because the project team get pressured to hit unachievable time-lines, and key activities get rushed or overlooked. It’s essential therefore that would-be implementers of CRM technology appreciate what the key components of the CRM project plan are, and how long they should take, and set everyone’s expectations accordingly.

That data is a side consideration – as I’ve mentioned, technology is generally the star of the CRM show, and the implementation of that technology becomes the focus of attention. However when people come to use their brand new system and find the data is old, duplicated, and incomplete, usage can suddenly fall off a cliff. The problem with data is that while it’s essential to a good system, reconciling and preparing data from potentially many, many unrelated sources can be a long, manual, and time-consuming task that often doesn’t get started soon enough in the majority of projects.

That half a day’s training will do – there’s a really tough adversary that you’re going to have to take on when deploying CRM technology – user adoption – and poor user adoption is the most common cause of death for CRM systems. The traditional thinking has been to give users a few hours of classroom training and then expect them to go off and use the system in a consistent and systematic way. While this may indeed work for a minority of users, in practice the majority require considerable training, hand-holding, monitoring, and a lot of other resources before they develop usage habits appropriate to an effective system. In no aspect of CRM implementation has less progress been made in the life of this technology, than user adoption. Understanding how tough a challenge this will be, and gearing up appropriately, is essential to realising value from a system.

Leave the reports until later – for reasons I won’t dwell on here (but can be found in this blog post) vendors tend to underplay the importance of reporting. For many organisations though, improving the depth, quality, and immediacy of management information, is a key project driver. Reports also have a critical role to play in determining whether staff are actually using the system, and using it in line with the agreed processes. It’s important therefore that as much focus is paid to delivering the reporting requirements as the functional requirements, and making sure these are available to support the effective adoption of the system in the first phase of the project.

These and other points are covered in more depth in the e-book which can be downloaded for free, (and without the need to leave your details), from here. If you are looking to implement a CRM system, or any other complex technology for that matter, dispelling popular misconceptions, many of which have arisen from the software industry’s need to mask complexity in order to sell software, is critical to maximising CRM’s rich potential.

CRM technology in five years time...

2010-07-11T15:40:00.003Z

The following is a quick response to a Linked In Answers question relating to the evolution of CRM technology over the next five years. It's something of a crude thumbnail sketch - I'll perhaps create a more considered response in due course - but it was a thought-provoking question and it would be interesting to get some comments on how people see things moving forward. Anyway, my response was as follows:

There's always a danger in expecting too much to change in five years. Looking back five years its been a case of steady evolution rather than radical transformation. What I think we will see is some commoditisation of CRM. I suspect this will be through a commercial cloud based application rather than through open source.

In terms of the CRM mid-market, I would expect to see Salesforce maintain its leadership position in hosted, and Microsoft CRM in on premise. I suspect we will see someone - perhaps Zoho - grab the low cost end of the market, to end up with three major players covering this space.

In terms of functionality I think we will see advances in mobile access, workflow, data management and improvement tools, and the functionality to monitor and manage social networks.

I also think there will be increasing awareness that the technology dimension of CRM is not that important, and the key battleground will be getting the right CRM strategy, setting up the processes within the technology to support the strategy, and getting people to use the system in a structured and systematic way.

I would also expect to see a significant shift in the amount of resources that are devoted to getting CRM right, in line with what we've see as the ERP market has evolved.

e-book on buying and implementing CRM software...

2010-07-01T10:54:00.001Z

I’ve blogged a lot over the years about the challenges of buying and implementing CRM software. I was conscious that there wasn’t that much easily accessible practical advice out there, so I figured it was time to get these posts into one place, and combine them with new material in order to, hopefully provide, a practical guide to anyone looking at purchasing CRM technology.

The result is a 42 page e-book entitled ‘an industry insider’s survival guide to buying and implementing CRM software’. It can be downloaded from here. It’s free. There’s no need to sign up, but all feedback is gratefully received as I’m intending release some further iterations, based on the responses I get.

I’m also planning on adding some additional titles, so any feedback on areas that might be of interest, would also be well received.

Common misconception about implementing CRM software...

2010-06-18T15:40:00.002Z

I’ve just finished writing a fairly long magazine article setting out what I consider to be some of the most misunderstood aspects of buying and implementing CRM technology. I will publish the full article once it’s gone to print, but in summary the eight key areas I identified were:

Misconception 1 – CRM is about choosing the right CRM software – it’s important, but not as important as people think. Technology won’t do anything on its own. The strategy, people and process dimensions are where the challenge is.

Misconception 2 – That the software vendor can cover off the strategy, people and process dimensions – not in my experience anyway. They may know the technology, but the application of that technology to beneficial effect, no.

Misconception 3 – That requirements documents should be three pages of bullet points – functionality oriented requirements specifications, that ignore strategy and process, do not generate successful, cost effective, CRM projects.

Misconception 4 – That vendor pricing is logical and predictable – again not in my experience, vendor pricing tends to be very erratic, and you can get caught out unless you give yourself plenty of choice.

Misconception 5 – That system development is the time-consuming phase – Customising and configuring CRM software is normally a lot quicker than people think, it’s other seemingly innocuous stages such as design, testing, or user adoption that catch people out.

Misconception 6 – That data is a side consideration – people don’t want to see old, duplicated, or incomplete data when they start using their new CRM system, but preparing data can be a bigger task than the rest of the project put together.

Misconception 7 – That half a day’s training will do - user adoption is your toughest adversary, expecting people to attend a few hours of classroom training then go off and use a system in a consistent and structured way is fatally unrealistic.

Misconception 8 – That it’s ok to leave the reports until later – vendors are notoriously squeamish about helping create reports in the early phases of a project, but improved immediacy and quality of management information is generally a key deliverable, and it’s also a key way of verifying adoption, so why delay?

Those, in summary, were my thoughts on common misconceptions, now what else did I miss?

CRM user adoption comments...

2010-05-24T07:59:00.003Z

I've enabled comments on the blog to accomodate the responses I've had on user adoption. As I think this is only available on new posts, please feel free to add any further comments on this topic here.

Left brain - right brain and CRM user adoption...

2010-05-19T17:58:00.002Z

In my last post about getting people to use CRM systems I asked for input on anything people felt I’d missed, and I had a great response from Michael Whitlow at CRT/Tanaka. I hadn’t thought about difference in left brain/ right brain people before, but it’s an interesting point. I would also agree that there are companies that just don’t have it in their DNA to meaningfully implement CRM technology. Anyway, his email is reproduced below with his permission:

‘I’ve spent a lot of time in my career in the company of engineers, and learned a great deal from them. To this day, my ability to engage the left brain is probably less than one-tenth the capacity of the average engineer’s, but that still puts me in an interesting position to observe behavior of my colleagues in the PR firm. I think the “right-brainedness” of the potential adopters can be a significant negative factor to CRM adoption.

While I’m not prepared to postulate that all members of the creative class will uniformly reject CRM as too constraining, too repetitive or too “whatever…,” I will say that our experiments with systems and processes to support our teams have seen mixed results. We all enter our time on each engagement, but there’s always some end-of-month threatening required to complete the time sheets for billing for about 10% of our billable employees. The inclination to enter the data required to make a CRM system work effectively is not a core competency for the average right-brainer, either, and we recently abandoned a Sharepoint-based CRM process for this reason.

So, to add to your list, I’d say start the process by knowing your targets and their strengths. If there is very little process in the business and little inclination on the part of team members to adopt processes, then there’s not much real hope for CRM, I’d guess. The organization must have been built on other strengths. On the other hand, businesses that have good process strengths are probably good targets for the discipline of CRM.

The ideal CRM for a right-brained person would be one in which any data entry is telepathic, requiring no effort to fill out a form or sort a spreadsheet or look up a contact name and address (or, perish the thought, to enter any data twice). Since there are a lot of service firms filled with left brainers, I think most service CRM approaches have focused on them. PR, Advertising, Social Media, Interactive firms? Not so much. We have traditionally employed people to be the designated left brainers – traffic managers, production managers, etc. They are called upon to take on the sometimes Herculean task of pushing creatives to accomplish our work on a schedule – even the work we love! Having been the designated traffic manager on a CRM approach, I can report that it’s much harder to get creatives to accomplish good CRM.

Wonder how others feel about this question of whether you can teach the right-brain dominated the virtues of process and have teams of such folks really use processes to improve their lives and the success of their enterprises?’

Getting people to use CRM technology...

2010-05-15T11:59:00.002Z

I’ve spent the last few months putting together a survival e-guide for buying and implementing CRM software. It’s a combination of existing blog posts and new material, based on my last fifteen years on the front-line trying to help organisations get operational benefit from CRM technology. One of the new sections is on the issue of user adoption, and a draft of my thoughts is shown below. It would be good to get any feedback on areas I might have missed, and if anyone wishes to review an advance copy of the guide please drop me a line.

On CRM user adoption

I was asked to help a software company brainstorm how they could get more value from their system. They had clearly spent a lot of money on it. They had a full time administrator, the software ran on a bank of perfectly maintained servers, and they were a prominent reference site for the vendor whose software they used. After a few minutes looking at their system it was apparent they had a problem though. No one was actually using it. To be precise out of a sales force of 120 only 7 staff members had even accessed the system in the previous month.

The moral of the story is that you can have the greatest CRM system in the world but if you can’t get people to use it in a consistent and structured way it won’t generate any benefit for your organisation. User adoption has been the primary cause of death for most failed CRM initiatives in a world where there have been a lot of failed initiatives.

In reality user adoption is not that complex an issue to address, but like many aspects of the CRM world it’s considered to be a technical issue. So as each new CRM software product is released, the vendor, correctly identifying user adoption as a key point of failure, announces another breakthrough in ease of use capabilities that will supposedly banish this ill forever.

Putting aside my belief that actually there has been very little change in the usability of CRM software in the last 10 years, ease of use is only one piece in the user adoption puzzle, and it doesn’t matter how easy to use you make software, it doesn’t mean it will be used. The following are the bits that I believe make up the bigger picture:

Have a clear purpose – as we’ve already noted it’s important to define compelling objectives for a system, but it’s also critical that users understand and buy into those objectives and it’s not just seen as another pointless system they have to update. Communicating this effectively is the key here.

What’s in it for me – while it’s important that the CRM system will create benefits for the overall organisation, it’s critical that it also provides benefits to the individual users in terms of making their lives easier, or helping them work more effectively.

Don’t compromise on ease of use – sometimes when you are developing a system there’s a decision point between spending a bit more to make things more ergonomic or intuitive for the user, these investments generally pay big dividends in improving uptake and usage.

Half a day is not enough – let me be emphatic here; do not expect your users to attend a classroom training session and immediately start using the system in a consistent and structured way. This will not happen. Classroom training is a starting point, but as I touched on earlier, it is just part of a sequence of training activities that will need to happen before you get strong usage.

Assume failure – in other words assume that people are not using the system in the way you wish them to until you prove otherwise. Have a list of system users and only cross them off the list when you’ve proven they are using it. Until then, keep training.

Resource up – user adoption activities, as perhaps is becoming clear, can be time consuming. Make sure you have the people in place, whether they are internal or external, to ensure that you can get through this phase of the project.

Middle management is key – in many cases the senior executive team will buy into a CRM project, but this buy-in doesn’t extend to the middle management tier. Nothing will kill the system off quicker than a user’s manager intimating that use of the CRM system is optional. Effort should be focused on ensuring that all levels of the management team are driving the use of the system.

Monitor – there should be someone whose role it is to carefully monitor usage. If users are not following the agreed processes then that needs to be logged and addressed. This is a key function, so make sure the chosen staff, are capable, motivated, and have the time available to do the job properly.

Accept it takes time – user adoption won’t happen overnight, it will take months, maybe years. Get it right and it will be worth it, but accept this is a long term activity.

Burn the boats – when the Spanish Conquistador Cortez landed in Mexico he ordered that the ships be burned to ensure his soldiers were solely focused on the task ahead and knew there was no heading back. If the only way to perform a given task is through the CRM system – perhaps generate a sales forecast, or the monthly activity report, or place an order – then the system will be used. If there are other means to do this, perhaps manually, or through an old system, it reduces the motivation to change.

Reports – are a key way for users to determine if processes are being followed. If they’re not, then you will quickly know it because there won’t get any usable management information. Strangely though reports are often a belated afterthought encouraged by vendors who point to the standard reports that ship with the software or wizzy report generators. In reality, since reports need to track your individual business processes, they often require fair amount of customisation and development, so make sure that this is factored into to your development schedule so they are ready to support the user adoption process.

On CRM and lead management...

2010-04-30T19:04:00.002Z

I've started to keep a rough tally of late. I'd say a third of the companies I make a sales enquiry to don't follow it up. A third do, but badly. And a third are pretty on the ball. Which led me to write this piece on CRM and lead management for the Cloud Crowd - http://bit.ly/bmi2wT

Too soon to implement CRM software?

2010-04-10T08:35:00.002Z

I was listening to an interview with Tony Hsieh when I was out running this week, and he was asked the question about the things he would have differently when Zappos was a start up. One of his responses was that he wished he’d rolled out the core values of the company on day one rather than at year five.

As this pretty much coincided with a conversation I was having with a customer about managing the rapid growth of their business, I started to wonder what else you needed to consider on day one, and if that included CRM technology.

This is a little counter intuitive in the sense that it’s when you least need CRM. There’s a handful of you sharing the same office, you talk to each other all the time, everyone knows what’s going on, processes are pretty simple, there aren’t so many customers, and everyone knows their needs and individual quirks.

Then as the company grows things change. New staff join who don’t have the history the founders have, perhaps they’re not in the same room, office, or even country. Keeping everyone on the same page is more difficult. Perhaps the product range increases, customer numbers go up, processes become more complex. There are more staff members interacting with the same customer, but it becomes increasingly difficult to do this in an informed and coordinated way.

If this growth is particularly sudden, and there aren’t the systems and processes to support it, then costs can ratchet up disproportionally and the quality of customer service can dramatically decline. I’ve seen so many organisations fail to come through this stage, which is why it was refreshing talking to the manager of a rapidly growing company this week who described how the first ten years of his company’s existence were about preparing to be the overnight success they subsequently became.

Perhaps systems considerations shouldn’t be a day one start up activity, but if the goal is to scale the business, then these shouldn’t be an afterthought either. It’s easy to focus on the product or service being offered rather than the systems and processes to support their successful delivery. The key I think is to get these in place before the business starts to scale in order to minimise costs and maximise the quality of service as volumes increase. If start ups can establish a CRM culture early, then they have a huge advantage over larger organisations struggling to retrofit CRM technology into their businesses. It may not guarantee you’ll become the next Zappos, but then falling a little short may not be a disaster either.

When should I pilot CRM software?

2010-03-13T15:45:00.002Z

Someone asked me recently how long they should pilot their CRM software before they rolled it out to the rest of the organisation. Perhaps the best way to answer that question is to first identify when it does (and doesn’t) make sense to run a CRM pilot. There are two circumstances where I’m in favour of running CRM pilots:

Where you need to validate that you have the design right – particularly for larger organisations, no matter how thorough your requirements gathering, there’s a risk that you miss or misunderstand something. A pilot in these circumstances is a good way of validating the design of your system before deployment to a broader audience.

When you need to prove the concept – if you are unsure whether CRM technology can add value, a pilot can be a sensible and cost effective way to test whether there is likely to be a return on investment for a broader roll out.

It should be noted that both these approaches require the deployment of a fully developed system designed to achieve defined operational objectives. In other words, even for a small number of users, there can be a significant level of investment in running a pilot.

Which brings me to the point of what a pilot isn’t. I’ve seen a number of CRM vendors suggest to their clients that they just use the software ‘out of the box’ and see how they get on. I guess this is a variation on the puppy dog close (‘why don’t you take this cute little puppy home for a few days and decide if you want to keep her?’). While this approach may be a sensible way of evaluating software, it’s a pointless activity from a pilot perspective because unless the software is set up to achieve an objective, no real value can be realised.

In addition to being a close representation of the full system, the pilot will need careful nurturing. If the selected pilot users don’t buy into the process then you’re not going to get any useful feed back, and this in turn can derail the whole project. This means that pilot users need to be carefully selected, ideally picking the more zealous users to spearhead this phase of the deployment. It also means that a large amount of supporting resource needs to be in place to ensure that users embrace the system and that consistent usage patterns are quickly established.

Going back to the original question – how long a pilot should run for, this will depend greatly on the type of pilot. A validation of design, can be relatively brief (assuming adoption occurs quickly), but a proof of concept will generally take a lot longer for the impact to manifest itself. This tends to stress the patience of many organisations, so proof of concepts tend to be a rarer phenomenon.

Which is a pity, because they can be great way to overcome the inertia that many organisations experience when considering major investments in CRM technology. A modest initial investment, and a little patience, can go a long towards unlocking CRM’s potential.

Would you pay to respond to a tender?

2010-02-20T18:04:00.002Z

The words had been thoughtfully picked out for me by the sender in yellow, but it would have been pretty striking without the highlighter. It was notice for an invitation to tender, and it contained the interesting condition that for anyone choosing to enter a cost of up to 2,000 Euros would apply.

Now perhaps I’ve lived a sheltered existence, but I’ve never seen an invitation to tender issued before where prospective vendors have to pay to take part. This was a condition of an invitation to tender for CRM development services. We don’t provide CRM development services, and so have no specific interest in this tender other than this ‘pay to play’ practice strikes me as wrong in several respects:

It’s unfair – It’s tough enough anyway for vendors. Responses to invitations to tender can involve weeks of work soaking up the time of people throughout the business. Should the vendor be lucky enough to be short-listed they have another round of work putting together presentations, demonstrations, and reference visits. The costs of this process can be huge, and given that by definition most prospective suppliers will be unsuccessful, it strikes me as morally suspect to ask vendors to stump up an additional ‘entry fee’.

It’s open to abuse – While I’m sure in this specific case things are above board, however if this practice is more widely adopted what’s to stop organisations requesting payment to enter tenders that are never awarded, or where the there was only ever going to one winner. It’s already commonplace for organisations to go through a tendering process to meet internal purchasing policies, when the decision’s already been made as to who will win.

It’s bad business practice – I imagine the aim of the pay to play practice is to reduce the number of ‘speculative bids’. However I can’t believethis justifies a 2,000 Euro charge. How long does it really take to weed out the prospective suppliers that don’t have a valid offering? What I’m sure it will do is reduce the number of good suppliers that bid, and why would you want to do that?

When we run tender processes we want the best suppliers to bid because we want to work with the best suppliers because they help ensure a successful project. Smaller suppliers are likely to baulk at a 2,000 entry fee, so one presumes the intent is to discourage them, even though in my experience I’ve seen little correlation between the size of a business and the quality of the CRM services they provide.

The top suppliers, the ones in real demand, the ones who can choose who they work with, I would imagine would share my distaste for this approach and decline to bid. What would happen if you advertised a job at your organisation with the terms that anyone submitting their CV had to pay a 2,000 fee? I’d imagine there wouldn’t be so many applicants. Perhaps a few that were sufficiently desperate, but the top folks, the ones in demand, the ones you really want, will go elsewhere.

Finally, I hardly think it makes for a harmonious working relationship with the selected supplier. Asking someone to stump up a fee for entering the process is likely to set a negative tone for the remainder of the relationship, making for a bumpy ride for all involved.

As distasteful as I find this practice, and ultimately self-defeating from a business perspective, I wonder in tough economic times if this is just a one off, or whether it’s the start of a trend.

Time to replace our CRM software?

2010-02-13T12:55:00.001Z

He was the last of the Mohicans. As I watched him he followed the prescribed process. The system hadn’t been well set up, so it was a prolonged and laboured procedure, but he followed it to the letter, key stroke after key stroke. This would have been great if everyone, or maybe even anyone, was doing the same. But they weren’t. His hard work was in vain. A waste. The system was long since obsolete.

I was there to answer a simple question, but I was actually answering a different, slightly more complex question. The simple question: ‘what should we replace out current CRM software with?’ The more complex question: ‘how can we make CRM software work for us?’

As I continued looking it was clear that there were business issues that needed solving. Leads were not being followed up, the marketing department was reliant on expensive advertising campaigns rather than the more cost effective direct marketing they wanted to do. Service procedures were long-winded, error-prone, and customer satisfaction low.

The problem wasn’t the choice of CRM software, it was how the software was being used. There was an easy solution, and it wasn’t new software. We simply took the CRM software the client already had and re-implemented it to better support their operations. There was no need to invest heavily in new software, we simply helped them take what they had and made it work. Investment = minimal, return on investment = huge.

I mention this because I often get asked what I think of product x as a replacement for product y, and it’s not a question I can easily answer.

The problem with most CRM software is that it isn’t set up, and/or used, in a way that will generate beneficial business outcomes. The technology itself is often not the problem. But unless this is understood, organisations investing in replacement CRM software are destined to make the same mistakes again, and in a few years time will again be looking to replace their CRM software.

All too often we dispose of software that’s more than capable of getting us where we want to go. Applications are unfairly maligned because the set up was wrong, the usage patterns were never established, or through lack of knowledge of its capabilities. And, at the same time, we are lured by the siren song of the software vendors into believing that new software is the answer to all our problems.

The answer is to forget technology for a while and focus on what we are trying to achieve. If we can answer that question, the technology question should answer itself. With clarity as to our end objective and how we will get there, we can make an informed judgement on whether our current platform is help or hindrance.

The outcome of taking this approach is that for many organisations making better use of what they have already may prove the most attractive option. Not good news for the CRM software industry perhaps, but the bottom lines of CRM software users may well benefit.

Advice on CRM implementation issues and a joke...

2010-01-30T11:08:00.002Z

There’s an old joke that goes something like this:

A man, driving through the countryside, stops to ask a farm worker for directions to a local town.

The farm worker scratches his head thoughtfully, and after a while, says ‘you know sir, if I was going there I wouldn’t start from here at all.’

This surfaced in my mind when I was asked for advice from a company implementing CRM, but, despite focusing on a simple contact management phase to start, were struggling to gain traction, particularly with some of the senior executive users.

I guess my advice was of the ‘I wouldn’t start from here at all’ sort, and may not have been terribly helpful, but my response was as follows:

Ideally when you deploy CRM, there are a clear set of ‘recognised’ problems that you are looking to solve, and compelling outcomes that you have in mind. The resolution of these issues would ideally have senior level support, and while this doesn’t guarantee usage, it certainly helps.

It sounds as if you are encountering resistance at an executive level though. This is a very difficult situation to overcome. If the executive team don’t support it, then it will be a major uphill struggle.

My suggestions for addressing the situation:

Re-visit the business case. What can you do with CRM that will get senior level support? I’m not convinced just contact management represents a big enough win to capture people’s imaginations. Work out how CRM can grow sales by 10%, and that might get some attention and backing. I’m all in favour of phasing projects, but you can do too little in the first phase and burn out enthusiasm for the project. See here for thoughts on phasing.

Also consider carefully if you have a reasonable chance of deploying process-driven CRM or whether you will have to settle for ad hoc usage per this blog post .

If you get senior level sponsorship and the resources to make the project happen then perhaps use this post to address some of the user adoption issues.

If you can’t get sponsorship, then probably the best thing is to find a small group of receptive users, focus resources on them, and help them transform their part of the business with the CRM system. If you can prove success in one area, that may help you obtain attention and resource for a wider roll-out.

It’s the work you do before the implementation that largely determines success or failure. Effective planning and requirements definition are the keys to success, and they set the tone for everything that follows. If you have a compelling vision that everyone buys into, then you have conditions that a ripe for success, without it’s pretty much impossible to create anything of meaningful value.

Which is why, frustratingly I’m sure, the best advice, when things go wrong, is often to retrace your steps and revisit the planning stage.

By the way if anyone has any other questions on implementing high return CRM systems, feel very free to drop me a line. I’m always happy to give my two penneth worth.

CRM project plans - where does it all go wrong?

2010-01-23T16:52:00.002Z

For those of you currently planning a CRM project, I thought it might be helpful to indentify some of the areas where things tend to go ‘off-piste’, but before I do perhaps it’s a good idea to suggest why we might care in the first place.

If the CRM project team come under time pressure, either through underestimating the time-line or through unforeseeable disruption, the, not unnatural response, is to try and speed things up. Unfortunately, often with limited things that can be sped up, this leads to cutting corners in some form or another. Commonly this manifests itself in dumbing down the requirements, reduced testing, and rushed training, which in turn invariably ends with user adoption issues which may ultimately prove insurmountable.

Therefore understanding which bits of the implementation process are prone to delay is a key way of effectively managing time-line expectations. So the following are my top six areas where people tend to get caught out:

Contract negotiation – you may have selected your CRM vendor quickly enough, but contract negotiation can be a major source of delay. Once matters reach the hands of the respective legal teams things rarely move fast.

System design – translating your requirements into a final design is a problem area. Not so much the design work itself, but, because what you sign off at this stage is what gets built (whether or not it is what you want), this phase is likely to generate much to-ing and fro-ing as the designs are finalised. This can be a particularly extended stage if requirements are ill-defined going into this phase (see here for my thoughts on requirements definition).

In fact at any key sign off point – the simple act of getting signatories together is prone to delay, for the simple reason that most will have other, invariably pressing, work commitments, and the effects of other events such as holidays, illness, maternity, paternity, or, if in the UK this winter, snow.

Data-load – because the point the data load into the system begins is often the point when it’s realised how bad the quality of data actually is. Data preparation is a time consuming piece of work, and is often not started early enough to avoid impacting project time-lines.

User acceptance testing – is the point where you get to check how well the vendor delivered on their design. This phase is commonly underestimated for some reason – probably through misplaced optimism about the number and easy of fixing bugs. It’s generally the iterations of identifying issues, fixing, testing, re-fixing, and potentially breaking other things that previously were working in the process, that make this a potentially delay inducing phase.

User adoption – is nearly always an issue because the amount of effort required to make it happen isn’t generally appreciated. It takes a long time to break old habits and establish new ones, and it can take many months of effort before this is achieved. And this can be many months more effort than was originally allowed for.

Then of course there’s the less foreseeable. In a recent project, pretty much the whole of the vendor project team were made redundant, which was more than mildly disruptive. These situations are not easy to cater for, however making reasonable allowance for the standard phases of an implementation is key to staying away from potentially perilous route of trying to deliver on a project plan that was never achievable in the first place.

CRM set to be a commodity? Interview with Raju Vegesna at Zoho

2010-01-14T10:34:00.001Z

The following is an interview I did with Raju Vegesna at Zoho Corporation. Some interesting thoughts, particularly on CRM software as a commodity:

[RB] Could you give us an introduction to Zoho Corporation and your role?

[RAJU] Zoho Corporation (formerly AdventNet Inc) was founded in 1996. The company is headquartered in Pleasanton, CA and also has offices in Austin & New Jersey in US. Zoho also has offices in India, Japan, China & UK. The company has over 1200 employees, is private, profitable and never raised any external capital. Zoho is a comprehensive suite of award-winning online collaboration and productivity applications for small and medium-sized businesses, as well as consumers. I am currently the Evangelist for Zoho.

[RB] What’s the typical profile of one of your CRM customers, in terms of things like size of organization, number of users, geography etc?

[RAJU] Companies with tens or hundreds of users use our CRM app. We also have many free users using the free version of our app. Our users are geographically well distributed. 50% are from US and 50% from rest of the world. The usage is high from countries that have good broadband connection.

[RB] What lead you to enter the CRM market-place?

[RAJU] We initially built an installable product to meet our own needs. It eventually evolved as a SaaS App which we use along with many users. We wanted to provide a good set of feature-rich apps for SMBs to run their business online at an affordable price. Obviously, CRM is an important part along with other apps we offer. When all these apps knit together well, it can be a compelling offering to SMBs. That is our vision and our CRM app is one key component in our application portfolio.

[RB] You’ve been pretty visibly targeting Salesforce.com users with your Zwitch programme, do you consider them your main competition?

[RAJU] Yes, Salesforce is our main competitor when it comes to CRM application. Customers are starting to see the value we bring to the table with a rich set of features, a good price, and integration with our broad set of apps.

[RB] How does Zoho CRM differentiate itself from other CRM vendors?

[RAJU] Our Zoho CRM differentiates in three key areas - features, integration and price. The application has breadth and depth at very attractive price points. Given the fact that users can start using a fully featured app for free is a great plus (the app is free for the first 3 users). Also, its integration with our other applications (Like Mail, Meeting, Writer, Sheet, Show etc) is unique.

From my own review work I found Zoho CRM had a surprisingly comprehensive set of functionality, you’ve also got a very broad suite of other applications, how do you as a company maintain that sort of rate of development?

[RAJU] Every application has a dedicated and passionate team focused on that market. The mandate for each team is to be the best in that category. In CRM, we want to be the best CRM out there for SMBs. This is the case for every single app. We have frameworks that take care of underlying plumbing so that individual teams focus on the application and features. Once an app reaches a certain level of maturity, teams work together to integrate them to work harmoniously.

[RB] The use of CRM technology to harness social media seems to be the hot topic of the moment. Are you releasing functionality in that area?

[RAJU] We are working on some improvements to CRM which will also include integration with social media. Unfortunately, I cannot provide additional details on this at this time.

[RB] Is there news you can share about your roadmap for Zoho CRM with us?

[RAJU] Zoho CRM will continue to improve as an application with additional features and improvements. Integration (with other Zoho apps) is going to be an important theme for CRM this year. We will also integrate CRM with external apps as well. We might launch a new application complementing CRM this year.

[RB] Other than Zoho perhaps, who do you see as the winners and losers in the CRM market over the next few years?

[RAJU] I don't want to name any vendors, but as general themes, I see CRM becoming a commodity app for businesses. This means, vendors charging an arm and a leg will bleed users. Vendors that integrate with other existing systems will win. Mobile will play an important role in CRM and vendors will have to embrace it. I expect CRM will continue to be an active market in coming years and we will see many vendors succeed.

Where do you see Zoho as a company in five years time?

[RAJU] Five years is eternity and it is tough to see where we will be. The fact that Zoho itself didn't exist 5 years back shows the rapid evolution in the market. We think SaaS will commoditize software and we will no longer see the margins we see today. We want to be one of the important companies around, innovating and serving our customers well.

How to implement CRM technology - an easy way and a hard way

2010-01-10T11:59:00.001Z

One of the first projects we undertook after I set up Mareeba was to review a client’s call centre. The call centre supported computer equipment across the UK, and was something of a victim of success, struggling to cope with a series of large orders that the client had recently won.

One of the key issues the client had, was that they struggled to appropriately prioritise and action issues that had a high impact on their customer’s operations. As a result they were struggling to meet their service level commitments, creating ill will within the customer base, and incurring significant penalty payments.

As a solution we helped them develop new operational processes and implemented a new CRM system to support them. We developed and supervised a customised training programme, and then, after initial hand-holding, left them feeling rather good about what we’d done.

When we returned two weeks later though, we got a bit of a shock. Yes, the system was being used, but by everyone in very different ways. There was no consistency to which fields were filled out or how they were filled out. One user might set a case as high priority, another user would define the same issue as low priority. The use of the ‘on hold’ function to stop service level timers, and the routing of calls to other service teams seemed pretty much random.

In short, while we had developed a ‘solution’ to a major client business issue, it wasn’t actually a solution to anything because the users weren’t using it in a way that created any value. Sure the issues were being logged, but all the great stuff we wanted to do like cut the resolution times for high priority calls, or reduce call volumes through better identifying trends, simply wasn’t happening.

Fortunately with a major commitment of additional time and resource we were able to steady the ship and the call centre becoming one of the cornerstones of the client’s subsequent growth. The point of the story is to expand on a theme I began in my ‘CRM is complex’ post, is that the process oriented usage of CRM is tricky to pull off, because you need to get all users to consistently follow the process in order for you to get results. And that, as the above example might suggest, is very difficult to do.

What’s interesting is that you will generally get some level of value from a CRM system even if usage is inconsistent. So in our call centre example above, all calls were being logged and attributed to the correct customer, so the client got some measure of benefit from being the fact those calls were being recorded and handled. What wasn’t initially being achieved were our aspirations for things like the quicker handling of high impact calls, because that required a more process driven approach than we could initially achieve.

So if you went out today and purchased a CRM system and you weren’t too concerned about everyone using it in a consistent and systematic way, then you would still derive benefits such as:

Improved follow up of opportunities through the ability to set call backs
Better retained information about prospects and customers
Improved coordination between different sales teams
Easier transitions when staff leave or change role
Improved productivity through better access to information and collateral
The ability to launch, albeit very broad brush, marketing campaigns
Better centralisation of customer information through integration into other systems

However these benefits are generally comparatively slight compared to those driven by a more process driven approach which might, in a business to business sales and marketing situation, include:

More effective lead management
Improved lead generation through highly targeted marketing campaigns
Improved communications to customers and prospects
Improved cross-selling and up-selling capabilities
Better control of the sales process
Improved sales forecasting
Better account retention and development process
Enhanced major bid control
Improved allocation of pre-sales resources
Enhanced sales margin control
Improved account planning
Enhanced major account development
Streamlined order processing and fulfilment
Improved customer on-boarding
Improved management of customer facing processes
Better visibility and management of client issues and complaints
Enhanced reporting - sales activity, conversion rate, marketing campaign ROI, lead source, pipeline, forecast, customer satisfaction, competitive activity, win-loss reasons, etc.

The problem, however, is that these are much more difficult to achieve for the user adoption reasons I outlined earlier. Which is why I smile, or maybe it’s a grimace, when I see on my Twitter feed someone tweeting from a vendor conference somewhere something along the lines of ‘wow, company x, rolled out product y to 5,000 users in two weeks!!!’. This may or may not be factually true, but assuming it is, then barring the use of a fairly large army of implementation personnel, and the addition of a minor miracle, then I would wager the usage pattern will prove to be of the ad hoc and inconsistent variety.

The more process driven the goals for the system, the more resources are required to be successful, but the greater the rewards if you are successful. The problem is that people badly underestimate just how much resource is required to achieve consistent and systematic usage patterns, which is why properly planning a potential CRM project is so important. If you can nail down precisely what’s involved in achieving a given set of goals, then you can make a considered decision on what are appropriate objectives. It doesn’t really matter whether you spend a little for a lower return on investment ad hoc approach to CRM, or spend big and go for the high return process driven approach. Where you don’t want to be is somewhere in the middle, spending big, but not big enough to pull off the process driven approach, and achieving as much as if you’d spent virtually nothing. A near miss is as good as a mile in this respect and that can be a very uncomfortable place to be.

CRM and the golden sales sausage machine...

2009-12-19T18:12:00.001Z

I’ve heard the concept of the golden sales sausage machine articulated many times in my career. In essence it goes like this: our sales people currently average say four appointments a week and they close one in four. Therefore if we crank up the lead generation to eight appointments a week instead of four, our sales will double.

On the surface the logic looks undeniable, and so the company cranks up the lead generation. The new appointment target is achieved, and everyone sits back and awaits the rewards. Which never come because the sausage machine theory has two key flaws:

Firstly, it assumes that all leads/appointments are uniformly close-able; in this case one in four. In reality the conversion rate of lead/appointment varies significantly with lead type. So, a customer lead, or a warm lead where a prospect initiates the contact with us, or perhaps a referral, will tend to have a significantly better close rate than a colder lead such as a cold call. The problem with the sausage machine approach is that it’s difficult to easily increase the number of warm leads, so the balance tends to be made up with colder leads that don’t convert so well. The conversion differential can also be very significant with a very wide range of closure rates across the warm to cold lead spectrum.

The second issue is that conversion efficiency decreases with work-load. Let’s say you were a salesperson and you only got one lead a month. You have a target to hit and commissions to earn, so you do everything you can to close that lead. You pull out all the stops and lavish such attention and service that you win the business. However as you get more leads you’re less able to provide that level of attention and your close rate is less successful.

There’s a crowding out effect as lead volumes increase, and this happens earlier than many people realise. There’s a tendency to focus on time in front of the customer as the measure of salesperson workload, but there are a lot of other key activities required to close sales, including preparation, follow up actions, and quotations. Attempts to maximise the number of appointments a salesperson attends often back-fire as key non-client facing activities are dropped in order to accommodate the increased work-load, and close rates can often significantly deteriorate across the range of leads, good and bad. It’s not uncommon as a result to see overall sales decline as salespeople struggle to cope with the influx, and start to drop the ball on what previously would have been considered their prime opportunities.

The benefit of having a CRM system which tracks leads and monitors sales activity levels is that the two effects described above should be very apparent through reporting. The difference in close rates between lead types may prove to be particularly insightful for many organisations as they increasingly struggle to get traction with traditional cold calling approaches. I’ve seen a number of businesses realise that what were previously considered successful lead generation activities in terms of the volumes of leads generated, were actually losing the business money when the dimensions of costs and resulting sales were considered. At the end of the day the golden sales sausage machine may prove to be unrealisable, but effective use of CRM can go a long way to helping organisations fine-tune lead generation and activity levels to increase sales.

CRM is complex, and that may be good...

2009-12-08T10:11:00.002Z

The phrase ‘CRM is complex, not because people want it to be’ which appeared in a tweet from Mitch Lieberman last week caught my eye, and, though I suspect I am using the quote outside of its original context, I wanted to write a piece about CRM complexity at least as I experience it – as an independent CRM consultant trying to maximise the pay-back from CRM technology.

Complexity is important because if you believe implementing a system to be a trivial task and it proves to be otherwise, the chances are you won’t be resourced for a successful outcome; rather like fuelling the aircraft for Paris, when the destination is Sydney.

In my experience there is often a yawning gap between perceived and actual complexity which means that many CRM initiatives are inadequately planned and resourced. I will expand on these complexities in a moment, but it’s also worth saying that CRM can be virtually complexity-free.

It’s not too challenging to get a CRM system up and running in a matter of hours. Out of the box software will provide capabilities such as contact and activity management which should allow users to perform their roles more effectively. Usage however is likely to be inconsistent and ad hoc, and though CRM technology in this form may provide some level of return on investment, it’s unlikely to have a materially beneficial impact.

The greatest value that CRM technology provides is to allow you to define, manage and improve your sales, marketing, and service processes in a way that better allows you to attract, increase revenues from, and retain customers. For many organisations these ‘front office’ processes have traditionally been poorly defined, badly supported by technology, and inconsistently executed. Using CRM systems to better control and automate these processes can add substantial operational value.

However using CRM technology in this way is the source of most of the complexities I referred to earlier, as the following challenges need to be met:

You have to decide how you want the system to add value. Automating what you do already may create benefits, but greater value is generally generated from improving your current processes and using the CRM system to support the new practices. Determining what these new strategies and processes are going to be is a demanding aspect of any CRM project.

Whether you change your business processes or not, a more process oriented approach to CRM will also tend to be more demanding from an implementation stand point. As you start to embed processes within the technology the more you tend to realise that the ‘out of the box’ capabilities need to be customised to meet your unique needs. Even the most basic of requirements need some level of system adaptation. In addition a process-led approach tends to flush out data migration and integration requirements that a more casual usage doesn’t require.

Finally, a more process driven approach requires users to use technology in a consistent and systematic way otherwise it’s unlikely to generate any value. Put in an accounting context, the books are unlikely to balance if you are selective as to what transactions you choose to record. Consistent user adoption is significantly more difficult to achieve than most people realise, and has been the ruin of many otherwise successful CRM initiatives.

So, in summary where CRM technology has its greatest impact is where it is consistently used to support an improved set of business processes, but this is considerably more complex to achieve than many buyers of CRM technology allow for. The key is to understand this and act accordingly. It’s better to investment a small amount, recognising that a system will be an inconsistently used personal productivity tool with a limited pay-back, than invest heavily without getting to grips with the associated complexity involved in a more value enhancing system.

Of course it would be great if CRM was easy, but that it isn’t is a great opportunity for companies who wish to achieve sustainable competitive advantage. Markets are dotted with companies who have successfully systemised their ‘front-office’ processes and continue to reap the rewards of doing so because their accomplishment is hard for others to emulate. For these organisations at least complexity is a friend not an enemy.

A more successful approach to CRM requirements definition - the wrap up

2009-11-25T10:29:00.003Z

In the last few posts I touched on why effective CRM requirements specification was important, and how to approach it. This week I want to wrap up this series by suggesting how this can be brought together in the final CRM requirements document.

Given that the structure of your document should be driven by its end purpose, it’s worth being clear about what it will be used for, which I believe comes down to the following:

To facilitate agreement internally as to what you are trying to achieve and how you are planning to achieve it, ensuring a common understanding and that the initiative is adequately resourced.

To define what functionality you will need to achieve your objectives to avoid choosing CRM software inappropriate to your needs.

To allow vendors to provide accurate, rather than indicative pricing.

To control and accelerate the implementation phase.

As such, I suggest a simple structure as follows:

Firstly, an analysis of the current situation, the problems you are looking to solve, and a statement of the desired outcomes. This should be as specific as possible.

Secondly, a statement of the business processes necessary to achieve the objectives, and how these will be supported in the system. I tend to break these into two parts: a narrative describing each process, and a flow-chart representation which includes a statement as to who is updating what within the system in order to facilitate the process.

And finally, the supporting functional requirements. I tend to start with a detailed description of each entity (for example people, organisation, lead, opportunity, and case records) within the system. This will include a detailed breakdown of what fields will appear on each entity and any related functionality. It’s also worth adding mock up screen shots which can be quickly created using something like Microsoft Visio, as this visual depiction allows people to more easily review the document.

All integrations into other systems will be fully set out. There’s a tendency, in the CRM requirements specifications I see, towards broad-bush statements such as ‘the system will integrate into system x’ with little information about what ‘system x’ is or what information is to be integrated, in which direction, or in what form i.e. real-time, batch, or a data view. It’s virtually impossible for a prospective vendor to gauge the complexity and cost of integration unless you can provide the supporting detail. The same level of detail should also be applied to any initial data imports into the system.

Finally, I generally set out the remaining functional requirements that don’t relate directly to individual entities, under separate headings in the document. These include the often overlooked aspects of reporting, administration and security needs.

The resulting output should be a substantial and comprehensive document that should facilitate effective technology and vendor selection and drive the implementation process forward in a controlled way.

The title for this series has been ‘a more successful approach to requirement definition’, and I believe the approach I’ve outlined differs from the more traditional practices in a number of key ways:

It places greater emphasis on the business goals

It recognises the importance of defining the processes necessary to achieve the business goals in detail, which in turn drives out the functional needs

It seeks to complete a complete blue-print of the system before engagement with a CRM vendor

There’s no question that this approach does increase your workload in this phase, but I believe effective requirements management is the biggest single determinant of CRM success, and the benefits of improved negotiating position, greater control of risk, time-lines, and costs, married with the ability to ultimately deliver a real game changing project, should make this a very worthwhile investment.

A more successful approach to CRM requirements definition - part three

2009-11-08T13:54:00.006Z

As I covered in my last post on CRM requirements gathering, the first goal is to define what sort of problems you are looking to fix, or what sort of beneficial outcomes you are aiming for. The next step, which I will cover in this post, is to define how you will use the CRM system to achieve those objectives.

Most CRM requirements documents that I come across on my travels tend to be a list of required functionality. There is curiously little mention of process – i.e. how the technology will be used.

There are a number of reasons why process is important in CRM requirements gathering. CRM technology is just a tool set, and unless you can define how that tool-set will be used to reach you objective you aren’t going to get there. It’s very much like travelling, you need a destination, but if you are going to get there you need to figure out the route as well.

The second reason that process is important, is that it’s often only when you look at the detail of how your goals will be reached that you will flush out all the data capture, integration and functional requirements that will determine the complexity (and cost) of the project and the most appropriate technology for your needs.

Let’s say you decided that the objective for your project was to increase the life-time value of your customers by increasing the frequency and relevance of the communications you send them. If you look at this purely from a functionality stand-point you may simply conclude that you need marketing campaign management capabilities.

If however you start to look at this from a process stand point, i.e. what are the things you are going to need to do to improve your communication, then all sorts of complexity can start to appear. So you might consider:

How do you want to segment the database to ensure our communications are targeted and relevent? How and when will you capture that information? How do you check the quality of data? How do you ensure that people do want to receive the information you want to send them? How will you handle those that want to opt out? How will you handle ‘gone-aways’ and ‘bounce-backs‘? How do you control changes to the customer data? How will you handle leads and enquiries arising from our communications? How will you maintain data quality over time? How will track the impact your campaigns are having? What reporting will you wish to produce?

As you answer these questions, and work through the processes you need to put into place, then the complexity of the solution often increases. For example you might determine that a key means of targeting your communications will be the products that the customer has previously bought from you. In order to obtain this information it may require a previously unforeseen integration into your financial system.

Looking at things from a process view point is therefore both a key way to check the system will support achievement of your objectives, as well as a means of flushing out the requirements that will determine which CRM software best suits your needs and how much the project is going to cost.

As a bare minimum I would advise you to document and detail all the processes that your system will support. If at all possible I would try and take it a stage further and set out precisely how the technology will support them. I tend to map out the processes and add a detailed commentary on exactly what’s happening in the CRM system. So for each step in the process I indicate who is updating what fields on which entities in the system. This does require a working knowledge of CRM technology, but it allows you to create a more detailed blue-print for the system which in turn gives you much better control of time-lines and budgets.

Next week I will wrap up this series, including my thoughts on a suitable structure for the final requirements document.

A more successful approach to CRM requirements gathering - part 2

2009-10-24T17:10:00.003Z

Last week I described why I felt a detailed set of business and functional requirements was essential to a high pay-back CRM project. Over the course of the next few posts I intend to set out some thoughts on how you can go about creating them.

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 in my travels, 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 unintentially 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. As I noted in my ‘Notes from the Camp Nou’ post, the organisations that use technologies the most effectively tend to focus on achieving process ‘best practice’ and use systems like CRM to drive those best practices through the business.

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 next post.

A more successful approach to CRM requirements specification

2009-10-11T14:33:00.004Z

Earlier in the year I wrote a series of posts entitled ‘Why Bob got fired’ which was meant to culminate in a piece about how to write a business and functional requirements specification for a CRM system – something I’ve seen people consistently struggle with over the years. Anyway somewhere along the line I got distracted and didn’t finish the series, so I thought I’d revisit CRM requirements specification and try and set out in as simple and clear a way as I possibly can my thoughts on the best way of approaching it.

Perhaps the best starting point is to give some definition to what I mean by CRM requirements documentation. I will cover this in more detail in the coming weeks, but in short a requirements specification does three things: it sets out the problems we are trying to fix or the desirable outcomes we are looking to achieve, it defines how those problems will be solved or outcomes achieved, and identifies the required supporting functionality.

I will also add that in my view a CRM requirements specification is a detailed piece of work more in line with a set of architect’s plans, rather than the high level list of functional bullet points that are often produced. It is created before technology is purchased rather than after, and by the user of the CRM system, not the CRM vendor.

I will talk more about how you might approach requirements gathering and best way to document them in later posts, but today I just wanted to set out why getting a good set of requirements is important, and that comes down to the following reasons:

It helps ensure the project receives the funding, resources, and management attention necessary for success because there is clarity about how the system will benefit the organisation. A lot of CRM projects fail to be adequately resourced because no sufficiently compelling outcomes are defined.

It improves user adoption because users better understand why they are being asked to use the system. Users tend to adopt technology considerably better if they can identify desirable outcomes if the system is a success.

It reduces the risk of purchasing an inappropriate technology because the detailed functional requirements are understood before the technology is selected rather than after.

It allows organisations to reduce costs, because vendors can provide firm quotations in a competitive environment against your detailed specification. Where high level requirements are provided, the best a vendor can provide is an estimate to be confirmed at a later point. The later point is a poor position to negotiate from, because by that stage you are generally committed to a single vendor.

It speeds up delivery of the project, because a detailed specification means that developers can work more quickly.

It improves cash flow, because the requirements gathering phase – one of the most time-consuming parts of the project – is completed before you start spending money with the vendor.

It reduces the risk of cost and time overruns, because there is less likelihood of new requirements appearing as the implementation process progresses (often referred to as scope-creep), and because there is less likelihood of your selected vendor discovering more ‘complexity’ as they understand your needs better.

It gives you more flexibility in managing the project because it’s easier to reprioritise work should the need arise.

It increases the return on investment for the system because there is a clearly defined business objective.

To my mind effective requirements gathering is the foundation of a successful project, and alongside defining a well thought out user adoption strategy, is one of the key activities which determines success or failure. If you can get it right, every other part of the project flows more easily, and, as an added bonus, it allows you to achieve more, at less cost, and with less risk.

Having set out why it’s important, next week I’ll set out my thoughts on what makes for a successful CRM requirements gathering approach.

11 ways to limit CRM implementation risk - part 2

2009-10-04T18:43:00.002Z

So you’ve been given a CRM project to deliver. How do you manage the risks associated with managing an implementation on time and on budget that also delivers value to your organisation? Part Two (Part One here).

Break the project into bite size pieces. There’s only so much resource that a project team has available for an implementation, and there’s only so much change users can absorb at any one time. It often surprises people how restrictive these bandwidth considerations can prove to be, so it pays to be very careful how you phase a project. Striking a balance between something that adds genuine value to the business without overwhelming your ability to deliver can be a tough call. It’s generally better to err on the side of caution as long as what you deliver is seen to make a real difference. I’ve seen as many promising projects fail because the initial foray into CRM technology was too timid as I have through trying to be too ambitious.

Get a commit on costs up front. As I mentioned in the last post, I recommend getting as detailed a set of business and functional requirements specified as you possibly can. Ideally there should be no ambiguity as to what you are looking to achieve and the vendor should be able to give you a firm price for the work involved. If this is not the case, then agree what the vendor needs to do before they can provide a fixed price. Depending on the complexity of the project they may do this without charge, but the key here is to get a fixed price without making a major commitment. If, as many organisations do, you make a major investment in software and services before costs are confirmed, then you leave limited room for manoeuvre later should your selected vendor decide their initial estimates were short of the mark.

Manage the vendor. One of the areas people often overlook is the composition of the vendor implementation team. Most CRM purchase decisions rely heavily on the perception of the vendor salesperson, who in my experience invariably disappears off on an exotic holiday once the implementation work begins. The vendor staff who will actually perform the work, and with whom you will be working closely for the next several months, are generally first seen when the ink is well and truly dried on the contract. To avoid nasty surprises it pays to make an assessment of the vendor’s proposed team as part of your initial purchase decision in order to ensure the assigned team are experienced and capable, and, perhaps most of all, are people you’re comfortable working with for the duration of the project.

One thing that should ring alarm bells is if your vendor has a large number of people swapping in and out of your project. This approach tends to help vendors increase billable time because they can charge for staff who might otherwise have been kicking around the office, but, because of the learning curve on any project, staff involved for short periods of time are unlikely to produce value for money and tend to generate a disproportionate number of quality issues. It’s generally better to insist on a small multi-skilled team who are available for the duration of the project. I’m also strongly of the opinion, though this isn’t always practical, that vendor implementation staff work at your site, where you can reassure yourself that they are fully focused on your, rather than someone else’s project. As a final point, I’d recommend that payments to vendors are made on reaching agreed milestones rather than on the more commonly used time and materials basis. This tends to concentrate minds on delivery rather than billing.

Identify the key risk points. Understanding what’s likely to go wrong in an implementation and having a plan to deal with if it does, is a key component of effective risk management. The problem is that some of the risk areas aren’t so obvious. Data migration and integration are well known problem areas, as is anything involving heavy customisation or development work, because of the potential to have multiple cycles of user acceptance testing. However issues can also arise from seemingly trivial sources such as third party add-on products, which software vendors frequently use to plug gaps in their functionality. I’ve seen several projects jeopardised because of short-falls in capability or performance from supposedly bolt-on applications. The other major risk area is where you need to involve other parties who have little skin in the game. A prime example might be an existing supplier whose system is being replaced as part of the implementation, but who you are relying on their help to extract the data. They have an important role, but no compelling interest in making it a success.

Don’t underestimate the challenge of changing people’s behaviour. Of all the risks that you will face when implementing CRM technology, the greatest is that people just won’t use it, at least in a way that will generate any value for your organisation. The standard approach to the user adoption is to load users up with software, give them half a day’s training, and expect them to start using the technology in a consistent and systematic fashion. This does not work. You have to expect that the average user will be very slow to adjust to a new way of doing things, and it requires a considerable input of energy and resources to ensure that change happens. The dimensions of effective user adoption are too wide-ranging to cover off in this post - I’ll try and cover them at another time – but suffice to say this has been a huge point of failure for most deployments of CRM technology, and developing an effective strategy is critical to your success.

Treat CRM as a programme not a project. So, you’ve delivered a great project and you’ve broken the back of the user adoption challenge. In principle now should be the moment to sit back and enjoy the accolades. However, CRM systems are delicate flowers they need to be nurtured over the long term, and it’s over the long term that the value of the investment in CRM technology will be realised. Amongst the key challenges will be ensuring usage remains consistent, as people leave and join the organisation, and that the system adapts to changes in strategy and circumstances. This is no minor undertaking, given the rapidly changing world in which we live, but is an essential requirement if the system is going to deliver long term value.

As a parting point the risk management considerations outlined both above and in my previous post apply regardless of whether you take a SAAS/hosted approach or run the system ‘on premise’. Contrary to some market mythology, I see no material difference in project complexity and inherent risk between the two deployment options. While I’ve picked eleven key risk areas, if you can define a compelling outcome for your project, develop a comprehensive supporting requirements specification, and can deploy an effective strategy for user adoption, you’ll be a long way towards being successful in your endeavours. Perhaps the best starting point though is to realise that, while it’s not rocket science, there’s more to implementing CRM technology successfully than meets the eye.

11 ways to limit CRM implementation risk...

2009-09-28T11:32:00.004Z

So you’ve been given a CRM project to deliver. How do you manage the risks associated with managing an implementation on time and on budget that also delivers value to your organisation?

Understand there is complexity. A lot of money has been invested by the CRM software industry in promoting the idea that CRM is straightforward. If people didn’t believe implementing CRM systems was easy, they wouldn’t buy much software, and that’s not what the software industry wants. While it’s by no means rocket science, there is considerably more complexity involved than people appreciate. If you get lulled into seeing this just a technology selection issue, you’ll get tripped up.

Write a tight and detailed requirements specification. A tight specification of requirements is the foundation for a well controlled project. The key word here though is detailed. It’s not hard to wander round the building asking people what they want from the system and in the process accumulate a reasonable number of bullet points, but this sort of list is not going to help you manage a project. A requirements document should thoroughly address:

What problems are we looking to solve?
What are the business processes required to solve the problems?
How will the processes work within the technology?
What are the supporting functional requirements?

Ideally you should be creating a detailed design for the system well in advance of selecting any technology. This enables you to:

Reduce the risk of purchasing an inappropriate technology
Get a firm price upfront from potential vendors allowing you to purchase competitively and reduce the likelihood of unexpected costs downstream
Reduce the risk of ‘scope creep’ where new requirements keep being added during the implementation phase causing delays and budget overruns

Create a sensible project plan. This isn’t as simple as it might seem. It’s human nature that while we may have been contemplating deploying CRM for many years, once the decision is made to progress there’s a desire for instant results. Consequently it’s easy to be hurried into an unrealistic project plan. In principle you should be able to look to the vendors for sensible guidance in this respect, but in 14 years in the industry I’ve seen remarkably few realistic plans. As a rule of thumb take the time-lines the vendor gives you, add 50%, and you shouldn’t be too far away.

Choose your vendor carefully. Technology and vendor selection may not be the most important constituent of a successful project, but it’s still important. Good requirements definition will help you understand what you need from your software, but it’s also important to assess the longevity of the options on offer. There’s plenty of vendors I can think of that I don’t expect to see around in a few years time, either because they are new and will struggle to get traction in the market or because they are at the end of their project lifecycle and are milking the last out of a cash cow product.

The other dimension of this is that many CRM technologies are sold through a network of implementation partners. These tend to be smaller businesses, with an even higher mortality rate, so due diligence here is just as essential. The last thing you want to be doing is abandoning a perfectly good system after eighteen months because your chosen vendor got bought out and the new owner pulled support of the technology, or through some similar doomsday scenario. You can’t remove all risks, but I strongly recommend sticking to established, successful technologies unless there is a compelling reason to do otherwise.

Ensure you have the resources in place. CRM projects are time-consuming. People have day jobs. The two things don’t sit well together. You need to understand the resource intensive aspects of the project. Activities such as project management, data preparation, system configuration, testing, and training are often more resource intensive than people expect. It is also particularly important that senior management have the bandwidth to support the project, because the project is unlikely to succeed without their active backing. By examining the resourcing needs carefully you can head off potential bottlenecks that can considerably delay a project.

11 ways to limit CRM implementation risk is concluded in the next post…

A surprise at 43...

2009-09-24T16:04:00.003Z

BusinessWeek adopted a rather surprised tone in its commentary on number 43 Amazon in the '100 best global brands' issue. It notes Amazon is both the fastest mover in this year's ranking, yet spends virtually no attention on advertising, preferring to invest in technology and distribution capability.

I think this just reflects the new reality that with the fragmentation of media, and the ease with which views and opinions can be shared across the web, the key battleground is the customer experience. Gone are the days that you can fool people into believing you have a great product by investing heavily in TV advertising. Sadly perhaps for the ad agencies.

Marketing resource management software

2009-09-23T07:06:00.003Z

Nice piece on Gartner's take on marketing resource managment MRM software in SearchCRM.

Sticking to the knitting...

2009-09-22T13:03:00.003Z

Many, many years ago, in my pre-CRM days I worked for the incumbent PC supplier to a very large financial services company. One day alarm bells started to ring. Our customer was evaluating another supplier. We knew where: behind locked doors in the basement. But who, was a mystery. Our polite enquiries were stonewalled. But by using some subterfuge or other we eventually gained access to the test facility, and there on the test benches we saw banks of desk-tops and servers, from a company called….what does that logo say? I can’t quite make it out…. D-E-L-L. Who the heck are they?

In the fullness of time we lost the account to Dell, and in the following years I’ve marveled at the ruthless efficiency of their business model. Machines, only available direct, built to order, payment received up front, no need to carry stock, perfect. They went from Michael Dell’s dorm room to dominate an industry. Even I became a loyal customer.

But acquiring Perot Systems? I can see the logic perhaps. The PC industry is slumping and services suddenly look a very attractive area. But the question is when does a unique position in the market become everyday? I can already buy Dell from PC World, and now they are an outsourcing giant as well? I’m not convinced this is going to work. When you start to look like every other global IT company why should I buy from you and not the others? Sometimes it’s better to understand what you do well and stick to it.

The rise of the CRM architect...

2009-09-11T10:51:00.002Z

Once upon a time when people wanted something built they went to their local builder. At some point in history though, people found this wasn’t working so well. Builders might be great at building, but they weren’t so great at designing buildings and the role of the independent architect was created.

Today, if you want to a new office built, you find a suitable independent architect and they will interpret your needs, create a set of plans which prospective builders can accurately quote against, help you select the right builder, and oversee the project to check your vision is realized on time and on budget. This seems to work well and is the accepted way of running a successful construction project.

I think there’s a close parallel between how the construction industry changed and how the CRM industry will evolve. If we look at the CRM market today it’s apparent we’re still in the pre-architect era. If you want a CRM system, in the main you go to a CRM vendor. This is fine if the approach worked well, but I think realization is setting in that vendors may be pretty good with their technology, but applying it in a way that adds value just isn’t their forte. In tougher markets this situation seems unsustainable.

Independent CRM consultancies like ourselves have been performing the ‘independent architect’ intermediary role for some time, but this approach has been the exception not the rule. I think things are changing though, and that independents specializing in implementation and operational best practices will increasingly sit between the client and the CRM vendor as a means of maximising value from technology. Whether we're still known as CRM consultants I don’t know. If it weren’t for the fact it’s a rather hackneyed IT term, perhaps CRM architects might be a better description, but, whatever the nomenclature ends up being, I think it’s the key to the power of CRM technology getting realized.

Notes on CRM implementation from the Camp Nou...

2009-08-31T08:30:00.001Z

Just back from spending some time with friends in Barcelona, one of whom is a senior IT executive at one of the larger FMCG companies, and one which I consider to be one of the most effective users of IT technology out there. As they are currently in the midst of a big CRM project not surprisingly conversation turned to the challenges of implementing new systems. So what follows are a few strands of their approach that I figure set them a little apart from the mainstream:

· A lot of effort goes into the planning for any IT project. They spend a lot of time establishing project feasibility and business case before any substantial investment is made.

· An IT deployment nearly always involves a change of business process. They rarely simply automate what they already do. They carefully research industry best practice and look to equal or ideally better it.

· They invest big because they know if things are done properly they will get an even bigger return.

· They place a big emphasis on getting it right first time, because they know re-implementing systems or putting in new systems every few years is a much more expensive route.

· They are prepared to spend a long time getting things right.

· They will occasionally implement short term tactical solutions but only as part of a broader strategic plan.

· Though they are an international company they recognize not all markets are the same. International operations can however generally be grouped based on similar requirements. While there are differences between groups, they ensure each group operates an identical set of processes.

· The change management, i.e. the getting people to use it, aspects of any project is taken very seriously and take up a lot of time and resources.

· Once a system is established the system is further enhanced but this is done uniformly across each individual group. No one is allowed to strike out on their own. If the process is further enhanced, it is further enhanced for everyone.

· The change control process is carefully regulated with a series of checks and balances. They manage it so no single senior executive, perhaps experiencing a rush of blood, can authorise changes without the consent of a broader cross-functional team. The governance function is established right at the start of the project.

While these guys are global FMCG, the points are relevent to virtually any deployment of information technology. I was particularly struck by how infrequently they simply automate an existing process without trying to fundamentally improve it, and how once the new best practice is embedded there’s no option but to follow it. You don’t see individual operations opting out and doing their own thing. The robust governance thinking was also interesting given leadership changes have often led to the demise of many an otherwise sound system.

Overall what comes out is a deep appreciation that IT will have a fundamental bearing on the future profitability of their business. It’s at the very heart of their business strategy, and it’s a key part of how they compete with other companies who see IT as a necessary evil rather than a source of competitive advantage.

A disconnect in desperate need of bridging...

2009-08-09T13:45:00.002Z

In his post ‘Are we solving the same problem’ Seth Godin brilliantly sums up one of the fundamental problems of the CRM industry even though he’s not actually writing about IT.

The point he makes is that people are much more comfortable discussing the solution to a problem than the problem itself. If we were to understand the problems better the solutions would be better, but this tends not to be the way of the world.

Applied to the world of CRM, I think CRM vendors are great at talking about their product’s functionality, but are considerably more sketchy about the problems their products are actually solving. This would be less of an issue if the purchasers of CRM technology could fill the gap, but not surprisingly perhaps, they often struggle to understand which of their problems CRM can practically solve.

Only when this disconnect is bridged will the true potential of CRM be realized.

One simple way to slash CRM implementation costs...

2009-08-05T17:41:00.002Z

In the early days of Mareeba we were working with a client to help them create an extension to their CRM system. As we usually do, we had created a detailed specification and circulated it to potential vendors for their proposed pricing. The quotes that came back seemed astronomical compared to what we felt was the modest scale of the work.

I was so convinced that the vendors had over-estimated we decided to take a bit of a gamble and stray away from our tried and tested fixed price approach. We identified a developer who we knew to have a solid track record at one of the vendors and paid for their services on a time and materials basis, on the basis that they would come and work with us on site.

On the first morning we’d stationed the developer in a glass fronted conference room, and it became obvious that he was fielding a large number of calls from his employer. After an hour of this I invited him to turn off his mobile for the duration of his stay with us. His relief was obvious; the guy had a great work ethic and just wanted to get on with things and was tired of getting interrupted for support calls or input on other projects.

With no distractions, a clear specification, and a capable and committed developer we made rapid progress. So rapid in fact we completed the required work, plus some additional ‘nice to have’ capabilities for just 20% of the price of the original proposals.

The key was that the developer worked away from their office environment where they were likely to get distracted by meetings, support requests, other clients, assorted crises etc, etc.. CRM vendors tend to have a pathological hatred of their developers being off site because they are not available to handle meetings, support requests, other clients, assorted crises etc, etc., and will generally come up with an extensive range of reasons that this just isn’t possible.

If it’s fixed price work I’ve tended to go along with it, unless the project time-lines are particularly tight, but for time and materials work it’s generally a condition of the contract that work is on site with the client. This may entail an increase in travel expenses, but these are generally dwarfed by the productivity gains. The time and material approach isn’t right for all circumstances, but, as this example suggests, used appropriately it can be a devastatingly simple way of slashing implementation costs.

Something of a rant I suspect...

2009-07-20T15:10:00.003Z

Conspectus Magazine asked me for an opinion piece that was published this week under the title of 'Could do (a lot) better'. I suspect they might have preferred a more gentle piece on CRM and social media for example. Instead they got something of a rant:

Could do (a lot) better

During the fourteen years I’ve worked in the CRM industry while a lot of things have moved forward, some of what I would consider to be the fundamentals of success seem barely to have budged at all.

If we look at CRM technology there’s no doubt enormous strides have been made. The breadth of functionality has increased, systems readily support remote access, and there have been massive strides forwards in their flexibility and ease of configuration. There are a wealth of architecture and deployment options, and, with the advent of open source options, never has the power of CRM technology been available to so many people.

From an implementation perspective, we’re largely past the era of high profile failures, partly as a result of better implementation practices, and partly because the technology is easier to deploy.

But, while this is all good news, if you examine the rather more core issue of whether CRM technology is adding real operational value, the picture looks considerably less promising. In the main, the bulk of organizations seem to be using CRM technology in its most basic way, and are consistently failing to achieve its potential.

A lot of the responsibility for this, in my opinion, can be laid at the door of the software vendors. The knowledge is out there about the importance of strategic vision, sound supporting processes, and effective user adoption as being critical to success, but the vendors are not choosing to apply it, and worse, their approach is far from conducive to success in a number of other respects:

A sales obsessed culture – as a poacher turned gamekeeper I’ve seen the pressure salespeople are under to deliver results. The commissions they receive for making a sale can be extremely high and the penalties for failure painful. If you’re a salesperson struggling to make your quarterly numbers then what’s good for the customer is unlikely to be first and foremost in your mind. I’d suggest there aren’t many conversations along the lines of ‘hey boss, I know we could get the sale closed this month, but I think it might be an idea if they mapped out their requirements a bit more to check whether our software is the right fit for them’.

A lack of real world knowledge – for many involved in the industry there is very little appreciation of the real world practicalities of successfully applying technology. Take user adoption – from the early days of the CRM industry, getting people to use CRM technology consistently and systematically has been a challenge. The vendors have tried to address this issue by positioning their products as easy to use, but from a personal viewpoint I don’t believe there’s been any real progress in actually making CRM software easier to use in the last ten years. Instead the vendors might have been rather better off devoting their energies to non-technology based solutions such as honing implementation strategies and best practices.

As another example, when I issue requests for proposals for clients I’ll always ask vendors for an assessment of the client administration resources required to run their systems effectively. Strangely many will fail to respond at all, and those that do come in at widely differing levels sufficient at least to confirm that there is very little knowledge in the vendor community about what actually happens downstream from the initial sale.

A lack of resource – finally, as a result of their technology oriented approach, and, I suspect, a desire not to add complexity and length to the sales-cycle, the CRM vendor community has largely elected not to clutter up their product and service portfolio with the analysts, strategists, and experienced consultants who can effectively apply the power of the technology.

Perhaps in this respect they are victims of their own marketing hype. For years the CRM industry has sought to ‘educate’ their clients that CRM initiatives were simple and cheap, on the basis that this would best encourage software purchases. Having suitably established their client’s budgetary expectations, the market for the services their clients really need just isn’t there.

So in respect of generating value from CRM technology I’d suggest we’ve made very little progress in the last fourteen years. Where progress has been made, it’s been through pioneering users or a handful of consultancies like ourselves, rather than instigated by the CRM vendors themselves, and I don’t believe it should be that way.

Perhaps what surprises me most is that vendors have been able to get away with delivering so little real return for so long. Maybe the tougher trading environment will initiate a sea-change. After all we now understand there’s something fundamentally wrong with lending money to people who can’t afford to pay it back and labeling it risk-free debt. Perhaps a time is dawning where clients will realize that the august institutions of the CRM world need to do more to deliver on CRM’s remarkable potential.

Seven tips for phasing CRM projects...

2009-06-16T18:17:00.002Z

‘Phase your CRM project’ is one of those frequently offered pieces of advice to would-be implementers of CRM technology, but what does this really mean in practice? So, seven quick tips for phasing CRM projects effectively:

Do the minimal amount that gets results – it’s easy to over-engineer CRM systems, but it’s generally better to implement something reasonably simple which generates quick results, and build on it. This approach reduces the risk of spending a lot of time and money creating capabilities that later prove to be white elephants.

The first phase must be value generating – whatever you do in phase one must create compelling value, otherwise you will struggle to get resources for later phases. I see a lot of vendors promoting the ‘suck it and see approach’, where customers are encouraged to buy some CRM software and then experiment. This might be good for short term software revenues, but rarely produces systems that clients want to continue to invest in.

Resources dictate phasing – getting users to use a system in a consistent and structured fashion is one of the key challenges of CRM deployment. User adoption requires people on the ground winning hearts and minds and this tends to be resource hungry, therefore one of the key determinants of phasing is the amount of resources available to do this. Try and do too much in one go and the implementation team can quickly become overwhelmed.

User micro-phasing to maximize adoption – there’s only so much change that users can embrace at one time so breaking down a phase into a series of micro-phases, for example by releasing capabilities over time, can be an effective way of addressing the user adoption bottle-neck.

Schedule subsequent phases in advance – if your CRM project is to be phased it generally makes sense to ensure that the timing, content, benefits and costs of future phases are broadly defined up front. This helps ensure resources are available when you need them and avoids the need to go through a lengthy capital allocation exercise for each subsequent phase.

Reporting must be phase one – for reasons that I explained here previously CRM vendors seem to discourage users from worrying too much about reporting in the early phases of a project. Since reports are the key way for the management team to ensure that the processes that the system supports are being followed, relegating them to the ‘manyana’ file virtually guarantees system obsolescence.

Manage ongoing system enhancement requests carefully – over time users will identify ways in which the system can be improved and enhanced. These requests need to be carefully assessed, managed and prioritized to ensure they will create genuine additional value. It’s easy to load up future phases with features that, while meeting the demands of a few vociferous users, fail to generate any return on investment.

Reflecting on CRM failure....

2009-06-07T15:51:00.002Z

I was asked to speak on the topic of CRM failure this week. The following summarizes what I covered.

The occurrence of outright failure, where no system ever sees the light of day is exaggerated. I’m only aware of a few instances of outright failure and this normally occurs when the CRM system is being integrated into another system, and usually where there is a mismatch in expectations between client and vendor regarding the complexity of the integration.

The more common manifestation of CRM failure is what we might term ‘the lights are on but no-one’s there’. The system functions, but generates no meaningful value. There might, for example, be a database of sorts, but the data isn’t trusted as being up to date, the occasional salesperson might use it to add a note of schedule a call back, but there’s no meaningful management information.

In our experience about 80% or so of CRM systems fall in this category. Which is fine if that’s what users were expecting, but for most there was a grander vision when the project was started.

For those that get it right though CRM technology can facilitate very high returns on investment. The sales and marketing functions often operate with poorly defined processes with little support from technology. By re-engineering these processes and supporting them with an effective IT infrastructure companies can add substantial bottom line value.

In terms of avoiding CRM failure I picked out the following five themes:

Asking the right question – prospective users tend to ask the ‘what technology is right for me’ question. The question they should be asking is ‘how do I apply CRM technology to my organization in a way that generates results’. Technology selection is important but it’s just a part of what’s involved in successfully implementing a CRM system. Users often fail to appreciate that the technology won’t generate results ‘out of the box’ (however much some of the hosted vendors might like us to believe), and that how it can be beneficially deployed is often far from obvious, and even if the application is clear, there will generally be some measure of customization to support the client’s unique processes.

Finally, on this point there are users that recognize that implementing these systems is far from straightforward, but assume the CRM vendor will help them navigate the challenge. In our experience the good vendors understand the technology but not the front-line application of it. They are likely to adopt a ‘tell me what you want’ position rather than guide the user.

Create a compelling vision – many users of CRM enter a project with an expectation that good things will happen rather than having a clear understand of what problem they are trying to fix. However not only does the objective need to be clear, but it also needs to be compelling otherwise the project won’t acquire the resource and attention bandwidth required for success.

Design in detail up front – most clients purchasing CRM technology have only a high level understanding of what they are looking to achieve when they enter the vendor selection phase. As a result they purchase software at a point that vendors can only estimate implementation costs. This makes them vulnerable to vendors coming back with upwardly revised estimates once the implementation begins, and the lack of a clear understanding of functional needs increases the risk of purchasing a technology that doesn’t meet their real needs.

A better approach is to create a detailed specification of requirements up front which allows vendors to provide accurate pricing in a competitive environment. We would estimate this reduces purchase costs on average by 40%, and also reduces the risk of ‘scope-creep’ in the implementation phase.

The user adoption challenge – it doesn’t matter how well thought out your system, if you can’t get users to use it in a consistent and structured way then it won’t add value. The conventional industry approach to user adoption is primeval and is further evidence of my earlier contention that vendors are fine with technology, but not the application of it to a real world setting. My experience is that users invariably come back from training sessions with scant understanding of how to use the system and for most vendors a half day user training session forms the entirety of their user adoption strategy. While user adoption is a multi-faceted challenge, we would stress the need to carefully monitor and review the progress of each individual user, and provide a tailored programme of support recognizing existing habits are hard to break and new ones difficult to set.

A CRM project is not just for Christmas – which is a play on the advertising campaign that ‘pets are for life not just for Christmas’, the point being that since the value of CRM technology accrues over the life of the system, we shouldn’t treat CRM as a one off project, and recognize we need to support it for the long term. CRM systems are particularly vulnerable to change, for example changes in business strategy which aren’t accommodated, or the arrival of new executives unfamiliar with the system’s capabilities can quickly plunge a system into obsolescence. Maintaining a high performing system over time has cost and resource implications that companies need to budget for up front.

In summary, if we are to escape the 80% failure rate, then we need a business process oriented, rather than a technology focused approach. Successful CRM systems thrive in organizations that are able to adopt a process oriented approach. We need to be aware that that this rigorous approach is not in every organization’s DNA, and for many this structured use of CRM should be a series of small steps, or in some cases should not be undertaken at all – on the basis it’s better to ‘fail’ without trying than after the commitment of a lot of resource and energy in a situation that was never conducive to success. For those that are prepared to go for it, the rewards are there. In a world where it’s increasingly to differentiate on the products and services we offer, when out latest and greatest can be ‘me too-ed’ virtually overnight, the effective use of information technology (not just CRM) is still a rare enough phenomenon as to represent a huge un-mined seem of business efficiency and competitive advantage.

Independent CRM consultants and their role outside CRM software selection...

2009-05-16T15:32:00.002Z

One of my training partners was telling me about one of his client’s purchase of a Microsoft CRM system, as we were out running this morning. As the story went the client had settled on MS CRM as the preferred technology and then went on to find an implementation partner. They solicited two bids. One came in a £60K and one at £250K. On the basis of price, not surprisingly they decided on the former.

I found it interesting that a user wouldn’t seek advice from a CRM consultant in this sort of situation given the wild disparity of pricing, but it didn’t altogether surprise me. This reluctance to engage outside help in these circumstances tends to stem from a number of false assumptions:

That selecting the right technology is the key challenge, and once you are settled on that everything else is straightforward. In reality while technology (and implementation partner selection) is very important, it is by no means the toughest challenge in applying CRM technology. The areas of strategy, process design, and user adoption are far more demanding.

That the quoted price in an accurate representation of what you will end up paying. Since most CRM vendor pricing is provided on indicative or estimated basis what the client ends up paying can be an order of magnitude different from the initial quoted price. The client either has to dumb down the requirements or accept the shift in budget.

That CRM vendors have the ability and inclination to deliver a system that significantly improves performance rather than a system helps them meet their sales targets. The two objectives rarely coincide in my experience.

While I don’t think these myths will be debunked overnight it will be interesting to see if independent CRM consultants do get more involved in situations where the technology for one reason or another is already selected. There are a number of, what strike me at least, as compelling reasons why we should, in that they help the client:

Achieve more - through using experience and understanding of how businesses operate to create the vision for a high pay-back system, and project management skills to make it happen.

At a lower price - primarily achieved by designing the system up front and letting vendors bid on a fixed specification which allows the comparison of like with like in a competitive environment, and reduces costs through effective negotiation.

With less risk - through experience and proven implementation methodologies.

With less internal disruption - by outsourcing what can be highly time consuming internal implementation activities.

I suspect that the role of the independent CRM consultant will change over time as people realize the technology question, while important, is just a part of a more demanding challenge – how do we apply CRM technology in a way that truly changes our business? When organizations start asking this question things are going to become very interesting.

The tyranny of the CRM change request...

2009-05-09T13:10:00.001Z

Conspectus asked me to write an opinion piece for them on matters of my choosing pertaining to CRM technology. While I suspect they would have preferred something rather more topical regarding CRM and Twitter, or CRM and H1N1 for example, I warmed to the topic of the CRM vendor’s fixation with selling software as being responsible for most of the ills of the industry. I won’t detail the line of reasoning, suffice to say if and when the article gets published I’ll provide a link to it.

I’m deeply immersed in taking a couple of sites live at the moment, and was therefore reminded of another facet of CRM vendor behaviour that supports my ‘software sale fixation’ theory – the change request. As I outlined in a recent post on the CRM design hell, vendors generally require you to sign off a design which they will go away and build, and if that doesn’t happen to be what you wanted when it’s delivered, they will raise a change request for you to sign off which will generally entail you paying them money to go away and change it.

In principle this is a sensible policy since it’s designed to prevent the phenomenon of ‘scope-creep’ where the client keeps adding new requirements. In practice however CRM vendors – and I suspect software vendors generally – use it in a way that defies some of the basic practices of customer service fully accepted by virtually every other area of commercial endeavour – primarily the notion that if p*** off the customer they are unlikely to come back and do more business with you.

Imagine if you went to a restaurant and ordered the soup and what turned up was mere a teaspoon full of your selected starter, and when you remonstrated with your waiter, you were informed that they had indeed delivered ‘soup’ and if you wanted more then of course you could place another order. Predictably, unless you were on some radical diet, you might feel rather upset, and might well choose, amongst other lines of protest, not to visit the establishment again.

While the two vendors I’m working with at the moment have proved pretty good in their use of the change request, they are very much the exception. Over the years, time and time again, I’ve seen vendors bludgeon their clients into submission with the heavy handed use of the change request process, and it creates such bad feeling I find it difficult to fully fathom why they do it.

The focus of vendors seems to be on what is ‘signed off’ rather than what is right to help the client’s business. And as long as something is signed off the vendor is generally happy, regardless of whether that something is in the client’s interests or not. Thereafter the standard operating procedure seems to be to maximize the short-term profitability of the client by using the change request procedure to limit even inconsequential changes.

This practice reflects the following aspects of the CRM vendors’ world-view:

That their role is to sell technology NOT deliver business solutions – however much ‘solution’ may litter their marketing literature and sales presentations.

That a project is a ‘one-off’ spend with the vendor. That ongoing revenue is seen as a nice to have rather than a fundamental requirement that needs to be catered for.

If things are to change the vendors need to understand that they can implement genuine business enhancing solutions, and when they do they will have a client happy to invest in their technology over the long-term. If and when this world-view changes then the change request may finally revert to a sensible tool to manage projects.

On CRM and User Acceptance Testing...

2009-05-02T17:41:00.001Z

Having sat through countless sales presentations over the years where vendors have rhapsodized about their carefully honed implementation methodology I can observe that the reality rarely measures up to promise of the pitch.

One manifestation is the quality of what gets delivered into the user acceptance testing (UAT) phase where the client assesses whether the development work undertaken by the vendor meets their requirements. It’s at this point that the vendor can, to use a sporting metaphor, throw their client a ‘hospital pass’.

In principle, and according to the fluently presented glossy implementation methodology, what the vendor should provide to the client is a rigorously tested system, which can practically be waved through UAT.

In practice however, the rigorous testing phase can quickly be dispensed with if the vendor finds them self under time or budget pressure, and the client effectively gets landed with the vendor’s testing responsibilities, or worse, gets to try and test something that’s effectively still in development – the equivalent of putting up the wallpaper while the plasterer is still at work. What might have been a relatively trivial piece of work is transformed into a death march as the bug count ratchets up and up.

Just to make this all slightly more pressurized, because UAT is pretty much the final step before live, most of the associated live activities are all now scheduled, and there’s relatively little scope to move dates out to reflect the unexpected influx of work, and so the test team ends up absorbing the workload the best way they can – generally dispensing with life’s luxuries such as sleep.

There are however a few things that can be done to help address this:

Have a detailed mutually agreed and understood design specification that gives you something to test against – this limits the scope for misunderstanding as to what should be delivered

Give yourself plenty of wiggle room in the project plan in order to absorb the unexpected developments that will inevitably occur.

Pay for implementation work on the basis of achieving defined milestones, and make sure one of those milestones is the delivery of a high quality system into UAT. I’m also wondering, though I’ve yet to try it, whether it’s worth offering vendors bonuses for hitting quality targets, just because of the potential downstream savings.

Make sure your vendor has scheduled for resources to be available to quickly fix the issues you identify, because if developers get allocated to other projects, you could be facing a long wait.

Assume the worst, because you’ll generally be proved right, and allow more time than you possibly think you’ll need.

In summary, while UAT is one of the final hurdles in the implementation process, it’s been responsible for more than its fair share of project delays, and has tempted many a project into the potentially fatal act of going live with a part-cooked system. As with many aspects of CRM implementation, it’s worth treating cautiously.

Did I call it wrong?

2009-04-18T16:29:00.002Z

Back in October I made a very downbeat assessment of the state of the economy and its impact on the CRM industry. While I winced hugely when Joel Spolsky announced the end of the tech recession back in February, a straw poll of vendors suggests that while the last quarter of 2008 was pretty dire, the first quarter of 2009 has been largely business as usual. So, what are we seeing in the CRM market:

The project pipeline is much more volatile with a much great likelihood that ‘done deals’ can be postponed or cancelled, making it much more difficult for vendors to plan their businesses.

Vendors have been making staff redundant.

Some of those vendors seem to have made too many staff redundant in response to the Q4 lull, and are finding themselves under resourced after the Q1 up-tick.

There seems to be much more movement in terms of end users shifting support contracts between CRM resellers – presumably because of concerns over long term viability and because some resellers will have a reduced quality of service because of cost cutting.

What I haven’t seen is much evidence of CRM vendors or resellers going out of business or consolidating, but it’s still early days. However at this stage it seems the CRM market is substantially more robust than I was expecting, and with a few potential green shoots appearing in the economy in recent weeks perhaps my dark predictions were misplaced. This may be because companies recognize that even in recession winning and retaining customers is vital, however I also wonder if we’re seeing the fulfillment of projects which were initiated before the financial melt-down and that we may see a slow down later in the year.

Ultimately I’m still not sure I’m wrong, but I will concede there is the possibility, and in this respect at least I'd be delighted to be proved so.

Unlocking revenues through better b2b customer management...

2009-04-04T10:51:00.003Z

A lot of companies underestimate how much value they have in their customer base, and this may never be more important than in the current climate. As independent CRM consultants we're currently doing a lot of work to help clients unlock that potential. A recent article of ours in CustomerThink explains some of the ways CRM technology can support this in a B2B environment - 'Cash in the Attic: Unlocking Customer Value with CRM Technology'

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

2009-03-26T19:29:00.001Z

The final major flaw with the functionality led approach to CRM requirements gathering is the Rumsfeldian notion of the unknown unknowns. Users, who invariably haven’t used CRM technology before, are expected to articulate a complete vision of what they want from a system, and invariably are only able to produce a handful of bullet points.

Even those who have been exposed to CRM technology before, generally because the system they used wasn’t well set up, and/or the deterioration of memory over time, and/or their exposure to a limited sub-set of functionality, tend to struggle to produce meaningful requirements.

On the other extreme, this approach does occasionally produce users who can create a very detailed but ultimately Frankenstein-esque vision of a system out of all context with what’s deliverable from conventional CRM technology.

The implications of the above are that:

The stated requirements are so limited that most packages in the market can meet them, and so the meaningful comparison is nigh on impossible.

Key functional requirements are missed which increases the risk of purchasing a CRM package that doesn’t meet the ‘real’ needs. For example I’ve seen a lot of organisations with very sensitive data security needs fail to document any data security related requirements.

Or in the ‘Frankenstein-esque’ situation the stated requirements are so ‘unusual’ that vendors are discouraged from bidding, and those that are received have huge price tags. I know of several expensive CRM tendering exercises that produced no responses at all, with all invited vendors deciding to ‘no bid’.

Anyway, that rounds out why the functionality led approach to requirements gathering doesn’t work, next time I’ll try and articulate a better way…

And now also Tweeting....

2009-03-07T11:10:00.003Z

Had I been a venture capitalist a few years back, and, had I entertained a pitch from the folks looking to develop Twitter, then here’s what I would have said (choking back tears of laughter): ‘OK, so let me get this straight, you want to develop this site right, and it’s like a blog right, but your big thing, your really, really killer differentiator, is that your going to limit the blogger to – what was it again? Oh yeah 140 characters!?!?!......’

I didn’t get Twitter. Like I didn’t get why someone might not be satisfied with their standard mobile ringtone – still don’t for that matter. In the end, and solely because a friend twisted my arm with sufficient violence, I signed up for Twitter and started to ‘Tweet’.

A couple of months on I probably still don’t fully get it, but I’m finding it oddly addictive. I’m not sure from a marketing or promotional standpoint whether it can or can’t add value (and that’s not really why I do it anyway), but as a means of accessing a torrent of information from the people you choose to follow (mine include Lance Armstrong and Guy Kawasaki), it’s unrivalled.

My own Tweets are an eclectic mix – the last 48 hours or so have included Coventry City FC, the M25, Port of Spain, and a bit of CRM, and are probably best branded work in progress. Should you already be tweeting and want to follow, you can find me here.

Six tips to surviving CRM design hell...

2009-03-05T18:48:00.002Z

Having spent the past six weeks in CRM design hell, I thought I’d share some tips on surviving the process while it was freshly seared on my memory. Trust me, CRM design work, rather like a prolonged course of dental treatment, isn’t the most fun way to spend your time. For those of you who haven’t been through CRM design before, it’s probably appropriate to first explain what it is: CRM design is where, having selected the CRM technology you wish to implement, you sit with your chosen vendor, and work out how your CRM requirements will be delivered in the new software.

On the surface this might not seem exactly onerous, but what you agree at this stage is what the vendor will go off and create, and if what they create doesn’t turn out to be quite what you wanted, then the vendor is likely to point out that, since you signed your name in blood that this was indeed what you wanted, they’ll now have to start all over again – and of course charge you for the privilege - so the project ends up taking a lot longer and costing a lot more than you intended.

In reality the design phase can be pretty straightforward, assuming the requirements are pretty close to the out of the box software. If however you require much in the way of customization or integration, the design phase will normally incorporate the dreaded design specification which you will be tasked with reviewing and swearing the requisite blood oath on the life your first born by way of confirmation of its accuracy.

Reviewing design documentation is to say the least challenging, so my six tips for surviving the experience:

Start with a good set of requirements – I won’t dwell on this as it’s a frequent theme in this blog, but suffice to say if you have a detailed well thought out set of CRM requirements - apart from saving you lots of money – it gives a ready means of checking off that everything you previously said you wanted is indeed what your vendor is planning to give you (vendors having tendency to slightly selective memories when it comes to things they feel might be awkward/expensive to develop).

Do not expect it to be in a language you understand – Design specifications are written for two audiences: you, as the client to sign off, and the vendor development team so they know what they’re meant to be developing, but actually mostly the vendor development team, who are generally extremely technical, which you may or may not be, and work with the selected software day in day out, which you probably don’t. So it’s a bit like being asked to sign a contract which is written in, say Greek, when English is your first language. So allow a lot of time (even a straightforward design document can take several days of work), and stock up on coffee and paracetamol.

Make sure you understand every word – Even innocuous phrases can have deep meaning, so these documents don’t suit a quick skim. The greatest mistakes I’ve made on projects have been where I’ve figured something’s been too arcane for me to take the time to fully understand, so my advice is no matter how dumb you feel the questions may be, keep asking them until you are 100% certain you understand what’s being said.

Expect trouble – You might be wholly convinced that your selected vendor are a pretty switched on bunch, and they might well be, but they will still make mistakes and omissions, and a lot of them, so don’t get lulled into thinking that you can trust them, and avoid the necessary investment in coffee and paracetamol. Even on a modest requirement I figure the vendor has done a pretty good job if I find less than a hundred issues on the first pass.

Finished reviewing? – the journey just begins – While you might feel a sense of a job well done having completed your review of the design, there’s normally plenty more to do. Curiously, many design specs have more mistakes in their second iteration than the first – a phenomenon for which I’m unable to offer any logical explanation. Half a dozen iterations isn’t that unusual for a moderate amount of customization, so budget for coffee and paracetamol accordingly.

Make sure the vendors have the resources available to action your input – You’d figure it wouldn’t surprise vendors that clients actually reviewed their specs, but it seems to. Once you’ve completed your review you would hope the vendor would be able to process your input in a timely manner, but if the relevent staff member has been allocated onto another project this isn’t going to happen, so it’s always wise to make sure that resource is available to quickly process the necessary changes, otherwise very lengthy project delays can ensue.

While this post is slightly tongue in cheek, the design phase might seem innocuous, but it really does catch a lot of organizations out. Very substantial overruns can easily result, so it’s really worth the considerable investment of time and energy required to get it right. There aren’t unfortunately any short-cuts, but coffee and paracetamol really do help.

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

2009-02-28T12:12:00.003Z

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

2009-02-21T19:14:00.002Z

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

2009-02-20T09:35:00.001Z

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

2009-02-18T08:49:00.001Z

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

2009-02-14T14:52:00.004Z

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

2009-02-03T12:07:00.002Z

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.

Chav-gate

2009-01-30T11:04:00.001Z

In a recent post on CRM and social networking, I suggested that the growth of forums, blogs, wiki’s etc. will mean companies have to pay greater attention to the customer experience, because never before have customers had as much scope to broadcast their opinions, and never before have people been more inclined to listen and act on them. As an interesting case in point we saw Chav-gate this week where a holiday company sent an email marketing campaign suggesting its holidays were Chav-free (wikipedia definition of Chav here for non-UK readers). Unfortunately one of the recipients was offended and decided to blog about it. Anyway before long the incident had made the front page of the BBC news web-site. I’m not certain whether this represents good or bad publicity for the holiday company ultimately, but it does illustrate the impact a small number of upset customers can have.

Do I stay or do I go? - when to change your CRM reseller...

2009-01-24T14:36:00.002Z

One interesting question that came up this week was ‘when is it right to change my CRM reseller?’ To position this a bit, a lot of CRM packages, Microsoft CRM being a good example, are sold through resellers and implementation partners rather than direct from the software vendor. This approach has its attractions in that it allows organizations to move on if they’re unhappy about the service they are receiving without having to purchase a whole new suite of software. Deciding if it’s right to move on though can be a challenge.

One of the keys is to determine why you’re looking to move. If your concern is that your existing system isn’t delivering value, then, in my view, a change of reseller is unlikely to be the answer. As I’ve covered ad nauseum in this blog, vendors and resellers, while understanding their own technology, don’t get business. They fail to implement high performance systems because they don’t have the knowledge and capabilities to apply their technology operationally in a way that generates value. A switch of vendor in these circumstances is unlikely to solve the problem, and is likely to waste a lot of time and money. It would, and I know I have a big fat vested interest here, be far better to look to an independent CRM consultant to help bridge the gap between technology and profit.

If your current vendor is holding back the performance of a successful system, then it may well be right to move. Before you make this decision however it’s worth noting that there’s more of a cost than many suppose in changing supplier. Firstly there’s going to be a time cost in seeking out and vetting alternative resellers, then there’s likely be a cost associated with getting them up to speed with your system, and then the potentially very significant expense of them wishing to re-engineer your system into a form they are happy to support.

Another consideration is that, in my opinion at least, the average UK reseller quite frankly isn’t very good. If you broke the reseller marketplace down I’d suggest 10% fall in the rogues and incompetents bracket, 70% in the poor to just about OK bracket, 15% in the good bracket, and a mere 5% in the very good to excellent bracket (hopefully that all adds up). In other words if you were to randomly select a reseller, the odds are you’re not going to get a very good one, which means the process of selecting a new partner deserves considerable care and attention.

Over the many years I’ve been involved in CRM, I’ve seen great systems destroyed as the result of the injudicious selection of a ‘new’ reseller, and I’ve also seen great systems destroyed as the result of the lack of a timely response to diminishing standards of support from an existing supplier. As I touched on in a recent post about how CRM vendors may be impacted by the economic challenges we are all facing, I noted that the one of the first casualties of tougher times for vendors and resellers will be the quality of support they are able to provide, so I suspect more and more CRM users are going to be faced with the ‘do I stay or do I go’ question in the next few years.

My advice would be that any move shouldn’t be taken lightly bearing in mind the costs of moving that I touched on earlier. It’s generally sensible to engage in a dialogue with an existing vendor to spell out the level of services you expect, with a view to managing an appropriate improvement in performance. If this can’t be achieved and the decision to move is made, then I’d suggest that significant effort in placed in locating one of those rare high performing resellers, and then even more effort placed in making sure you get the best out of them. As the saying the goes ‘the grass may be greener on the other side but you still have to mow it’.

5 ways to unlock customer potential in a B2B environment...

2009-01-23T18:04:00.001Z

Mycustomer.com asked me to do a guest blog-post for them. The piece I put together was around how CRM technology can support the growth of business from the existing customer base in a business to business environment. Since this can be reasonably accessible ‘cash in the attic’, it seemed fairly topical in the current environment.

The post can be found here.

A blurring between on premise and hosted CRM software...

2009-01-20T18:26:00.001Z

Once upon a time it was pretty simple. If you wanted hosted CRM software you paid per person per month. If you wanted your CRM software in-house you purchased a perpetual license up front.

In ‘The Knives Your Sales People Should Have’ Brad Feld points out it doesn’t have to be this way, and probably won’t be moving forward - ‘In 2009 (and going forward) customers will buy software using both perpetual licensing and subscription licensing, regardless of how the software is deployed’

In other words, whether I want my software in-house, or hosted, I should be able to choose to pay up front, or per person per month. I think he’s spot on, and we’ll see a much more flexible approach to pricing models for CRM software in the coming months as the recession forces software vendors to listen rather more carefully to how their customers want to pay for and deploy their software.

Top CRM blogs of 2008...

2009-01-16T18:59:00.001Z

It’s always good get positive feedback on the blog, and it was gratifying to make it to number 5 – up from number 10 last year – in InsideCRM’s top 20 CRM blogs of 2008. Thank you InsideCRM, who’ve done a great job themselves this year on the blogging front, particularly on the Entellium story.

A CRM expert - apparently...

2009-01-08T19:35:00.006Z

SearchCRM has kindly invited me to join their CRM 'expert' panel. So if you are interested in my answers to questions such as:

The pro's and con's of developing a CRM system in-house

The challenges of implementing open source CRM

The top 10 implementation pitfalls

How to measure CRM effectiveness

Then go here. You may have to dodge an advertisement or two and sign up (for free). Obviously feel free to send any questions to the site or to me directly if you prefer.

Why vendors may learn to love independent CRM consultants...

2008-12-29T15:55:00.001Z

I get the impression that most CRM vendors are at best deeply suspicious of CRM consultants. Not surprisingly, as a CRM consultant myself, I’d argue the negative impression is undeserved, and that we provide considerably more benefit to vendors than they realize. The common complaints are that access to the client is managed and therefore they don’t feel they have control of the sales cycle, and that the purchase process is likely to be more competitive and therefore the odds of winning are longer.

While there’s some truth in this - vendors have much less scope to use spin or charm to secure the sale - I suggest the odds of securing a consultant run sale are higher than the average prospective sale simply because the contract will be awarded to someone, as opposed to most prospective sales which peter out with no decision, generally because the business case hasn’t been made.

It’s in the area of business case generation and general CRM project planning that independent consultants add a lot of value to both client and vendor. Their involvement means that by the time a vendor becomes involved, the foundations of a solid business case and appropriate funding are in place. I’ve worked with clients who’d been talking with vendors for years, but who had never proceeded because they hadn’t satisfactorily determined how the technology would help them.

Establishing business cases is something I think vendors are largely very bad at. To an extent this is because end users are wary of vendors and don’t open up in a way that facilitates the process, but mainly because vendors tend to be technology rather than benefit focused. This blinkered approach is partly about comfort – it’s easier to talk about something you are very familiar with (your software) than something you are not (the potential client’s business) – but also about experience: it’s challenging to apply technology to a potential client’s unique business unless you’ve considerable operational experience and insight.

Aside from helping create the environment in which a CRM project will happen, the consultant also benefits the vendor by smoothing the path of the CRM implementation process itself. Consultants will advise clients on key planning issues such as funding and resourcing, as well as facilitate effective requirements gathering. There are consequently fewer things that go wrong in the implementation process which increases project profitability and customer satisfaction.

It’s in this last respect that vendors particularly benefit. The projects we work on generate significant value to the end user which means they in turn are more likely to invest further in the system. As I’ve argued repeatedly in the past, the average CRM implementation generates little return, and therefore receives little on going investment. The presence of the CRM consultant therefore produces a client that has a considerably higher than average life time value, and can provide considerable reference value.

Ironically, many of the projects we work on become flag-ship case studies for the vendors, though our role in the process isn’t generally acknowledged. I suspect this is because CRM vendors associate us solely with vendor selection activities rather than the business case generation, planning, budgeting, and requirements gathering activities that are vital to ultimate success.

The only vendors that should dislike independent CRM consultants are those with something to hide. Sadly, there a quite a number who rely on deceit rather than candour to win business. They rarely appreciate our work in exposing their fabrications. Even this of course is beneficial to the honest majority in the vendor community because it helps ensure decisions get made on a level planning field, and that dishonesty doesn’t prosper.

Perhaps I’d be naïve to figure on getting many more Christmas cards from vendors next year, but in time perhaps more will appreciate that the end user isn’t the only beneficiary of our involvement.

CRM and social networking...

2008-12-20T13:07:00.003Z

I was quoted in Computing the other week making somewhat unsupportive remarks about the CRM vendor’s attempts to harness social networking. In essence my feelings are that companies need to understand the impact of social networking rather than concern themselves about taming it.

If we go on a brief historical tour, then once upon a time it was relatively easy to control the image of a brand, and that image could be many steps removed from reality. A company could take a fairly ordinary product and with some clever television advertising enjoy huge success.

Then the technology tide turned. The arrival of the TV remote control meant that people could change channel when the ads came up, or use a video player to fast forward. The arrival of Sky meant that viewers were no longer limited to four channels. And then there were a plethora of new forms of entertainment, such as computer games and the world-wide web, which meant that advertiser’s no longer controlled our attention.

If that wasn’t bad enough, then along came what became known as web 2.0., where people were generating their own content through the likes of blogs and social networking sites. The problem with user generated content was that companies had no control as to what was said, and, perhaps more importantly, people took notice. Decades of exposure to advertising meant consumers were highly resilient to marketing messages, but people were happy to listen to their peers.

So when I do my Christmas shopping and I’m looking for the best indoor aerial booster on Amazon, how do I decide between the hundred options I’m presented with? Simple; I read the customer reviews. What did other people who previously bought the products I’m looking at think of them? Rather than take any notice of the carefully crafted marketing literature the manufacturer has kindly supplied, my purchase decision is made purely on the basis of something the manufacturer can’t directly control - the opinions of their customers.

The reaction to the impact of web 2.0 by many companies though has been ‘how do we tame this to support our own objectives’. Hence we see the sort of initiatives outlined by Salesforce.com and Oracle in Martin Courtney’s article. It strikes me however that it’s rather more useful to know there’s a large shark lurking where you’re about to go swimming, than to try and teach it to become your friend.

As the internet becomes closer and closer to providing people with perfect information about the products and services they are about to buy, then the appropriate response should be to focus on managing the reality rather than the image. If I claim to be the finest widget manufacturer in the world, then I need to ensure that the quality of all my interactions with customers, prospective customers, and all those who may influence customers and prospective customers, is consistent with that claim.

If my widgets are indeed fine, but my customer support department leaves a lot to be desired, then this reality is likely to be recorded in blog posts, forums, and social networking sites, and my ‘finest’ image is shattered no matter how hard I work on the marketing side.

Therefore if CRM has a role to play in the context of social networking, it should be to help organizations manage their reality, and ensure that people experience consistently high standards across all touch points. This is not something I feel companies generally do terribly well, and I suspect many would benefit from switching resources into this area. After all, the problem with negative comment on the internet is that not only can’t you control it, but it doesn’t have an expiry date; it can be losing you business years after the search engines first picked it up.

How to revive a failing CRM system...

2008-12-04T17:58:00.002Z

The following is a copy of an article I wrote for Winning Edge Magazine published by the Institute of Sales and Marketing Management (ISMM) under the title 'Can we fix it, yes we can' where I attempted in 700 words to explain how to revive a failing CRM system:

Can we fix it, yes we can

There’s been a lot of bad press about customer relationship management (CRM) technology over the years. While a lot has been made about CRM failures, the reality is that only a very small proportion of implementations actually fail in the sense that the system doesn’t go live. Where CRM has commonly failed is in its ability to positively impact the bottom line.

As a thirteen year veteran of the CRM industry I’d estimate that 80% of CRM systems seriously under-perform their potential, with the majority generating very marginal, and in many cases negative value for their owners. Most systems are limited in scope, and usage tends to be occasional and unstructured. So how did we get into this state? Two reasons I suspect:

Firstly, CRM vendors are, in general, first and foremost motivated and equipped to sell software, as opposed to deliver benefits. They may truly believe their software delivers value, but there is a big gap between raw technology and an implemented system that generates operational benefit. In particular vendors have failed to appreciate the importance of analysing and encompassing their clients’ business processes, and have struggled with user adoption.

Secondly, for those systems that do bridge the gap, many have failed to remain relevent over time. This is often because there has been insufficient maintenance of the system, or the business and changed and the system hasn’t adapted.

While businesses may be able to overlook the fact that their CRM technology isn’t delivering on its promise in the good times, the tougher economic environment means that these systems are letting them down just when they need them most. The need to attract and retain customers has never been more pressing. The good news is that it’s often relatively easy to turn a CRM system round, and with the investment already made, this can often be achieved without significant additional expenditure.

Incidentally, if you aren’t sure whether your CRM system is performing or not, one quick check is to review the reports generated by the software. If you can’t find any useful, comprehensive, or accurate data about the running of your business you can safely assume your system isn’t doing a lot for you.

So how do you get your system back on track? The following are the key steps:

· Define what you want your CRM system to do. This might be to improve the management of leads of enquiries, better control the sales process, enhance the customer experience, or reduce the cost of handling sales orders, either way it’s critical to understand what the end objective is.

· Map the business processes required to deliver the defined objectives. This may be a case of re-engineering what you already do or developing new processes from scratch.

· Document how your processes will work within your CRM system. There are a number of ways you can do this, but we tend to create process diagrams in Microsoft Visio, and annotate how the system is being updated at each step in the process. It’s also worth creating mock ups of any screen customisations that might be required.

· Make the changes to the system. Since many CRM technologies are highly user configurable, this may well be something you can do yourself. If you do need the help of your vendor, then the tight specification generated through the previous steps will allow you to minimise costs.

· Clean up your data and ensure the information in your system is complete and up to date.

· Train, train, and train some more. Comprehensive user adoption takes work.

· Ensure that you have reports in place to track the performance of your processes.

· Monitor usage carefully.

· Continue to finesse, improve, and enhance your system over time.

There are massive benefits to using CRM technology to control your key customer facing processes. Not only does it facilitate a host of operational efficiencies, but utilising the notion that you can’t manage what you can’t measure, one of the key benefits is being able to continue to improve over time. Your CRM system may not be doing much to help you today, but getting things back on track might prove the difference between prospering and failing in difficult times.

CRM and improving order fulfillment...

2008-11-27T17:25:00.001Z

As I’ve touched on in previous posts, the art of getting value out of CRM is to embed key business processes within the technology. While a lot of attention gets paid to sales and marketing processes, ‘downstream’ areas, such as order fulfilment, are often overlooked but often offer rich potential to add value to the organisation.

Let’s take a hypothetical example. A company sells widget making machines. When an order is received for a widget making machine, there are a wide range of activities, involving a lot of different departments, before the system is installed and paid for. So, in this example, there might be a need to complete contracts, arrange finance, send a welcome pack, survey the site, ship the machine, install it, train staff on it, activate the support contract, handover from sales to account management, invoice, etc. etc.

This is all very difficult to do, or do well at least, without any central coordinating technology. By embedding these processes in an enabling technology like CRM, a range of benefits may accrue. For example:

The fulfilment processes becomes faster with less manual handovers.

There’s less work involved in fulfilling an order, and that work can often be performed by less skilled people.

There’s less of an overhead in monitoring the process, the system can identify the exceptions.

There’s less scope for error, so the quality of delivery goes up.

With fewer errors there’s less management time spent fire-fighting problems.

Cash flow improves because orders are shipped faster, and, since quality is higher, there are fewer reasons for customers to delay payment.

Better visibility of problems and bottlenecks in the process allow the process to be further tuned to increase performance and quality.

The system supports more sophisticated processes that allow customer satisfaction generating activities to be integrated in a way that was impossible with manual systems.

Customer satisfaction increases, which, in turn, ripples through our Web 2.0 enabled world to increase order volumes

OK, so you’re almost certainly not selling widget making machines, and this is a very hypothetical example, but we’ve seen a lot of benefit in managing a wide variety of fulfilment processes in CRM. Funnily enough, it’s often not the most obvious processes that ultimately generate the greatest value.

Getting a CRM education...

2008-11-20T18:55:00.004Z

One of the points I made in a recent post on CRM requirements specification, was the part that education plays in CRM requirements gathering. In brief, the more people understand about the use of CRM technology, the better their contribution to the requirements gathering process.

Expanding on that a little; the more people understand about CRM technology and the realities of implementing it, the more likely the overall project is likely to be a success. The question is ‘where do you get that education?’. And that isn’t so easy.

Sure, it’s no challenge to see as much CRM software as you care to view. There’s no shortage of vendors more than happy to show you their wares, but what about the ‘realities of implementing’ part; now that’s a challenge.

In fact the realities of implementing CRM are something the CRM vendors would probably prefer you didn’t know. They are inconvenient details that can interfere with the main event – selling software. Since the vendors tend to dominate the airways, then there’s not much ‘reality’ available.

Anyway, this all leads to my last plug for a while at least. We’ve launched another new service (the last for a while - I promise) the ‘elegantly’ named CRM Executive Briefing service, which is designed to provide would be implementers, or indeed re-implementers, with an executive primer on the realities of implementing CRM technology. Further information can be found here.

CRM - buyer beware

2008-11-09T15:28:00.001Z

I was talking to a salesman the other day about a sale he’s working on. We discussed his potential client’s requirements, and I asked him what pricing he was putting forward. The figure he came up with was considerably less than I would have expected, and considerably less than I figured it would take to implement a good system. When I asked how the figure had been worked out, the salesman explained that there were a number of companies bidding, and his proposal was geared to what he felt the customer was going to be comfortable paying.

The salesman in question is a good guy, and I’d consider him to be pretty ethical in his approach. In essence he’s just playing the game. His job is to sell software. If he were to say to the client ‘look what I’m proposing is double what my competitors are offering, but I think it’s what you need to get a great system’ the chances are they’d figure he was trying it on and would buy elsewhere.

And this to my mind is the heart of the issue with CRM; vendors will sell what they think customers are prepared to pay, not what’s necessary to get the job done. For example, I suspect most people in the industry understand that user adoption is a big issue, but know that if they put in the package of services to address it, it’s going to be challenging to get it signed off by the customer in a competitive environment.

I think this problem has got worse rather than better in recent years with the advent of the software as a service (SAAS) market. Apart from the need to install software, a minor part of the implementation process, SAAS offerings are no less free of the need to offer services than their on premise counterparts. Services however just don’t seem to fit well with the SAAS business model, and I’ve had senior SAAS executives tell me that their focus is subscriptions, and services are seen as a necessary evil required to win new business rather than a source of revenue in its own right.

This isn’t going to be an easy problem to solve. Vendors have a driving need to sell software, and it isn’t in their interest to identify things that might make that process any more difficult. People like us may give the independent perspective – and you can be sure we’ll continue to work hard to do so - but the airwaves are dominated by the vendors. Some day perhaps one of the vendors will take a stand, but until that time, buyer beware.

An explanation as to why implementing CRM may or may not be easy....

2008-11-03T16:27:00.002Z

I was asked this week what the pit-falls were of implementing CRM technology. This is the sort of question that can tempt you into gushing out a long list of potential hazards, but, when you come to think about it, for many, maybe most people there are very few pit-falls in implementing CRM. If all you are looking to do is to keep track of your contacts, or remember to call Fred again in January when we know he’s go some more budget, then it’s pretty hard to go wrong.

Where CRM can have a far bigger impact is managing the wider range of business processes involved in winning and retaining customers. And since whenever I mention the term ‘businesses processes’ people’s eyes tend to glaze over, and I generally sense they are losing the will to live, I’ll try and illustrate what I mean with a few use cases:

A capital goods manufacturer spends a significant sum on marketing in order to generate leads for the sales force. The sales force is very good at following up leads where there is an immediate intention to buy. They are very bad at managing leads where the interest is longer term. The company uses CRM technology to help it better track those leads. It creates processes to ensure leads are never lost, and that longer term leads are returned to the marketing department, who, through carefully developed campaigns, nurture them until they are sales ready. Lead to sale conversion rates increase significantly, and since small changes in conversion rate have a highly leveraged impact on profitability the company grows significantly.

A company sells a wide range of IT products and services. It has a large customer base, but the sales team tend to focus on winning new business. Relatively little attention is given to expanding the range of products it sells to its existing customers. The company introduces a new set of account management processes. These require the sales team to identify for each of the customers the products and services they might buy, but currently don’t, and plan how these will be promoted. This planning process is managed through the CRM system. The shift to a proactive planning approach generates a significant growth in sales.

A membership organisation offers a help-desk service to its membership. Contact with members is not systematically recorded. The company introduces a CRM system to ensure all calls to the help-desk are logged. The company automatically generates customer satisfaction surveys for all calls. The statistics for the number and type of calls received, and the related satisfaction levels are carefully analysed. The company is able to improve the quality of its service, and reduce call volumes by proactively addressing common issues. Membership renewal rates increase.

A housing association has a legal obligation to track and address complaints in a timely way. Complaints are logged in a spreadsheet and allocated to staff to follow up. The administrator spends a lot of time chasing up responses, and from time to time complaints fall between the cracks. The association implements a CRM system. The system tracks not only complaints, but also other less ‘formal’ expressions of dissatisfaction as well as the compliments it receives. Careful monitoring of this process allows it to increase compliance, and improve its services based on better visibility to what it’s getting right and wrong.

A company selling marketing services has a complex order fulfilment process which needs careful managing. The company uses hard-copy files. The work is time-consuming and prone to error. The fulfilment process is embedded in the CRM process. Orders are delivered quicker, at a higher quality level, and with less work. The company scraps plans to hire new staff to help it manage an increase in orders.

In essence, in order to attract and retain customers, organisations operate a myriad of business processes. In the absence of effective systems to manage these processes they are often inefficiently or inconsistently performed. It comes down to the maxim – you can’t manage what you can’t measure. The customer facing operations of a business can often be considerably improved by embedding them in a CRM system where they can be more effectively monitored and managed. However, and coming back to the pit-falls of implementing CRM technology, this more process oriented approach throws up issues that don’t arise if the use of the system is more limited.

Firstly, you have to think through what you want the processes to be, and that may be very different to what they are today.

Secondly, as each process is generally unique, there’s a need to tailor or customise the system to support it.

Thirdly, you need to get everyone using it in a structured and consistent way, which is no small undertaking.

Fourthly, you need to develop a reporting suite in order to help monitor the processes, because the out of the box reporting isn’t likely to reflect how you do business.

Fifthly, once your processes are being run through the system, you have to manage it in a way that quickly adapts to the inevitability that things will change over time.

Which is why a process oriented approach to CRM is not for everyone. The potential benefits of doing it are huge, but there’s an overhead as well. For organisations that are rapidly changing, and/or don’t feel they can persuade their employees to consistently use a system, this is not a good approach. The key is to know what camp you are in. It’s a lot better to recognise up front that it’s not in your DNA to use CRM technology in this way, than spend a lot of time and money proving it.

So where do we go from here?

2008-10-26T16:09:00.002Z

Well another week brings more economic bad news. Recession seems inevitable, so I figure it might be a good time to try and work out what it means for the CRM industry. Anyway these are my thoughts:

Firstly, you’d figure that people are going to spend a lot less on buying new CRM systems. For those that do decide to invest, then the decision making process is I suspect going to be longer, more complex, more competitive, with considerably more focus on the business case. CRM vendors take note; how you sell software will have to change. I think there will be a shift in thinking from ‘which CRM software do we choose?’ to ‘is this really going to give us a major payback in the short term?’

The market will consolidate. Pre-dot com bust, there were a large number of on-premise CRM vendors, post dot com bust the market consolidated dramatically. Then Salesforce.com came along and did a stellar of marketing themselves, and was soon followed by a wave of me-too software as a service (SAAS) CRM vendors. Some; probably many, possibly most, won’t survive.

I’m not sure on the on-premise CRM side there’s that much left to consolidate in terms of technologies, however the value added reseller (VAR) network that support technologies like Goldmine, Microsoft CRM, Sage CRM, SalesLogix, will struggle. These applications developed by the likes of Sage, Microsoft, and FrontRange are sold and supported more or less exclusively through a network of resellers. These resellers are generally small, typically turning over around £1 Million, and are rather more susceptible to the vagaries of the economy.

Even if your VAR survives the down-turn – and many won’t - it doesn’t mean you (as the owner of a VAR supplied CRM system) are going to escape the impact. As these businesses look to trim costs, the quality of the service may be impacted, and I suspect many VAR’s will cut back the portfolio of products they support. There’s been something of a trend in recent years towards VAR’s supporting multiple CRM products, and I suspect that in tougher economic times there will be a trend back to focusing on the core business, which may leave many clients effectively orphaned.

That said, even if your VAR or on-premise technology provider goes out of business, disruptive as this may be, at least you will still have a working system and you can look to make alternative arrangements at your leisure. If your SAAS provider goes bust there’s a big question as to whether you will have access to your own data, and even if you do manage to extract it before the lights go off, what are you going to be able to do with it?

The irony is that the better use you make of CRM technology, and the more it underpins the performance of your business, the more vulnerable you are to disruptions in the performance of your CRM vendor. Ultimately CRM vendor failures may in turn result in some of their customers failing too.

With less money being spent on new technology, I suspect firms will look harder at what they already have. There’s a considerable amount of underused CRM software out there, and considerable scope for companies to rationalise. All vendors will be hit by this, but in this respect I think SAAS vendors are particularly vulnerable. If you’ve purchased on-premise software it’s largely a sunk cost, with SAAS it’s ongoing expenditure, which, subject to contractual terms, can be terminated as required.

If vendors do decide to ditch software, I suspect the open source vendors will be key beneficiaries. The software may not be as feature rich, but then if you are one of those companies which for one reason (and it may be for very good reasons) or another are never going to use CRM technology well, it’s not going to make a huge difference anyway, so you might as well go for the low/no cost option.

On the other hand, for those who do decide to keep what they have, I believe there will be considerably more focus on wringing value from their investment. Perhaps this will finally mean the point that I’ve been banging on about for several years now, that CRM success is based on process, people, and technology, not technology alone, may finally hit home. In the absence of funds to lavish on new technology I expect the emphasis to shift to re-implementing existing technology in way that does add value.

There’s no doubt we’re heading for ‘interesting times’, but perhaps it will teach us an invaluable lesson along the way – the art of extracting value from technology.

Unsinkable CRM...

2008-10-22T09:04:00.000Z

In retrospect, suggesting that the Titanic was unsinkable, was hardly the most accurate of representations. The origins are interesting though. ‘The Shipbuilder’ magazine published an article in 1911 where the term ‘practically unsinkable’ was used. The article in turn seems to have borrowed extensively from a White Star Line publicity brochure quoting many sections verbatim. While the word ‘practically’ does qualify the claim, it’s apparent that in people’s minds the ‘unsinkability’ bit was absorbed and the ‘practically’ bit was discarded. The myth was now established; and since White Star would be the primary commercial beneficiaries, one would imagine they were hardly motivated to set the record straight.

Anyway, I mention this because I recently set myself the task of reading as many CRM related articles as I could find. While some were very good, I was surprised at just how many bore little relationship to the ‘real’ world, at least as I understand it. Some clearly emanate from the marketing department, and are high on spin, and low on insight. And there were also a lot of articles written by journalists, who, in the absence of any domain expertise, were clearly patching together vendor press releases (i.e. spin) in order to create supposedly well balanced factual stories. It’s also clear that one article created in this way, may indeed fuel multiple other less than accurate pieces, and I was interested to note how many incontrovertible ‘facts’ about CRM presented in the mainstream press, clearly had their origins – albeit perhaps several generations of articles earlier – in a vendor marketing department. Over time, and multiple iterations, ‘practically unsinkable’ became ‘unsinkable’.

Aside from making the obvious point that you might want to be cautious about what you read about CRM, I just wanted to note it’s my intent to post a monthly summary of interesting articles, which I come across. If you find any good articles on the practical application of CRM for beneficial purposes – as opposed to ‘version 7.42 of our marketing leading application has just been released with new and improved…etc etc’ – then please drop me a line. I don’t mind if they are written by CRM vendors, as long as they add value. Ultimately the more that can be done to take the spin and misinformation out of the market, then the better the potential to realise the true benefits of CRM technology.

CRM SOS

2008-10-13T17:17:00.001Z

As promised, shameless plug number two. Last week I mentioned CRM VM, but the other new service we’ve launched is CRM SOS (second opinion service). As the name suggests we’re giving people the opportunity to get an independent second opinion if something a vendor tells them doesn’t feel quite right. Having seen some ludicrous proposals for upgrade work and customisation services in recent months, it struck us that giving people the option to get a second opinion from an impartial source might allow them to cut costs at a time when the pressure’s increasing to do more will less. We’re also aware that if the economy continues to tighten, and there is less of a market for new CRM systems, then vendors will inevitably switch their attention to squeezing more from their customer base. Anyway, shameless plugging over – details here though if you want to know a bit more.

The best will suffer most...

2008-10-10T18:36:00.003Z

As a long standing veteran of the CRM market, I can recall what happened in the last down-turn in the economy post 9/11. Up to that point CRM vendors seemed to be springing up all over the place, thereafter there was a rapid consolidation. In recent years we’ve seen a surge in new CRM vendors riding on the shirt-tails of the SAAS movement. Will there be a consolidation in the face of the current economic down-turn? Yes, I think a rather major one. But this time around the impact could be very different. Post 9/11 the companies ‘consolidating’ were on premise vendors. Sure it wasn’t pleasant that if you vendor went bust or was acquired, but at least you still had your data. If SAAS players start disappearing that may not be true.

Witness the incredible goings on at Entellium this week, brilliantly reported by Chris Bucholtz on InsideCRM. Senior executives have been charged with wire fraud. It’s alleged that they ran two sets of books, the real ones, and an extremely inflated version for the investors. All employees have been let go, and who knows what’s going to happen to the customers. Entellium won’t be the last to go, and some organisations are going to get badly burned in the process. Sadly it’s the ones that use CRM the best that will suffer most.

CRM Value Maximisation...

2008-10-03T16:54:00.001Z

One of the things that never ceases to depress me is the hundreds of millions spent on CRM software that while live is generating marginal value for the organisation using it. In my experience the vast majority of CRM systems under perform against their potential. There are a number of reasons for this, but the two key ones are that a) CRM vendors are motivated to sell software not implement high pay-back systems, and that b) though some organisations have been successful in implementing CRM, the systems haven’t kept pace with the business over time and has fallen into obsolescence.

Anyway I mention all this as the preface for a shameless plug on one of two new services – the second new service I’ll shamelessly plug in a separate post. We’ve launched a new service this week called CRM Value Maximisation, or CRM VM for short. The rationale is as follows: most CRM systems under perform. Perhaps in a buoyant economy you can get away with it, but in tighter times the performance of the CRM system can be life or death. If you accept you need to get your CRM system on track who do you turn to? There’s the original vendor perhaps, but then they probably got you in this state in the first place, and their answer is likely to be to sell you some large commission generating batch of products or services which will nicely empty the wallet but probably won’t change anything. Or, and this is where we come in, you could turn to an independent who has a track record of getting value out of CRM technology, and with no software to sell, and is focused on getting you on track.

So that’s how CRM Value Maximisation was born. We’ve positioned it as a quick, and cost effective review service, performed over a couple of days, with a fixed price (£2,400 actually) and targeted at mid-size CRM implementations. The output will be an action plan of immediately actionable high pay-back changes, and a road-map for the longer term development of the system, and we even throw in three months of remote mentoring to help get the changes done. In many respects it’s the formalisation of something we’ve been doing for several years, but we wanted to try and package it in a way that was attractive to organisations trying to come to terms with a more hostile trading environment. I’m excited about it because I know we can make a great deal of difference, but then my thoughts are irrelevant, it’s what the market thinks that ultimately counts. If you want to know a little more, the CRM VM link is here.

Winds of change?

2008-09-29T18:00:00.001Z

Quite a nice video interview on the SearchCRM site with Gartner analyst Scott Nelson at the recent Gartner CRM Summit entitled ‘CRM’s Not Dead’. Interesting observation that he feels there’s an awakening in the market that while technology is important, so too is a vision about what you are trying to achieve, the need to redesign processes, clean up data, and manage organisational change. He uses a nice example of the contrast in thinking and resourcing on ERP projects as opposed to CRM. To my mind the market’s still technology obsessed, but I hope he’s right that things may be changing.

Eight keys to successfully training CRM users...

2008-09-24T17:12:00.024Z

One of the questions thrown up in open forum at the Sugar CRM event last week asked for recommendations on the best approach to training users. Since this didn’t garner a particularly illuminating or comprehensive response I thought I would set out a few thoughts on what I see as some of the keys to effective CRM training:

One - Do a lot of it – the amount of training required to help users change existing practices shouldn’t be underestimated. Giving users half a days training and expecting them to start using the system in consistent and structured fashion is a triumph of hope over experience.

Two - Training should reflect process – the training should be tailored to your specific processes and supporting customisations. Too often users are trained on the ‘out of the box’ software with little emphasis is how they should be using the software in context to their own organisation. This does not foster effective usage.

Three - Training should be role specific – the things you want your telemarketing team to do with the system may be very different from the pre-sales team. A one size fits approach is going to dilute training effectiveness.

Four - Don’t forget the management team – they may be busy, but if they don’t use it, the project will fail. They need to be trained as well.

Five - Don’t limit yourself to classroom training – the classroom has its place but one to one training should be proactively targeted at individuals struggling to embrace the technology.

Six – look for trouble – don’t assume that if there’s no screaming everything is alright. A user should not be considered trained until you’ve validated they are using it in a consistent and structured fashion.

Seven - Training is an ongoing programme not a one off event – the approach to training needs to recognise new staff will join the business, and new capabilities will be added to the system over time. In addition memories fade, so refresher training is also important.

Eight - Make the right decision between vendor and in-house training – there isn’t a simple answer to which is better; it will vary from organisation to organisation. In-house (i.e. you use your own staff) training is likely to be more cost effective, but is predicated on having someone that can communicate well, and the time and inclination to make it work. Vendor training is generally high quality, but tends to be expensive and many vendors struggle to customise their training approach for individual clients. Which ever choice you make, monitor the quality of what’s delivered, nothing kills a system quicker than bad training.

CRM, it’s dirty and you want it…

2008-09-20T17:00:00.001Z

While on the subject of television adverts and the Sugar event, I’ve always had great respect for the way that Unilever has marketed Pot Noodle. Pot Noodle emerged in the late 70’s as a convenient instant snack. By rights the healthy eating revolution of the new millennium should perhaps have killed it off as a product. While, in common with other perhaps less healthy food options, it might have resorted to the 50% less fat, reduced salt, added vitamins and fibre, approach, Unilever were happy to call a spade a spade. There was no attempt to suggest Pot Noodle to be a healthy option; quite the reverse, the company was happy to play on it’s image and position it, through a series of largely non-PC adverts, as an illicit vice, with catch lines such as ‘it’s dirty and you want it’.

I mention this because I feel there are times that CRM vendors are best advised to position their product based on how people actually perceive it rather than what the vendor might like it to be. Sitting through a presentation by the Sugar product manager at the CRM Acceleration event I wondered why the prime positioning seemed to be around the ease of use of the product. The reasoning was: most CRM implementations fail (can’t find fault with that) because CRM software has never been easy enough to use. This incidentally is the line every non enterprise vendor has been trotting out since non enterprise CRM vendors first started launching CRM software.

This approach is flawed for two reasons. One, it’s simply wrong. CRM implementations fail, not because in the main technology is difficult to use, but because CRM vendors have largely ignored the vital process and people dimensions of implementing CRM technology. Secondly, the point of positioning should be to differentiate your product, and when everybody occupies the ‘it’s easy to use space’ it’s becomes meaningless.

Would I consider Sugar as an option for a client? Yes, absolutely. Would I do it because it’s easy to use? No. Sugar’s a great option, because in our credit crunched world you get a heck of a lot of CRM functionality at a very aggressive price point. If I was the Sugar CRM product manager I’d take a leaf from Unilever’s book and position the product based on how people really perceive it. And perhaps ‘it’s cheap and you want it’ might not be a bad tag line either.

BT and Sugar CRM...

2008-09-18T08:48:00.003Z

One of my favourite TV adverts is for British Telecom (BT) and features Gordon Ramsay using a carving knife to gain access to the innards of a PC, while in the background his kitchen is rapidly descending into chaos. The voice over is something along the lines of ‘Do what you do best’, and the advert closes with a strap line of ‘IT. Communications. Support’.

OK, the communications bit I understand, but BT for IT and support? So when I received an invite from Sugar to their CRM Acceleration event in London which featured a presentation on the recently announced tie up with BT, I was interested to find out more.

Sadly the one thing I didn’t find was more. Mick Hegarty’s (Director of Marketing, BT Business) presentation was fine on the importance of CRM in a tough trading environment, but there was absolutely no detail as to what BT are/will be offering. I’d have asked of course but there was no opportunity for questions at the end of the presentation, and the BT delegation seem to absent itself rather smartly as soon as Mick left the stage. Conversations with Sugar staff were equally less than illuminating.

In principle a tie up between BT, one of the world’s largest telecoms companies, and Sugar should be big news. Sugar CRM is a relatively new arrival to the CRM market, and is starting to make itself felt. Access to BT’s small and mid-size customer base could allow it to make a big impact. IT of course is littered with high profile strategic alliances that promise much and deliver little. Yesterday didn’t give me any confidence that this one will be different, but time will tell.

CRM and 1 per cent improvements...

2008-09-09T09:16:00.001Z

While I was away on holiday earlier in the summer I read Richard Moore’s book ‘Heroes, Villains, & Velodromes’ which tells the story of Chris Hoy who went on to win three gold medals in Beijing. While Chris’s achievements are not surprisingly the focus of the book, there’s some intriguing insight into the infrastructure that sits behind Chris, namely British Cycling.

Britain failed to win an Olympic cycling medal during the whole on the 1980’s. At Atlanta where Britain only won one gold medal in all events (rowing), cycling contributed two medals. Thereafter, guided initially by Peter Keen and later Dave Brailsford, a steady transformation was initiated that culminated in the team winning seven out of the ten available track cycling gold medals on offer in Beijing, and with only one of the track team – Mark Cavendish who had to console himself with his four Tour De France stage wins earlier in the summer – not winning a medal.

While British Cycling has undoubtedly benefited from an influx of lottery funding, so too have many sports which haven’t gone on to create similar results. What stands out with British Cycling is the quality of infrastructure that has been built up and the complete professionalism of the team. There’s a nice quote in Moore’s book from Dave Brailsford that summarises the whole ethos, attributing success to ‘performance by the aggregation of marginal gains. It means taking the 1 per cent from everything you do; finding a 1 per cent margin for improvement in everything you do’.

To switch this to CRM for a moment, the concept of continually improving things is something that intrigues me from a CRM standpoint. I’m convinced that the route to success with CRM technology is not just to get things right on initial implementation, but to create an environment where the system is continually tweaked and enhanced over time to maximise the value. In the coming weeks I’ll try and put down some more structured thought on the change management challenge of CRM, but suffice to say at this stage I think this is something that many organisations struggle with.

Switching back to sport again, Sunday saw the Ironman UK triathlon take place in Sherborne, in which I was privileged to be a competitor. 2.4 miles of swimming, 112 miles cycling, and 26.2 miles running later, I’m feeling a little sore, but fortunately I’m in one piece! I can now switch back to a rather more sedentary life style which should result in some more regular blogging. I can’t however guarantee the end of the sporting metaphors, I think there’s a lot to learn from the way professional sports teams go about their business.

Reporting and the two great fibs of the CRM industry...

2008-08-20T17:29:00.003Z

The reporting aspects of CRM technology produce two of the great fibs of the CRM industry:

Fib number one – ‘The CRM system comes with 200 standard reports which will meet most of your needs’ (cue the salesperson to point to a long and seemingly exhaustive list of reports on the screen). In reality each organisation’s processes and informational needs are unique and are rarely met by the out of the box standard reports. This is exacerbated by the fact that many CRM software developers seem to have been rather more rather more focused on developing the long list of standard reports, rather than ones that might be useful or insightful.

Fib number two – ‘You just need to use our report wizard/third party reporting package and you can extract any information you like’ (cue the more skilled salesperson to demonstrate putting together a simple report). I guess this is less of an outright lie than misinformation. In reality you probably can build most reports that you want as long as you are sufficiently trained and have the time to do so. The reality however for the reports people actually end up wanting, even seemingly simple ones, are generally difficult and time consuming to produce.

You might figure that the vendors would be interested in developing reports as an additional revenue stream. However this seems to be far from the case for a number of reasons:

Firstly, because vendors seem to struggle in applying their technology in ways that adds value and see reports therefore as a nice to have add-on rather than a fundamental part of a value generating system.

Secondly, writing reports can prove a fairly toxic activity from a vendor viewpoint. It’s very easy for the vendor to lose money a) because most customers want a fixed price up front, b) because seemingly easy reports can be very complex, c) because customers tend to want their reports displayed ‘just so’, d) because it’s a bit of an exacting science - the report either displays the desired information or it doesn’t, and e) because it can expose flaws in the set up of the CRM system itself which the vendor may then find themselves on the hook to resolve.

Thirdly, creating custom reports for customers is invariably an expensive activity, and as many clients are working to tight budgets, this tends to be the part of the project it’s easy for the vendor to cut in order to win the deal.

In conclusion if you are running an existing CRM system which doesn’t produce meaningful reporting, then chances are you have a system that’s not set up to add organisational value, and you might want to consider re-implementing in a way that does. If you are looking to purchase a new system, then don’t be persuaded that report generation is some inconsequential activity that can be tacked on at some later point; it’s the lifeblood of an effective system.

CRM and great aunt Edith...

2008-08-14T08:21:00.001Z

Sitting in on a series of CRM short-list presentations this week, I became acutely aware of just how much we seem to rely on acronyms and jargon. I had to stop a couple of sessions because it was obvious that the audience wasn’t following what was being said. Even when you ask presenters to stop using jargon it’s amazing how quickly they can lapse back into it. I’d love to say I’m clean on this point, but while it’s something of worked hard on over the years, it something I still catch myself doing.

If you can’t convey points in a way that your great aunt Edith would understand (if you don’t have a great aunt Edith feel free to substitute a similar non IT savvy friend or relative) then stop and re-word it in a way she can. Ultimately the buyers and users of CRM technology are rather more like great aunt Edith than most people in the CRM industry seem to realise. If we are to be effective in getting CRM technology used to add business value, ditching the comfort blanket of CRM industry speak is a key first step.

Fully managed CRM...

2008-08-05T18:07:00.005Z

I’ve been reading CRM RFP responses for much of the week and I’ve seen a number of references to ‘fully managed systems’. This caught my attention at first because it seemed to support the suggestion in my last post that outsourced of administration of CRM systems may prove a new growth area. Further reading however indicated that ‘fully managed’ was nothing more exotic than the ability to host the technology externally.

It strikes me that the whole area of administering systems is a somewhat confusing and misleading one. While one of the attractions of hosted CRM is that someone else is tasked with maintaining the availability of systems, and there is no doubt this is beneficial if you are an organization without a depth of IT resource, it should be noted however that if a system is deployed effectively, the bulk of system management and administration still resides with the user regardless of whether the system is hosted or on premise. The following is a fairly random and small sample of administration tasks which may have to be performed regardless of whom is managing the physical server:

Adding new users
Retiring old ones
Changing security rights and user profiles
Importing and exporting data
Querying the database
Creating reports
Adding new mail-merge templates
Adding tables/fields
Managing pick-lists
Identifying and managing incomplete data
Identifying and managing duplicate records
Addressing user queries and questions
Performing training for new users
Collating issues and potential bugs
Liaising with vendor help desk
Realigning territories
Realigning activities
Setting up and managing remote user capabilities
Checking that defined usage procedures are being followed
Adapting processes
Liasing with vendors over the day to day running and development of the system
Etc. etc. etc.

As the length of this sample list indicates, ongoing CRM administration duties can prove considerably more demanding than might initially meet the eye. Therefore if you see the words ‘fully managed system’, it’s worth questioning what this means in practical terms.

If I’m to be proved right, that there will be an emerging market where all administration tasks are outsourced, then the precursor to this will have to be organizations realizing better value from their investment in CRM technology. If you are only getting two and sixpence back then it’s hard to see organizations inclined towards spending money on external administration, whereas if you have a system that’s hugely value generative, investing to protect the goose that lays the golden eggs makes rather better sense.

Outsourced CRM administration...

2008-07-29T09:33:00.002Z

Ever since InsideCRM rightly observed that my blog postings were somewhat erratic, I’ve attempted to maintain a certain level of regularity, even if the posts are hardly prolific. However I’ve be on holiday in a rather remote part of France where internet access proved taxing to say the least, so despite my best intentions, blogging was put on hold for a few weeks, so forgive me, but I'm back now!

One of the last conversations I had before I left was around the question of administrative resources for a project due to go live in December. I always ask prospective vendors how much time they recommend a client should allow for administering a system. I rarely get a sensible answer. This perhaps reflects that vendors lack the experience/interest in the real world application of their technologies, and that since most CRM systems are largely unstructured the administrative requirements appear light.

The administrative requirement for CRM systems that ‘do’ things for clients by contrast can be significant. Supporting users so that they are able to follow defined processes in a structured and consistent manner can be both time-consuming and challenging (please note I’m talking about user rather than system administration here, so this point is applicable regardless as to whether it’s a hosted or on premise solution). It is also a critical role; get the wrong person doing it and it can be ‘game over’ in terms of a productive and high pay-back system.

One critical decision that companies need to make when implementing CRM systems, ideally early on in the process – hence my conversation six months ahead of live - is whether this role can and should be performed in-house or outsourced. I think there are four basic considerations in deciding whether to keep administration in house:

Do we have/can we get the right person to do the job? – as I mentioned this is a pivotal role and is often the weakest link in many system deployments. The skills required to be effective are invariably underestimated as the person has to be both comfortable working with the technology, but perhaps more importantly has to be able to win friends and influence people in the battle for effective user adoption.

Do they have the time to perform the role? – as I suggested earlier, ask many vendors and you’d figure this was a minor chore. In practice high pay-back systems are generally demanding on administrative resource, particularly in the early days. Consequently many systems founder because the administrator isn’t allocated sufficient time to perform the role effectively.

Are they motivated to perform the role? – this is a particular issue where administrative responsibilities are shared with other duties. I see many talented administrators who see the non-administration parts of their job as more interesting/rewarding and consequently this is their area of focus to the detriment of the CRM system.

Can we retain them? – as Warren Buffett observed – and I’m paraphrasing here – I like companies that can be run profitably by an idiot, because one day they may be. As I’ve touched on before weak administration is the point of failure for many otherwise successful systems. If you have a constantly revolving door because it’s impossible to maintain interest in the administration role for any duration, so the odds of recruiting a rogue administrator increase.

As a general rule the administrative requirements of effective systems are considerably higher than people realise. In light of this, organisations tend to assign the role in-house because it’s seen as a minor inconsequential chore. A better appreciation of the administration function might lead many organisations to conclude this function was better outsourced. As organisations start to make better use of CRM technology it will be interesting to see if outsourced administration becomes a significant growth market.

Nine ways to improve CRM software demonstrations...

2008-07-08T17:52:00.004Z

I may well have covered this topic before, but as someone asked me my thoughts on this topic this week, and as I’ve been both sides of the table more times that I’d care to think about, I thought I’d draft a ‘x ways to improve CRM software demonstrations’ post, so here goes:

1. Go SLOW – there’s a strange effect where some of the best CRM software demonstrations I’ve seen are by people new to the organisation because their still getting to grips with the software and as such they move about the application slowly. Invariably you see the same person in action 12 months later, and their presentation is nowhere near as effective for the simple reason that they have reached a point of proficiency with the software such that they now outpace their audience’s ability to keep up. I’ve rarely seen a demonstration done too slowly, but I figure 80% plus are presented too fast.

2.Keep it relevent – the audience want to know how the software will make their lives easier, they really don’t want to spend time looking at arcane capabilities that have nothing to do with their day to day jobs, yet time and time again I see vendors showcasing ‘really cool’ features that are irrelevant to the people they are presenting to.

3. Cut the ‘about us’ presentation right down – yes we need to know who you are and your credentials, but this should be a two to five minute exercise not an hour. Most of these presentations blend into each other with different vendors spending a lot of time saying exactly the same thing. This is the opportunity for vendors to crisply set out why they are different, but 95% of vendors go on way, and I mean waaaaaay too long in this area.

4. Keep to the time-lines – there will either be an explicit or implicit duration for the demonstration, be sure you know what it is and stick to it. Again some vendors, once in full flow, fail to register their audience has either mentally or physically left the building.

5. Interact – the most effective demonstrators foster a dialogue with their audience. They get people involved and talking, and when they are involved they are actively listening, and when they are actively listening they are open to the key messages you are looking to convey (assuming you have key messages of course – see point nine)

6. Check it all works - for every four presentations I see I’d estimate at least one suffers some sort of technical breakdown that badly disrupts the flow of the presentation. Yes, these things happen, but I suspect better preparation would reduce the incidence considerably, and if it does happen the impact is considerably mitigated if the presenter keeps the audience in the loop as to what’s happening rather than staring manically at the lap-top screen muttering over and over ‘but it was working earlier, but it was working earlier’.

7. Don’t answer a question with a demonstration – if someone asks ‘does your software do X?’ the reflex response is to show them just how well it does X – which generally dissuades other people from asking any other questions for fear of landing up with an equally long-winded response. The better answer is ‘yes, would you like me to show you ?’

8. Differentiate – the purpose of the CRM software demonstration should be to explain ‘why you’. Most get used to explain why the software is just the same as everyone else’s.

9. Have knowledge or bring it with you – too many demonstrations founder on the rocks of ‘I’ll have to get back you on that one’. You may get away with it once or twice, but after that your credibility is shot. If the presenter is weak on in depth knowledge, or the audience is likely to be demanding, it’s wise to bring back up. If you do however make a promise to come back to people, keep it.

A rather low tech breakthrough and the implications for CRM technology...

2008-06-30T18:59:00.005Z

There was an interesting article on the BBC site – and elsewhere I’m sure – which highlighted a breakthrough in significantly reducing the amounts of deaths and complications resulting from surgery. The breakthrough was not as you might suppose a technology related one, but the simple introduction of a check-list. Apparently the check-list drawn up by the Harvard School of Public health on behalf of the World Health Organisation covers areas such as: Do we have the right patient? Are we operating on the correct body part? Have we left any items within the patient that perhaps shouldn’t be there?

Interestingly this introduction of this low/no tech device has proved highly successful. A study in the Lancet indicated that prior to the check-list there was a 64% probability that one of the procedures would be forgotten, and results of a pilot in eight countries showed a substantial decrease in complications and deaths.

So if highly trained surgeons and their teams operating in a ‘mission critical’ fashion in what you would suppose would be a highly process driven environment could make basic errors, then it does raise the question as to how we are faring in the rather less process driven world of sales and marketing. If surgeons, and probably more pertinently their patients, can substantially benefit from the introduction of a check-list could this have implications for how we market and sell?

I know from my own experience that one relatively unsophisticated, but highly effective application of CRM technology, is to help salespeople and their managers better navigate the sales cycle by providing what is in effect a check-list of things that the salesperson should be asking or aware of. For example, how does the sales opportunity fit with defined qualification criteria? what’s the decision making process? what’s the decision time-line? Who’s involved in making the decision? what’s the compelling event, have we passed out contracts to the legal department for review? etc etc. We found that even highly capable and experienced salespeople overlooked basic information which would give them better control of the sales and a higher likelihood of success.

But that’s just one area – how many other areas of our front office endeavours could be beneficially check-listed? From some of the howlers in scrambled email marketing campaigns of which I’ve been a regular beneficiary, I’d suggest there are quite a few marketing managers that wished they’d consulted a check-list before they pressed the send button. Perhaps the nub here is that if you systemise processes effectively there’s substantial scope to improve what you do, and I believe that CRM technology has a much bigger role to play in this respect than people generally appreciate.

Talking CRM requirements gathering...

2008-06-23T16:54:00.003Z

Strangely I spent a fair proportion of the weekend talking requirements gathering. An old friend of mine is a senior IT manager at a global 500 company, and we were stuck in the car together for much of the weekend travelling to and from a mutual friend’s stag do. So in between pondering on the complexities of delivering a best man’s speech in two languages, one of which I don’t speak, we got to compare notes on what we believe constitutes good requirements gathering practice. There was – surprisingly perhaps - considerable consensus on what we felt was important. The following are the key points – those that I remember at least:

Good requirements gathering is fundamental to the success of any CRM project. Get this right and you are 70% of the way there.

Most organisations do not do a good job of it. Which partially explains why most CRM projects produce at best marginal results.

The starting point for any requirements gathering is to define the vision as to what issues are being addressed or improvements are sought.

The vision has to be defined by senior executive sponsors. No senior executive sponsors, no project.

Senior executives are unlikely to be able to define the vision on their own, they invariably need to supplement their knowledge of the business with what’s achievable through technology. Education plays a key role in requirements definition.

Not all visions require a technology solution; sometimes the answer solely lies in the area of people and process.

Even if the vision requires a technology solution, the dimensions of people and process are vital (though in the main are generally ignored).

Requirements gathering increases in detail over time as the vision is refined and developed. The vision has to be supported by the detail of the processes and associated functionality required to achieve it.

The requirements gathering process is not a 5 minute exercise, done properly it will occupy a substantial proportion of the project.

Requirements should be continually challenged to ensure that they are key to achieving the vision.

Requirements need to be gathered in context to what’s available from technology otherwise potential opportunities may be missed, or there may be excessive elaboration of requirements where the costs clearly outweigh the benefits.

It’s dangerous to define requirements too narrowly; the benefits of implementing technology can often be wider than is immediately apparent. It’s also important to take account what other systems will impact or by impacted by the project.

Phasing is vital – there’s often opportunity to generate considerable value through a relatively simple initial deployment, and then add capabilities over time.

That said beware the ‘let’s go out of the box’ mode of thinking; any effective system has to be tuned to ensure it encapsulates the business processes required to deliver the vision, and that almost always requires some modicum of change.

Understandable but illogical...

2008-06-13T16:19:00.000Z

I guess my recent posts about CRM vendor’s improving the quality of their RFP responses suggests we put we put huge store in the quality of response we receive. While the quality of response is indicative of the vendor’s interest in the opportunity, the key thing we are interested in is a vendor’s track record with similar projects.

Over the years we’ve worked on a lot of projects with vendors and we get to know their strengths and weaknesses. One thing I would observe is that performance is often inverse to the quality of the sales approach. In general if the salesmanship is slick, the quality of the implementation has turned out to be rather ordinary. Conversely there are companies that we’ve decided to go with despite severe misgivings through the sales cycle, who have proven to be outstanding implementers and people to do business with.

Perhaps this reflects the fact that most CRM vendors aren’t entirely balanced, they are either great at selling, or they are great technically (though there are also a lot that are far from great at either). Inevitably though most CRM purchase decisions are driven by the quality of the sales approach. This is entirely understandable but also entirely illogical given that the salesperson invariably isn’t going to feature much in the client’s life once they’ve cashed the commission cheque. It’s much better to select vendors on the basis of their technical and support organisations because you’ll be relying on them for the life of the system.

So if you accept the observation, then perhaps the secret to a harmonious working relationship with your CRM vendor is to find one who’s technically capable, well respected, and profitable but whose salesmanship leaves a lot to be desired.

Go hard or stay home...

2008-06-11T16:21:00.001Z

There was a point that I missed when I did my ‘9 ways CRM vendors can improve their RFP responses’ post the other week, and that’s ‘go hard, or stay home’ (as an old athletics coach of mine was fond of saying). In any batch of RFP responses we receive there’s normally a few where the author’s heart clearly wasn’t in it, and while they had taken the time to respond, it was clearly something of a token effort.

It intrigues me why people do this to themselves, after all a poor RFP response is still time-consuming to put together, perhaps not as time-consuming as a good one, but there’s probably not a lot in it in relative terms. Perhaps it’s a triumph of optimism over common sense and respondents figure that at least if they get something in however poor, there’s a chance that all the other competitors will get struck by lightening, or similar freak accident of nature, and they’ll win by default. In many cases it’s clear some poor sole or reseller has been dumped with the task of responding, however pointless they feel the exercise maybe, and go through the motions simply to tick the box with their boss or software author that the task has been completed.

Given that few organisations are going to purchase a CRM system from a vendor who hasn’t taken the trouble to craft a credible response I figure vendors could save themselves a lot of unnecessary effort if they took a more clinical approach to determining if an opportunity is worth chasing. The most successful organisations I’ve worked with pick their shots carefully, and once they’re satisfied its business they want and can win, they’ll throw everything at it. Saying no to an opportunity is not a sign of weakness, and CRM vendor selections exercises are not (generally) lotteries.

CRM - it's not about the customer...

2008-06-03T15:37:00.001Z

I get to read a fair number of articles written by CRM software vendors. Generally you can tell how new to the organisation, or how close to the front-line the author is, through the number of references they make to customers. If there’s lots of reference to ‘knowing your customers better’ etc it’s a reasonably sure sign the author knows little about the real world application of their technology.

While on the surface the term CRM technology would suggest it’s all about improving customer management – it’s in the name after all - in reality I’d suggest CRM technology is principally about process improvement, and ultimately, and perhaps counter intuitively, the benefits of process improvement may have little to do with the end customer.

I work on around a dozen CRM projects at any one time. If I pick a fairly random selection of core business processes I’m currently implementing, these include:

Management of pre-sales resources
Sales process management
Order process management
Order fulfilment management
Lead logging and tracking
Marketing campaign management
Anti-social behaviour management (local authority)
Complaint handling
Contact management
Account management and planning
Contract renewal management

It’s not that these processes don’t touch the end customer, and in many cases may improve the customer experience, but the reality, rightly or wrongly, is that most organisations purchase CRM technology because it helps them manage their business processes more effectively to generate operational efficiencies. Improving the customer experience is often a desirable side effect, but is not the main objective. Organisations can often significantly increase profitability through the use of CRM technology without moving the needle significantly in terms of what the customer experiences.

Take lead management for example. In many organisations there is no systematic approach to handling sales leads. Often if the opportunity is not short term the lead gets forgotten about and the opportunity is missed. Effective lead handling systems and processes ensure that a higher proportion of leads are converted, increasing sales and profitability. Yes, the customer should have a better experience of working with the company – they didn’t get forgotten about after all - but these systems are implemented because companies want more sales.

Anyway, I’m not sure it’s a hugely insightful observation, but it does strike me there’s a huge gap between what people really buy CRM technology to do, and how it’s portrayed in the media, and I suspect that’s part of the reason so many organisations have failed to embrace it effectively.

9 ways CRM vendors can improve their RFP responses...

2008-05-27T17:17:00.002Z

As I’ve been writing ‘10 tips…’ type lists, and as I’ve been slogging through RFP responses for several days I thought I would compile a ‘9 ways CRM vendors can improve their RFP responses and make my life a bit easier (and ultimately increase their sales)’ list, so here goes:

1. Develop a coherent structure to the document – In virtually every other field of communication there are accepted structural norms, but for some reason these go out the window with RFP responses, with different sections often randomly sequenced together. Ultimately a RFP response is meant to be a persuasive selling document; few are.

2. Differentiate – I figure most marketing managers don’t get to see the RFP’s that get sent out, but they should - and I suspect they wouldn’t be happy. The fundamentals of marketing are differentiate or sell on price. Few CRM vendors succeed in differentiating themselves. Terms such as easy to use, fast to deploy, scalable, 360 degree view, any time anywhere access are used by everyone. It strikes me there’s plenty of potential to differentiate, but it generally doesn’t happen.

3. Just because you have it don’t feel you need to tell me about it – I see whole swathes of text written about features functions and attributes that are of entirely no relevance to my client. I’m sure it’s wizzy technology but if it’s not relevent I’m not really interested.

4. Customers don’t care about you – sorry, they just care about them. You may have the best help desk in the world or project managers second to none but if the client doesn’t understand if and how these are going to be beneficial to them, it’s meaningless.

5. Which means that… – Clients in the main don’t want technology so much as business solutions. Few RFP responses contain much reference to benefits. If in doubt apply the words ‘which means that…..’ after every feature.

6. Be open about the hidden costs – vendors tend to see the world in terms of their costs not the costs of a project as a whole. Implementations will generally require investment in hardware, database software, administrative resource, reporting software, project team time etc etc. Don’t con the customer and pretend these costs don’t exist – they are going to find out sometime. And before a software as a service (SAAS) vendor pipes up that these costs don’t apply to them, I’ll add a postscript and say and if you are a SAAS vendor don’t pretend that you aren’t going to need implementation services.

7. If it’s going to take 20 man weeks to develop a capability it’s not ‘fully compliant’ – applying the most lateral interpretation of a question in order to indicate compliance is not being open and honest, and as buyers will buy from people they trust, it’s not doing you any favours.

8. Answer the question – questions are posed in RFP’s for a purpose. Answering a different question to the question asked, but one you like better, is not answering the question.

9. I want to read one document – I don’t want to slog through 47 different attachments or yomp through a 500 page technical addendum to find the answer to the questions asked. If you’ve got good relevent material makes sure it’s in the main document where it’s going to get read.

CRM and the cataclysmic event…

2008-05-18T11:29:00.000Z

A couple of posts ago I mentioned a site visit I attended with a client. One of the interesting aspects of this site was that they had installed the CRM system as the response to a near death experience. They were a long established organisation, a recognised brand, and comfortably making ends meet. Then a cataclysmic event occurred, that effectively dried up their revenues. It wasn’t an event of their own making, and it wasn’t foreseeable, but ultimately they only just survived. Rattled by a close shave they embarked on a full review of the business and launched a series of initiatives to improve operational efficiencies, one of which was the CRM project.

Waiting for the cataclysmic event as a cue for change is a dangerous strategy because survival can’t be guaranteed. Organisations can enjoy a dangerous level of success where despite not being optimally efficient, the business still makes healthy profits, and there is no compelling reason for change. However the lead times to create efficient systems are often such that implementing technology as a means to address sudden change is often unsuccessful.

This is a point I’ve made to many firms over the years, sometimes the successfully and sometimes not. However the point becomes increasingly relevent over time. The speed of technologically, environmental, social, economic, and competitive change ever increases. While there’s no antidote for either the cataclysmic event or rapid dislocating change, optimising efficiency at all points in time is a critical necessity. CRM alongside many other technologies has a key role to play because ultimately they create the infrastructure that generates both the efficiencies and the ability to respond and hopefully benefit from change.

Ten ways to implement CRM on a tight budget…

2008-05-09T17:12:00.000Z

With the economic environment getting tougher, the need for effective CRM systems increases, but with budgets often getting tighter, the scope to introduce much needed technology decreases. I often work with companies who are looking to implement CRM technology on tight budgets, so in this post I’ll set out ten ways to implement CRM technology more cost effectively:

1. Get your requirements carefully mapped out first – The more detailed a specification of your requirements that you can generate, the better positioned vendors are to provide firm pricing. Firm pricing let’s you identify the most competitive offerings, and helps you identify which capabilities you can do without if you a struggling to hit budget. Many organisations rush to select a vendor with an ill defined set of requirements in the expectation that the vendor will develop the final specification. As it’s in the vendor’s interest to maximise the commercial value of the project, and at this point you are pretty much locked in, you can expect to pay around 50% more by adopting this approach.

2. You don’t need to go for premium brands – While the temptation may be to go for well known CRM brand, they may not be the most cost effective option. A tight requirements specification will help you identify the functionality that you do and don’t need, and you may well find that lower cost options can comfortably meet your needs. Even some of the free open source and low cost commercial open source offerings can represent a viable route forward if your needs are not too sophisticated. It’s advisable to undertake careful due diligence however to give assurance the vendor you’ve selected is likely to remain trading in tougher market conditions.

3. SAAS is not by definition cheaper – Despite what the software as a service (SAAS) vendors may suggest, hosted software may or may not be cheaper than ‘on premise’ alternatives, even when just measuring the year one costs. Unless there’s a compelling need to deploy technology in a certain way, it’s wise to keep an open mind between hosted and on premise options.

4. Shop around – Organisations often pay too much because they unnecessarily limit choice. As a case in point, we recently issued a RFP for a fairly straightforward system, and included several resellers for the same CRM technology. Pricing estimates from those resellers ranged from £30,000 - £150,000. Had we had a more limited distribution we might have ended paying substantially more than we needed, or discounted a potentially attractive technology.

5. Negotiate well – While your budgets may be tighter in a down economy the vendors are likely to be feeling the pinch too, so there’s generally plenty of scope to negotiate. While software costs and day rates tend to be the key target for negotiation, it’s also worth looking the number of service days the vendor is proposing to determine if they are appropriate for the project. If in doubt speak to an independent CRM consultant, they can often add a lot of value in this area for modest outlay.

6. Don’t overload on software – There are already billions of pounds worth of unused software out there sat on shelves gathering dust; don’t add to it. There can be a tendency to buy software for a much wider group than will actually use it. Few CRM vendors penalise you for buying software incrementally, so it often pays to start off small and add licences as you need them. You may well find you need a lot less software than you originally thought.

7. Keep it simple to start – It’s generally best to phase projects. Just implementing the basics can often add a lot of value, and further capabilities can easily be added over time. This reduces the amount of costs up front, and as organisations often only see the realistic potential of technology after they have been using it for a while, it often avoids the development of expensive white elephants.

8. Take on more yourself – There’s little point in paying vendors to perform tasks that you can easily perform yourself. With many of todays CRM technologies being highly user configurable there is plenty of scope for organisations to do the basics themselves and let the vendors handle the more technically demanding parts.

9. Rent a developer - Some of the most cost effective deployments we’ve worked on came when we paid for a developer by the day; got them on site where we could keep an eye on them, asked them to turn off their mobile phone, and told them what we wanted written. It requires a good understanding of the business and functional requirements and knowledge of the technology you’re deploying, and isn’t advisable in all circumstances, but we’ve implemented systems at under 20% of the originally quoted costs by operating this way as opposed to letting the vendor do the initial design work.

10. Use third parties – You don’t have to use the vendor for everything. You can often find capable, well qualified third parties and independent contractors to involve on a project without having to pay a vendor premium. Sites such as Rent A Coder can also expand your options by giving you access to cost effective developers located across the globe. You may have suck it and see a few times before you find people that have the right skills and that you can work with, but as the rates are so competitive you can afford a few false starts.

By using your imagination and defying a few of the conventions of CRM implementation, it’s amazing how cost effectively CRM systems can be deployed. Perhaps sometimes budget constraints can be beneficial; necessity is after all the mother of invention.

Six pieces of CRM implementation advice...

2008-04-27T18:08:00.002Z

I had the pleasure of going on a CRM site visit during the week. It’s always interesting to discuss other people’s experiences of implementing CRM systems. I always ask what advice they would offer to others about to undertake an implementation, and thought it might be refreshing to pass on some thoughts that weren’t mine for a change. So six pieces of advice for those implementing a CRM system:

1. Be aware that the implementation of new technology also provides a temporary window for more far reaching business change. Use it or lose it.

2. Don’t underestimate the internal resources that CRM projects soak up.

3. It’s easy for key implementation activities such as testing, documentation and training to get crunched at the end of a project as deadlines loom. Make sure these are not compromised.

4. Make sure you engage key users early, this has a big impact on how quickly and effectively the technology is adopted.

5. Don’t try and do too much – phase it.

6. Find the right vendor.

Late and over budget – the hidden traps of implementing CRM systems…

2008-04-21T14:41:00.003Z

While the instances of outright failure are few and far between these days, CRM technology implementation projects continue to be a source of pain and frustration. Recent research relating to IT projects in general indicated that the average project came in 56% over budget and 84% later than expected. While I’ve no figures for CRM specifically, I’d hazard a guess that that the performance of the sector was even worse.

So what catches organisations out? Before I try and answer that, I’ll make the point that I’m referring to the meaningful use of CRM technology; technology deployed in a way that will deliver significantly beneficial results. It’s easy to throw some software on a server, or sign up for a hosted provider, however high pay-back CRM systems generally require considerable work in setting up these technologies in order to generate results.

Here are the six aspects of CRM deployment that tend to ambush the unwary:

Poorly defined requirements – many organisations initiate CRM implementations with only a hazy notion of what they are trying to achieve, or what the final solution will look like. As a consequence requirements tend to change as the project progresses, and new requirements emerge, which puts pressure on resources, schedules and budgets.

The availability of internal staff – CRM projects are hungry on the use of internal resources. For example users will be involved in requirements definition activities and training, the IT team in project management, key users and sponsors as part of the project team, and senior management in overseeing the project. When fully mapped out, the demands on internal staff can be considerable, and, as most will have ‘day jobs’, projects often suffer disruption as staff struggle to balance their day to day activities with the demands of the project.

Sign offs – as the project progresses there are generally a series of sign off points at key milestones. It’s common that sign offs will involve a range of individuals in the organisation as well as senior executives making up the project board. The logistics of coordinating sign offs can be complex. The simple act of diarising review meetings that all required parties can attend can add months to a project, and is a phenomenon that isn’t well catered for in many project plans.

Data – good systems require good data, and, if the new system is to be populated with existing data, it’s important that the quality of that data is high. Many organisations are surprised at how many data sources they possess and how poor the data quality is. The cleansing of data and reconciliation of different versions of the same record in multiple data sources can be very time-consuming. While there are tools that can help, this process tends to be very manual, and is not something that can be fully outsourced as it requires considerable input from the data owners.

User acceptance testing – once the customisations and configurations to the software are complete, there’s generally a phase of user acceptance testing to ensure that the requirements will be met. This can be a surprisingly extended process as many members of staff representing each functional area may be involved. The process is also highly iterative in that bugs and issues detected in the first round of testing will require re-testing, and it’s not uncommon for ‘fixes’ to prove not to be, or break other previously working areas of the system. It’s not unusual to have to go through several rounds of testing. This is also at this stage that additional requirements emerge particularly if the original requirements were lightly specified.

User adoption – an effective system requires consistent and systematic usage. The system can be ‘live’ but not generating the desired returns. Organisations generally underestimate what’s involved in achieving comprehensive user adoption and often put too much faith in the value of classroom training. Classroom training has its place but adoption demands a host of proactive measures such as targeted training and interventions for reticent or struggling users. It’s not uncommon for user adoption programmes to take many months of sustained efforts before the new habits and practices become ingrained.

While effective requirements definition will go a long way towards addressing budget and cost overruns (though the importance of this should not be underestimated), for many aspects of CRM deployment there are no easy short-cuts. The key is to be realistic about the demands these projects will place on the organisation and manage expectations accordingly. Too often CRM projects are deemed failures because they failed to meet impossibly demanding and often self-inflicted deadlines. A better review of what’s involved and a more analytical appraisal of the availability of resources to meet those demands will go a long way to ensure project success.

Removing the c from rm...

2008-04-15T18:13:00.000Z

As I’ve mentioned in previous posts, I’ve always been a bit uneasy about the ‘Customer’ in CRM. I prefer to view the deployment of CRM technology as a means of bringing about process efficiencies which may, or may not impact the customer. So a good example of a ‘may not’ might be using CRM technology to improve the effectiveness of salespeople. i.e. an organisation might have invested in the latest sales methodology and wants to ensure that the benefits are maintained when the original training is but a distant memory, and encompasses the new working practices within the CRM system. The salespeople are more effective as a result and the company hopefully more profitable, but the customer is unlikely to feel much direct benefit themselves.

In practice most process efficiencies have both customer and non-customer benefits. We have a system going live currently where we’ve spent a lot of time automating and streamlining a range of order management and fulfilment processes. These processes were previously handled by a range of Excel spreadsheets, Access databases and hard copy files, and were time consuming and lengthy. The changes we’ve implemented should improve fulfilment quality, reduce lead times, and require less resource, which should lead to a desirable win/win. The customer gets a higher quality product delivered in less time, and the organisation deploying the technology lowers its costs of fulfilling orders.

I don’t want to dwell on it, and of course it’s not going to change any time soon, but in my line of work I see a lot of people delay introducing potentially highly beneficial technology because they want to get their ‘customer’ strategy sorted first. If we removed the c from rm then perhaps, more people would understand the wider potential of the technology.

If Warren Buffett ran a CRM company...

2008-04-07T07:29:00.002Z

If you ever want an object lesson in candour and taking an objective long term view then look no further than Warren Buffett’s annual shareholders letter. Observing on the mayhem in the financial markets in his 2007 letter he notes ‘You only learn who has been swimming naked when the tide goes – and what we are witnessing at some of our largest institutions is an ugly sight’.

Whether or not it involves lending money to people who can’t pay it back, short-termism is a hazardous practice, and one that’s rife in the CRM market. There are two key manifestations of this in my view. Firstly there’s an undue focus on initial project profitability at the expense of customer satisfaction. While I have no issue with vendors looking to make money on the work they do, I think there’s a tendency to obsess on protecting margin, generally through the heavy handed use of change requests, rather than concern as to whether they will have a customer who wants to retain their services at the end of the implementation process.

Secondly the emphasis tends to be on getting the project ‘done’ and moving on to the next one regardless of whether the system is generating any genuine business value for the customer. Partly this is a question of capability – CRM vendors ‘know’ the technology, but few have an understanding of how to apply it, and partly because it’s easier not to: injecting the inconvenient reality that there’s more to achieving CRM success than buying technology and plugging it in, introduces the sort of uncertainty that can distract from the fundamental objective of selling software.

If Warren Buffett were to suddenly find himself running a CRM company, I’d imagine it would become a rather profitable one, because Mr Buffett, unencumbered with a background in the IT industry, would quickly deduce two things 1) unhappy customers are unlikely to make you very rich, and 2) the greater value you can generate for your customers the more they are likely to invest in your products and services. Sadly there aren’t many Warren Buffetts out there, rather fortunately for the CRM industry I suspect.

Which in turn...

2008-03-31T17:23:00.000Z

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

2008-03-23T14:15:00.003Z

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

2008-03-15T18:29:00.001Z

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

2008-03-08T18:57:00.001Z

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

2008-03-02T18:42:00.001Z

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.

from blood, brains, and beer...

2008-02-26T17:58:00.001Z

In his improbably entitled autobiography ‘Blood, Brains, and Beer’ David Ogilvy quoted Louis XIV: ‘Toutes les fois que je donne une place vacante, je fais cents mecontents et un ingrate.’ – every time I give someone a job, I make a hundred people unhappy and one person ungrateful. Neither party was talking about the CRM vendor selection process of course, but it’s a very appropriate observation nonetheless.

Mastering the complex sale again...

2008-02-23T13:53:00.003Z

Well the invitation to vendors regarding show-case sites didn’t illicit an overwhelming response, though that could be a reflection on the breadth of readership rather than anything else. That said I did get an unexpected email from Jeff Thull the other week after my note about his ‘Mastering the Complex Sale’ book, which was a timely reminder for me to offer a few thoughts based on actually having read it in its entirety rather than the first few chapters.

The fact the book is now liberally scribbled over is a pretty tell-tale indication there’s a lot of useful material. As I mentioned before the book is predicated on the principle that ‘customers are not experienced in diagnosing complex problems, designing complex solutions, and implementing complex solutions.’ which entirely fits with what we see in our day to day work as CRM consultants. Given that the wealth, health, and ultimate survival of organizations will increasingly come down to their ability to apply the myriad of technologies at their disposal effectively, this observation is not without significance.

For the sake of brevity in this post I’ll pick up on just a couple of other strands from Jeff’s work. The first is the emphasis on performing a formal cost calculation to quantify the benefits the solution will provide. Most salespeople shy away from this, or perhaps aren’t capable of doing it. You can get away with this to some extent in boom times, but in the tougher trading environment we are starting to experience this I suspect is going to be increasingly critical.

The second aspect I liked was what I’d characterize as Jeff’s depiction of the ‘noble’ salesperson who only sells to those that can truly benefit from the solution, who will walk away if they can’t provide the most appropriate solution, and who sticks around when the sale is complete to ensure the promised benefits are actually delivered. This is in stark contrast to the sell at all costs sort-term-ism that typifies the IT industry today. I suspect what we will see in coming years is a new generation of IT vendors that differentiate simply on their proven ability to deliver genuine business benefits.

Ultimately I guess I find Jeff’s book compelling because it mirrors much of our own raison d’etre – i.e. to bridge the gap between CRM technology and ultimate profit. And while on the topic of CRM, Jeff did note that he had plenty to say on the topic of CRM failure in his book ‘The Prime Solution’, so once I’ve finally cracked Michael Porter’s ‘Competitive Advantage’ which has stared at me reproachfully from the bookshelf for way too long, I’ll be interested to see what he has to say.

Why independent CRM consultants do more than help you choose software...

2008-02-16T14:33:00.002Z

When people think about independent CRM consultants they tend to see us as advisors on technology selection. While this is a key part of what CRM consultants do, in reality we tend to be involved throughout the implementation cycle and add value in ways that may surprise the uninitiated. The following article sets out how.

First of all though it’s probably wise to add some definition to the term ‘independent CRM consultant’. I tend to see the role of the consultant as helping organizations select and implement CRM technology in a way that generates business value. For reasons that are beyond the scope of this article CRM technology and business value have not generally gone hand in hand. I’d suggest perhaps 80% of CRM implementations fail to generate more than marginal value.

While we might share the same name it’s important to point out there are two very distinct types of ‘CRM consultant’. There are those who focus on the customer experience, and there are those that help organizations implement CRM technology. If it helps clarify the difference; the customer experience can often be improved without implementing CRM technology, and CRM technology can generate all sorts of benefits and efficiencies for an organization which might have nothing to do with the customer experience. In terms of this article I’m talking about consultants that work in the later camp.

It’s also worth noting – as it’s a somewhat abused term - independent CRM consultants are by definition independent, they don’t have software to sell, are vendor agnostic, and receive their compensation from the organization buying the software and not the seller.

Traditionally the CRM consultant has been heavily involved in the technology selection process because choosing the right CRM software has never been the easiest of tasks. There’s a lot of technology options, and then throw into the mix the marketing hype, the claims and counterclaims of competing salespeople, and the knowledge that the wrong selection can doom a project; it’s no surprise that organizations turn to the independent consultant for help in making the right choice.

However this is only part of the consultant’s role. There are five other key areas where independent CRM consultants are looking to add value:

Feasibility and planning – consultants are helping organizations determine whether a CRM project makes sense in the first place and in what form. This involves helping define the business case, estimate cost and resource requirements, evaluate different options and identify key implementation considerations so that organizations can make a dispassionate assessment whether to proceed, and can structure a project in a way that the potential return on investment is maximized.

Requirements definition – defining and documenting business and functional requirements for a CRM system, and helping organizations re-engineer or introduce new business processes in order to benefit from the technology, can be a demanding process. It is also essential to being able to make the right technology choice, and has a big impact on the speed of the downstream implementation. However it’s not easy to do unless you have a good working knowledge of CRM technology, which means it’s often an area best performed by an outside specialist

Negotiating pricing and terms – while many organizations would feel they are strong negotiators, CRM consultants have very specific knowledge as to what’s achievable through negotiation with each vendor, and perhaps more importantly can review implementation estimates to spot any excess fat. It’s not uncommon for a consultant to reduce the initially quoted price very significantly, and clients can get a very big return from a very brief engagement.

Implementation - the implementation phase is also an area that consultants are increasingly playing a role, either as project managers, or more commonly mentoring the client’s project manager, who may not have extensive experience of managing CRM projects. While the instances of outright project failure are rarer these days; budget overruns, and missed live dates are common place, which means that companies look to get specialist advice to keep things on track.

Working with existing systems - the big growth area in CRM consultant involvement has been for organizations wrestling with the decision as to whether to replace an existing system. Systems often under perform as a result of a poor implementation or user adoption issues, rather than a fault with the underlying technology. Re-implementing existing software can be considerably cheaper than buying a new system, but organizations often need outside guidance as to whether they are ‘salvageable’. For those that choose the re-implementation option, getting help ensuring ‘it’s done properly this time around’, is also common theme.

While many may continue to associate independent CRM consultants primarily with the vendor selection stage, many organizations are finding we can add value throughout the life of the system. It may not be the most common approach to implementing CRM technology – most organizations will continue to work solely with a CRM vendor- but for many, working with an independent consultant is proving the key to unlocking CRM’s often elusive promise.

It's not the done thing old chap...

2008-02-09T11:37:00.000Z

I’ve been doing the CRM equivalent of wearing neon pink in a Wimbledon final, coughing when your opponent is about to take a vital putt on the 18th, or bowling underarm in a test match, in other words going against protocol. More specifically we’ve been asking for reference sites before we’ve even started a formal vendor selection process. It’s not perhaps something I would normally do, but one of the key sponsors for a forthcoming project is a great fan of learning from others, so we’ve been asking prospective vendors, if they’d like to showcase their talents and take us to one of their sites.

The response has been interesting – rather like a new mother who has been informed their baby is rather ugly – in effect ‘it’s not the done thing old chap’. Ask to see some software and you are likely to get trampled underfoot. Ask to see some real-life examples of the application of technology to beneficial effect and the room goes rather quiet.

Traditionally site or reference sites are generally an afterthought in the due diligence part of vendor selection, a rubber stamp exercise long after the actual decision has been made. They shouldn’t be, but that seems to be the accepted norm.

Which raises the question why are vendors so squeamish on site visits. There are, I suspect a number of good reasons. Firstly it tends to involve calling in favours from customers to host these events, and secondly you can never be quite sure what that customer might actually say on the day.

That said, these are manageable issues, I’m a poacher turned gamekeeper don’t forget, and in my previous lives I went to great lengths to ensure we had both good showcase sites and that customers were prepared to host visits. If we were negotiating terms on a project we would make sure that if we had to give something away we got something in return, often a commitment to host a certain number of visits per year.

I suspect the real reason is – and yes I’m going to hark back to a familiar theme – that a lot of vendors don’t actually have that many good, slick, revenue enhancing sites to showcase, for the reason I frequently go back to in this blog, that very few CRM implementations manage to bridge the gap between technology and a revenue enhancing system.

So, if you are a UK vendor and have sites that showcase you as a stand out implementer of high return CRM technology, then feel free to contact me, I have a large membership organization who might be interested in talking to you.

An unhealthy influence...

2008-02-04T18:39:00.000Z

Nice piece in BusinessWeek entitled ‘Just say no to drug reps’ about a programme to help doctors to resist the influence of pharmaceutical salespeople. The article cites some interesting research:

'A doctor who spends just one minute with a sales rep typically ends up prescribing 16% more of that rep's product than he or she was prescribing before. And a four-minute encounter is likely to prompt a 52% jump in prescriptions'

It would be very interesting to get similar research about how influential IT sales people are. My own feeling is that the majority of major IT investments are made on the basis of trust/rapport with the salesperson rather than an un-influenced analysis of functional fit. Sadly something many live to regret.

So what is a CRM Consultant?

2008-01-26T18:01:00.000Z

I had a phone call from a lady yesterday wanting to know what background/qualifications she needed to become a ‘CRM Consultant’. Before I could give her any advice I thought I’d better clarify with her the various definitions of the term CRM consultant, since it means very different things in practice, though to my mind there are three broad groups:

The first are consultants that are focused on the customer experience. They help organizations improve customer satisfaction levels. This might have a CRM technology dimension, but their work can be totally independent of it.

The second area where the term CRM consultant is used frequently is within firms selling and implementing CRM technology. Confusingly the title can be used by a variety of different functions within the organization from telemarketers, to salespeople, to developers, to project managers.

The third, and rather small group, are the independent CRM consultants. Independent CRM consultants help organizations implement CRM technology but are vendor neutral – they don’t sell technology.

The advice on how to become a CRM consultant depends on which of the three camps you want to be in. In terms of independent CRM consultants though there’s no easy route. We look for people who are extensive experience of implementing CRM technology, but also have an excellent understanding of how businesses work, and can apply that understanding to a wide range of vertical markets. Good independent CRM consultants are like hens teeth, which is why we’ll always be a niche consultancy. But then we like it like that!