Portfolio Scope (LPM)

When managing a portfolio of projects or programmes, the scope of the portfolio (and the primary measure of success) is defined by the strategic portfolio outcomes. Under Lean Portfolio Management, a new definition for the scope of the portfolio is required.

The recommendation is that you think of this scope in terms of a customer segment (which customers are we serving) and a customer need (what needs do they have that we’re addressing). The benefits of this are twofold.

Firstly, this roots the purpose in a why rather than a how (such as a solution or a piece of technology). This should enable the portfolio to experiment and be innovative in finding new, more effective, and more cost-efficient ways of meeting the need; and to decommission, replace or consolidate existing solutions without being tied to them.

Secondly, this creates the ability to align scopes to the parent portfolio and to sub-portfolios, either through a decomposition of the customer segment (into by customer sub-segments), a decomposition of the customer need (into different need specialisms), or a combination of both.

There will be many options for how to do this decomposition – the answer will be different depending on context but should aim to maximise technical efficiencies (not having multiple portfolios responsible for very similar solutions that could be common) and minimise customer overlap (not having multiple portfolios all engaging with the same customer on similar needs).

For example, a portfolio delivering digital comms (a need to communicate digitally) could organise its sub-portfolios around different types of digital comms (chat, video, e-mail). Given these are likely to have a shared technology solution, an alternative could be to organise around customer need if there are groups of customers that have a sufficiently different need to require different technology solutions (e.g. office-based vs mobile). If there is not, it’s likely that the portfolio doesn’t require further decomposition.

Not sure what you’re trying to say here…

Thanks Jon. I’ve tweaked the text, but there’s probably more detail required to expand on this. I’ve added it to the backlog!

1 Like

I agree, your point is unclear.

I understand you are highlighting the choice of organising around customer need vs organising around technology capability. Perhaps you are trying to explain this, but I don’t think it’s as simple as organising around customer need = good, organising around technology capability = bad. Wardley Mapping is my tool of choice for figuring this balance out. If you organising purely around customer need, you end up with lots of duplication in your tech stack. If you organise purely around technology capability, you lose customer focus. But within a value chain, there are a series of customers with teams delivering lower level platforms or components to higher order Products, so there is never a single customer. Using Wardley Mapping you can segment your architecture based on evolution and visibility to an end customer. It allows you to deduplicate where it makes sense, maintain duplication where you need divergence of solutions to test ideas and minimise dependencies.

The other factor to consider when considering scope is cognitive load as per Team Topologies. Given that you probably don’t want (because it wouldn’t be effective) a Portfolio Management Team of 30 people, there is only so much they can consider on a quarterly basis. How much money are they trying to allocate between how many Products? How many people do they need to convene for Portfolio Reviews, etc? If thousands of people need to be within the same Portfolio because of close collaboration and dependencies, I would personally take a step back and consider the overall architecture of your solution, whether that’s a website or a submarine. It would call for more intentional architecture and less emergent architecture to better define the interfaces between the parts and therefore allow the Portfolio to be divided into sub-portfolios.