Home > Work > My experience of project failure

My experience of project failure

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.

Advertisements
Categories: Work Tags: ,

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: