The CRM Consultant

When should I pilot CRM software?

noreply@blogger.com (Richard Boardman) — Sat, 13 Mar 2010 15:45:00 +0000

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?

noreply@blogger.com (Richard Boardman) — Sat, 20 Feb 2010 18:04:00 +0000

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?

noreply@blogger.com (Richard Boardman) — Sat, 13 Feb 2010 12:55:00 +0000

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

noreply@blogger.com (Richard Boardman) — Sat, 30 Jan 2010 11:08:00 +0000

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?

noreply@blogger.com (Richard Boardman) — Sat, 23 Jan 2010 16:52:00 +0000

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

noreply@blogger.com (Richard Boardman) — Thu, 14 Jan 2010 10:34:00 +0000

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

noreply@blogger.com (Richard Boardman) — Sun, 10 Jan 2010 11:59:00 +0000

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

noreply@blogger.com (Richard Boardman) — Sat, 19 Dec 2009 18:12:00 +0000

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

noreply@blogger.com (Richard Boardman) — Tue, 08 Dec 2009 10:11:00 +0000

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

noreply@blogger.com (Richard Boardman) — Wed, 25 Nov 2009 10:29:00 +0000

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

noreply@blogger.com (Richard Boardman) — Sun, 08 Nov 2009 13:54:00 +0000

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

noreply@blogger.com (Richard Boardman) — Sat, 24 Oct 2009 17:10:00 +0000

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

noreply@blogger.com (Richard Boardman) — Sun, 11 Oct 2009 14:33:00 +0000

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

noreply@blogger.com (Richard Boardman) — Sun, 04 Oct 2009 18:43:00 +0000

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

noreply@blogger.com (Richard Boardman) — Mon, 28 Sep 2009 11:32:00 +0000

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

noreply@blogger.com (Richard Boardman) — Thu, 24 Sep 2009 16:04:00 +0000

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

noreply@blogger.com (Richard Boardman) — Wed, 23 Sep 2009 07:06:00 +0000

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

Sticking to the knitting...

noreply@blogger.com (Richard Boardman) — Tue, 22 Sep 2009 13:03:00 +0000

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

noreply@blogger.com (Richard Boardman) — Fri, 11 Sep 2009 10:51:00 +0000

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

noreply@blogger.com (Richard Boardman) — Mon, 31 Aug 2009 08:30:00 +0000

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

noreply@blogger.com (Richard Boardman) — Sun, 09 Aug 2009 13:45:00 +0000

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

noreply@blogger.com (Richard Boardman) — Wed, 05 Aug 2009 17:41:00 +0000

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

noreply@blogger.com (Richard Boardman) — Mon, 20 Jul 2009 15:10:00 +0000

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

noreply@blogger.com (Richard Boardman) — Tue, 16 Jun 2009 18:17:00 +0000

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

noreply@blogger.com (Richard Boardman) — Sun, 07 Jun 2009 15:51:00 +0000

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.