06 Jul 2006 - I'm feverishly completing work on a number of requirements documents at the moment, prior to going off to do a David Walliams next week. Unlike the Little Britain star I’m not lathering myself in goose fat for a swim across the channel, but I’m off to Klagnefurt to take part in Ironman Austria. Two and a half miles swimming, 112 miles cycling, and a marathon await this blogger on July 16th. With the long range weather forecast predicting 30 degrees it could make for an interesting day!
Anyway between last minute training and a full roster of projects, my posts have been a little sporadic of late (or downright weird as in my Tazo recollections). Hopefully, if I can survive the race without too much damage, normal service can be resumed again soon!
The CMC says: GOOD LUCK RICHARD!
30 June 2006 - I had something of a flash back this morning as I waited in line to pick up a Starbuck’s order. There were a couple of bottles labelled 'Tazo Berry' in the preparation area. The name rang a bell, but I couldn’t quite place it for a moment or two. Assuming my memory is correct, and we are going back quite a few years now, Tazo's (aside being some sort of condiment currently in use by Starbucks) used to be the name of a promotional activity launched by one of the crisp companies. Basically they were little disks which were secreted in each pack of crisps with different characters on them.
The reason I remember them was that they played a not inconsiderable role in securing a large CRM system for one of the companies I worked for. As I recall there was a tender process for a system being run by the prospective customer’s IT department. One of the sales team got wind of the fact that the IT team was (for unfathomable reasons) desperately trying to collect the full set of Tazo's but were short several characters. The sales team took it upon themselves to initiate a monumental crisp consumption exercise that culminated in the location of all the missing items (and the addition of several inches of additional waist-line). These were duly presented to and gratefully received by the client's IT team, and in due course, and not coincidentally I suspect, our company received the contract for the system.
I mention this rather strange recollection to illustrate one point – the influences on purchase decisions are complex, often emotional rather than rational, and sometimes downright bizarre. Organisations will go to great lengths and expense to make objective purchase decisions, but I suspect when it comes down to it that’s not how decisions get made.
On a point related to my last post where I was bemoaning scheduling a workshop on the same day as an England match, a friend pointed me to what appears to be a Dutch web-site called www.markthisdate.com – can't say I've tried it yet, but it seems to allow you to download various types of event schedules such as the world-cup, or Tour de France, into your Outlook diary. So maybe that’s one problem solved for the future.
Mayhem to come?
23 June 2006 - It would be a nice feature for my own CRM system if it populated my calendar with significant events such as bank holidays, international public holidays, and other noteworthy occurrences, like say major sporting events. That way I might have avoided scheduling a workshop for the day of the England V Trinidad and Tobago match. Anyway, from what I could gather from the commentary it was one of those matches best watched on radio. As way of consolation the journey home at least was rapid – I can’t remember the M4 quite so devoid of traffic during rush-hour – and I did at least make it home for the last ten minutes.
At least the workshop went well. The client is well down the road to defining their requirements, so our focus was to help further shape them in the context of what is available 'out of the box' with some of the mainstream packages. This involved running through point by point and illustrating how each requirement could potentially be delivered through a CRM application. One benefit of doing this is that the client gets quick feedback as to the complexity and associated cost of delivering each functional requirement. They can consequently refine their needs by more effectively judging when to customise and when to live with standard functionality, and it becomes far easier to structure the project in the context of any budgetary constraints.
Anyway, given the inherent lack of certainty of predicting England’s progress through the remainder of the competition, there is significant potential for diary mayhem to come. Then again if we go on to win I guess I can live with it!
An international dimension...
14 June 2006 - Several of our current projects include deployment to international offices and users. This tends to make the implementation more challenging, and I’ve seen a lot of projects get tripped up because they didn’t appreciate the additional complexity. On the one hand requirements are generally a lot more diverse, not just in terms of local currency and language needs, but also because there can be distinct differences in the nature and operation of each market.
Secondly, user adoption can be much more ticklish when you are dealing with independent operations distant from head-office. A situation often exacerbated when international offices end up short of the resources they need to make the project a success because of the cost and relative inconvenience (unless the office happens to be based in one of the more exotic locations) of sending project staff around the world.
One of the key objectives with these implementations is to ensure the project isn’t perceived as a solely head office initiative and that the needs of the international organisations are well represented throughout the project. Resource allocation also needs to reflect the additional user adoption challenge of remotely based users and be weighted accordingly. Sadly our involvement in these projects has not yet resulted in as many travel opportunities I might have hoped for; technology is proving our enemy in that respect. There’s too much we can accomplish these days without leaving the office, never mind the country.
A self-made astronaut...
8 June 2006 - As I touched on in an earlier post, we are moving close to live day on one of our major projects. This week we got to see the fruits of the development work that's been ongoing for the last month or so. We put a lot of effort into gathering requirements and designing systems and it’s always a gratifying moment when we get to see the finished article. Which is not to say there’s not a lot of work left to do; there's an extensive testing programme now underway to check that what's been specified is what's been developed, and indeed whether what’s been specified does actually meets the user requirements – which is of course the ultimate acid test.
This testing process is actually more demanding on time and resources than it might initially appear. There was a nice line in an article in the latest edition of Fortune magazine on teamwork where it was noted that "Neil Armstrong didn't get to the moon through rugged individualism; there is no such thing as a self-made astronaut." The testing process is certainly no solo endeavour, and the project team are having to pull together well to get through it. It doesn't matter how well written the specification or the code, issues will inevitably crop up. Identifying them, logging them, communicating them back to the vendor, retesting the fixes, ensuring the fixes haven't broken something else, is time consuming, and it's easy for the project to drift off schedule if you haven't made sufficient allowance for just how long it can take. That said it’s not an area to cut corners. Users have a fragile faith in technology, and if they are greeted by a host of bugs the first time they use the system, it may also prove to be the last.
Success is never final...
2 June 2006 - It's a much hackneyed phrase, but we live in a world of unparalleled change. A couple of random facts derived from copies of The Economist currently sat on my desk – a feature on Goldman Sachs, notes that 30% of the company’s revenues in 2005 (i.e. a small matter of $7 billion), came from activities that didn’t exist when the company floated in 1999. An article about Nokia – in the era of the camera-phone, Nokia sells more cameras than any other company (I can't say I saw that coming when I got my first Nokia phone in 1995).
The pace of technological change, the impact of the internet, the rise of China and India, the splintering of the media, global warming, global terrorism, the increasing concentration of retailing power, to name but a few influences that are putting our businesses into increasing flux. Thinking about our customers, I can't think of one client who isn't facing significant new business challenges, whether it’s a major new competitive threat, absorbing an acquisition, being absorbed through acquisition, moving into a new market, moving out of an old market, etc etc.
I make these obvious points to highlight a key challenge from a CRM standpoint – while we have to build systems that positively support our strategic initiatives (and market success in this endeavour has been spotty to say the least) we also have to maintain those systems so that they continue to support the business as it addresses new threats and exploits new opportunities over time. As Winston Churchill said - 'Success is never final', and I think too often efforts in this respect mimic the plight of the novice skier executing a turn where the strategic leg of the business goes right, and the systems leg carries straight on.
For previous installments of Boardman's Blog, see: