There are many situations in life where we find ourselves wishing things were better. Hardly a day goes by in which I don’t dream of being a scratch golfer. In these moments of reflection, I consider the difference between my golf game and Rory McIlroy’s and wonder how that gap might be bridged. Luckily, my wife is always on hand to stop me giving up work to spend more time on the driving range.
It’s a shame that she is not on hand to help companies that set about procuring new IT systems. They too are apt to consider the perceived difference between the current situation and a future ‘desired’ situation as a first step in figuring out what should be done. In their case, it seems completely logical to attempt a definition of this future utopian situation and to use this to estimate the distance that must be travelled to get there. If they had someone like my wife around to review this plan, she would tell them two things; first, that they don’t know what they want and second, that they would be mad to attempt it. And in most cases she would be absolutely right.
Because, although it does sound logical to see things this way, experience has taught us that it seldom works out as we hope. Defining a set of business requirements has to be one of the most difficult challenges any company can face. How does any company know what it needs? Who has this information? How is it to be extracted from their brains, verified and consolidated with the opinions of others to create an overall view of what is required? If the project may last 2 years, what will be needed by the end of this period? And if the new system won’t be replaced for 10 years, what might the business need over this period?
Of course, expert consultants can assist this process by pointing out many of the typical requirements that the company might have, and inviting a selection/ranking of these. But still, the challenge of identifying what the business needs now, and may need in future, is an extremely challenging one. In most cases, the result is a long and detailed document that gives everyone confidence that the requirements are known. This is akin to me producing a detailed breakdown of all the things my golf swing needs to achieve in order to beat Rory McIlroy. It looks good on paper, but is it any use? For a business, is this what is really needed? If we build it, will we be happy? Or will we create things we don’t need and fail to create the things we do need?
From this shaky starting point we create a Gap Analysis to show everyone what needs to be done to take us from where we are now to our stated goal. This becomes the base document on which the future project is based. And therein lies the danger for any business that treads this path. Because, in general, companies do not know what they want. And even when they do know what they want, they are not able to describe it. And when they describe it they often describe a proposed solution rather than the actual need. In the words of Don Reinsersten*, “The sad truth is that there is no one ‘voice of the customer’. It is a cacophony of voices asking for different things. Even at a single customer, we need to balance the needs of technical decision-makers, end users, system operators and financial decision-makers. All of these actors weigh different attributes differently.”
And yet, in the face of all of these uncertainties, we have created our Gap Analysis and had it signed off. This document will support our multi-million dollar, business-critical IT project. Fasten your seat belts. As my wife would say, “You don’t know what you want and you’re mad to attempt it.”
*I am indebted to Don Reinersten, who has expressed many of these sentiments better than I can in his foreword to ‘Agile Software Requirements: lean requirements practices for teams, programs and the enterprise’ by Dean Leffingwell (published by Adison Wesley)
Be the first to comment