Delivery Teams (LPM)

Rather than funding specific innovation or change initiatives, portfolios should fund delivery capacity, with the detail of what these deliver being agreed as part of the Quarterly Planning Process.

This means that each Portfolio will need to understand how to allocate and organise its delivery capacity to most effectively deliver its objectives and roadmap. This could mean alignment of delivery organisations to change initiatives (resulting in something that looks like a traditional project), but similarly could involve a single delivery organisation taking responsibility for innovation, change and run of a given set of products where there is a significant technology overlap, or a delivery organisation responsible for keeping the lights on for legacy systems as efficiently as possible.

This allocation and organisation of delivery capacity should be reviewed as part of the Quarterly Portfolio Review, allowing them to evolve as the demand for new capabilities emerges and old existing capabilities reduces. However, given the introduction, closure, ramping up, or ramping down of capacity is likely to require a lead time, portfolios should be maintaining a view of the expected delivery capacity on their Portfolio Roadmap, allowing time to prepare for changes.

For clarity, when we talk about delivery capacity, we’re talking about teams (or teams of teams). These can either be internal delivery teams (potentially embedding external people), or external suppliers providing entire delivery teams (or teams of teams) as a service. When contracting with external suppliers for delivery capacity, agile contracting methods should be used. A key element of this being joint ownership of delivery – the portfolio should retain decisions on prioritisation and objectives (the what), with suppliers being responsible for the how, and with decisions being made collectively. This will require the portfolio to become an intelligent customer, taking responsibility for setting the direction and strategy.

For portfolios that primarily manage a portfolio of sub-portfolios, there is unlikely to be a need for long-lived delivery capability, however, there may be times where there are innovation or change activities that span multiple sub-portfolios. These can be established through dedicated innovation or outcome teams at the portfolio level.

For me ‘Delivery Teams’ is a bit of a dirty word because it reinforces traditional concepts of strategy at the top and ‘doing what your told’ at the bottom. Product Teams should be responsible for what problems get solved, not just how they get solved. Product Management is about Product Discovery as much, if not more, than it is about Product Delivery.

We’ve grappled with this for a while. I agree that the Delivery Team term is a bit loaded - I tend to just call them ‘teams’ and then let people fill in the descriptor of their choice!

I like ‘Product Teams’ as it encompasses (as you say) problem and solution space. But it doesn’t port well to teams that don’t think of themselves as building products but are delivering services instead.

(PS - welcome to Yokoten @JonathanB! Great to have you here!)

Firstly, I’m not wedded to the term “Delivery Team” and entirely open to the fact that there could be a better term. Suggestions and ideas welcome.

The primary reason we chose this term however, was a feeling that not all teams under LPM will necessarily be Product Teams, and we therefore wanted something generic that could apply to several different team types (i.e. they could be delivering a product, or a service, or an outcome). However fully appreciate that the connotation with delivery is that they’re delivering features or outputs to someone else’s plan, so maybe we failed!

What might be valuable is a catalogue of different team types that you might see or need when using LPM. And maybe some worked examples of how you might structure teams. If we can’t come up with a better term, maybe that will make it very explicit as to what these teams might look like.