Waterfall Methodology

We saw how project management is about controlling Cost, time and scope of the deliverable, in the earlier post, in which we saw how a carpenter did not get quite the right results (or got poorer quality) when trying to create a set of table and chair for little children.

With this learning he at least was now confident of his ability to produce this furniture set. So our carpenter (let us call him Mr X) decided to scale up his enterprise. He hired a team of young carpenter fresh from their apprenticeships with other master carpenters.

Analysis

Mr. X did a lot of analysis in the market, going to schools and also the homes where little children would use the table and chair to do their studies as well as have their meals.

Design

Satisfied Mr X, put on paper a series of drawings that showed the dimensions of the planks and the pieces of wood that would form the table top, the seat of the chair and the backrest, as well as the legs of the tables and the chairs

He produced a great set of design blueprints for his team to start looking at for creating the actual furniture units. He left his team to start working and call for him after they had put together the chairs and the tables

Build

His team cut the wood into the planks and pieces as defined by Mr X's design drawings.

Then they set about fixing the pieces together and, lo and behold, they had the furniture ready.

Test

When Mr. X started testing them he found the quality to be even worse than what he had produced all on his own !! The legs of the table and chair had been fixed but very crudely and without any consideration for the straightness and therefore the sturdiness of the pieces.

It would require a lot of effort to pull off the binder, take out the screws & nails, that hinged together the legs with the wood. There would surely be some scars, scratches and holes left here and there, even if the pieces get taken off.

So what happened?

This was the waterfall methodology of project management where each of the analysis, design, build and test happened only after the previous stage finished. The actual output became visible very late into the 3rd stage and therefore the outcome was much less desirable, and diifcult to correct. It would take the majority of the time taken in the build phase to put that correction into place.

Hence came about some re-thinking that led to the emergence of the Agile philosophy in the world of software engineering.