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.

CRM project plans - where does it all go wrong?

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

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

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

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

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

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

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

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

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

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.