Managing a project portfolio means deciding which initiatives get people and money, and which wait or get stopped. A project is accountable for delivering scope; the portfolio is accountable for the choice. The split of accountability starts by naming the functions: sponsor, portfolio owner, project management office and project manager.
Quick Overview
What you’ll learn:
- Which decisions belong to the portfolio and which no project manager can make
- Which functions have to carry a name for a portfolio to work at all
- What a decision gate that genuinely closes initiatives looks like
- Where portfolio risk sits once the single-project view is no longer enough
Who this article is for:
- Managers running several initiatives that compete for the same specialists
- Project managers moving into a coordinating role across a set of projects
- Anyone standing up a project management office in a mid-size organisation
Reading time: 7 minutes
The Portfolio Owns the Choice, the Project Owns Delivery
A portfolio is a set of projects and programmes held under one decision about priority — the framing used by the portfolio management material on apm.org.uk, which separates selecting initiatives from running them. The distinction reads as theory right up to the week two projects ask for the same architect. At that point it stops being a scheduling argument and becomes a question about which initiative matters more to the organisation, and nobody below portfolio level is positioned to answer it.
The practical consequence is narrow: a list of projects is not a portfolio. It becomes one once it has an owner, selection criteria written down before initiatives are collected, and a moment at which an initiative can cease to exist. Without that third element a portfolio only grows, and within a year it consists largely of work nobody closed, because closing was nobody’s job.
The common opening mistake is trying to fix a portfolio with tooling. A tool reports state; it does not say no — and a portfolio that cannot say no is a register of promises.
The Roles That Have to Carry a Name
The sponsor owns the business justification for one initiative: that it still makes sense, and the signature under the decision to continue. The sponsor sits on the demand side, not the delivery side. Where the sponsor is also the person delivering, nobody is left to challenge whether delivery is still worth doing.
The portfolio owner owns the set as a whole: priority between initiatives and alignment with strategy. This is a function rather than a job title — usually a board member or an area director, in other words someone who holds the budget and can say “not now” without escalating further.
The project management office owns transparency and rhythm, not the content of decisions. The PMO material on apm.org.uk describes it as an organisational structure that supports projects: controls and reporting, assurance, process improvement and specialist support. The account of standing one up, indexed on pubmed.ncbi.nlm.nih.gov (Journal of Healthcare Information Management), lists what the first year produced: agreement with departmental leaders on planning, prioritising and budgeting projects, a formal route for requesting projects, and project management training. A PMO that starts setting priority has taken over the portfolio owner’s function, and in the same move has stopped being a trustworthy source of data about the portfolio.
The project manager owns delivery of scope inside agreed tolerances, and escalation when those tolerances stop holding. Their mandate ends at the boundary of one initiative, which is a property of the split rather than a flaw in it.
All four work on one condition: every function carries a name, and each one knows what it does not decide. Portfolios in which “everyone decides priority” have no priority — they have a queue settled by whoever argues loudest.
Portfolio Risk Is Not the Sum of Project Risks
Once a set of initiatives is managed together, a second class of risk appears that no single project register holds: dependency between initiatives, concentration on one scarce competence, and total exposure of the portfolio to one supplier or one technology. The scientometric study of project portfolio risk management indexed on pubmed.ncbi.nlm.nih.gov maps it as a formal knowledge domain linking project, risk management and portfolio concepts — which is the usable part here: portfolio risk is handled as a field of its own, so the register is kept at a different level, by a different owner, and it reads differently.
For a portfolio owner the usable form is short. Name the dependencies between initiatives explicitly, because they are invisible inside each project’s own plan. Name the people whose absence would stall more than one initiative. And treat concentration as a risk in its own right, not as an efficiency.
Agile Delivery Does Not Remove the Portfolio
Methods such as PRINCE2 and AgilePM describe how one initiative is delivered, not how a choice between initiatives is made. An agile approach shortens the feedback cycle and changes what a gate looks at: not a year-long plan, but a working increment and a current justification for continuing. The accountability split survives intact — the sponsor still owns justification, the portfolio owner still owns priority, the PMO still owns transparency.
Governance, as described on apm.org.uk, is the framework of authority and accountability around those decisions, and its most practical part is the gate: a planned point at which an initiative is approved for the next stage, given a condition to meet, or stopped. A gate that works sits in the calendar rather than being convened after the fact, carries a pass criterion agreed before the stage it governs, and leaves a decision recorded with a date and an author. Stopping an initiative is a legitimate gate outcome, not a team failure.
Read Also
- AgilePM, Scrum and PRINCE2 side by side: which fits your organisation — delivery methods compared, useful when deciding what you show at a gate
- Project management tools and methods you need to know — the tooling layer that supports portfolio transparency without replacing it
- Project budgeting and cost control: A Practical Comparison of Approaches — the other currency portfolio initiatives compete for, and the ways of holding it between gates
Build Your Skills
This topic is developed in the AgilePM® Foundation - accredited training with exam and AgilePM® Practitioner - accredited training with exam courses. The first organises roles and management products; the second works on applying them inside a specific organisation. Contact us to match the scope to your area of accountability.
Frequently Asked Questions (FAQ)
Who decides priority — the PMO or the portfolio owner?
The portfolio owner does. A PMO is a unit that supports delivery: standards, methods, reporting and help for project managers. The portfolio owner is a decision-making function — setting priority and owning alignment with strategy. The PMO supplies the material the decision is made on, and loses credibility the moment it starts making that decision itself.
Does an IT portfolio behave differently from any other portfolio?
The mechanics are the same; the binding constraint differs. In IT the scarcest resource is rarely budget and almost always a specific competence: an architect, a database administrator, a security engineer. Selection criteria in an IT portfolio therefore have to account for the availability of named people, not only cost — otherwise the portfolio approves a plan nobody is free to deliver.
Can a portfolio survive teams that deliver iteratively?
It can, by aligning the rhythms. The portfolio stays the level at which priority is decided, teams work iteratively, and decision gates land close to increment reviews so that decisions rest on what actually works. Agility does not remove the need to choose between initiatives; it changes the evidence the choice is made on.
Where does project management end and portfolio management begin?
At what is being decided. Project management answers how an agreed scope gets delivered; portfolio management answers which scopes are started at all, and in what order. Hence a different owner, a different horizon and a different success criterion: a project is accountable for delivery, a portfolio for the composition of the set. Where no portfolio exists yet, the starting point is an inventory of initiatives with named sponsors and an appointed portfolio owner; selection criteria and a gate calendar follow.