The 4Ps For Project Management - PM 360 Consulting
post-template-default,single,single-post,postid-17315,single-format-standard,wp-custom-logo,theme-bridge,woocommerce-no-js,ajax_fade,page_not_loaded,,qode-content-sidebar-responsive,columns-4,qode-theme-ver-11.0,qode-theme-bridge,wpb-js-composer js-comp-ver-5.1.1,vc_responsive

The 4Ps For Project Management

4Ps For Project Management

The 4Ps For Project Management

4Ps For Project Management

The Telescope vs the Microscope

It’s critical to understand how Portfolios, Programmes, Projects and Products — the 4Ps — fit together and how to navigate them in your career. Start here.

Short Summary of the 4Ps

Now we have working definitions of the 4Ps, let’s look at how the roles of portfolio, programme, project and product managers overlap and where they are distinct. To do that, we’ll use the Fried Egg Model.

The Fried Egg Model
The Fried Egg Model helps us understand many related fields and see how role descriptions are connected. There are considerable overlaps (egg whites), with the specialisms (egg yolks) being relatively small.

Activities that are common across all the 4Ps include:

Understanding the customer(s) that will be served by the Project, Product, Programme or Portfolio so that their needs and wants are known and prioritised. In many organisations, user experience (UX) or customer experience (CX) people do this full-time;
Understanding the business and how their activities fit into the bigger picture and help the business meet its plans;
Understanding internal and external stakeholders, including their needs and attitudes towards your work;
Aligning stakeholders with your strategy, goals, objectives and deliverables, to minimise disruption and maximise outcomes;
Developing a strategic and tactical roadmap that aligns with other activities being planned by the business;

Communicating intent and deliverables to allow stakeholders to challenge and accommodate your needs and to ensure dependencies are understood;
Converting strategies to plans so that delivery teams can work within the constraints of the business;
Managing budgets and costs within constraints set;
Defining Objectives and Key Results (OKRs), aligning with stakeholders, tracking progress and delivering the required outcomes;
Identifying, resolving and managing risks to outcome and delivery;
Leading multidisciplinary teams;
Getting things done in the context of the organisation. Examples of sign-offs that might be needed include legal, brand, marketing, sales, security, health & safety and so on; and Transitioning to operations.

Whilst we love the DevOps approach of ‘you build it, you support it’, only the smallest organisations can do this in reality. If you have thousands or millions of users, your DevOps teams won’t be staffing the helpdesk; you’ll have a dedicated contact centre, and they need to know how to support users.

These egg whites are relevant to all delivery leaders, irrespective of whether you deliver a simple project, an extensive programme, a software product or a billion-dollar portfolio. Where you need to develop your egg yolks is the subtle challenge that needs to be managed. Some factors you need to consider include:

1.The level of detail you can get to— a portfolio chunks down to projects, products and programmes (the ‘telescope’), whilst a product chunks down to epics, features and stories (the ‘microscope’);

2.The closeness to the customer — a product manager is the most intimate, but a portfolio manager still needs to have a solid understanding of who they serve and why;

3.The extent of the reach of their work — a portfolio manager deals with change only. A product or project manager deals with everything for their product or project only. A programme manager crosses into the business and ensures that full end-to-end capabilities are delivered, but only until the capabilities are embedded;

4.The balance of building vs operating — project managers will hand over to operations at the end of the project, whilst product managers will continue building and operating until the product is retired. Often, though, a project manager will end up being the product manager as they gain intimacy with what they’ve built;

5.The extent of cost management vs revenue management — depending on whether you’re managing an external-facing audience or an internal-facing one, you will be concerned with a different set of metrics and a different investment mindset. All four ‘P’s can face outwards and need to balance investment vs revenue, but they all also face inwards and need to balance investment vs uptake, compliance, or other measures of value generated;

6.The extent of customer choice — if your product is the company’s ERP system, then your customers don’t have a choice. They use your tools, or they choose a new employer. However, if your product is an e-banking app, they can genuinely decide to call instead or move to a new bank. The extent of choice is essential in the emphasis of how we apply our skills. Still, all Ps need to ensure that their users have a positive experience, taking as little time as possible to do their activities and continue using the tool in future;

7.The extent of buy vs build — can you be a product manager if you’re using a Software-as-a-Service product from somewhere else? Yes, you can, but the challenges are different (and more difficult) because you have to balance your users’ needs with the needs of your service producer and manage a relentless upgrade cycle in often complex organisations. For example, you may be the product manager for MS Teams in a 150k person organisation and explain constant tweaks to a constantly catching-up userbase. In many ways, that’s harder than being a product manager for 150k customers where you have control over every aspect of deployment and iteration;

8.The phase of capability development— once a product is in users’ hands — particularly customers — it’s live. You can’t go back. Given the need to comply with many standards, regulations and internal compliance obligations, organisations often choose a project manager to build the initial release. Project managers focus relentlessly on ensuring that what a business releases isn’t going to land them in court. Product managers focus relentlessly on what the customer needs. They aren’t always the same thing. Once a product is in the wild, a test and learn approach is practical, but I have seen otherwise outstanding products scrapped once a project team has unpicked the mess of technical debt and compliance debt that prevents scaling out or scaling up.

There are more factors to consider, but I hope that it’s clear that there is no panacea — complex organisations need a mix of portfolio, programme, project and product people to be successful and they need them to have similar and compatible skills.


Article written by John Davidson  2oth April 2021