Rather than run / operations being delivered by a separate siloed organisation, under a Lean Portfolio Management approach, this falls under the purview of the portfolio. This reflects the portfolio’s accountability for (innovation, change and) run.
Each portfolio should therefore maintain a Product Portfolio that contains all the operational systems that the portfolio is directly responsible for operating and maintaining.
Portfolios should have several responsibilities towards these systems beyond the traditional operations responsibilities that reflect their overall responsibility for maximising value and minimising cost – specifically the ongoing investment, constant improvement and “ever-greening” of systems (to maximise value delivery) combined with optimisation and cost reduction (to minimise costs). Significant investments would be expected to appear on the Portfolio Roadmap, however, there should be constant low-level investment underneath this.
It might also be advantageous to track systems against a set of lifecycle stages as a way of agreeing and defining the strategy for each, for example:
Emerge – this is a new system that is currently being built. The primary objective is to get the system into production and delivering value to users.
Grow – this is a system that’s now operational and in active use. The primary objective is now to invest to maximise the value that the system delivers – either through onboarding more users or increasing the functionality it provides.
Sustain – this system is now mature and is not seeing a significant increase in users or functionality. The primary objective is now to invest to reduce costs.
Decommission – this system is no longer required (usually as it’s now been superseded). The primary objective is now to migrate users off and decommission it.
It may also be of value to map operational systems on a graph against two axes – value being delivered and potential risk of disruption (e.g. by new technologies, obsolescence, changing user needs). This can help identify systems where there is an opportunity to invest to increase value or reduce the risks of disruption, or where new systems require replacement and decommissioning.
Ahh ok, this makes sense and probably makes my comment on the Innovation Portfolio section redundant. At the heart of my confusion is the definition of a Portfolio. As I understand it, you have defined it to be the management of a budget for a set of outcomes which have similar properties (i.e. uncertain innovation, de-risked change, and efficiency seeking Product). An alternative, which is closer to SAFe’s definition could be a collection of Product Teams that are greater than the sum of their parts. These Product Teams need to work across innovation, change, and operations. With this definition I would consider it a single Portfolio. Guardrails would be used to determine the balance of investment and there may be different metrics and mechanisms for managing activities under each banner. But it’s still a single Portfolio.
Another thing which probably contributed to my confusion is the definition of the term Product. For me a Product is enduring, for example electronic document management and is fulfilled through Systems (e.g. SharePoint). Some organisations would call SharePoint a Product (I’m sure Microsoft do), whereas in my organisation we know we will need electronic document management for the foreseeable future (enduring Product), but it may not be fulfilled by Microsoft SharePoint.
Whilst you are terminology agnostic (which I get), because ultimately it doesn’t matter what stuff gets called, being clear on what certain terms mean, helps people understand higher order concepts.
And we’ve probably overloaded this term, which isn’t helpful. The premise we’re making is that under Lean Portfolio Management, you’re not managing a single portfolio, but a set of portfolios - a portfolio of change (Epics), a portfolio of innovation (some of which will become Epics), a portfolio of Products (physical things which need support and maintenance - see below), a portfolio of teams (some of which may own one or more products, and which are collectively delivering your innovation and change portfolios), and potentially even a portfolio of sub-portfolios.
Sounds like we need a glossary!
I believe we’ve consistently used the term Product here for a physical thing - a computer system, or a physical widget. The equivalent of a System in your excellent example. Which is obviously different from your definition, and I think probably different from a lot of material on “Product” thinking.
I think our feeling is that this definition better aligns with the English definitions of the words, which makes it easier for people to understand. It also happens to align with the terminology used by a majority of our recent clients! But up for a debate on this, and whatever the answer is, we should be absolutely clear here on the definition we’re using.
What this means is that when we say under LPM you need to manage a portfolio of Products, what we’re saying is that you need to think about whether the physical things through which you currently deliver value to your customers are still the right things, whether some need to be decommissioned or rationalised, whether you’re driving innovation to work out what their replacements might be, where each product is in it’s lifecycle, and what that means for what you invest in.
For reference, we then tend to use the term Service for the delivery of value that’s independent of how it’s delivered (the electronic document management in your example), with one of the primary uses of LPM being to manage the Service (whether this is done at a team level or at a team of teams level).
@JonathanB@Matt The more I think about this, the more I think that the term “Product Portfolio” is just going to confuse.
So I propose that we rename this to “Run Portfolio”. Alternative suggestions welcomed, but I think this complements the Innovation Portfolio and Change Portfolio nicely.
This (I believe) also means that we avoid the terms “Product” and “Service” throughout the guidance, which I think will help in avoiding tapping into people’s preconceptions.