Partner Event:
Understanding parallels and intersections - 22nd June 2023 - PMI UK (South East) 5-7pm UK time
We all understand portfolio, programme and project as "P3" - an age-old acronym.
Some of us argue that Product Management should also be mentioned in the same breath as P3 - and believe that we should be using the acronym "P4".
What is the similarity between Product and Project (including programme and portfolio too) and why would we want to extend the acronym to P4?
How do they both fit strategy delivery?
Firstly, the similarities:
Point 1 - each of the P4 entities has a justification made from a promise to achieve objectives, generate value in return for spending funds and resources. The strength of the justification enables prioritisation.
Point 2 - they each may deliver cross functionally - using resources from outside their immediate lines of authority.
Point 3 - they each have an accountable person but may not have complete authority or empowerment to achieve their objectives.
Point 4 - each of the P4 entities may be controlled via scope definition, milestones, resource allocation vs actuals, budget vs spend, risk, actions, issues, decisions.
When put like that - what logically are the differences?
Point 5 - It is said of portfolio, programme and project that they are 'finite'. They are meant to end. The end point for each may be less clear, and further away for 'portfolio' and 'programme' than 'project'. Product is also finite, but some would argue for many product types, development and exploitation is more continuous delivery. Perhaps product is closest to programme, and product group closest to portfolio.
Point 6 - 'run' or 'change'? Many suggest that projects and programmes are about making changes to the busienss - but actually project and programmes are also used to deliver customer solutions - which can be considered business as usual. Products / value streams are often thought of as part of 'run' - but products are significant contributors to strategy delivery, and some say they are 'change'. How about we recognise Value Creation, BAU and Change.
Point 7 - 'benefit realisation' or 'value stream'? Finite deliveries - like programmes and projects work to deliver change into the organisation, and change brings resulting benefits - which may be savings, risk reduction of capability to generate value. Continuous delivery - like service functions, engineering functions, manufacturing etc. produce streams of value. It is products (customer facing or internal) that generate value streams with.
But how do both fit business strategy?
The question is - is your strategy emergent ot directed?
q.1. Are your projects 'aligned to strategic objectives' or do you form projects to achieve strategic objectives?
q.2. Are your products developed, then exploited, or developed to be exploited?
q.3 How do you make choices between funding/resourcing a new product and key business transformation?
What is the relationship between project and product?
q.1. Do you develop and sustain your products using projects?
q.2. Is exploitation of your products (generating value) 'Business as Usual' (BAU)?
q.3 Do you get your BAU ready for your products using projects?
Another perspective?
Some of us were brought up with project & programme management. We're 'wired' to 'create then handover' to 'business as usual'. We think product management is about ice cream, soap powder & computer games - nothing to do with business matters.
How about a rethink. Why? Recognise this example?
Finance System project - an old on-premise system goes out of support. A case is made to 'go to the cloud' based on assumed savings from lower running costs vs the cost of IT set up.
A 'Business Owner' is identified as the interface for an 'IT project manager'.
What happens?
- the Business Owner is too busy to properly lead from a customer perspective, & is not experienced in change
- the IT project manager focuses on tech & ignores business change
- the 'customer' is poorly engaged in analysis & needs are missed
- when the IT project manager is 'finished', the Business Owner & team spend hundreds of unrecorded hours to 'get it to work'
- a support contract is turned on with the supplier but IT stays at arm's length
- shortly after 'go live' an automatic update breaks several reports
- there are things the user base can't do - Excel work arounds start to proliferate
- the Business Owner loses interest
- no one seems accountable for estimated benefits, or has foresight for the 'Finance System', or has integrative overall oversight
We could have thought of the Finance System as a CAPABILITY which needs a PRODUCT MANAGER. Take 2:
- a Sponsor is appointed as accountable for overall ongoing capability - including initiation, change & sustainment
- the product manager ensures analysis is done with customer focus
- the product manager holds the IT project manager to account for competent delivery of what the customer wants
- the product manager has provisioned adoption support & avoided the finance team spending hundreds of hours to 'get it to work'
- a support contract is turned on with the supplier, and holds IT to account to manage
- shortly after 'go live' - an anticipated automatic upgrade is smoothly included
- the product manager listens to the user base & add minor additions to a small changes backlog which prevent the need for excel fudges
- the product manager is responsible for measurable value achieved
- the sponsor retrains interest as the sponsor, not as a 'mug'
- the product manager provides foresight & integrative oversight for the 'Finance Capability' throughout future operations
Have some Ice Cream and stop dropping balls - Put some product management into your business life!
Maybe you can decide whether you want to say P4 not P3 from now on?
info@deepteam.co.uk
18 The Chase, Maidenhead, SL6 7QW
© Copyright 2023. All rights reserved