On buying Tiger Wood's golf clubs...

In a recent article for the BBC Bill Gates made the following point:

‘So if you look at how progress is made and where competitive advantage is created, there's no doubt that the ability to use software tools effectively is critical to succeeding in today's global knowledge economy.’

I’m hardly going out on a limb to suggest the ability for an organisation to harness technology will be an increasingly key determinant of success or failure. The key words however in the above quote are use and tools. The acquisition or possession of technology is not sufficient; it has to be applied in a way that creates value.

If I were of a mind to, I guess I could purchase a set of golf clubs just like Tiger Woods uses. I suspect my game might improve a little as a result, but nowhere near as much as it would if I combined the technology with some lessons and practiced more. Too many companies buy the technology (golf clubs) but don’t learn to improve their game by using the tools effectively, probably because shelling out the money is relatively painless, but applying the technology involves considerable sweat and commitment.

The good news is that if it were easy to do everyone would be doing it. For those companies that want to find a new source of competitive advantage in a world where the latest product or service innovation is ‘me too-ed’ in minutes, learning to apply technology can be a powerful source of sustained competitive advantage.

InsideCRM Top 20 Blog...

Well it's always nice to get some recognition. InsideCRM has kindly listed us in their top 20 CRM blogs - at number 10 in fact. They note the following:

Richard Boardman has worked on both sides of the CRM fence — first at a major CRM provider and then as a consultant at his own firm. This gives him both firsthand insight and a host of contacts to draw from. His monthly interviews with other CRM pros gives his blog a broader view, and his own commentary is polite (as befits a Brit) but to the point (as befits a good blogger). If the posts were more frequent, this blog would rank higher on our list.

I'd note I didn't set out to be polite, though I did intend to be more frequent. The basis for a New Year's resolution perhaps...

Get the full top 20 here

Sometimes it does go wrong...

I was presenting at a seminar this week and made the observation that in terms of mid-sized CRM deployments the vast majority make it through to live – albeit with varying degrees of angst and heartache along the way (and ultimate return on investment). Then I recalled that the last time I made the same observation was in a seminar almost two years to the day previously. There were two gentlemen on the front row, who I later got chatting to, who had just issued a purchase order for a reasonably substantial system. The alarm bells had rung a little because their ambitions for the system seemed significantly out of proportion to their anticipated budgets.

Roll on twenty one months and I came to be chatting to a rather dispirited CRM project manager whose tale of woe I suddenly realized related to the same project. Nearly two years after the original purchase order had been placed, no system had been delivered and vendor and client were now consulting their lawyers. It was a classic example of a mismatch of expectations, which is perfectly illustrated in Steve McConnell’s book ‘Rapid Development’ which shows a cartoon in which two men are looking at a plot of land planning a development. The client has a thought bubble emanating from his head showing a building rather reminiscent of the Taj Mahal, and the builder with a bubble depicting a considerably more modest residence. Both men are happy based on a completely different concept of the deliverables.

While outright project failures are a relative rarity these days, the more common manifestation of the expectation mismatch are project delays, budget overruns, and delivered systems that don’t actually generate much value. The cause is generally still the same, a tendency towards what might be termed ‘bullet-point’ requirements. These are high level requirements that present plenty of scope for misinterpretation. In this particular case it looks as the bullet points hid the detail of what both parties were anticipating in the way of integration between systems. The client envisaged a rather involved real-time two way integration between the CRM and several other key systems, the vendor saw this as a rather more simplistic batch upload.

I know it’s a point I tend to make ad nauseam, however effective requirement gathering and documentation is the foundation for a successful CRM project. It facilitates a number of desirable things:

It lets you select software in the light of a detailed understanding of requirements allowing you to choose the most appropriate package and avoid being committed to an option that doesn’t meet your needs. It allows you to select a vendor based on firm pricing proposals rather than guess/estimates, considerably improving the basis for comparison and the client’s negotiating position. It avoids a ‘hostage’ situation when detailed requirements are constructed post purchase of the software when it’s in the vendor’s interest to ‘grow’ the scale of the project, and the client is locked in. It reduces the risk of budget and project overruns through limiting scope creep, when ‘new’ requirements keep emerging during the implementation process

And if things go really badly it can avoid a lot of pain, recriminations, and lawyers fees as well.