Software project estimation and planning: Just a combinatorical optimization problem?

As a follow-up to my posting “Software estimation considered harmful?” I want to talk a little bit about seeing a software project as a combinatorical optimization problem.

Do you know the Knapsack-Problem?

Imagine you are living in Papua New Guinea in the rainforest. You want to trade some of your "cargo" (see Jared Diamond, "Guns, Germs and Steel") at the market in the next big city. It is a two-days walk and you have to carry your cargo in a backpack. You separate your cargo in different boxes. Each box has a different weight and a different price per item.

You can't take all your cargo with you, because your backpack would be too heavy. So you have to decide which boxes you want to take with you. Of course you want to take the boxes with the lowest weight (i.e. the lowest costs) and the highest possible price (i.e. the highest value).

Which combination of cargo has the lowest costs and the highest value for you?! (To be able to solve problems like these gave our ancestors an advantage in the process of natural selection and evolution of mankind).

Let us now talk about software projects. For each software project you have to answer the following questions:

  1. When will the project be finished? (Time between project start and end, delivery date)
  2. How much will the project cost? (Costs, mandays and/or money)
  3. Which features will be included? (Expected functionality in this time/cost period)

Question number one is almost always fixed. Normally the customer knows in advance until when the software must be finished to be useful. Normally you can't change the delivery date. This means, that you have time constraints.

Question number two is almost always fixed, too. The customer has maybe planned an IT budget for a new system. Anyway, nobody has infinite time to deliver a product. So you have some kind of budget constraints.

The answer to question number three requires hard work, systematic analysis and intelligent thinking: You have to go and find out for yourself, what your customer really needs. I don't mean you should simply just ask your customers for his software requirements.

You have to dig deep to find out this:

Which combination of features has the lowest cost and the highest value for your customer? (To be able to solve problems like these gives a software company an advantage in the process of natural selection and evolution in the IT-business).

If you have a fixed budget and a fixed delivery date you better find out what has to be delivered to make your customer happy and successful. Your customer expects the best system that can be delivered in time and in budget.

To map this situation to the before mentioned Knapsack-Problem:

The time (working days) between the start and end of the project is your backpack.

The maximum weight you can carry in this backpack is equivalent to the mandays budget for your project. (Number_of_developers * Working_days) <>

And your "cargo" are the features you have to implement. Each feature has a cost (the mandays needed for implementation) and a value attached to it. The value can be difficult to define. Sometimes you measure the value of a feature in relation to its implementation costs. Sometimes you measure a feature on how much profit it will generate our how much cost savings your customer can achive. Giving features a priority to determine the value is often easier: If a feature has a high priority for your customer, this normally means that the value is high and vice versa.

This is the way how we see software projects. It leads us to a simple planning algorithm:

  1. Find and describe all features that the customer needs. (What is a feature?)
  2. Estimate each feature. (Minimum estimation granularity 0.25 mandays, maximum 5.0 mandays)
  3. Attach a priority to each feature. (Must-have, want-to-have, nice-to-have)
  4. Make a releaseplan. (Solve the combinatorical optimization)
  5. Implementation. Evolutionary Delivery every three weeks. Never skip or change a delivery date. Monitor your progress and anticipate risks. Check your planned estimations and actuals every day on feature level. This continuously improves your ability to make better estimations. This way, you’ll find problems long before they turn into risks.

To get into the details, I have to write more Blog postings. Stay tuned.