Taking the P!
What’s the difference between Products, Portfolios, Programmes and Projects?
Recently, whilst overseeing a Portfolio of Projects for a client, the IT Director requested that I come and provide assistance to help clarify the scope and define an appropriate governance structure for a new piece of work.
The issue they had encountered, as a partial Sponsor, was that though the initiative had been approved funding, no one directly involved in the initiative could clearly articulate the scope and in essence ‘what’ it was that they were trying to achieve; the approval had been given on the basis that it had a vocal senior Sponsor. The IT organisation had provided approval due to it not wanting to be perceived as a blocker, and hence felt that by applying specialised resources to review the request and determine the scope of said initiative, could then advise an appropriate course of action.
I’ve witnessed similar situations in the past, and have heard of similar scenarios from colleagues in different organisations in different sectors. Hence, I’m reasonably confident that this isn’t an anomaly and thought it useful to clarify the different types of ‘P’s that professionals are likely to to encounter and highlight the high level nuances of each.
Portfolio Management
A portfolio can refer to a set of projects, products, programmes and sub-portfolios and or a mix of all four. The key thing to remember with a portfolio is that within it the constituent projects and programmes etc. they may not be inter-dependent or directly related.
Ultimately, portfolios exist in order to manage and align business strategy to that of execution; to achieve the business’s strategic objectives as cost effectively and as quickly as possible. Accordingly, management of these and the associated governance structures will reflect this. With a primary focus on assessing each respective piece of work’s business case and associated key criteria (scope, risk profile, business/customer value and the associated cost and time estimates), whilst periodically reviewing approved work to ensure that they are on track to achieve there stated objectives.
Depending on the organisation’s maturity, the way of assessing which requests receive the required resources will be to apply a scoring/rating to each criteria and then use a weighted average calculation in order to provide an overall score. The request with the highest scores will receive the relevant funding and those that don’t will either be mothballed until funds become available or cancelled.
Product Management
Product Management, is focused on
‘the building of desirable, feasible, viable, and sustainable products that meet customer needs’
© Scaled Agile, Inc.
As such, in order to design, develop, test and deploy a new product into the market, products can employ both basic and or complex structures consisting of portfolios and or standalone projects, depending on their complexity and the organisations market offering. For example an organisation may have a portfolio of products of differing levels of maturity within the product life-cycle requiring .
If it is an established product, it should also have a supporting organisation dedicated to servicing existing customers. If it is a new product one of the elements that you will need to clarify is who will support the product once it is launched and what is the handover process to them? You may find that if it is a brand new product you may need to define and recruit a support organisation, which will provide this function once the product is launched. Depending on the size and scale of the product, establishing this organisation could become a distinct project.
Programme Management
Programme Management, defined in the PMBOK as
‘a group of related projects, subprograms and program activities managed in a coordinated way to obtain benefits not available from managing them individually.‘
PMBOK 5th edition
Programmes, thus, are made up of projects which have dependencies and may also have elements of related work outside of the scope of one or many of the constituent projects. A project can also exist outside of a programme.
Therefore, Programme Management is focused on ensuring that the activities and projects within its scope achieve the overall programme benefits statement. In order to achieve this objective, the Programme Manager is likely to devise an additional tier of governance and set of activities to align and steer the associated projects and dependencies to ensure that these are met.
Project Management
At the lowest level of the collection of ‘P’s’ are Projects. These are temporary organisations assembled in order to provide a fixed result in the form of deliverables, which inform the project’s scope.
By their very nature, projects have fixed beginning and end dates at which point the project is disbanded and the deliverables are handed over to a customer. Examples of a deliverable would be working software or the delivery of a physical document/certificate or piece of hardware.
Project Management, at its very essence, is about clarifying the associated deliverable(s) with stakeholders and overseeing the management of resources to produce these in relation to cost and time constraints. These three elements – Scope, Cost and Time – are sometimes referred to as the ‘Iron Triangle’.
Hierarchical structure
The above hierarchy is intentionally complex in order to highlight how Products, Portfolios, Programmes and Projects can be structured. Though it should also be stated that Projects can also be in complete isolation. This in part can be a partial explanation as to why there is sometimes confusion caused around these terms. Thought the key takeaway is, when scoping a new initiative, to focus on listing deliverables, be these in the context of Features and User Stories if developing a software solution, or hardware and supporting documentation if delivering a physical good.
Summary:
All these approaches exist in order to deliver value to the customer as efficiently as possible, whilst managing finite resources. Regardless of the complexity of an initiative, the key is to drive clarity around a list of deliverables as this will be the baseline from which you can determine what value/benefits that the project or projects are providing and from this determine if additional levels of governance are required. This should be determined post the primary activity of scoping a project, which is an iterative process. A first pass of playing back to stakeholders the deliverables that they require, will allow you to determine what it the desired end state, an appropriate delivery structure and a supporting governance model in which to steer the initiative.