The totem of CRM project failure

I remember a number of years ago (too many to want to recall) when a Gartner statistic was often bandied about around the number of CRM programs that failed (here’s a roundup of others).  It was a shockingly high number and I still see it used to this day even though CRM is not what it was (in meaning, scope or size).  As the discipline has matured it has splintered, redefined itself (Big Data, Customer engagement, experience management etc. etc).  And this process of redefinition in itself is indicative of the challenges the discipline has faced in really showing what it is there to do.  Yet at the heart of it CRM remains the same; it’s about using technology to improve the results we get from our customers (and by default the results they get from us).  It’s not about technology, it’s about USING technology.  All, and I mean all, of the relationships we have as customers are underpinned, driven by or just plain represented by technology these days.  It is all pervasive.  But our customers don’t care what software we use to support them do they?  They really don’t.  They just want the right outcome and we as providers of products and services do too.  So here’s the thing. We obsess for so long and so hard about the software we ought to choose we lose sight of the outcome.  We lose sight of the word USE in our definition of CRM.  And any program, project or plan that ignores that word USE will fail and fail big time. So why is this?  Well for one thing we spend too long talking to the wrong people and asking the wrong questions.  The result?  Getting the wrong answers.

Let me offer an analogy I’ve used a number of times before in the real world.

Imagine that, at short notice, you need to drive 300 miles in a day; your only option a hire car (or rental).  So what do you do?  How do you spend the first few hours of your day

  1. One hour choosing the colour of the car
  2. Two hours choosing whether it’s petrol or diesel
  3. Half an hour deciding how many cup holders you need
  4. Two hours on automatic or manual?
  5. And so on and so forth …

So it’s lunchtime already and you’ve finally found the car you really want to hire.  Trouble is you’ve only to left yourself with 3 hours to make the distance.  So you drive like a maniac, get a couple of speeding tickets and you’re still late.  Trouble is in business you’re in a race.  If you don’t get there on time then you lose.  And here’s the motto.  ” The journey only starts once the wheels start turning”.   Now I don’t want this analogy to get stretched to breaking point but there’s a few more miles left it in the old girl yet.  When you hire a car you choose a car quickly that meets your general needs and then get in and start driving the damn thing.     You may discover along the way that the seat position is not right but hey at least you got there on time. When you rent a car you don’t go and get brochures from all your favourite car brands to try and select a model do you? They are not going to give you the right advice on what’s best;  all they want to do is sell you a car.  Enough here; let’s flip back to the business world.

We spend so much time, energy, pain and effort on just getting the technology in that we only ever pay lip service to the U word.  Why is this?  We talk to the software makers rather than focus on customer outcomes.  We call it business change without ever really understanding what that really means.  We treat business change as a tactic without ever realizing that business change is THE strategy.  The particular axe I’m grinding in this article is around how we build our customer technology programs from the ground up;  in my humble opinion they are built wrong.  And if they are built wrong they will work wrong.  So what to do differently?

Focus on the what and why of CRM rather than the what and how

This is an interesting one and worthy of a lot more study so I’m going to make some questionable statements here that should stimulate debate.

Making a headlong rush to requirements definition as a part of your program will take you off track.  It may be an issue with how your requirements are articulated but all too often your requirements will focus on the detail and describe how something should be done as opposed to whether it’s worth doing in the first place. Post project or program approval the standard IT processes in your organisation will kick in.  Teams will be assembled and the cavalry will start to charge.  You’ll have teams of BAs or others gathering requirements, creating beautiful documentation that will pile up on shared folders on your team collaboration space.

This activity will create a little industry in itself and this energy and effort will start to create a strong gravitational pull on the direction your program will take.  The weight and authority of the written words in your requirements will start to shift the balance of power away from what you are trying to achieve and over to how you are going to achieve it.  Now what makes this a problem is that all to often how you are going to do something in the future will start to take on traits and characteristics of how you do it today.  Your analysts will be talking to people across your business who won’t always have clear insight into what the business is trying to achieve.  They may have different perspectives, challenges and resistance to the overall purpose of the program.  Keeping the balance right will require an ongoing focus on reminding people what you are trying to achieve and why this is so important (you should know this after all).

You’ll need to have a clear navigational point against which all requirements must be assessed

The power of keeping the what of your program front of mind is that it will allow you to challenge anything that confronts it.  These include new requirements, new requests and inbuilt resistance to change  that will challenge and divert the purpose of your program.  What I find works is to construct a pyramid that can connect the detail to the vision.

  1. Your business challenge and business vision
  2. Business outcomes that will describe the vision as achieved or as the challenge met
  3. Design principles that will help satisfy the business outcomes
  4. A set of bounded requirements that can be connected back to the design principles and the business outcomes.

Everywhere you go and for everyone to talk to have some pretty pictures that explain this pyramid.  You won’t want anything that diverts your program’s purpose getting embedded in the SDLC ecosystem so ensure that your BAs etc.  and anyone managing relationships with stakeholders can also talk to a refer back to your pyramid.  Challenging requirements before they gain traction is vital.  This also means that you’ll need to have clear governance and almost dictatorial control of system decisions to override embedded self interest and resistance.  I used to be relatively blase about governance.  A lesson I learnt.  Connect sign off to board level and this will help drive your development efforts in the right direction.  Even better is to ensure that you can measure everything you do against your target operating model.  Having that as your touchstone will surely help.  So my take always on all this is:

  1. Detailed requirements are never enough to build the picture of success
  2. Create a target operating model that everyone can see, touch and buy into
  3. Ensure that your governance is structured around implementing the TOM as opposed to the business “requirements”
  4. Make sure you have a process to challenge and document that challenge for any changes to scope

Focus on trajectory and momentum in your program

A final big point i’d like to make before this “post” becomes an essay is that momentum and trajectory are everything in your CRM program.  Ensure that you can keep up the pace of change and delivery and ensure that you can demonstrate momentum (the idea that real stuff is being done).  This isn’t just about delivering those pesky things called “quick wins”.  It’s about making sure that you don’t ever get bogged down in one phase, area or function. I liken it to using crocodiles as stepping stones.  If you slow down you’ll get bitten. What does that mean to you and your program?  It means that sometimes you’ll need to move on to the next stage even when members of your team haven’t tied a bow around the last one.  It means that you need to judge when to move on even if everything is not 100%  The challenge is knowing what to leave and when to move.

Never forget the customer’s customer

A finally finally.  Never ever forget that what ever you build or deliver will be tested against the market.  Tested against the needs of the real stakeholders who never saw, heard, participated or ever expressed the remotest interest in what you were doing.  Look back over all those requirements and documentation.  Ask yourself, how much of this was asked for and needed by our customers.? Why & how much of this is really needed for us to deliver competitive advantage to our shareholders?  Those are the truest criteria against which you should evaluate every dollar or pound (or currency of your choice) you spend on your customer (insert phrase du jour) program.  Happy hunting.