An organization that adopts LeSS (Large-Scale Scrum) does not need portfolio management in the form we usually know it. Organizational descaling that comes along with LeSS removes the need for project, program and portfolio management.

Let’s explore in detail how that works.

There are two common kinds of Portfolio Management: project and product.

Project portfolio

It is by far the most common form. Project portfolio management is a continuous process of decision making when to start / stop a project, and budget / people to assign.
Project portfolio is based on idea that you have many projects and you need to manage them. Idea is that Project portfolio is useful since projects tend to become expensive and miss deadlines. It is a way to somehow gain control of projects, whether they are waterfall or so called Agile.

The reasoning behind the need is based on centralized decision making, otherwise everyone starts projects without any control. Once people are assigned to a project, they shouldn’t be reassigned to something else. Top-level management knows what is best for company, therefore everyone becomes restrained by projects. The only place where decisions are revised is Project Portfolio workshops.

So, what are the problems in this way of working:

• Everything in project portfolio management is about projects. Many dysfunctions related to projects become even bigger:
• The goal is to finish as many projects as possible. Value creation is only implicitly part of portfolio management process.
• Emphasis on managing projects tends to create two separate realities: One of actual value created and effectiveness, and other is concerned with project budgets, resources, when to start or stop one. Successful project is one that is finished on time and within budget, regardless of value / risk created. In other words, the focus is on “work”, and not the actual “thing” (product) that provides direct value.
• Trying to fix a fundamentally broken system of complex project management by better management from outside of the system, without actually doing something about the system itself.
• Tightening the control drives people to become ever more creative in gaming the system. E.g. fake project reporting that is just good enough to keep management happy, and still keep things going with longer deadlines / more budget.

From big to smaller projects

Big, long and costly projects are a bad idea. Nowadays, everyone seem to agree on this. Therefore, some would say, inspired by agile development, we should have many small projects and manage those in so called “agile portfolio management”.

When looking closely, we see tremendous number of projects and they get finished maybe faster. There are so many of them that people are assigned to multiple projects at the same time. In fact, many of these projects when finished, don’t produce any value yet. In order to produce actual value, concept of “program” is introduced. Each of the projects has a project manager, a program has a program manager, there is PMO office, etc. I think I would rather have long and costly projects :-).

A deeper and less visible problem described in the new LeSS book that will be published soon is the problem of big-batch requirements prioritization. This results in big upfront prioritization and planning related to work for each product. Therefore, although we seem to have removed the problem of big-batch prioritization of a large project, it is largely replaced by complex portfolio management.

Move people faster from project to project

Another form of so called “agile portfolio management” is where teams potentially work every iteration on a different project. This is even worse than small projects approach. Why? Not only there is no focus for people, there is also misunderstanding what iterative and incremental development means. Business agility is NOT the ability to move people or teams around as pleased.

In some cases, “agile portfolio management” is explained as a way to assign people instead of teams to work. It means that individuals work one iteration with one group of people, and next one with a totally new group. This results in very wasteful tracking, reporting and task-switching and complete disregard of human need to belong to a stable and safe group, a team.

The project portfolio management is trying to solve a problem by fiercely treating the symptoms, and sometimes making whole situation only worse. It is focussing on the process for managing work, and not work itself.

How does LeSS deals with Project Portfolio Management?

In LeSS, there is one Product Backlog per product, managed by one Product Owner regardless of size. LeSS organization does not need projects in order to deliver a product in iterative and incremental manner. Teams are stable and receive all work from Product Owner. This work is for the benefit of a single product and all teams have whole product focus.

Work regarded as portfolio management, such as choosing what to do and what not to do, is part of Product Backlog prioritization.

Therefore, if there are no projects, then there is no need for Project Portfolio Management.

But, what about delivery of multiple products in combination as part of a program?

In such case, the product is incorrectly defined. If there is a big dependency between parts we wrongfully call “products”, then those parts together would be a better definition of a product.

What if one product suddenly becomes much less important?

Since a product is broadly defined, we are talking about a big shift in organization’s strategy. Even huge enterprises have limited number of products as perceived by customers. Nevertheless, teams could be moved from one to another product. This is something teams are not likely to experience often.
Organization that encounters such problem has already achieved rather high level of business agility. It is a luxury problem.

Product portfolio

Product-based portfolio is almost a completely different story. Although both are called portfolio management, there is little similarity between the two.
As mentioned before, an organization has at best a handful of products. Managing this portfolio is part of strategic planning. It is less complex and intrusive into product delivery than Project Portfolio management. The main participants are Product Owners together with management concerned with strategy. Each Product Owner will explain own Product Backlog, share the vision and target for next few sprints. The outcome of this workshop is re-alignment with company strategy with possible changes in Product Backlogs.

The focus is also on measuring value created. Every Product Owner uses own or shared business value model for assessment. When strategy changes, so does the value model. Value model is a concrete representation of strategy, used to assess product achievements and product backlog.
E.g. “How many active customers do we have with this product?”. Number of active customers is a value model, and this aspect might become more, less or not relevant in time.

In turn, this information drives decision making for not only product backlog, but possibly also how many teams should be involved in product delivery.

Teams will typically not notice much since they are already accustomed to continuously changing Product Backlog regardless of the reason why it changed.

We are running so many projects and programs, how can we ever switch to this model?

Start refocusing towards product delivery and value creation. Don’t accept to have this only at the end of a project / program. Value those more than encompassing projects. I’ve noticed that once customer keeps getting value, management starts to transform this limited project or program into one which runs longer and has more budget. And this is great! Who cares if a project is not within time and budget anyway? 🙂

The next step is that people speak less and less about project / program stuff. There is less or no need for project and program management anymore. LeSS adoption will naturally drive this process.