Adopt Lean Budgeting
Introduction
As adoption of agile extends beyond Technology, it has begun to clash with traditional resource planning processes and governance. Organizations know that they must continuously fund an agile team such that it is “long lived” or “durable”. They know they must disconnect funding from the work, and connect it to the team instead. In legacy terms, we could say that the funding for “change” must look and feel like “run”.
What is agile project accounting?
Agile project accounting describes the framework organizations use to budget, forecast cost, track actuals and accrual while driving value creation and benefit realization.
Start with work hierarchy
Before getting into the mechanics of investment governance, organizations must first have established a portfolio work hierarchy. This is a critical first step. The trick is to ensure that the work hierarchy you establish strikes the balance between being sufficiently high level (and abstracted from delivery) to allow a significant future planning horizon, while also ensuring that it is not so far away from delivery that it becomes meaningless.
We have found that this work hierarchy (illustrated below) is effective in achieving this.
The diagram above illustrates how this should be done. The specific nomenclature that you choose to use is not important3. In the appendix of this document, we have included a view of this work hierarchy, following the popular LPM framework.
In this work hierarchy, the business case exists at the Initiative level. As we shall see however, this is not necessarily where the funding code is assigned.
Traditional funding model
In the traditional model, a business case is raised to deliver a project. When that business case is approved, funding is assigned to that project, typically using a project code. That project code will have a given budget associated with it, as well as forecast benefits. We can visualize this diagrammatically along these lines:
The funding code lasts for the duration of the project.
So far, so easy, right? Read on…
The Lean model
The world gets a little bit more complicated when we look at how we fund agile initiatives. We already know that we do not want to fund the initiative, we want to fund the team.
Let us take a real-life example. Our initiative might be “Launch in the USA”. To achieve this initiative, at the very least we are going to need support from Marketing teams, Legal teams and Product teams.
We can visualize this diagrammatically like this:
Notice that the funding codes are applied to the Agile Team, not to the Initiative. But that does not mean that we should not be putting them through investment governance. It simply means that the route they must take is a little different.
The Lean Project Accounting Blueprint enables organizations to combine these two funding models. Using the , you end up with something that can be visualized like this:
Can I retire waterfall entirely?
Most organizations start from the position that they would like to adopt agile delivery wholesale. There is certainly nothing in principle against this. Organizations must ensure however that they do not lose sight of what they are trying to achieve, more broadly. That is to say – move faster, deliver more value, empower your teams and get closer to the customer. Some initiatives/projects simply fit better within a waterfall mold. For example, agile is typically more effective in a complex domain where learning is required. Waterfall can be more effective in a clear domain where the same work has been done before and hence can be replicated, repeated and scaled more effectively by a waterfall process.
💡 When thinking about what is right for your organization, be sure to pursue pragmatism over principle; trying to fit a round peg (naturally waterfall initiative) into a square hole (enforced agile framework) can act as an impediment to productivity, rather than a catalyst
One example might include an initiative to outsource a business process (AKA BPO). There are some very clear steps that such an initiative must undertake to ensure successful delivery. It probably starts with vendor selection and an RFP. Then move to agreeing commercials. This part of the initiative has a clear start and end, with success criteria and scope that can be deeply understood at the beginning of delivery. Setting clear milestones in this context is likely to be conducive to success.
Our experience is that the best way to approach your agile journey is to start with a team, or a few teams as a pilot. After proving this out, ironing out the creases, and iterating the model to best fit your organisation, roll it out further, to include additional teams. This can be helpfully thought of as using a textbook-Agile approach to the agile transformation itself. That is to say, start small, identify a pilot/PoC/MVP, iterate, refine and double down when you have found the winning formula.
There are also hybrid examples. For example, a telecoms provider who’s software engineering follows agile principles, but who’s network construction (i.e. towers, cables) is waterfall.
Implementing governance
So you have got this far. You might be thinking – “this much I know. But how do I put this into practice in my organization?”.
Read on to explore the dedicated article on implementing investment governance.