The inventory had dozens of lines and far fewer projects
The first full inventory of the project portfolio arrives as a spreadsheet with several dozen lines. Each line has a name, a sponsor and a colour. Leadership has looked at versions of this list for months, and nobody has questioned what it actually contains.
The review starts with the obvious columns: scope, budget, owner, end date. By the tenth line, a pattern is visible. Some lines have no budget because someone else funds and runs the work. Some bundle five or six separate efforts under one ambitious title. A handful turn out to be a single slide from last year’s management offsite, never developed further.
Most project portfolios carry three kinds of impostor that are not projects at all: interface work on someone else’s project, programmes without programme governance, and header initiatives that never grew into work.
None of these lines is fraudulent. Each was added in good faith, by someone who needed a place to track something. But a list in which only some lines are projects cannot be prioritised, resourced or governed as a portfolio. The scene repeats across organisations at a similar stage of maturity, and the fix always starts in the same place. Naming the impostors is the first act of portfolio governance.
Interface work on someone else’s project is a dependency, not a project
The first impostor is interface work. A shareholder builds the facility. A main contractor delivers the system. The technology comes from a licensor. Your organisation has real work to do at the boundary — reviewing designs, preparing to receive, coordinating access — and somebody logs it as a project.
The signals are easy to spot once you look for them. You do not control the scope. You do not set the schedule. Your “milestones” are copied from the other party’s plan, and your budget covers people’s time but none of the deliverable. When the date slips, the decision to recover it is not yours to take.
Managing this as a project produces a familiar frustration. The project manager reports red, cannot act on it, and starts to look ineffective for problems they never owned. The correct treatment is a dependency and interface register: what you need from the other party, by when, what you must provide in return, and the escalation path when either side misses. That is delivery assurance, a different discipline with different instruments, and it belongs in the portfolio as a dependency rather than a project.
Reclassifying it does not make it less important. The interface register still deserves a standing slot in the portfolio review, because a missed dependency can stop a real project just as surely as a missed internal milestone. What changes is the question the review asks: not “why is this red?”, but “who on the other side owes us what, and has the escalation gone out?”
A programme without programme governance is just a large wish
The second impostor is larger and harder to challenge. It is strategy implementation shaped like a programme: several related projects, a business benefit that only appears when they all land, and a senior name attached. What it lacks is programme governance.
The signals are structural. No programme sponsor owns the benefit. No programme board has authority over the components. Nobody tracks benefits rather than milestones, and the component projects report separately while competing for the same people. The line in the portfolio says “programme”. The reality is a cluster of projects that happen to share a slide.
There are only two honest treatments. Either give it what a programme needs — a sponsor accountable for the benefit, a board with authority over the components, a benefits view that outlives individual project closures — or stop calling it a programme and manage the components as separate projects with explicit dependencies. Keeping the label without the governance is the worst option, because it promises integration that nobody is delivering. Getting the name right is not pedantry. It decides what governance the work receives.
A header initiative is a label that never grew into work
The third impostor is the most common and the easiest to miss. It is a header initiative: a theme from a strategy session or a board presentation that entered the portfolio as a line and never matured beyond it. “Digital operations.” “Customer excellence.” “Lean culture.”
Its signals are distinctive. There is no scope statement. The owner is a committee or a function, not a person. The status has said “ongoing” for three quarters. Underneath sits a task list, occasionally a few genuine activities, but nothing with a defined deliverable or end.
Header initiatives are not harmless placeholders. They absorb attention in every review, they make the portfolio look fuller than it is, and they let a leadership team believe a priority is being worked on when nobody has been asked to work on it. The treatment is binary and time-bound. Within a fixed window, convert it into a real project or programme, with a charter, a named owner, a scope and a deliverable. Otherwise, close it and record why.
Impostors survive because a long list looks like momentum
If the impostors are this easy to recognise, why do they persist? Partly because inventories count lines, and a long list looks like momentum. Dozens of initiatives sound like an organisation on the move. A shorter list of real projects, a dependency register and a few closed headers can sound like a demotion.
The impostors also tend to carry senior names. Downgrading a chief executive’s initiative to “header, to be chartered or closed” takes a conversation most PMOs would rather avoid. And often nobody gave anyone the job of sorting. Intake gates, where they exist, usually start after the inventory was already built.
The cost is concrete. You cannot prioritise across mixed categories, because a dependency, a programme and a slogan do not compete for resources in the same way. Capacity planning double-counts people who sit on interface work and on the projects it serves. Portfolio reviews spend their time on lines that no decision can move.
Sorting the inventory is the first act of portfolio governance
The sort itself is simple. Every line in the inventory faces three questions:
- Do we control the scope and the resources? If not, it is a dependency. Move it to the interface register.
- Does it have a defined deliverable and an end? If not, it is a header. Charter it within a fixed window or close it.
- Does it combine several projects towards one business benefit? If so, it is a programme. Give it programme governance, or split it.
Whatever passes all three tests as a single, owned, bounded piece of work is a project. Expect the project count to fall sharply the first time you run the sort. That is not a loss of ambition. It is the first time the portfolio describes what the organisation is actually doing.
Run the sort as a working session with the sponsors, not as a desk exercise inside the PMO. Each reclassification is a decision, and it should be taken and recorded by whoever governs the portfolio, with the sponsor in the room. Sorting done quietly by the PMO gets reversed at the next review. Sorting decided openly sticks, because the people who added the lines agreed to move them.
Done once, the sort is a clean-up. Done at the door, it becomes an intake gate, and the impostors stop arriving in the first place.
A portfolio nobody has sorted is a list, not a portfolio.