A Theoretical Model for Estimation and Risk Management

How do you control an agile project? I have had many discussions with people lately about how to manage the budget and estimation of an agile project. The following post argues that a project with a business case of $20 million should deliver in steps of no more than $500,000. The argument is sadly only based on “common sense”, and not on actual project experience. (There are too few Agile managers in Oslo)

I think that working to get an estimate in front of a project is counter productive. It requires much speculative work with requirement specification and design which in my experience increase the chance of project failure. But without it, you cannot come up with an estimate at all. So what can you do?

The first thing you need to do is to get a rough business case. Let’s say you estimate that a full delivery of the system is worth $20 million. How did we get to the estimate? Preferably though bottom-up marked analysis (that is: Our organization can sell 200 licenses per month at $10,000 each by spending $2,000 on marketing and sales per copy. This gives a net profit of ($10,000 – $20,000) x 200 x 12 = $19.2 million per year). A back-of-the-envelope business case is much better than nothing.

Given that we always overestimate the business case and underestimate the effort, lets say that in order to get a profit margin, the total project can only cost half of the business case. For our example, our total budget is $10 million. Now, how risk adverse are we? That is, how much of the budget are we willing to gamble at the same time? Let’s say we’re fairly gutsy, so we’re willing to gamble 10 % of the budget without seeing any real return. In our case, that’s $1 million. Seeing as we don’t want to cancel a delivery the minute it busts its budget, we would like to have a delivery milestone that allows us to continue if we feel the end is near. So, let’s cut our delivery budget in two: $500,000.

So here is the answer: For a large project where we are reasonably gutsy, we cannot responsibly budget to spend more than 2.5% of the business case before we have irrefutable proof of progress. Irrefutable proof of progress means that someone outside the project can use part of the software that is delivered. Before this time, your risk exposure is the full amount of money spent on the project so far. Once you have a delivery, you can calculate return-on-investment on that delivery.

If you have experience that validates or refuses this model, I would love to hear about it.

About Johannes Brodwall

Johannes is Principal Software Engineer in SopraSteria. In his spare time he likes to coach teams and developers on better coding, collaboration, planning and product understanding.
This entry was posted in Software Development. Bookmark the permalink.