We are building a car #1 – waterfall methodology

Waterfall is the most-used project management approach in the IT industry. In short, it consists of dividing the project into phases, to which we attach the input data and describe the final intermediate (e.g. analysis, implementation, tests). At the end, of course, we get a finished product.

The above description looks quite good. We have a well-described process, and we know what to expect. On the other hand, you can often hear about missed or unfinished investments. If public orders come to your mind – bravo! This is the best example where instead of talking about development, we talk about wasting money.

The truth is that (with accuracy to a few exceptions) usually such projects seem quite good on paper. I do not recall a situation in which, by reading a detailed description of the subject of the contract, I was critical of the project itself. What happens in the course of this, that out of quite a reasonable documentation we receive something lacking in sense?

As part of stimulating our minds, we will follow this process today. Namely, we will design and build a dream car. It is not without reason that I chose such a “project” – most of us have a similar (or at least any) idea about an ideal model, parameters or appearance. Mine would probably be red, sporty and incredibly fast.

The cast

Actors in our project

In our story (of course simplified in relation to reality) the following people will appear:

  • Product owner – one day you and me, and today a person who will soon spend money to get his or her dream car and can not wait for the result,
  • Project manager – commander in chief on the part of the contractor, implementing the project, responsible for results, the most overworked person in the company; no one knows if he sleeps at all,
  • Senior designer – in short, “the professional”, a person (more often a team) who physically implements your project,
  • Assistant – any project without an assistant? Seriously? ?

Act one – preparation for purchase

Preparation for purchase

A waterfall project and specification are almost inherent elements. I will devote a few separate articles to the specification and its preparation. For now, you need to know that it just has to be. Most often, “presence” is defined quite differently by analysts and clients. The difference in the size of the document necessary to determine the cost estimate often reaches several thousand percent.

For the needs of today’s considerations we can assume that the specification is present, and the main goal of the project can be described by three points:

  • red color,
  • sporty body,
  • 0-100km/h in 3s.

The next natural step is choosing an implementation company. The time devoted to this stage is usually proportional to the size of the investment. You will review the realizations, calculate the price / quality ratio, specify risks, etc. It is also the time to hear out presentations prepared by business developers, and to collect offers. In this process, I usually participate on the other side.

The proper course of the project begins after signing the contract. In the waterfall method, the contract should be prepared in accordance with the principle “what, when, for how much”, that is, it should consist at least of:

  • specification (as acceptance criterion),
  • deadline (often divided into stages),
  • budget.

In such a prepared document (often really thick), only your signature is missing. The act is summed up with a firm handshake – it’s time to get down to work.

Sealing the deal

Second act – project implementation

While the first part of the main narrative ran according to your experiences, the time of implementation is most often referred to as “time for us”.

It is not my intention to describe the production process, especially since each project requires some adaptation of usual practices. However, referring to the contract itself:

  • technical department realizes the scope of the project,
  • project manager looks after the budget,
  • testers care about quality and consistency with specification.

It is worth noting that you do not have too much influence on the production process. Instead, you should expect a product finished on time and for the price listed in the contract. There is a bit of generalization in all of it (for example, a contract can predict stages), but the most important thing is that during the implementation you may have no influence on the scope of the project.

We will speed up our little story to the moment of completion of work and presentation.

Act three – sometimes things look good only on paper

We arrive at the most exciting moment in the project – the transfer of effects. The deadline ends. Everyone puts the finishing touches before the presentation.

Try to empathize with the situation. In a moment you will claim your dream car. This is a very important moment. What may be your surprise when you see the following effect:

Waterfall in practice\

Waterfall in practice 2 Waterfall methodology in practice

If the above graphic raises any doubts – yes, the company just shot your car using a cannon. There is no room for interpretation, there is a bang, a lot of smoke and a car that reaches 100km/h very quickly, but in the most idiotic of ways.

It does not look good. After all, everything is according to the documentation, the key points of the scope have been met. However, you are left with the product that lacks one critical feature that I have not mentioned in this article yet:


It is the value provided that determines the success or failure of any project. Depending on what we do, the value takes on completely different dimensions – monetary, practical, aesthetic, etc.

The above example is a textbook case of negation of the practical value of the project. There is no explanation required – a car fired in such an explosive way will not take you too far.

Act four – retrospection

While writing this article, I was twice accused of proving by the extreme. Indeed, the scenario presented will probably never happen to anyone, but I encounter analogous situations in IT projects every day:

  • the form is ugly,
  • controls are unusable,
  • no one mentioned that an e-mail should be sent when the synchronization was completed.

The examples can be multiplied, especially in innovative projects (and this should be the case in implementations of e-Commerce platforms).

Whose fault is it?

In situations such as this, the time of settlement by fault comes naturally. This is actually the end of chemistry, given that you usually have to do something again, within the same budget. On the example of public procurement, where the price “knocks from below” is to be or not to be for the (often modest) profit of the contractor.

I will answer the question in a completely different way – whose fault it is does not matter. What matters is that you still do not have what you need.

What difference does it make whose fault it was? In the end, the resolution of this dispute may last several times longer than the project itself. Even if the reason from the formal point of view is on your side, you’ve probably lost a lot of time, nerves, and ultimately, you do not have any guarantee that you will get something that will be more than just “correct”.

The liability assessment is not a remedy for unwanted value

In the traditional project management method, you actually agree only to pay for the correct project. Correctness is well defined and practices that are likely to fill all potential gaps are tested.

If I told you that, after a year since the beginning of the project, you will see someone shooting your car using a cannon, but at the same time I would assure you that in the same money the company will fix their mistake, pay the penalty for exceeding the deadline and you will get what you wanted – would you agree?

Of course, you would not – no one needs emotions related to a second or third chance. We want everything to be as we dreamed the first time.

The waterfall method does not guarantee this. Why take risks then?


Projects realized using the waterfall methodology, by nature, orbit around the correctness of the product. Provided value is only a side effect that does not have to occur. Although this method is widely used in the service industry, and can also give good results, it is worth considering before you bet the value of the contract that the project will be successful for you.

In the next article, we will try to approach the issue differently. But about that in a few days.