Archive for April, 2010

Towards better requirements

April 28, 2010 Leave a comment

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: ,

The Beauty of Maps

April 26, 2010 Leave a comment

As a sometime geographer, I had intended also to make the occasional post about London. I have one or two in progress, but they are taking a bit of time to take shape.

I don’t have time for much television, and certainly not every day, so I’m catching up via iPlayer on the BBC’s Beauty of Maps series on BBC4. I just watched City Maps – Order out of Chaos, which told the story of two old maps from 1682 and 1748, and a very different contemporary map! The programme puts the maps in the context of their time, and explain why they show what they do (and what they chose to ignore).

Well worth viewing, both this episode and the whole series, still available for the next 70 days or so on iPlayer.

Categories: London Tags: ,

Why are business requirements always so rubbish?

April 18, 2010 1 comment

OK, perhaps not always, but surprisingly often. I have worked on a several failing projects, and almost always they failed right at the outset by making a mess of the requirements. Here are what I have found to be the most common reasons for poor requirements, in no particular order.

1. Lack of clarity in understanding own processes

The key business users unintentionally hinder the discovery of the full set of requirements, including

  • focussing on the part of business they understand best, based on their own current or past role, to the neglect of the rest.
  • failing to involve others in the team who do the job now, so that the requirements capture what used to be done rather than what is needed now.
  • have been doing the job for so long nothing is documented, and they struggle to recall all the edge cases out of context.

2. Incorrect specification

This is where, irrespective of the above, the requirements reflect some major flaw in the business’s approach, which is initially hidden from the development team.

  • The requirements describe the current process, but it is sub-optimal.
  • We’ve had a great idea but we haven’t tried it out in practice.
  • There will be change, but we don’t know what it is yet, so we’ll have a guess (but not tell you we’re guessing).

3. Inability to make a decision and stick to it

Sometimes it is right to change a previous decision, when new information comes to light, but too often decisions are repeatedly revisited and reversed, when nothing has changed. This seems to happen most often in large organisations where there are too many stakeholders and politics takes over.

4. Defining solutions, not requirements

This is not always a bad thing, as some system context is usually appropriate (e.g. target operating system). However one system I worked on was to implement a Direct Debit system to accept payments, when it soon became clear that the most cost-effective solution would be to employ an additional part-time cashier. The business would not countenance this and insisted that it had to be collected by Direct Debit at a much greater cost.

5. Inability to write clearly and unambiguously

We are all guilty of writing rambling sentences containing tortured syntax. Business jargon is often used without clear definitions. Both give plenty of scope for misinterpretation. Ordering the requirements within the specification in a coherent sequence can also be difficult, making it hard to spot all related requirements.

6. Focus on process, not quality

Some organisations focus on demonstrating that a process is being followed for its own sake, not for the benefits the process is supposed to bring. Success is judged by the presence of a ticked box on an audit form, not by the quality of output. Numbers are easy to measure, quality isn’t. I worked in one organisation where a full set of documents was always produced and formally agreed by all concerned but its content were neither accurate nor complete, and of no value at all. (But we passed our audit). There is no excuse for this.

7. Hurried requirements

A weak manager under pressure thinks: We’re already running late, so we’ll do a quick job and lob it to the developers, and then we can claim that the project is still on time, and leave them to sort it out later. Hopefully I’ll have moved on by then…

Categories: Work Tags: ,

My experience of project failure

April 8, 2010 2 comments

I have worked on many IT development projects; my experience is typical in that some of them were very successful while others were barely disguised disasters. When I look back at the projects that came in late, over budget and not to specification (usually all three, if they weren’t cancelled altogether) each failure has many contributory factors but in the end they can all be fitted into two main categories:

1. Poor project management
2. Poor requirements

None of my projects ever failed to deliver because the team found the solution to be technically impossible.

My experience corresponds with the findings of surveys that are regularly quoted.

All developers like to rant about how inept all project managers are; it is easy, but not instructive, to point the finger in that direction. There are a lot of things going on in a typical medium-large project over which even the best project manager has little control (corporate politics, key decision makers’ ability, other groups or departments, suppliers) and which can threaten even the best-managed project. It is no surprise that a proportion of them fail.

What I find surprising is how often a project goes off the rails because the business requirements haven’t been defined correctly – surprising because this is really the only bit the business has to get right, and it is also the one bit they ought already to understand better than anyone else. Most of the projects I have worked on have suffered from defective requirements at the outset.

There are some common symptoms that may suggest poorly defined requirements.

  • Lots of meetings endlessly revisiting and reviewing, but nothing ever gets signed off
  • High volume of Change Requests

Failure adequately to define the requirements at the outset obviously makes a major hit on the total cost of the project, and its overall success in delivering what the users want.

It is widely known that there is a huge penalty for discovering requirements errors at a late stage in the process. King and Morasco quote Roger S Pressman and Robert E Grady’s evaluation of the relative cost of fixing a defect found at the test stage as being 15 times as expensive as discovering the same error at the requirements stage. After deployment the multiple is 80.

This is particularly damaging where the requirements are given to a third party supplier to implement. At best, the project delivers what the business asked for, but not what they wanted, and probably not something they can use. If developed off-site, this might not come to light until User Acceptance Testing.

More likely, the flaws are identified singly during development and gradually fixed. The burden of additional work, and effort of managing change, to correct the specification in mid-project inevitably leads to increased cost and schedule overruns. Often this may lead to contractual wrangles with suppliers, which can be even more costly – especially if the relationship is not a good one and both sides are seeking to cover themselves in the event of a dispute.

So my view is that the key area to focus on is requirements, both as a customer or as a supplier, as it is the one major area that it is entirely within the ability of the project team to control. In future posts I will be outlining my thoughts on how to do this.

Categories: Work Tags: ,