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.