Product Portfolio (LPM)

Lean Portfolio Management
1

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.

2

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.

3

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.