How do you ensure that agile projects don't go over budget?
In one of my recent workshops, a participant asked me a question: how do you ensure that agile projects don't go over budget? It's a pertinent question, as some have noticed that agile projects can sometimes cost more or have a less predictable budget than traditional projects. Yet, according to the inverted triangle theory, this shouldn't be the case.
For those unfamiliar with this theory, allow me to explain. In a traditional project, we start by defining the scope of the project. Once this scope is clear, a budget and schedule for delivering the solution can be established. Thereafter, project management focuses on effective delivery, closely monitoring activities.
In an agile context, where the final solution is not yet defined, financial risk is managed by setting a schedule and a budget. Normally, in this context, the most flexible management lever is scope: the aim is to deliver the greatest possible value with the resources available.
Below is an example of an inverted triangle, taken from the book Choose Agility by Mathieu Boisvert and Sylvie Trudel.
In theory, an agile project should be stricter than a traditional project when it comes to staying on budget and on schedule: once resources are exhausted, the project should stop. So why do some projects go over budget? Here are three anti-patterns of project management that explain these overruns.
Not planning an MVP
The MVP, or minimum viable product, represents the minimum scope necessary for the product to be usable by the target clientele. In an agile project, it's crucial to aim beyond the MVP, as this version often doesn't provide enough added value. However, the MVP serves as an important checkpoint: once reached, it can be decided whether the project should continue or stop. Reaching the MVP early limits the risk of going over budget and over schedule, unlike a project that neglects this stage and risks having to continue indefinitely to obtain a usable product.
Failure to track budget and schedule indicators during reporting process
Few agile methodologies explain in detail how to report on a project's progress. Yet it is essential to track scope delivered and value achieved. This can be done using progress charts such as the burndown chart or the Sunset graph. These tools make it possible to visualize the progress made to date, and to project what remains to be delivered by the end of the schedule. This projection enables us to estimate whether the MVP will be achieved, and how much additional value can be delivered with the resources available.
But these charts are insufficient, because they measure scope progress on the schedule, but not the budget. It's therefore good practice to add a budget tracker, which measures actual spending from one sprint to the next.
Do not project consumption until the end of the project
An often overlooked practice is the projection of budget consumption over the remaining timeframe. This projection is relatively simple to carry out, since in an agile project, human resources generally represent the main expense and are generally stable over time. If projected expenditure exceeds the initial budget, it is crucial to review the product roadmap to separate essential items from optional ones.
But sometimes overtaking is unavoidable
If, despite improving your practices, the budget continues to exceed forecasts, it may be necessary to revise the budget itself, or terminate the project if projections point to imminent failure. However, these measures represent the last resort and should not be the norm in agile project management. The good news, however, is that with better monitoring practices, you'll be able to make a decision sooner rather than later.
Below you'll find a sample of the dials, from our dashboard template for monitoring actual and projected expenditure indicators as part of an agile project.
Still curious?
For those who wish to continue and learn more, I invite them to follow the series entitled Series - Creating an agile dashboard with Power BI by Simon-Pierre Morin and Mathieu Boisvert.
