Agile budgeting: How much will it cost?

Your organization will have many questions about your agile project, but the most common one will be “how much will this cost?” This may be a money related,  resource, or a time related question. Either way, budgeting for agile projects require a different approach to traditional project costing and budgeting.

A Harvard Business Review article found that 1 in 6 IT projects run over 200% of budget – a value that is staggering when thinking about multi million Dollar projects. This problem originates from two distinctive areas – under-scoping the true cost of the project, or not managing the project costs as they change.

Delivering Cost Estimations

Your organization will request you provide a cost approximation for your agile project or specific sprint. Part of the challenge around cost estimations is that agile teams aren’t always sure how specific and detailed the estimations should be.

Traditional cost estimations can take a lot of time, and they distract from the development team. There are various approaches that you can take in completing your cost estimations.

Burn Rate Cost Approach

The first approach is to work with your sprint session burn rate and period. Considering the sprint session has a fixed number of time resource units, it can be simple to work out the true cost if the cost of each resource is obtained. Depending on what costs are available to you, the approach can either be:

• Average cost per person per hour. This is the simplest approach as you multiply the hours of each resource utilized during the sprint by the average cost you have been supplied. As an example, if you have one part-time resource and one full-time resource at $100 an hour (assuming 8 hours a day), a two week sprint would be (40 hours x $100) + (80 hours x $100) giving you a $12 000 per 2-week sprint cost.
• Specific cost per person. This approach would require some additional calculations, where you will need to derive an hourly cost per person based on their annual salary cost. Once you’re down to an hourly rate, the calculation is the same as average cost per hour.

While this budgeting is a straightforward approach, its major challenge or downfall, is that it is heavily dependent on calculating the correct burn-down rate or scoring each agile task accurately. It also requires the tasks to have been estimated before you can turn the sprint cost into a project or solution cost. This only solves one part of the problem.

Another issue is that it doesn’t solve for the additional costs outside of the sprint planning. You will need to extend your costing model to provide for testing hours, administration hours, meeting hours and design hours.

Precision-alignment approach

Another approach is more budget orientated and less estimation orientated, and requires a set of business outcomes that are prioritized
.
This practical example is based on an article by Debbie Madden writing for Harvard Business Review. Let’s assume you’re building an online retail shop for clothes. This business requirement can be broken down into a handful of areas that translate to major solution tasks, such as:

• A landing page for marketing
• A search function
• A checkout function
• Product pages
• A customer knowledgebase
• Order management system for customer agents

The next task is to then estimate, based on previous experience or some guidance from developers, what each task would take:

This gives a first-sweep budget range of $210 000 - $360 000. Despite this wide range, the business can already make a decision if the minimum budget exceeds the resources available for this project, or is way under resources available. If the range is too broad for the business, you continue with the next step.

Take all the tasks, and assign a priority to each one, which allows a distinction between ‘must haves’ and ‘optional maybes’:

As the business assigns a ranked priority, it then reveals that some items may be optional, and it also illustrates which items need a more-specific cost estimation. In this hypothetical example, the top 3 priorities  receive more attention resulting  in a budget that is of a tighter range:

* displays the revised time estimation

The revised timings and cost now provide a more acceptable budget range of $230 000 – $330 000. This budgeting process takes substantially less time (completed in a day) and provides business with enough data to not only make a decision to go ahead, but a budget to manage the project.

Blend to your environment

Both approaches take different directions but provide useful budgeting information for your agile project. You can combine elements of both approaches depending on how you have implemented agile principles in your organization. For example, if your agile environment is mature and you need to provide mid project sprint costs, the first approach is ideally suited. If your environment is less mature and the project is at an early stage, the second approach might be more suited as it quickly delivers cost approximations at the right stage of the process.

After the budget, comes discipline

Two things will happen once you enter your project: you will either use fewer resources (time, money, etc.) or you will use more. Either way, daily management of the project and timely updating of your stakeholders is critical.

The situation that needs the most discipline and feedback is when you have detected that the project budget was under provisioned. Many times this is not a simple case of making mistakes during the budgeting process, but rather unexpected obstacles occurring during the project execution such as:

• Delays caused by 3rd parties beyond your control
• Rework that was unexpected
• Resource unavailability, such as illness
• External cost shocks, such as currency fluctuations

The advantage with agile-based methodologies is that there are activities and actions in yourthe methodology that give you early warnings and many touch points to alert your stakeholders of thesere are problems.

The daily progress session (i.e. daily scrum meeting) is the most important activity. It gives you daily feedback on progress and burn-down rate, and highlights any obstacles that can impact project cost. The minute the burn-down rate is less than expected, you have the opportunity to alert your stakeholders and let them have early input if any decisions need to be taken.

Another key area is to adjust the budget and gain sign-off when project scope changes. Agile methodologies allow the adjustment of the scope during the process, but the discipline is to keep adjusting the project budget each time the scope is adjusted. This continual adjustment prevents ‘budget shock’ and ensures your project doesn’t become another statistic of a project that is late and over-budget. In many cases, ‘late and over-budget’ projects actually translate into ‘more functionality’, but only if the stakeholders have not been kept properly informed.

Nothing special to be special

Project budgeting is a business essential, and many project managers will be familiar with some form of budgeting process. Agile budgeting has a slightly different twist on traditional budgeting in that it needs to take into account the changing nature of agile based projects. Adapting to these changes can give you a simplified process to getting business resource assessments for your projects, and maintaining a transparent, accurate project budget while delivering agile solutions in your organization.