Why user-centered design is more efficient than waterfall development methodology (part 1 of 2) Theory

Why user-centered design is more efficient than waterfall development methodology (part 1 of 2)

One of the main challenges user experience professionals face is how to convince our customers to work under a process of user-centered design instead of the traditional waterfall methodology. In this article I propose a simple comparative exercise to analyze the economic efficiency of one process over the other.

Assumptions

Suppose we receive a request to develop a mobile application in five weeks. According to the preliminary analysis we have done, the project will require two weeks of design that will feed four more weeks of development. The second week of design will overlap with the first development week so the project will last five weeks as requested by our imaginary customer.

The cost of a designer and a programmer is U$S50 an hour (fifty American dollars) each, so the total project cost could be estimated as follows:

  • Design Tasks: 80 (hours) x 50 (dollars) = U$S 4,000 (four thousand dollars)
  • Programming Tasks: 160 (hours) x 50 (dollars) = U$S 8,000 (eight thousand dollars)
  • PROJECT TOTAL: U$S12,000 (twelve thousand dollars)

Risk estimation

The risk can be estimated in many ways. For the purpose of this exercise it was calculated using two variables:

  • Risk = accurate requirements definition x development time

Considering that inaccurate requirements and longer development time result in higher risk.

Waterfall development process

A waterfall development process consists of a series of consecutive stages of work (in this case, design and development) until the completion of the project, which ends with the delivery of the application according to the requirements defined at the beginning of the project. If we were to draw it in a simple way, the process would consist of three stages:

This methodology does not contemplate the possibility of measuring the performance of the application until the end of the project.

It is in part because only then will there be a deliverable that can be measured, and in part because waterfall methodology does not consider it necessary to measure the performance of a product before launching it. In any case, the results may then be estimated by measuring the product performance in the real market once it is launched.

With this in mind we can say that a cascade process for this project would require an investment of U$S12,000 dollars and five weeks of development to know how the application works.

The risk in a waterfall development process

When we add the risk component, previous estimations of time and costs change substantially. Let’s see what happens with the two variables in our analysis that measure risk:

  • Requirements specification: the requirements definitions made before starting a project and not revised later as development progresses contain a number of assumptions that make them inaccurate and sometimes directly wrong. In this regard, Jason Fried and David Heinemeier Hansson quite rightly raised the issue in their book Rework. They pointed out that the moment in which a development team knows the least about how to solve a given problem is just before starting to solve it. However, in a waterfall process that precise moment is when all requirements are defined and that will guide the entire development process leveraging risk of deviations because of defective product requirements definition.
  • Development time: The moment to measure the performance of the application and, therefore, to identify potential problems and make adjustments would be during the fifth week of the project, that is, towards the end, having already consumed all budgeted hours for design and development.

Considering these two factors, the risk of deviation in a waterfall development process is high. In fact, a recent study by IAG Consulting says that companies defined as immature in requirements definition fail half of the times to reach goals set for an application, and require 35% more time and budget to achieve them.

Returning to our example, if the application is under the expected performance (which has 50% possibilities of being the case) the project will require 35% more development time and budget to make the necessary adjustments in order to be successful. This would carry the total investment to US$16,200 dollars and nearly seven weeks rather than the five originally estimated.

This whole process could be drawn like this:

Now we see the difference between the initial estimates and what really happens as a result of increased risk during the development process as a consequence of decisions taken based on poorly defined requirements.

In the second part of this article we’ll describe how the User-Centered Design avoids these deviations, reduces risk, time and development costs. Stay tuned!

3 comments

  1. Bobbye

    May i simply say what a relief to discover someone who truly is aware precisely what they are discussing on the net. Far more folks need to go through and see why. We find it difficult to feel you aren’t widely used as you certainly hold the surprise.

  2. Mohammad

    having adopted the user-centered development methodology in my university project, I would say it is far better than waterfall as you have already explained. Thanks Juan as this article was really helpful.

    Mohammad
    De Montfort University

  3. automobile workshop

    You actually make it seem so easy with your presentation but I find this matter to be actually something which I
    think I would never understand. It seems too complex and very broad for me.

    I’m looking forward for your next post, I’ll try to get the hang of it!

Leave a Reply

Your email address will not be published. Required fields are marked *