Home > Work > Towards better requirements

Towards better requirements

My personal experience is that the main contributory cause to failed IT projects has been poor requirements gathering. This has been a common finding in many surveys carried out over the years. But what can IT project managers do about it?

I suppose above all else, awareness is the first issue. For non-technical managers, the initial problem seems deceptively simple – “I want a system to do x” – possibly more or less the same as an existing system – “it can’t be that difficult, surely?” But of course, it is difficult, and nearly always requires much more rigour from the business than they are used to. An IT project manager must take a very evangelistic approach to make clear to the business, especially higher up in the management chain, the amount of sheer effort needed.

The second issue is clarity, working to ensure that all awkward questions are asked, assumptions challenged, and edge cases identified. The role of IT is to keep nagging away at the business until all the vague, hidden or forgotten requirements are exposed.

Next, they have to be recorded in such a clear way that there is no scope for misinterpretation. This is another area that needs a lot of attention. I find that the overwhelming majority of people working in IT have a scientific academic background and are not instinctively comfortable with expressing themselves in writing. At school they dropped subjects like English and History, to avoid all the essay writing. So a lot of us in IT have to make an extra effort.

Appropriate use of techniques can help, in that they provide a way to discover all the assumed, hidden and unknown information that must be put in order before system development can begin. Following a particular methodology may also help to record it too. There is no single best option that always leads to better results than any other (whatever proponents of this or that approach might claim), but following an established practice reduces the scope for repeating everyone else’s mistakes. Which approach to follow is a matter of preference.

Finally, project management has to be very outward focussed. In the successful teams I worked with, the Project Manager was often almost invisible to the team, and most of them wondered what he actually did. He spent all his time managing the source of all the real problems – i.e. the business and any other external group – and deflecting them before they impacted the development team. A good Project Manager puts issues in the line of sight of business managers early, to make sure there is enough time for the business to confront them in time and in the right order.

This applies as much (if not more) during the requirements gathering phases as at any other time, when deadlines seem far away and time can easily slip.

All this is easy enough to say and much harder to achieve – I don’t claim a better track record than anyone else. It is fair to say that there are plenty of opportunities for people who want to shine!

Categories: Work Tags: ,
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: