Implement Lean Finance
If you have not read Introduction to Agile Project Accounting, we strongly recommend doing that first before reading this article.
Demand management
The starting point is to make changes to the existing demand management process. The demand management process must be able to account for the methodology that you are planning to use to deliver the initiative (e.g. agile, waterfall or hybrid). Below you can see how this works, at a high level:
It is important that this split is clear, and binary at the funding level. This point in the process is represented by the “Methodology review” step. Note that it is possible to have initiatives that are separated into their “traditional delivery” components and their “agile delivery” components. This adds complexity to the investment tracking, so this should only be done in cases where it is absolutely necessary.
An example of when this type of “hybrid initiative” might make sense is an initiative requiring predominately traditional delivery, but also requiring enabling work from an agile product team. Take GDPR compliance as an example of this. There is a clear, predefined scope that needs to be achieved, much of which will have a sequential (waterfall) delivery approach. An organisation might choose to stand up a specific project team to deliver this. This project team might live outside of the agile teams. However, to deliver the project, changes may be required to the mobile app, and to the website. In this hypothetical example, the mobile app, and the website are both supported by dedicated agile teams.
Therefore the changes that are required to be made to these platforms should be delivered via the agile demand management and planning process.
Portfolio Kanban Overview
💡 Curious about how this works in Kiplot? Explore the Portfolio Kanban feature overview, and learn more about how it works.
Approval, prioritization and representative costs
In the investment governance process illustrated above, we have assumed that the upper flow (building a traditional business case) is self-explanatory and well documented elsewhere. The lower flow (build value case) is where we will dig a little deeper.
In the diagram below, we have broken down the different steps that make up the value case creation process:
Prioritization in Kiplot
Explore the Kiplot prioritization feature to enhance your project management skills.
1. Estimating initiatives
The first step in building the value case is to establish an estimate for the initiative. This should involve senior product owners, team members and architects who are sufficiently familiar with the technology, products and customers affected. The estimation process at this level is not fundamentally different to the way that a traditional initiative is estimated.
The objective is to establish a very rough order of magnitude to act as an indicative guide for the amount of effort the organization might expect to expend, to deliver it. It is likely that this estimate will be reviewed and refined over time. Note for information on capitalization within Lean Accounting, please see appendix.
Portfolio level estimation is challenging due to the insufficient amount of information available at this stage. Applying agile estimation concepts (typically practiced in lower level sprint planning) can be helpful here (e.g. Relative estimating using a known base and a range of numbers in the Fibonacci series).
2. Calculating representative cost
If you want to be able to compare and prioritize the relative value of a series of proposed initiatives, the next step is to convert this effort estimate into a representative cost estimate. The purpose of doing this is to allow a like-for-like comparison at the point of prioritization. Without an indicative understanding of cost, you will be unable to objectively compare the relative business cases of a given initiative.
Note that the initiative may also include a set of costs that are fixed (e.g. recharges, capital costs etc).
It is important that this conversion is passive, automated and separated from the estimation process. It should be a mechanism that allows the estimate to be represented as a cost. Not a process that encourages product owners and/or technical architects to focus on cost at the point of estimation.
3. Value hypothesis
Having estimated the cost side of the equation, our next step is to look at the value side of the equation.
To keep things straightforward to begin with, you may wish to require all estimates to connect their value directly to profitability8. For more mature organizations, you may allow value estimates to be provided against non-revenue benefits (e.g. more users using the Mobile App or Reduction in volume of calls to contact centers). Doing this can help teams to think in terms of direct impact to the customer. However, the organization must retain the ability at some point in the process to connect this “Why” to commercial gain (long term or short term) in terms of revenue gained, cost saved, or risk mitigated.
That is to say that you may allow teams to estimate the future value of an initiative in terms of new users on the mobile application (for example), but we must be able to understand the perceived value of new users on the mobile application, in terms of commercial value to the organization.
The Lean Project Accounting Blueprint allows organisations to run a portfolio of traditional initiatives in conjunction with agile initiatives. However, we know that we do not expect an Agile Initiative to maintain a “financial forecast” or be governed in terms of “budget” in the same way as a waterfall initiative. Instead, we expect the Initiative to be approved, and the work to deliver it to be allocated out to the teams required to deliver it.
Comparing traditional to agile
That presents a problem when we seek to track the inflight progress of an Agile Initiative in financial terms. In order to track holistic progress across the portfolio, we must establish equivalence across the attributes of a traditional initiative, and an agile initiative.
A straightforward example is:
Understand the Value Hypothesis
In agile initiatives, the value hypothesis serves a similar function to the benefits case in traditional projects. It helps to define the expected outcomes or value of an initiative, guiding decision-making and ensuring alignment with strategic goals.
In order to allow portfolio tracking, we must establish these equivalents across the other key financial lenses: Budget, Forecast and Actuals.
Budget: Initiative estimate is to an agile initiative what the budget is to a traditional project.
Forecast: The combined total of the estimates of the epics assigned to an initiative is to an agile initiative what the current financial forecast is for a traditional project.
Actuals: Time recorded against Epics within the Initiative is to an agile initiative what time recorded against the project is for a traditional project.