Budget-based project management is an alternative to classic estimates that has some following in the Agile community. In their book “Fifty Quick Ideas to Improve your User Stories”, Gojko Adzic and David Evans, discusses how using a budget instead of estimates can help to deliver better projects.
Detailed estimation works against the whole idea of flexible scope, but many companies we work with fall into a common trap when they insist on work duration estimates. ‘We are terrified of uncertainty – we would rather be wrong than uncertain,’ said Dan North at Oredev in 2011. A nice precise number feels good, it feels as if someone is in control. The premise of this process is deeply flawed, because all the estimates come with a margin of error that is rarely considered. There are several popular error reduction techniques, such as estimating with intervals of confidence and estimating based on statistical averages, but in many situations this is actually not the right problem to solve.
Long-term estimates give the wrong impression of precision and promote long-term commitment on scope, which eliminates the biggest benefit businesses can get from agile delivery – adaptive planning.
Instead of estimating, try to start with a budget for a bigger piece of work, in terms of both operational costs and time. This budget can then become a design constraint for the delivery team, similar to scalability or performance. Essentially, rather than asking ‘how long will it take?’, ask ‘when do you need this by?’ and ‘how much can you afford to pay for it?’ The delivery team then needs to come up with a solution to fit these constraints. This, of course, requires transparency and trust between the people delivering software and the people paying for it, so it is much easier to do for in-house software than for third-party delivery.
Setting the budget, instead of estimating, eliminates the need to add up smaller estimates, because the final number is already known. This in turn eliminates the need to break down the larger milestone into lots of small stories and analyse them upfront. This prevents wasting time on unnecessary analysis and avoids commitment on scope, and instead establishes a commitment to deliver business value.
Another important benefit is that this approach sets additional design constraints, which enable the delivery team to come up with solutions that fit the business case. A budget makes it clear whether things have to be improvised or should be gold-plated.
Source: “Fifty Quick Ideas to Improve your User Stories”, Gojko Adzic and David Evans, Leanpub
The main question asked at the beginning of a project is often ” How much is it going to cost?” Usually people start estimating the effort and then translate the result in a budget. Some people advocate doing the opposite. If I can spend X dollars for this project to improve my supply chain, what will be the results. Most of the advantages of taking this approach are listed above. For me, the main benefit of taking a budget-first approach is that it should force the people to prioritize all the features and adopt a value-based selection process for each amount of money that you are going to spend. It naturally requires a high level of trust as the stakeholders recognize that they can not define the exact scope of a project before it begins and accept that each participants will do his best to produce the higher value solution under the constraint of the initial budget.
Some of the discussions about value and budgeting are going even further with the “Beyond Budgeting” approach developed at Statoil. This approach tries to go beyond command-and-control toward a management model that is more empowered and adaptive. It is based on a set of 12 principles that redefine the management model.
More references about Agile project management and budgets
Your Agile Project Needs a Budget, Not an Estimate
#NoEstimates – Alternative to Estimate-Driven Software Development