Why User-Centered Design is more efficient than waterfall development methodologies. (Part 1/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 and 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 each hour of a designer and a programmer is U$S50 (fifty american dollars) each one of them, so the total project cost could be estimated as follows:

• Design Tasks: 80 (hours) x 50 (dollars) = U$S 4000 .- (four thousand dollars) 
• Programming Tasks: 160 (hours) x 50 (dollars) = U$S 8000 .- (eight thousand dollars) 
• PROJECT TOTAL: U$S12.000 (twelve thousand dollars) 

Risk Estimation 

The risk can be estimated in many ways. For the purposes of this exercise was calculated from 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 have to draw it in a simple way It will 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 just at that time there will be a deliverable that can be measured and in part because waterfall methodology considers no necessary to measure the performance of a product before the launch of it. In any case, the results may then be estimated by measuring the product performance in the real market once it was 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 performs. 

The Risk in a Waterfall Development Process

When we add the risk component, previous estimation in terms of time and costs changes substantially. Let's see what happens with the two variables in our analysis that compound 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 this issue in their book Rework. They pointed out that the moment in which a development team knows less about how to solve a given problem is just before start to solving it. However in a waterfall process is that precise moment when all requirements are defined and after that they will guide the entire development process leveraging risk of deviations because of defective product requirements definition. 
• Development time: The elapsed time to measure the performance of the application and, therefore, to identify potential problems and made adjustments would be during the fifth week of the project, that is in the end, having already consumed all budgeted hours of 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 be 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 happen 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 describe how the User-Centered Design avoids these deviations, reduces risk, time and development costs.