Lean-agile Portfolio Management
Comparing prioritization in waterfall, agile and lean-agile

Check out our Lean-agile portfolio training offer ...

Portfolio management

Portfolio management serves an important function in an organization: help decide what initiatives will get funded to help the organization achieve its strategic objectives. The basic point of portfolio management is making investment decisions. Portfolio management therefore needs to compare the benefit of an initiative with the cost to realize it and since there are in general more initiatives than funds, prioritize them and ultimately decide which ones will run.

We do this in fundamentally different ways in waterfall, agile and lean-agile, as each of these approaches value creation and ultimately portfolio management in a different way.

The waterfall approach: fixed scope – fixed price – fixed business case

Portfolio management has for years been an extension of traditional management of companies, with a yearly budget cycle, company objectives, and the recognition of projects as the means to organize change.

For projects to fit in this general approach, they need to meet four requirements:

·                    The goal, scope and business case are clearly defined up front

·                    The cost is determined by the need to use resources to realize the scope

·                    The authority and mandate to spend the budget and use the resources is delegated to a project manager

·                    The use of the resources and the delivery is planned in a deterministic way

Portfolio management (deciding which initiatives will be approved) then seamlessly works with the PMO (Project Management Office), since the approved initiative (plan) is expected to be executed according to plan. In fact, conformance of execution to plan is the single most important criterion by which to evaluate the project manager.

Not: the realization of the business case. It is remarkable how much effort we put in tracking the cost side of a project (timesheets, earned value, budget monitoring), and how little effort we put in monitoring the results, let alone in making sure that the project delivers the value as intended. Most companies do not calculate afterwards if the project achieves its intended results.

Projects have become cost centers, not value creators

If we just consider projects from the side of value creation, some aspects become strange. At the start, the idea of a precise scope generating a precise business benefit is acceptable. But it clearly cannot be fully binary. A somewhat smaller scope would generate some business value as well, a somewhat larger scope would presumably generate some more value than the scope finally decided on. In some cases a full scope can be determined and make sense (think: completely phase out all iSeries legacy systems, or installing a new IT-environment in all bank branches), but in other cases the border of the scope remains vague, by definition. That should be fine, but we cannot handle it: we need the exact scope in to determine a fixed budget and set a goal for the project manager. The way we manage projects therefore makes us believe a project needs a fixed scope.

A second thing we ignore is how the business case is influenced by time. Although we plan our projects with great precision and want to manage projects according to On Time, On Budget and On Scope, the timing element we are talking about only concerns the execution of the project and the use of resources, far less often the influence of timing on business value.

A project charter then becomes a kind of contract, sometimes literally, to realize a fixed scope for a fixed price with a fixed timing. And so it seems that if we have spent half the budget and have achieved half the scope, we have also created half of the business value, so we are well on target to achieve 100 % of each.

This assumption hides two elements: not all parts of the projects contribute equally to the creation of value, and we often do not consider how timing influences business value.

Agile and scope management

One of the big changes that Agile introduces is that we do not fix scope up front. Instead, we continuously discover what items should belong to the scope as users see the product we deliver and can imagine and explain what new features would bring value. The product owner identifies the requirements and prioritizes them by the business value they deliver.

Although this is conceptually a vast improvement over waterfall practices, real life is more complicated. Prince2 for Agile still works with a fixed budget and timing, and basically only allows relatively minor adjustments to the scope. Scrum could do better, but in reality bumps into the glass ceiling of the budgeting process. The philosophy is that a project/product development initiative gets funded as long as it delivers business value (more business value than the teams cost) and so a project would peter out when no more valuable work can be detected.

Agile therefore breaks one major assumption: a single business value will be created by a single scope. Instead, we discover the scope and go on working until we can no longer generate value, that is the cost of creating the value is higher than the value created.

But agile also has a significant weakness. Scrum has some suggestions on how product development should be funded, all very pertinent, but they have not made it to the core of the methodology. LeSS, really scaling scrum to a corporate level, has no chapter on how product development is to be funded and has no portfolio layer. Product management takes on the role of prioritization within product development and may have the right insights in value creation, but there is no mechanism proposed for prioritization across initiatives.

Agile portfolio management is possible when we compare how much business value is generated per unit cost in each of the different projects or products being developed, so that we can stop work in products where the ratio of value creation over cost is lower than average, but this does not seem to be common practice.

Lean-agile prioritization

Lean-agile uses a different prioritization mechanism, based on the Cost of Delay (see my previous post). Lean-agile has access to all the advantages of agile scope management, as the core process in product development is agile and we still discover scope in an agile way.

Lean-agile (SAFe) prioritizes items in the different backlogs by WSJF (Cost of Delay divided by a measure for duration/workload) instead of just Business Value over Cost/Workload. WSJF is a better measure for the creation of business value as it considers the effect of time on the value and the indirect effect of the value creating (creating or enhancing other opportunities or diminishing the overall risk of failure).

Lean-agile takes this time dimension into account because the lean aspect of the approach focuses on the creation of flow, that is on minimizing the delays and the queues. This in turn generates a sharper focus on the effect of timing in business value.

The effect is interesting. The better model for business value creation serves as the basis for prioritization. Since we continuously manage for time optimization in lean-agile, this prioritization mechanism will enable better value creation for the same effort. It will also outperform agile prioritization because we use a more pertinent model for the creation of business value.

Lean-agile portfolio management

The mechanism does not just do this for the features in a single product but across products as well. This enables lean-agile portfolio management, the prioritization of work across initiatives.The strength of e.g. SAFe is that Lean Portfolio Management is effectively elaborated.

Lean-agile portfolio management can do more. SAFe couples it to a mechanism for funding Valuestreams, using an approach inspired by Beyond Budgetting. The main benefit of this approach is that funding is decoupled from projects, so we no longer need the notion of project budgets and in fact do not even need the concept of projects any more.

There are major advantages to this. For one, we do not need the role of project manager anymore. Since e.g. Scrum has no place for a project manager, this makes introducing agile easier. There is also no longer the need for a project budget approval cycle, which is hard to decouple from fixing scope up front. It replaces budget control with decentralized prioritization by product management, again better in line with agile thinking.

In the general SAFe picture, the Portfolio layer is on top, giving an impression of hierarchy. In fact, the portfolio function is ‘upstream’, translating ideas and business strategy in approved initiatives (epics). You may want to check our slides on this. The goal is to significantly shorten the time to approve budgets/initiatives or changes in budgets, so that less time is lost between having a valuable idea and launching the initiative. Lean-portfolio management therefore helps in the general lean idea of creating value faster: we lose far less time in setting up and monitoring projects.

The second major advantage of lean-agile portfolio management is that it helps in translating strategic business priorities into initiatives in a disciplined way and fund them appropriately. The discipline of LPM helps in better alignment of the portfolio to business.

Finally, all of this leads to a very important point. This approach gives levers to business to prioritize initiatives by themselves. This allows business to take more responsibility for value creation and helps in the dialogue between those who want the functionality and those who will deliver it. The SAFe City simulation workshop demonstrates this. And our customers are adopting this interactive approach of card-based prioritization to make for faster, more interactive and more fun portfolio prioritization.


Lean-agile prioritization is based on a better model of value creation than is used in either waterfall or agile. Waterfall really requires fixed scope to approve a fixed budget in a time-consuming budget approval process. Agile does way better by leaving scope open and allowing adaptation to changing requirements, but its approach to value creation does not explicitly pay enough attention to the time-dependency of value creation. The more disciplined and elaborated Cost of Delay and Weighted Shortest Job First approach of lean-agile and SAFe can economically outperform agile prioritization.

This is not the main point though. The better approach based on Cost of Delay allows to set up a Lean-agile Portfolio Management. Its main function is to provide a valid alternative to existing portfolio management approaches, which are completely based on old-style Command and Control through traditional budget approval systems. This LPM approach helps decentralizing decision making and agility itself by removing the need of project budget monitoring.

In short, introducing LPM will be a major enabler of your (lean)-agile transformation.

Sign in to leave a comment


Prioritization in Lean-Agile
Focus on Cost of Delay rather than Business Value