If we look at traditional portfolio management, like MoP or SfPfM, the focus is on doing the right projects and programmes in the right way and delivering business benefits. These are temporary set-ups to help the organization to change. I would say the traditional change in the perspective of change the business and run the business. See attached figure 1 which shows the position of portfolio management in this traditional world according tot he MoP framework.
We see, more and more, organisations benefit from the fact to keep multi disciplined teams together to deliver more often and faster changes to existing products, systems and processes to accommodate business agility. These teams become permanent and will have their position in the organizational structure. This means these teams become part of the Business as Usual / Run the business environment. In this case, the work to be done, the functional changes, additions, regulatory changes etc. will be brought to these teams. The teams can focus on the development or become DevOps like teams. And this is a complete mind shift if I compare this with the traditional projects and programmes where the people are brought to the work itself.
I expect that the number of projects and programmes will decline because much of needed changes will be handled by these permanent teams. I don’t believe projects and programmes will disappear completely. For transformations, developing new product/market combinations, organizational and/or behaviour changes etc. we still need these temporary projects and programmes but after delivering, and closing these projects/programmes, new permanent teams can be established to maintain and operate the results. In these situations, we can still benefit a lot from frameworks like PRINCE2 Agile, AgilePM, MSP, RPM, and AgilePgM.
We see an enormous increase in the usage of agile delivery frameworks like Scrum by these permanent delivery teams. We also see an explosion of the number of these teams and this asks for a certain level of coordination between these teams. Delivery of specific changes may ask for orchestration between these permanent delivery teams. The usage of Scrum of scrums is not enough and new frameworks to help with this coordination are needed. Frameworks like Nexus and SAFe are developed to support this orchestration.
Like we had in the past, also for these permanent teams we need to prioritize the work to be done. At the lowest level, the development team itself, a product owner can do the prioritization, and if there are a few teams a group of product owners can discuss and agree about the prioritization among the teams. But when we have more and more teams there is definitely a need for portfolio management at the highest level. The SAFe framework contains a portfolio level to divide budget between different value streams based on the alignment with strategic themes. Within the value streams epics are prioritized by using backlog and using simple business cases or mechanisms like Weighted Shortest Job First (preference for those epics with the shorter duration and higher Cost of Delay).
As a result, we will have two portfolio management mechanisms. One for the temporary bigger one-time changes in the Change the business organization and one for the changes managed by the permanent delivery teams in the Run the business organization.
I would suggest to integrate these two mechanisms into one portfolio office. In figure 2 I changed the original set-up based on MoP and suggest to integrate the portfolio part of SAFe with MoP.
It still starts with Strategic / Business Planning. The Portfolio Office needs to be closely aligned with this strategy team. Based on the strategy there will be the understanding of strategic themes (SAFe) or categories (MoP). Here we also need to understand which value streams in the organisation are supporting the strategy. As a result, one or more permanent teams can be dismantled or added. In the traditional set-up portfolio management was only looking at Change the business and prioritized the work to be done by the Programme and Project Management organization. Now we see that also the work to be done by the Development / DevOps teams as part of Run the business needs to be prioritized. During the Understand practice (MoP) we will look at all traditional changes and Epics and categorize them across buckets for the traditional (temporary) world as well as the Backlog for the (permanent) world. Following the SAFe framework these Epics can be assigned to the corresponding Value Streams and within the Value Streams (outside the portfolio Office) to the corresponding Agile Release Trains and from there, via the Program Increment Planning meetings to the delivery teams.
I am looking forward to your ideas regarding this set-up. Many people are looking for Agile Portfolio Management. Maybe this article can trigger a discussion and as a result an outline of Agile Portfolio Management can be co-created.