P3M stands for "programme, portfolio and project management". Product management is a closely related discipline and as most software organisations do product development I’ll include it in the discussion.
P3M Levels:
programme, project, portfolio
and product management
That bit is simple. The tricky bit is agreeing what a project, product, portfolio or programme is. Projects and products are pretty straight forward but definitions vary quite a lot for programme and portfolio. A portfolio for some people is a set of products where for others it is a group of projects. I have, for example, met a portfolio manager who was responsible for some projects and within the same division met a another portfolio manager who was responsible for the product portfolio of the entire division. Programmes are sometimes seen as simply as a complex project or set of projects, or, more interestingly, as an initiative to deliver business benefit.
The summary is that despite the 3 in P3M I actually think there are five Ps which form a sort of hierarchy: product portfolio, programme, project portfolio, product, and project. The levels in the hierarchy are optional and many organisations will only have a couple. For example a product development company might just have the product portfolio level and products. The accompanying diagram shows the five levels. The four grey-blue levels are my primary interest and where P3M focuses. Products are shown in yellow to highlight the different nature of this level and associated practices.
The rest of this blog explain my take on each level and interrelationships between the levels. I’ll start simple with project and product, move through programme, and end up at portfolio (both product portfolio and project portfolio).
What is a Project?
Most people have a common understanding of a project. The PMBOK definition nicely encapsulates this:
A project consists of a temporary endeavour undertaken to create a unique product, service or result
Successful projects deliver on time, to budget and to specification (i.e. scope and including associated quality implications). The Agile community argues, rightly, that you normally can’t get all of these at the same time. Or put another way you can fix two of the three but one of them must flex. Agile teams normally flex scope.
(I find the PRINCE2 definition of a project a little vague hence less useful. In PRINCE2 speak a project is “a management environment that is created for the purpose of delivering one or more business products according to a specified Business Case”.)
What is a Product?
in the business sense a product is something that attempts to satisfy a market’s want or need. Product managers are responsible for product management of these products. In the web world products are often divided into audience facing sites and underlying platforms.
In contrast some project management methods, e.g. PRINCE2, use the term “product” for a deliverable or set of deliverables produced within the project. Nominally these deliverables contribute to the business solution but any interim deliverables are discarded and do not form part of the final solution. A product breakdown structure is central to planning within PRINCE2. “Products”, in this sense, have nothing to do with product management.
What is a Programme (or Program)?
Views on “what is a programme?” vary quite a lot. Typical definitions are:
- A complex project
- A set of related projects (or portfolio)
- Either of above with the aim of changing the organisation
Wikipedia: Program Management hedge their bets by saying
Program management or programme management is the process of managing several related projects, often with the intention of improving an organization’s performance.
Personally I see little reason to give a different name to a complex project and I favour portfolio for a set of projects so I opt for the programme definition involving organisational change.
In her blog entry Johanna Rothman: Defining Program Management and How Agile Helps Johanna defines a programme as a group of projects with a combined value:
A program is a collection of projects, where the value is in the overall deliverable. Yes, each project may have a deliverable that’s valuable, but the value to the organization is when all the sub-projects get together and deliver their product.
If “value to the organization” means business benefit then we’re on the right track. However I’m less keen on this if the suggestion is that the value of the programme is merely the sum of the value of the sub-projects.
In the Managing Successful Programmes (MSP) framework of the British Office of Government Commerce (OGC) a programme is intended to deliver capability (via projects) which, when utilised, results in business benefit. I like this because it helps clarify what a programme manager is meant to do as opposed to what a project manager does. I admit I tend to paraphrase the MSP/OGC definition into the slightly inaccurate phrase “programmes deliver business benefits”.
As an example of the wider, MSP/OGC style, sense of a programme I’m currently managing a piece of work that includes several sub-projects:
- Design, buy and install some infrastructure
- Design and build a Collaboration System
- Updates to an existing Content Management System
- Updates to existing Media Asset Management System
- Update training courses to cover new systems
These sub-projects are undertaken by different teams under different project managers and in different locations. So the programme could certainly be described as a “complex project” and a “set of related projects”.
But the whole, in this case, is not just the sum of the parts. Even if all of the teams deliver on time, within budget and to the spec I could still fail at the programme level. My objectives, as programme manager, are around:
Microsoft PM
Microsoft have a role called a “program manager” reminiscent of an old style web producer. It combines product management, project management, and team leader responsibilities in a small team working on a feature set within a larger product/project. As this rather radical redefinition of a programme manager is a MS specific thing I won’t consider it further.
- Capability building, i.e. building the system etc
- Capability utilisation, i.e. getting users to adopt the new system, hence changing the way they work as a result, but also ensuring they feel good about that change so they keep using the system
These are outcomes of the work but they are non-cashable of themselves. ultimately my programme has to pay for itself through cash benefits. The nature of the business means we can’t increase revenue so the programme has to result is a lower cost base, i.e. lower headcount.
What is a Portfolio?
A portfolio is essentially a collection of something and in the P3M world I distinguish between a project portfolio and a product portfolio. These portfolios are managed in quite different ways and have a quite different relationship to programme.
Project Portfolio
One of the definitions of a programme is as a set of projects. I prefer to think of a programme as including a portfolio of related projects. I make this distinction between programme and portfolio because it is quite common to have a portfolio of projects without an overarching programme. Several companies and departments I have worked with manage their projects as a portfolio, including making priority calls on budgets and resources and providing some coordination between the projects. All this without there being any coherent higher level goal. However these are the same portfolio management activities required within a programme.
Project Portfolio Management tends to focus selection of projects the selection and execution of project. Wikipedia: Project Portfolio Management says:
Project Portfolio Management (PPM) is a term used by project managers and project management (PM) organizations to describe methods for analyzing and collectively managing a group of current or proposed projects based on numerous key characteristics. The fundamental objective of PPM is to determine the optimal mix and sequencing of proposed projects to best achieve the organization’s overall goals – typically expressed in terms of hard economic measures, business strategy goals, or technical strategy goals – while honoring constraints imposed by management or external real-world factors. Typical attributes of projects being analyzed in a PPM process include each project’s total expected cost, consumption of scarce resources (human or otherwise) expected timeline and schedule of investment, expected nature, magnitude and timing of benefits to be realized, and relationship or inter-dependencies with other projects in the portfolio.
Some product development companies try to manage their work as a project portfolio. This might be sensible if funding is allocated for discrete bursts of energy and teams are mobilised to do the work then disbanded. There is, however, a cost of this because projects, being temporary affairs, add start up and closure activities that are unnecessary in on-going product development. A second caveat is that project portfolio management lacks the high level strategic thinking necessary to make best use of resources to achieve strategic outcomes – something that is covered by product portfolio management.
The person running a project portfolio within a department might be called a “portfolio manager” or “programme manager” (although I’d argue the latter isn’t appropriate given there is no programme as such). Within a programme the “programme manager” might run the underlying project portfolio directly or they might hire a “delivery manager” to take on this role.
Product Portfolio
A product development company should manage their portfolio, in this case a portfolio of products. Most software development companies fall into this category. Product portfolio management involves the same sort of activities as project portfolio management including making priority calls on budgets and resources and providing some coordination between the teams. The goal is to implement business strategy by investing more or less in specific products.
In a larger company the person managing a product portfolio, including line management of staff, is likely to be called something like “product group manager” or “product unit manager”. A group of these might report into a higher level manager who might run the entire operation as a mega-product portfolio. For example, the new media division of a large media company was run as a product portfolio with “product unit managers” running sub-portfolios. In this instance the divisional head delegated coordination of the mega-portfolio to a “Portfolio Manager”.
A company using product portfolio management might run a programme to start a new product.
Organisational Examples
P3M Levels:
programme, project, portfolio
and product management
A particular organisation doesn’t need to have all of the levels, in fact they are unlikely to have all levels. For example, a company running pure Scrum will effectively have a product portfolio and products. They won’t have programmes, project portfolios or projects because these things do not exist in Scrum.
It is quite common for a product development company to use a programme to start a new product. The programme would create the new product and also create the organisational unit with on-going operational responsibility for the product. The programme is likely to have sub-projects managed as a project portfolio, for example, design and build the product, recruit staff, train staff, market new product, extend related products, etc. At the end of the programme the new product would be managed in the product portfolio. Projects might not to exist outside a programme.
A software house, i.e. a company that makes their living by creating bespoke software for external customers, is certain to run the work as a project portfolio with at least one project per client, balancing resources between the competing clients based on their own priorities. A project for a client could well be part of a programme although typically such a programme would be internal to the client and led by somebody from the client organisation. An example of this would be where the vendor is responsible for building a new software tool but the client would handle associated recruitment, training, sales and marketing.
References
Johanna Rothman: Defining Program Management and How Agile Helps
OGC. (2005). Managing Successful Projects with Prince2. TSO.
OGC. (2007). Managing Successful Programmes (MSP). TSO.
Project Management Institute. (2004). A Guide to the Project Management Body of Knowledge (PMBOK Guide) [3rd Edition]. Author.