Project Managers: Save money by investing in Requirements

The return on investment in requirements can be returned very quickly. This article makes the case.

Projects demand the spending of money in the anticipation of future benefits. But how certain are we of those benefits? Did we understand the underlying problem before the green light was given to the project? Did we try to anticipate the total costs? Or does the project exist for purely political or other reasons that have nothing to do with business objectives? Now, with the words recession and credit crunch echoing around, is not the time to be wasting money. Now is the time to have a rigourous approach to both requirements and to business cases.

A requirements process starts with the identification and analysis of underlying problems and potential opportunities. Michael Jackson, the consultant and writer, not the singer, has written persuasively of the importance of starting with a thorough problem analysis; (‘ Software Requirements and Specifications’). Only once the real problem is understood can we sensibly start to calculate the likely benefits and even to see if these benefits fit with our organisation’s business objectives.
With the problem understood, it is worth checking to see if someone else within the organisation is already working on, or perhaps has even found, a solution; in this case, your requirements process will have prevented more money being spent needlessly.

In analysing the problem we have presumably identified the stakeholders - the problem owners. With their help we can determine the problem’s scope costs; we now have the basis of our ‘do nothing’ option for the business case. We can propose possible solutions, scope and cost them, analyse their inherent risks and suggest appropriate project approaches; the rest of our business case is now well on its way. We are well placed to make an initial assessment of the return on investment, break-even point, etc. And if we keep managing these stakeholders well, when it comes to eliciting the detailed requirements we can be confident that we are getting them from source.

Having got us off to a good start, the rest of our requirements process is ready to roll. To ensure that this process gives us a good return, we need to ensure that it is flexible. If the project fails, we of course get no return; we will however have incurred cost and wasted other resources. And if the project fails there is good body of informed opinion that says the failure is unlikely to be due to technical reasons. The reason is far more likely to be inadequate requirements. I think the first time I saw the graph highlighting the most errors get into a system at the requirements stage was in ’75 – James Martin. More recently, the well known requirements specialists, James and Suzanne Robinson, have made the same point. The Standish Group have observed that many of the most significant project success criteria are requirements related (‘Chaos 10’ – The Standish Group).

Fortunately though, more is not necessarily better; we need to work cleverer, not necessarily harder. We’ve understood the problem, we’ve identified the high level requirements for a solution, so let’s make the rest of the effort proportional to situation as we know it.

Spending too much time on unnecessary formality or detail will reduce the potential return. But as Soren Lauesen has pointed out (in ‘Software Requirements, Styles and Techniques’), there is more than one way to capture requirements. How formal or informal do you want, or need, to be? Do the requirements need to be written down at all? How much do developers already know, in advance of your requirements effort? Can we re-use requirements? Getting the most appropriate answers to these and other such questions demands a risk based approach to requirements. How large and complex is the project? What is the experience of the developers or the likely availability of the users?

If the project is trivial or something we have done a hundred times before, any requirements effort may be slight. But if the project is strategic and novel, or is being outsourced and developed on the basis of a legal contract, we’d better take care. Even here, though, we should ask if we need to get to the level of writing, ‘The user must be able to .....’? How well does the supplier know our business? How many successful examples of such systems have they created in the past? Could we make do with well written use cases and a class model? The trick is to fully investigate the situation, understand the quality policies of our own (or our client’s) organisation, do the risk analysis and then select the optimum elicitation and documentation techniques.

And if we get the requirements correct, the path is smoothed for a successful development, verification and implementation. As in American football, if part of your team removes those big obstacles early, the rest of the team can run, unfettered, with the ball – and score.

So in summary, we do not necessarily need to spend a fortune or take forever to obtain adequate requirements. We need sound and judiciously chosen techniques in the hands of trained and experienced people and we need to respond appropriately to the perceived risks. If we do this properly, a relatively small investment in requirements should both save us from potential losses and open the way to considerable gain.

For further interest, see also our course, >Requirements Driven Project Management