Hope is not a strategy

Quoting from a recent Cynthia Rettig article ..."TECHNOLOGY has always been about hope. Since the beginning of the industrial revolution, businesses have embraced new technologies enthusiastically, and their optimism has been rewarded with improved processes, lower costs and reduced workforces. As the pace of technological innovation has intensified over the past two decades, businesses have come to expect that the next new thing will inevitably bring them larger market opportunities and bigger profits. Software, a technology so invisible and obscure to most of us that it appears to work like magic, especially lends itself to this kind of open-ended hope." Read the full article here.

And as Rick Page says "Hope is not a strategy".

Cynthia (and many other IT pundits) cites examples of organisations wasting tens of millions of dollars on unsuccessful implementations, and you know, in the small-mid tier market it is just as frustrating and disastrous wasting tens of thousands of dollars on a bad outcome.

The problem so many times as she well articulates is that most systems available now are blindingly sophisticated and complicated and come with so much potential customisation that the implementation projects invariable run off the rails and frequently very early on in the time frame. This is exacerbated by the fact that there may not be a clear definition of what is to be done and how, and even if it was defined it may well have changed between system selection, project initiation and implementation.

The hairy-chested challenge for any organisation is to be able to meaningfully define their system requirements in the form of people, processes, systems and outcomes (and to keep it up to date) and to be able to articulate these requirements in a way that allows 1) potential solution partners to understand and affirm that they can deliver a solution and 2) for the company to be able to compare a number of potential solutions, do a gap analysis and assess the risks and rewards of each offering prior to making a selection.

It's a big ask and one that is generally too hard to both achieve at the start and keep current through the project - so the requirements tend to be boiled down into a request for information/tender document as lines of "yes/partially/no" compliance for feature/function wish lists. It is very hard to describe a business objective and supporting end-to-end process in this manner and even harder for a solution partner to respond at any level of reliable detail. There can be an awful lot of "it depends" in any RFI response. So invariably there are some (or many) iterations of this as questions are asked and answered as a part of the qualification stage for both parties.

Upon system selection the maddening customisation journey begins and again there are challenges to all parties to keep focused on achieving the objectives that were not really defined well enough to start with. And there goes the budget, the time line and the project managers hair.

So is there another way? We think so. Use a process modelling tool to map, model and describe what the overall system requirements and objectives are. Involve stakeholders from throughout the business to add accuracy to their areas of specialisation. Give them a simple tool that allows them to depict what they require within the constraints and standards of the overall framework. Save this into a navigable website that allows everyone to traverse through end to end processes and track what the actual objectives and desired outcomes are and then issue that as part of your RFI/T pack and use it to assess the responses and do the gap analysis. Get really smart and issue a simple tool to the RFI respondents allowing them to truly relate their solution to the specification.

It moves the system requirements and fulfillment process into a new world and brings great transparency and clarity to the task for all stakeholders. The effort invested upfront pays dividends all the way to the end of the implementation as there is an accurate and consistent benchmark to work against for the life of the project.

This sort of approach removes the "hope" from your systems selection and implementation strategy.

The Disney Process Magic

Yes yes - its been a while since I last blogged - a busy time on the work and home front - not least being a few weeks holidays with the family that had us slog through my all time favourite place - Heathrow airport - not once but three times - we'll come back to them.

One stopover was a trip to Tokyo Disney Land - a magical place for the true believers under 8 years old and also surprisingly a magical place for those of us interested in customer service and process driven things. I have been triggered today by someone elses visit to an American Disney franchise here.

Let me start by saying that Disney Land is not for the feint hearted as it is perhaps at the pinnacle of American commercialisation however the Tokyo location is almost surreal as it wraps a lovely Japanese-ness around the rapacious American core. Then again it is very much a Japanese domestic tourist destination and as an international tourist with none of the local language maybe I missed the more subtle nuances of how they extract extra cash from the wallets of the day's "guests".

Let me tell you what Disney Land is brilliant at - people processing. Yes, there are queues but they obsessively (and happily) tell you how long you will have to wait from check points - you knowingly choose to wait that long (we were generally at the "only 5/10 minutes from this point" on a rainy midweek day but there are plenty of "only 45 minutes from here" signs which would make for a very slow day). Yes, there are barriers setup to allow the daily parades to occur but they are very low key and are erected so subtly and disassembled so rapidly that they barely interfere with the crowds. Everytime you think "where is ...?" or "how do I ...?" or "I wonder if ...?" there is a smiling and willing "Cast Member" at hand to guide the way and with a charmingly over the top little flourish which I gather is the "Disney way" of giving directions throughout the franchise - and always with as genuine a smile as you could expect in this sort of environment - more of that great global training that Tom Hoobyar refers to. As a queue grows beyond the guide rails to contain it as if by magic additional rails are smoothly and quietly clicked into place to bring control back to the crowd. They know where they want the queues to form and they manufacture the queue in such a way as to get best space efficiency and least interference to the other spaces in the vicinity. The place is spotlessly clean and I got the impression that if you did drop any litter (deliberately or otherwise) a smiling sweeper would appear out of nowhere to pounce on it with glee. There isn't even a chip missing in any of the thousands of bench seats scattered everywhere. I was told by Ariel's (one of 6 apparantly) boyfriend in the queue at Narita on the way home that the maintenance crew works 24x7 to keep everything in near perfect condition - and it shows. As you walk around what is one of the top tourist destinations in the world there is no sense of shabbiness, over use, wear and tear or threadbare - the place is like new despite the millions of bodies that surge through it every year.

Now let's compare that to my nemesis - Heathrow - where do you start - 2 ends of the spectrum. Sure Disney is a commercial enterprise very focused on maximising the dollars it can extract out of your pocket and a destination you have actively chosen to visit - and Heathrow is probably neither of those - but does that excuse their unwillingness or inability to be efficient and effective at what they do? Just about any customer centric business (and what isn't these days) could benefit from a Disney-like culture of cast member engagement and obsession with efficiency. The Disney "successful guest outcome" was surprisingly seductive for this sceptic.