Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Project Failure is Due to Bad Requirements

DZone's Guide to

Project Failure is Due to Bad Requirements

Many truths are counterintuitive to current beliefs. This article is oriented towards beginner and intermediate developers and product managers.

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

Projects can fail for a number of reasons, but at the root of most failures is a failure to gather correct and consistent requirements. We've all laughed at some variant of the above diagram, but these issues are all because:

  • We fail to capture correct and consistent requirements.
  • We play "broken telephone" when we are communicating requirements.

Let's take a concrete example. Suppose we have an orienteering challenge where you need to go from the start point below to the finish point. This is the actual requirement.  

But there is a gap between what the actual requirements are and what is actually written down.

Good Requirements

As long as the written requirements don't diverge too much from the actual requirements, you will have time to adjust the requirements during project execution and still get to the finish point.  

So as long as the initially written requirements are in the green zone, you can still complete the project on time because the requirements point you in the correct direction.

Mediocre Requirements

Now suppose one of the following happen:

  • You don't have all the core requirements because insufficient people were consulted.
  • You have conflicting requirements from different sources.

When you have less than accurate requirements, you will be in trouble. The initial code and architecture of the project will be created based on the quality of the requirements. If those requirements are suspect, then there will be rework as code needs to be adjusted as the scope of the project seems to shift.

So, now you will find yourself in one of the yellow zones below:

Even with the best execution, the project will be challenged. Deadlines will be missed as you attempt to bring the requirements back to what they need to be. This is like trying to change a tire on a car and discovering the jack is missing.

It is important to realize that adjusting poor requirements is not Scope Creep.  Fixing incorrect and inconsistent requirements is necessary and it is pointless for a project manager or executive to disallow these changes. It would be worthwhile for project postmortems if the project manager tracked whether a requirement was missing or inconsistent.

Challenged projects are typically declared as successes, but only after massive compromises, burned out resources, damage to reputations, and loss of revenue.  When all the damage is taken into account, this is hardly a victory.

Bad Requirements

The last situation occurs where you only have vague requirements before you start a project.  This situation happens where the executives need a project done quickly and over-estimate the team's familiarity with the subject domain.

These projects start with requirements in the red zone below. You don't have a prayer of completing this project and it will turn into a Death March with all of its characteristics (see Death March Calculus).

Making core course corrections to bad requirements is like trying to change a tire on a car when you are going down the highway at 100 mph. It won't happen.

Conclusion

It is human nature to assume that the sooner you start a project, the sooner you will finish. That assumption is only correct if you have good requirements to point you in the correct direction. Good requirements are consistent and correct and include, at a minimum, the core requirements for the primary users.

Starting a project with mediocre or poor requirements is simply a recipe for project failure. Mediocre or poor requirements are incomplete and inconsistent.

If you have been part of a project failure, then you will discover that despite the other factors that went wrong, requirements failure was at the root of it.

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

Topics:
project management ,apache ,agile ,death march

Published at DZone with permission of Dalip Mahal, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}