« Memorizing the PM Network Diagram - Your Key to Passing PMP
Single or Multiple Project Portfolios? »

Waterfall vs. Cyclical PM: Identifying Requirements Beforehand

April 22, 2009 | Author: PM Hut | Filed under: Requirements Management

Waterfall vs. Cyclical PM: Identifying Requirements Beforehand (#20 in the Hut Project Management Handbook)
By Wouter Baars

It is nearly impossible to identify all of the requirements (functionalities) beforehand.

The waterfall method prescribes the formulation of requirements as the project result of the definition phase. Ideally, there should be little further deviation from these requirements throughout the rest of the project. The development of software according to the waterfall method requires the investment of considerable time in the beginning of the project in analysing the necessary functionalities (requirements). This leads to a functional design. Using the functional design as a guide, the software architect makes a technical design in the design phase. The technical design includes a description of how the desired functionalities should be implemented.

Although this may appear quite straightforward, consider the following situation. There is a project to produce a new automobile. As an active automobile driver, you are asked to formulate the requirements for an automobile. You consult with other drivers and create an extensive list:

  • The automobile must accommodate four people.
  • The automobile must have a steering wheel in the front on the driver’s left-hand side, a brake pedal, a gas pedal and a hand brake.
  • The automobile must have four wheels.
  • The automobile must have white headlamps and red tail lamps.
  • et cetera (the actual list would obviously be enormous)

Using your list as a guide, the designers develop a new design, which is subsequently built several months later. One day, as you are walking down the street, you see an automobile stopping. You realise that you neglected to include brake lamps in your list! You immediately telephone the engineer of the automobile manufacturer, who nearly explodes in reaction to your call. You maintain that it is only a small change. For the automobile manufacturers, however, it is a disaster.

The automobiles that have already been made must be completely disassembled, cables must be stretched from the brake pedals to the rear, the rear of the automobile must be completely re-designed in order to accommodate the brake lamps, the boot hatches that had already been produced would have to be discarded and the list goes on.

While the example above is somewhat absurd, it reflects an almost daily reality in software development. Programmers erroneously assume that the clients, customers or users of the software that is to be developed know precisely what they want Clients erroneously assume that the software builders can make (and adapt) everything in the shortest possible time. This problem is the greatest source of conflict between customers and software builders.

The following anecdote illustrates the fact that there are many conflicts between customers and software suppliers. A beginning entrepreneur wanted to obtain legal insurance for his business. He asked about the possibilities. When the broker asked him to identify the sector in which his business was active, the entrepreneur replied, ‘IT’. ‘Too bad’, replied the broker, ‘there are so many lawsuits between IT suppliers and customers that there are no insurance companies that will write legal-insurance policies for IT companies’.

Next in the Hut Project Management Handbook:

Waterfall vs. Cyclical PM: Estimating Time to Implement a Functionality Is Difficult

Previously in the Hut Project Management Handbook:

Waterfall vs. Cyclical PM: Software development is a Creative Process

Wouter Baars has a Master of Science degree in Industrial Engineering and Management Science. He has been a project manager for several years for The European commission, Waag Society, KPN (Dutch telecom provider) and many smaller organizations. He is specialized in creative projects such as serious game development, e-learning and software development. Currently he is teaching project management and coaching organizations that are working on their project management. More info on his work: www.projectmanagement-training.net.

Originally published by DANS – Data Archiving and Networked Services - The Hague

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Wednesday, April 22nd, 2009 and is filed under Requirements Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

4 people have left comments

Yet another reason why Agile rocks for software projects. I just can’t the point why a lot of software companies out there have not adopted Agile yet.

Anyone care to explain?

Anne LeBlanc wrote on April 22, 2009 - 11:21 am | Visit Link

Anne,

I don’t think the author said that Agile is better than waterfall, he just said that requirements in software projects are hard to gather in the beginning.

I have to state the following facts:

- Waterfall is a time tested methodology that was used in software projects since the inception of programming (it worked then, and it’s still working now).
- Agile is not an independent methodology, it’s just waterfall with more feedback.
- On an unrelated note: Agilists are becoming more and more a cult (which is scary).

Sorry for the harsh answer, but I’ve read so much stuff praising Agile as if it’s the best thing since sliced bread, while it’s really nothing more than Waterfall with a lot of feedback (which is not always a great thing).

Rajesh wrote on April 22, 2009 - 1:25 pm | Visit Link

@Anne,
Yeah Agile rocks, and I do love it.
But consider the critical applications as well, they do need to be done in water-fall approach.

One thing from Agile methodologies which I have not figured it out is the approach to contract and specially financial matters. If you want to implement a project in agile approach that’s great but how one estimate the project cost at the beginning ?
can anyone help ?

MajiD wrote on April 22, 2009 - 2:18 pm | Visit Link

@MajiD:

have a look at my handbook at the website (www.projectmanagment-training.net). There are some rules and statements about financial aspects and contracts in regards to agile projectmanagment. The main issue is that with waterfall, the goal is set (in a contract). In an agile approach not the ultimate goal is set, but the time to be spend on the project. This off course is scary for the buying party, but if you get them to understand that the waterfall agreement is very insecure because it is imposible to set the ultimate goal/achievement at the very early start of a project, they tend to trust the building party (sometimes). Trust and cooperation are the keywords here, understanding that (software) projects are uncertain, and that both the client and the creating party need to share (the risks of) this uncertainty.

Wouter Baars wrote on April 23, 2009 - 3:53 am | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories