Swimming naked?

Buried at the tail of my seemingly off-message post about Greg Lemond’s last gasp victory in the 1989 Tour de France, was an assertion that businesses generally, and SME’s in particular, are failing to make effective use of technology as a means of providing competitive advantage. You may or may not agree with me of course, but as part of that post, I also promised a couple of theories as to why executives were reluctant to engage in this area.

Firstly, whether it’s because we as today’s executive team were not in the main raised in an era where computers populated every school room, home or desktop - or perhaps, that the industry has managed to acronym people into viewing information technology as some impenetrable dark art - there’s been a tendency to delegate all thing IT to the IT department. The heavy reliance on the IT department to drive strategy has an inherent problem, simply put the IT department's raison d’etre has tended towards maintaining the status quo, rather than initiating major change. Major IT change is inherently disruptive. People don’t like disruption – and have a tendency to shoot ring-leaders when it happens. IT managers understand this. They, in the main, do not want to be shot. They, in the main, will be pushing for conservative, easily manageable incremental change, not bold new strategies.

Secondly, the executive team are conditioned to expect little from IT. When change does occur it seems to be mystifyingly disruptive, and of marginal incremental value. We remember the upgrade to the email system last year; the one that cost thousands, had everyone locked out of the system for two days, which gave us what? A couple more features that no-one uses. Peruse the newspaper, watch the news, there’s an article about another big government IT project, awesomely over budget, and with no delivery date in sight (the private sector ones perhaps being rather more effectively hushed up).

Thirdly, there’s a tendency towards what military strategists might identify as a proclivity to prepare to fight the last war. In other words, our strategies tend to be driven by our experience of the battlefields of the past, rather than consideration of the character of those of the future. It’s what led France, after the first war, to construct the vast static defence of the Maginot line, only to see German forces sweep around it. Advances in military technology changed the rules of the game. In the same way in business we tend to compete on the basis of what’s worked in the past, rather than what will work in the future.

While many executive teams are defensive in their use of IT, an increasing number are not. Household names like Dell and Amazon are transforming their markets through the innovative and effective use of information technology. On the SME front we see a small, but increasing cadre of companies quietly dedicated to upsetting the market status quo by deploying IT in a way that fundamentally changes the rules of the game. Interestingly, speaking to one senior executive last week, whose company is very focused on IT as a strategic weapon; he noted their gains in market share were seemingly hidden to their competitors by the general growth in the market as a whole. Perhaps the true extent of the impact of the IT innovators won’t be fully felt until market conditions get tougher. As Warren Buffet noted in his 2001 letter to Berkshire Hathaway investors – ‘you only find who is swimming naked when the tide goes out.’

In sickness and in health...

One of the areas I touched on last week, was the tendency for organisations purchasing CRM technology, to focus on functionality rather than implementation credentials.

We have a couple of projects at the moment where we’ve helped the client finalise their business and functional requirements, and are now assisting them through the vendor selection process. One area we’ll certainly be focussing on, is the strength of the implementation teams from each prospective vendor. Typically engagement with a vendor breaks into two phases – pre-sale and post-sale. Each phase has its own set of characters, and it can be a little like watching Sven Goran Eriksson’s England play a friendly international – it’s likely to be a whole new team in the second half.

Which is an interesting point, because purchase decisions tend to be driven, whether purchasers fully realise it or not, by the buyers comfort with the salesperson – who of course is going to play, at best, a back seat role through the implementation process, and quite possibly will never be seen again. The team that can make or break the project – that are going to do the real work – that can make your life a joy or abject misery – rarely come into play. Which seems a little like selecting a wife or husband solely based on three dates with his/her distant cousin.

I think it’s important to include the implementation team itself in the decision making process. It’s particularly key to meet the principal players, particularly the project manager/lead, and look to assess their capabilities and track record. When you perform due diligence type activities, such as reference calls and visits, it can be insightful to validate both the technology, the vendor’s general implementation prowess, but also the specific performance of the team you will be working with. At the end of day, perhaps your comfort with the people who will be doing the actual work is more important than affinity with the person selling it.

To create a firestorm...

If you want to create a firestorm, just post on one of the CRM forums indicating you are looking to purchase a CRM package and ask if anyone have any recommendations. Within minutes you’ll have a few dozen posts extolling the virtues of various packages, some mainstream, and others previously unknown outside the author’s back bedroom. Aside from a range of sensible well argued opinions (albeit proferred with relative ignorance of what you are trying to achieve), you will inevitably see posts from Rob (rob@megacrm.com) saying that he’s just purchased this package called MegaCRM which is truly, unbelievably fantastic, and pretty much sells your products for you – which will in turn be countered by Mary (mary@superdupercrm.com) who has just purchased SuperDuper CRM, which is replacing the MegaCRM system they threw out because it was utter manure, and here’s a list of all the features it has (bearing an uncanny resemblance to the SuperDuper CRM product brochure). And by the way please note here these are fictional products and any resemblance to products, either existing or dead, is completely unintended.

Anyway you get the picture – there are a lot of packages out there, and no shortage of people to argue passionately on which they believe to be the best. For SME’s there is considerably more complexity, because not only do they need to choose a technology, but because most of these technologies are sold through a network of resellers, they need to choose an implementation partner as well. As a result, a lot of the work we do is around helping our clients judge the most appropriate combination of technology and implementer to meet their needs.

Just to re-iterate a point we’ve made in the past, and one I fully expect to be making again in the future – the vendor selection process is largely a lottery, unless you have a clear understanding of what you are trying to achieve. It’s hard to gauge functionality if you are uncertain about what functionality you need. In addition, it’s very difficult to get comparative pricing if the requirements are fuzzy, because the vendors can only give you an estimate, which may bear no resemblance to the final invoice figure.

Traditionally in the CRM selection process, the technology tends to be the star of the show. If you were to analyse the split of focus between technological capability and implementation capability, I’d estimate it to be about 90% - 10%. This seems to me somewhat imbalanced, given that I would expect a good implementation of a mediocre technology to vastly outperform a poor implementation of an excellent technology. While we are very conscious of getting the technology decision right, we also place a lot of emphasis on the choice of implementation partner. We believe this is just as important in achieving high returns for the client. It’s an area I don’t feel gets a lot of attention, so this post functions as a brief introduction to several more over the coming months, where I’m going to set out some of the things we look for when assessing the implementer rather than the technology.

Paris - July 1989

One of the greatest moments in sport that I’ve ever witnessed, was the final stage of the 1989 Tour de France, when the American Greg Lemond snatched victory from Frenchman Laurent Fignon, by the tour’s narrowest ever margin, a mere eight seconds.

It was an astounding achievement in many respects. Lemond had been shot and nearly killed two years earlier in a hunting accident. This was his first year back in the Tour. Not expected to perform, he found himself riding for a low budget team, and ended up largely unsupported as his team mates dropped out in the mountains. With only one stage to go, Lemond trailed Fignon by 50 seconds.

In normal circumstance it would all have been over - by tradition the last stage is largely a procession into Paris, and the lead doesn’t change - but for the first (and last) time the tour was to be settled by a time trial against the clock. While this gave Lemond a glimmer of hope, it was the very faintest one. Given the short length of the stage – a mere 24km –no self respecting race commentator gave him a hope.

Lemond rode off two minutes ahead of Fignon, covered the distance averaging 34 mph, the fastest ever time trial in the Tour de France, and crossed the line to watch Fignon cover the distance 58 seconds slower, and lose the tour to the American by the tiniest of margins.

What is less well known, is that Lemond’s win came as the direct result of a significant new advance in cycling technology. Emanating from the triathlon community – a very young but innovative sport at the time - was a new design of handlebar. It totally changed the traditional set up; the U shaped bars put the rider’s hands and elbows together in the manner of a down hill skier, and in so doing dramatically reduced frontal resistance.

The new bars made riders not a little, but a lot faster. With the exception of Lemond, the traditional cycling community largely ignored these developments, content to do things the way they had always been done. But Lemond needed an edge and was happy to try something new. Without the new handlebars, victory would have gone to Fignon.

It strikes me there are parallels between the attitude of the cycling peleton and the business community towards harnessing technological change. I’ll perhaps speculate on the why in future posts, but in my view executive teams in the main are still uncomfortable capitalising on technology advances.

The ‘triathlon’ bars, as they were dubbed, had been in use for some time. The ‘technology’ was freely available to anyone who was prepared to invest £50 or so at their local cycle shop, and the 2 to 3 mph improvement in speed they provided was well documented. Despite the evidence to the contrary, the traditional cycling community was blinkered to the notion there might be a better way of doing things.

From a CRM perspective – the technology is freely available for a modest investment, but I strongly believe there is too little executive focus on using it to achieve real business gain. I’ve no doubt this will change over time as it becomes recognised as a key source of competitive advantage. The good news, for those who want to reap the maximum reward, there are so few organisations executing well on it, that the field is still wide open to gain the best returns.

A bridge too far?

Shoe-horned in between engagements, we finally got one Mareeba task completed this week, the selection and publication of a new bridge for the header of the web site.

The design agency we used for the original site came up with a beautiful image of the sun setting behind the Sydney Harbour Bridge and the rather too identifiable (as it turned out) Opera House. Over which was written our strap line - ‘the independent consultancy that bridges the gap between technology and success’. All very well done we thought. What we hadn’t considered of course, was that anyone searching the web for a CRM consultant, was, rather reasonably, going to conclude we were based in Sydney, New South Wales, rather than Amersham, Buckinghamshire – and quickly move on to the next site.

On the surface locating a new bridge shouldn’t have posed a Herculean task, but it proved rather more time consuming than I expected. We had four simple criteria 1. it had to fit with the existing colour scheme. 2. that it was a British bridge, or at least geographically neutral. 3. that we could acquire the image without demolishing the marketing budget, 4. that the image worked in the thin letter box style strip the header occupied.

A tour of the mainstream image libraries proved frustrating. After investing a significant time identifying potential images and decrypting the labyrinthine complexity of the associated licensing arrangements, I finally determined that sourcing an image that way was going to cost twice as much as it has cost to design and develop our web site in the first place.

Plan B, was to take a picture myself. One well-meaning suggestion was that the river Misbourne, which flows round the back of the offices, might prove suitable material. Given, that it would take a less than Olympian effort to hurdle the Misbourne even at its widest point, and the penalty for falling short would likely be no more than slightly moistened footwear, I concluded it wouldn’t prove a real show-case for what we perceived as the rather broader expanse between ‘technology and success’.

An operation to photograph bridges along the Thames valley was in the advanced planning stages, when we were pointed to http://www.stockbyte.com/, from whom we were able to source at a very reasonable price, the current image. Andy, our web developer, was a little concerned that the selected photograph of the Forth Rail Bridge wasn’t as geographically neutral as it could be, until I pointed out that a fair proportion of our client base resided within its twenty mile radius.

I liked the Stockbyte approach, as well as their pricing. Their help-desk was patiently informative when I phoned to pose a series of questions that were thoroughly and clearly documented on their web-site, had I taken the trouble to look properly. I particularly liked the email that followed sign up on the site, from their CEO Jerry Kennelly which concluded with the line – ‘Our product experts are always available to help you - or if you want to share something with the guy who started the company, drop me an email (I will reply personally - but not always instantly).’ Nice touch.

Anyway the bridge change may not have been our most strategic move to date but I’m a great believer that lots of small improvements are conducive to great results. We’ll see!

Be afraid, be very afraid...

‘It’s not in the standard product…..but it would only take a couple of days of customisation to add it’.

Sit in on enough vendor presentations and it’s a phrase that you are likely to hear often repeated.

My tip - if you hear these words, be afraid, be very afraid.

The reality is that most of the CRM packages are very flexible, and ‘it would only take a couple of days of customisation’ is not wholly untrue.

What this sound-bite fails to convey though, is that customisation is only one link in a much longer (and more expensive) chain of billable events that might more accurately be characterised along these lines:

1.The implementer meets with the client to gain a detailed understanding of the required additional functionality.
2.The implementer documents the requirements and submits them to the client for approval.
3.Based on the approved requirements, the implementer creates a design for how the new functionality will be incorporated into the system.
4.The implementer submits the design documentation to the client for approval.
5.The implementer revises the designs based on client input and re-submits for approval.
6.The implementer performs the customisation work.
7.The customisations are tested internally and any bugs identified.
8.The implementation team de-bug the customisations following review by internal testing.
9.The implementers help the client set up a user acceptance testing infrastructure.
10.The implementer passes the customisations to the client for acceptance testing.
11.The client submits any identified bugs or functional shortcomings to the implementer for resolution.
12.The implementer and the client debate what constitutes a bug, and what constitutes a change request.
13.The implementer fixes the identified bugs, performs the agreed change requests, and re-submits them to the client for user acceptance testing sign off.
14.The client signs off on the user acceptance testing.
15.The implementer/client updates related documentation such as training and usage manuals.

And of course the process is only as short as this if everything goes reasonably smoothly. Add to the above, the additional associated project management overhead, and consider that client side activities such as requirements definition and user acceptance testing can involve several staff simultaneously, and that the considerable amount of elapsed time will delay the return on investment, then it’s wise to consider departures from standard functionality with some caution.