Independent CRM consultants and their role outside CRM software selection...

One of my training partners was telling me about one of his client’s purchase of a Microsoft CRM system, as we were out running this morning. As the story went the client had settled on MS CRM as the preferred technology and then went on to find an implementation partner. They solicited two bids. One came in a £60K and one at £250K. On the basis of price, not surprisingly they decided on the former.

I found it interesting that a user wouldn’t seek advice from a CRM consultant in this sort of situation given the wild disparity of pricing, but it didn’t altogether surprise me. This reluctance to engage outside help in these circumstances tends to stem from a number of false assumptions:

That selecting the right technology is the key challenge, and once you are settled on that everything else is straightforward. In reality while technology (and implementation partner selection) is very important, it is by no means the toughest challenge in applying CRM technology. The areas of strategy, process design, and user adoption are far more demanding.

That the quoted price in an accurate representation of what you will end up paying. Since most CRM vendor pricing is provided on indicative or estimated basis what the client ends up paying can be an order of magnitude different from the initial quoted price. The client either has to dumb down the requirements or accept the shift in budget.

That CRM vendors have the ability and inclination to deliver a system that significantly improves performance rather than a system helps them meet their sales targets. The two objectives rarely coincide in my experience.

While I don’t think these myths will be debunked overnight it will be interesting to see if independent CRM consultants do get more involved in situations where the technology for one reason or another is already selected. There are a number of, what strike me at least, as compelling reasons why we should, in that they help the client:

Achieve more - through using experience and understanding of how businesses operate to create the vision for a high pay-back system, and project management skills to make it happen.

At a lower price - primarily achieved by designing the system up front and letting vendors bid on a fixed specification which allows the comparison of like with like in a competitive environment, and reduces costs through effective negotiation.

With less risk - through experience and proven implementation methodologies.

With less internal disruption - by outsourcing what can be highly time consuming internal implementation activities.

I suspect that the role of the independent CRM consultant will change over time as people realize the technology question, while important, is just a part of a more demanding challenge – how do we apply CRM technology in a way that truly changes our business? When organizations start asking this question things are going to become very interesting.

The tyranny of the CRM change request...

Conspectus asked me to write an opinion piece for them on matters of my choosing pertaining to CRM technology. While I suspect they would have preferred something rather more topical regarding CRM and Twitter, or CRM and H1N1 for example, I warmed to the topic of the CRM vendor’s fixation with selling software as being responsible for most of the ills of the industry. I won’t detail the line of reasoning, suffice to say if and when the article gets published I’ll provide a link to it.

I’m deeply immersed in taking a couple of sites live at the moment, and was therefore reminded of another facet of CRM vendor behaviour that supports my ‘software sale fixation’ theory – the change request. As I outlined in a recent post on the CRM design hell, vendors generally require you to sign off a design which they will go away and build, and if that doesn’t happen to be what you wanted when it’s delivered, they will raise a change request for you to sign off which will generally entail you paying them money to go away and change it.

In principle this is a sensible policy since it’s designed to prevent the phenomenon of ‘scope-creep’ where the client keeps adding new requirements. In practice however CRM vendors – and I suspect software vendors generally – use it in a way that defies some of the basic practices of customer service fully accepted by virtually every other area of commercial endeavour – primarily the notion that if p*** off the customer they are unlikely to come back and do more business with you.

Imagine if you went to a restaurant and ordered the soup and what turned up was mere a teaspoon full of your selected starter, and when you remonstrated with your waiter, you were informed that they had indeed delivered ‘soup’ and if you wanted more then of course you could place another order. Predictably, unless you were on some radical diet, you might feel rather upset, and might well choose, amongst other lines of protest, not to visit the establishment again.

While the two vendors I’m working with at the moment have proved pretty good in their use of the change request, they are very much the exception. Over the years, time and time again, I’ve seen vendors bludgeon their clients into submission with the heavy handed use of the change request process, and it creates such bad feeling I find it difficult to fully fathom why they do it.

The focus of vendors seems to be on what is ‘signed off’ rather than what is right to help the client’s business. And as long as something is signed off the vendor is generally happy, regardless of whether that something is in the client’s interests or not. Thereafter the standard operating procedure seems to be to maximize the short-term profitability of the client by using the change request procedure to limit even inconsequential changes.

This practice reflects the following aspects of the CRM vendors’ world-view:

That their role is to sell technology NOT deliver business solutions – however much ‘solution’ may litter their marketing literature and sales presentations.

That a project is a ‘one-off’ spend with the vendor. That ongoing revenue is seen as a nice to have rather than a fundamental requirement that needs to be catered for.

If things are to change the vendors need to understand that they can implement genuine business enhancing solutions, and when they do they will have a client happy to invest in their technology over the long-term. If and when this world-view changes then the change request may finally revert to a sensible tool to manage projects.

On CRM and User Acceptance Testing...

Having sat through countless sales presentations over the years where vendors have rhapsodized about their carefully honed implementation methodology I can observe that the reality rarely measures up to promise of the pitch.

One manifestation is the quality of what gets delivered into the user acceptance testing (UAT) phase where the client assesses whether the development work undertaken by the vendor meets their requirements. It’s at this point that the vendor can, to use a sporting metaphor, throw their client a ‘hospital pass’.

In principle, and according to the fluently presented glossy implementation methodology, what the vendor should provide to the client is a rigorously tested system, which can practically be waved through UAT.

In practice however, the rigorous testing phase can quickly be dispensed with if the vendor finds them self under time or budget pressure, and the client effectively gets landed with the vendor’s testing responsibilities, or worse, gets to try and test something that’s effectively still in development – the equivalent of putting up the wallpaper while the plasterer is still at work. What might have been a relatively trivial piece of work is transformed into a death march as the bug count ratchets up and up.

Just to make this all slightly more pressurized, because UAT is pretty much the final step before live, most of the associated live activities are all now scheduled, and there’s relatively little scope to move dates out to reflect the unexpected influx of work, and so the test team ends up absorbing the workload the best way they can – generally dispensing with life’s luxuries such as sleep.

There are however a few things that can be done to help address this:

Have a detailed mutually agreed and understood design specification that gives you something to test against – this limits the scope for misunderstanding as to what should be delivered

Give yourself plenty of wiggle room in the project plan in order to absorb the unexpected developments that will inevitably occur.

Pay for implementation work on the basis of achieving defined milestones, and make sure one of those milestones is the delivery of a high quality system into UAT. I’m also wondering, though I’ve yet to try it, whether it’s worth offering vendors bonuses for hitting quality targets, just because of the potential downstream savings.

Make sure your vendor has scheduled for resources to be available to quickly fix the issues you identify, because if developers get allocated to other projects, you could be facing a long wait.

Assume the worst, because you’ll generally be proved right, and allow more time than you possibly think you’ll need.

In summary, while UAT is one of the final hurdles in the implementation process, it’s been responsible for more than its fair share of project delays, and has tempted many a project into the potentially fatal act of going live with a part-cooked system. As with many aspects of CRM implementation, it’s worth treating cautiously.