Getting the Best Bang for Our Buck - Waste or Value?

Too often we measure software development projects by using criteria such as schedule or budget.

We treat these projects as construction projects and forget that a software development project is also a product development project that cannot be measured by using the same criteria.

This blog entry takes a bit different approach, and explains why the traditional approach does not work and describes the problems that the traditional approach cannot solve.

What is Our Goal?

It is a somewhat common belief that a software development project is successful if the software has all required features, and it is is delivered on time and on budget. However, this definition has two problems:

  1. It does not verify that the delivered software solves the right problem.
  2. It does not evaluate if our investment was justified.

As we can see, this definition can only be used to verify that we were able to build the software on time and on budget. It does not help us to find out if it was a smart decision to build it at the first place.

When we want to find out if a software project was successful, we should measure the return of investment. Wikipedia specifies the return of investment as follows:

The return of investment is one way of considering the profits in relation to capital invested.

So, why does this matter? It matters because the odds are that we are in the business of making money. We can make money by following one of these options:

  1. We can use our software to make more money.
  2. We can use our software to save money.

The bottom line is that the only way to know if we built something useful (this helps us to make money or save it) or just burnt cash is to track our return of investment.

Naturally we don't just want to track it. We want to maximize it. This should be the true goal of every commercial software development project.

Do the Math

We can calculate a return of investment by dividing the profits (or money saved) with the money spent, and multiplying the result with 100. Lets clarify this concept by using a simple example:

If we spend 100000 and make 150000, our return of investment is 150%.

As we can see, calculating the return of investment is hardly a rocket science but it is still essential that we do it. Why? Lets move on and find out why the return of investment is an important tool for measuring the success of a software development project.

The Pareto principle states that

Roughly 80% of the effects come from 20% of the causes.

The surprising thing is that this principle applies to software as well. According to studies, only 20 percent of the software’s requested features are used on a regular basis.

Wait, did we just hear that 80 percent of the features add little or no value to the delivered software?

Yes. That is exactly what we heard.

Congratulations! We just spend 80000 for building features that no one is using (we assume that the cost of a single feature is constant).

Lets continue our example and consider the following scenarios:

  • Instead of spending 100000, we use only 20000 to make 150000. This means that our return of investment is 750%. That is a pretty figure!
  • If we take a more conservative approach and assume that we can cut down the development cost to 75000 (and still make 150000), our return of investment would be 200%. That is not as impressive figure than 750% but it does seem a bit more realistic.

The studies prove that we can increase our return of investment without doing any damage to the developed product. We just have to select the features that add the most value to the delivered software, and implement only these features. Unfortunately, selecting the right features is not that simple.

Houston, We Have a Problem

There are several methods that we can use to manage our software development projects but none of them is problem free. The most fundamental problem that we are facing is described at following:

  • Traditionally a requirement specification is written before the software is implemented. The problem with this approach is that we get feedback from the users after the software is implemented. Making changes to an existing application is not cheap. It costs both time and money. Another problem is that the software is build based on our vision of the product. Does our vision really solve the problems our users are facing?
  • Agile software development methods such as Scrum could improve our situation. However, the problem is that often Scrum is used only to break the implementation of the product into small iterations. The importance of sprint review meetings is not often understood. This leads into a situation where continuous improvement is not done and no real feedback is given. We might be thinking that we are giving solid feedback, but the truth is that the feedback is still based on our vision of the product. Are we sure that it is correct?

Both of these approaches have a common problem:

The features of the product are described in a requirement specification (in Scrum we just call it a product backlog) that is based on a holistic vision of our product.

Now, if we are using Scrum we will probably argue that the product backlog is being updated by the product owner based on the feedback he receives. This sounds nice but let me ask a one question:

When was the last time an item was removed from our product backlog?

Exactly. It doesn't happen very often.

How this will help us to find the most valuable features and improve our ROI? The truth is that this does not help us at all. The question that we should be asking is this: should we get rid of the product backlog (and the requirement specification)?

Let's face it: we have no idea whether we are adding waste or value. In my next blog post I will describe how we can select the right features and solve the right problems.

0 comments… add one

Leave a Reply