Getting to the CRM software short-list...

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

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

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

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

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

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

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

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

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?

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?

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?

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?

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

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.