What is project portfolio management?
Project portfolio management is steering your projects as one body of work rather than one at a time. Not: is this project on schedule? But: are we collectively doing the right things, and can we actually carry them?
That sounds like a nuance. It is the difference between an organisation that has two hundred projects and an organisation that knows which twenty of them matter.
What it is
A portfolio is everything an organisation puts its capacity for change into — projects, programmes and the work that keeps the lights on. Portfolio management is the process that makes choices about that set: what starts, what stops, what waits, and on what grounds.
Three questions sit at the centre of it.
- Are we doing the right things? Does this work still serve where the organisation is going, or did it simply start once and never stop?
- Can we carry it? Is there capacity, and are the people who would do the work genuinely available rather than nominally assigned?
- Do we know how it is going? Not project by project, but across the set: where is it stuck, and what does that mean for everything else?
None of those questions is about how a project is run internally. Project management is about doing a project well. Portfolio management is about which projects ought to exist at all. An organisation can be excellent at the first while being comprehensively lost in the second — and that is the usual combination, not the unusual one.
Portfolio, programme and project
These three words get used interchangeably, and that is where a great deal of steering-group confusion begins. The distinction is worth holding onto.
A project delivers a defined result, with a start and an end. A new application, an office refurbishment, a migration.
A programme is a coherent group of projects that together deliver one change. It has its own governance and usually its own sponsor, because the individual projects deliver nothing much on their own.
A portfolio is not coherent, and is not meant to be. It is everything, side by side, competing for the same people and the same money. A portfolio does not deliver change — it decides which changes get delivered.
Which leads somewhere that is easy to miss: the portfolio is the only level at which "no" is a legitimate answer. Inside a project or a programme, stopping is a failure. Inside a portfolio, stopping is simply one of the outcomes — and a portfolio in which nothing ever stops is not choosing anything.
Why it goes wrong
More has been promised than there are people
This is by far the most common, and the most quietly destructive. Every project was approved on its own merits, every individual decision was defensible, and the sum of them is half as much work again as there are hands.
What makes it hard to catch is that nobody is being unreasonable at the moment of deciding. The question "do we have the capacity for this?" is usually not asked at approval at all. The bill arrives months later, spread thinly across dozens of projects that each slip a little, and by then it looks like a delivery problem rather than the choosing problem it actually is.
Nobody remembers why it started
Ask about any project currently running why it began, and surprisingly often you get nothing beyond "it was decided at some point". The decision was taken in a meeting whose minutes exist somewhere, by people who have since moved on.
Without that trail you cannot stop the project either. Stopping requires being able to explain why the reason for starting no longer holds, and that is only possible if the reason was written down in the first place.
The portfolio is a list, not a choice
Plenty of organisations have an overview of everything that is running. That overview is an inventory: it describes. It only becomes a portfolio when something hangs on it — an order, a ceiling on how much can run at once, a moment at which everything is weighed again.
A list that is dutifully updated every quarter but from which nothing is ever removed is an administrative record. There is no shame in that, but it should be called what it is, because it gives you no grip on anything.
How to start
You do not need to start big here, and you would be unwise to. A workable first pass looks roughly like this.
- Make one list. Every project, including the small ones, including the ones from the business unit that always arranges its own affairs. Incompleteness is the real enemy here, not imprecision.
- Add one sentence per project about why it exists. Where that sentence cannot be written, you have already found your first problem.
- Estimate capacity roughly. Not hours per week per person — that comes much later. For now it is enough to know how many people there are and how much of them has already been committed.
- Compare those two numbers. Almost always there is more work on the list than there is capacity to do it. That gap is the conversation, and it is a far more productive one than asking why project X is late.
- Agree when you will look again. A portfolio assembled once and then left alone is an inventory again within six months.
What is deliberately not on that list: a scoring model, weightings, a maturity programme. Those come later, and organisations that begin with them tend to get stuck designing them.
Four situations, not a ladder
Maturity models are useful as description and harmful as ambition. The point is not to reach the top; it is to know where you are and what the next worthwhile step would be.
Broadly, there are four situations. In the first there is no overview — projects exist, but nobody could say how many. In the second there is a list that is accurate and does nothing else. In the third there is choosing: a predictable moment at which work is started, stopped or deferred. In the fourth there is also looking back — did we get what we expected, and if not, why not?
The step from the second situation to the third is the only one that genuinely changes anything. The step from the third to the fourth is valuable, and plenty of organisations never take it and function perfectly well.
The vocabulary
The field carries a lot of jargon, and some of it is unavoidable.
Portfolio governance is the deciding half: who chooses what, at which moment, and on what basis. It is worth naming separately because organisations routinely have the reporting and none of the deciding — a monthly pack that describes the portfolio to people who have no forum in which to change it.
Demand management is the process before anything starts: how requests arrive, who assesses them, and how a decision is reached. What that looks like in software is on the from idea to an approved project page. Without it work begins through the side door and the portfolio is permanently reacting to things it did not choose.
Capacity management asks whether the work you want to do fits the people you have, at portfolio level. The operational layer beneath it — who is doing what next month — is resource management. The distinction sounds like hair-splitting and is not: the first is a choice for the executive, the second a planning question for a team lead.
You will also meet types of work. A project delivers something new, a change alters something that already exists, and operations keeps running what is already there. All three compete for the same people, and a portfolio that counts only projects systematically undercounts.
Tools — and when a spreadsheet is genuinely fine
The most frequently asked question in this field is whether a spreadsheet will do. The honest answer is: yes, for considerably longer than a vendor will tell you.
A spreadsheet works while one person maintains it, the project count is in the tens, and the question being asked is "what is running?". It starts to strain on three fronts at once: when several people need to update it at the same time, when you want to see how something developed over time rather than how it stands today, and when capacity becomes an actual calculation rather than an estimate.
A PPM tool buys you three things, mainly: one version of the truth, history, and a fixed shape for the conversation. What it does not buy is the willingness to choose. An organisation that will not say no does not start saying it because the software is better — it just says yes faster, with nicer charts.
So choose late, and choose against the process you already run. Buying a tool to impose a process that does not yet exist is the most expensive available way to discover that the process was the problem.
What a tool like that then costs, and where the gap sits between the price on the website and the number on the invoice, is covered in the guide what does portfolio management software cost.
When you do not need this
There is a real chance this whole subject is not for you, and it is better to read that now than to conclude it in a year.
You do not need portfolio management if you have few projects at a time — up to about ten you can simply hold it in your head, and formalising costs more than it returns. Nor if your projects do not share people: where each team does its own work with its own staff, there is nothing to allocate and therefore nothing to steer. Nor if, in practice, one person decides and has the whole picture in their head. That is fragile, but it works, and building a process around it solves a problem you do not yet have.
Where it does start to pay: as soon as the same people appear in several projects, as soon as you can no longer explain why something is running, or as soon as "we will give it a go" reliably means something else quietly stops.
That last one is the clearest signal of all. If work can be added without anything being removed, there is no portfolio — there is a waiting list.
More on this subject is in the guides. How Migreat! from Promigion approaches it is set out on the portfolio management software page. A full overview of the platform is on the homepage. Working inside a PMO or portfolio office yourself? The page for PMO and portfolio management covers specifically what stops that overview being rebuilt by hand.