Estimating vs Budgeting – Managing Agile Project Costs in 4 Steps

Almost all software development projects start with a dilemma – how much are they going to cost? This question occupies the minds of CEOs, board members, clients… Other similar questions might be “How long will the project take? How many user stories will we implement in the next sprint? What will we need to get the project done? How much extra budget should we allocate?

If we sum up all these questions, we’ll get “how much effort will this project cost in terms of time and/or money?”

There are 2 common answers to this question: either we don’t know the budget for the upcoming project, or we can make an estimate for it.

Stakeholders don’t like the answer ‘we don’t know’ because they always need an answer to their question and they don’t have the knowledge to answer it themselves. The technical staff doesn’t like the estimations because estimating takes a lot of time and it’s often wrong — stakeholders sometimes turn the estimates into maximums and get nervous if the team exceeds them.

A recent study revealed that one in six IT projects has a budget overrun of 200%.  That’s a very high rate of misestimation. To minimize the risk of having your next project go wrong, you have to abandon estimating and start budgeting.

In this article we give a 4-step tactical method for budgeting; it will take you less time than estimated, and it can be updated during the lifespan of the project.

1. Identify decisions

When you think about budgeting, or estimating the project, it is critical to know what decisions you are trying to make. What will be your steps when you obtain the data? What will you learn from them?

You can make different decisions and some of them are:

• You could start the project, or cancel it;
• You could recruit people, or outsource some functions;
• You could dedicate budget for the next 2 months;
• You could develop some user stories in the next sprint;
• You could start a new company.

You should not proceed further without truly knowing what decision you are trying to make. If you can’t identify which decision you are making, estimation and budgeting will be both a waste of time.

2. Compare precision to decision

Once you’ve made a decision, your next task is to connect the tool with the task. For example, if you have made a detailed decision (i.e. how much will we do in this iteration?), then estimation is a good tool for the job because its precision matches the crude decision you are making.

If you don’t have a clear decision, budgeting is a more suitable tool for more strategic decisions.

3. Define the budget

If you’ve made a strategic decision, you can budget it by a top-down method, and make it as detailed as you need to in order to have enough information to make your decision.

For example, let’s your project be to build an online food delivery app. What will be the high-level functionalities of the site? Maybe something like these:

• Shopping Cart
• Browse dishes
• Search dishes
• Place order
• Manage orders.

Do you know enough to answer “how much will this website cost?” Probably not. You need to get as many details as possible first and then define the project budget.

When you have information to answer “How much is this going to cost?” you can decide if you can afford this project.

4. Ranges and confidence levels

For example, you expect the project to cost between 1M-4M. If your budget is 3M then you should search for more information. You will have to assign certainty levels to each module. To do this, you must:

• Prioritize the modules (e.g. 1, 2, 3, etc.)
• Determine which modules are “Required” vs “nice to have”.

You can create one budget for the complete project and list the modules to include in the minimum viable items as “Required” and everything else as not required. On the other hand, you can create a budget only for ‘minimum items’ and leave the rest of the product intentionally unclear. The usefulness of the top-down method to budgeting is that it is much faster than the estimation, so you can quickly get a budget several times during the project as you know more details.