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.