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.

💡 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:

💡 Learn more by exploring the Kiplot prioritization feature overview.

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,

💡 “Value hypothesis is to an agile initiative what the benefits case is to a traditional initiative”

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.

Traditional project governance

Agile initiative governance

Implementing lean financial governance requires a clear understanding and adaptation of both traditional and agile methodologies within your organization. By establishing equivalents between these approaches, such as aligning value hypotheses with benefits cases and converting effort estimates into representative costs, you can ensure effective and consistent portfolio tracking. This balanced approach allows you to manage a diverse set of initiatives while maintaining financial accountability and strategic alignment across the board.