← Back to news

Objectives First, Projects Second: Why Most PMOs Build Their Portfolio Backwards

Most PMOs build their portfolio from the project list up. Here is why starting from objectives instead changes what a PMO can actually defend.

Ask most PMOs how their portfolio came together, and the honest answer is that it accumulated. A request here, a good idea there, a project inherited from a reorganisation, a pet initiative from someone senior enough that nobody asked too many questions. None of it was wrong on its own terms. All of it started from the work, not from the reason for the work.

This is building a portfolio backwards. It is also, by a wide margin, the normal way it happens.

Why building backwards feels natural

Projects are concrete. Someone can describe a project in a sentence: build this, migrate that, launch this feature. Objectives are abstract by comparison, and abstract things are harder to start a conversation with. It is much easier to say yes to a well-formed project proposal than to ask whether that project earns a place under any objective the organisation currently holds.

There is also a structural reason. Most project intake processes were built to answer "can we deliver this," which is a capacity and feasibility question. Almost none were built to answer "should this exist at all," which is a strategic question that requires an objective to already be defined before the project ever arrives. Without that objective sitting there first, the only question left to ask is the feasibility one, and feasibility questions get answered yes far more often than strategic ones do.

What building backwards actually costs

The organisations most exposed to this are the ones that also measure themselves well. Only 18% of project professionals show high business acumen, and 70% of large-scale digital transformations fail, not typically because delivery was poor, but because the portfolio was never built from a strategic starting point in the first place. A backwards-built portfolio can hit every delivery metric and still fail the one question that matters, because delivery metrics were never designed to catch this kind of failure.

The specific costs show up in predictable places. A PMO cannot explain, in board terms, why a particular project exists, because nobody can trace it back past "someone asked for it." Resource gets allocated to whichever project shouted loudest this quarter, rather than whichever project the organisation's stated priorities would rank highest. And the review conversation that should stop weak projects never quite happens, because stopping a project requires someone to argue it against an objective, and there was no objective to argue it against.

What objectives first actually looks like

Building forwards starts with a different first question. Instead of "what should we build," a PMO objectives-first asks "what outcome are we trying to move, and what would prove we've moved it." Only once that objective and its KPI exist does a project get considered as a candidate to serve it.

In practice, this reorders three things that most PMOs currently run in the opposite sequence.

Objectives get defined and reviewed before the annual project list, not alongside it. If objective-setting and project planning happen in the same meeting, projects will always win the argument, because they are concrete and objectives are still being worked out.

Every new idea gets evaluated against an existing objective, not against its own merits in isolation. A good idea with no objective to serve is not yet a project. It's a candidate for a conversation about whether a new objective needs to exist, which is a different, more deliberate conversation than approving a project on the spot.

KPIs get attached to the objective before delivery starts, not retrofitted afterward to justify a project already underway. A KPI defined after a project has launched tends to describe what the project happened to produce, rather than what success was meant to look like before it began.

Why this is harder than it sounds

None of this is difficult to write down. It is difficult to practise, because it requires saying no to a concrete, well-argued project because it does not serve an existing objective, which feels, in the room, like blocking good work for the sake of process. It is not. It is the only mechanism that stops a portfolio from growing every year without becoming any more strategically focused.

The right number of projects to reconsider in most portfolios is almost always higher than the organisation currently believes, and that number tends to become visible only once objectives exist as the starting reference point rather than an afterthought layered on top of a project list built without one.

How to reverse the order on an existing portfolio

Most PMOs reading this are not starting from nothing, they are trying to retrofit objectives onto a portfolio that already exists. That is a genuinely different, more forgiving exercise than starting from scratch.

Begin by writing down the strategic objectives the organisation actually holds this year, even if they were never formally documented before. Then take every active project and attempt to link it to one of those objectives. Some links will be obvious. Some will require a genuinely honest conversation about whether the project was ever really about strategy, or just about momentum. And some projects will not link to anything, which is not a failure of the exercise, it is the exercise working exactly as intended.

That final group, unlinked projects, is the most valuable output of the whole process. It is the first honest list most PMOs will ever have of work that exists for reasons other than the organisation's stated strategy.

How software supports building this way

An objectives-first approach only holds up if the structure of the system matches it. If a platform treats projects as the primary object and objectives as an optional tag, the tool will always default users back toward project-first thinking, no matter how the process is documented.

The reverse structure matters: objectives and KPIs sitting at the top, with portfolios, programmes, and projects created underneath them and required to inherit that context, so a project without a linked objective is visibly incomplete rather than quietly acceptable.

Project Director is built this way specifically. Objectives sit at the top of each Business Unit, KPIs attach to measure them, and Portfolios, Programmes, and Projects are created beneath that structure, inheriting the strategic context rather than having it bolted on afterward. A project with no objective is not hidden in the data, it is visibly, structurally incomplete.

Frequently asked questions

Isn't it better to capture good ideas whenever they arrive, rather than only when an objective exists for them? Capturing the idea is fine, and should still happen through a structured pipeline. The distinction is between capturing an idea and approving it as a funded project. An idea with no current objective can sit in review rather than be rejected outright, which keeps the door open without granting automatic approval.

What happens to projects that don't link to any objective during a retrofit exercise? Each one needs an honest conversation: does it reveal a real, currently undocumented objective the organisation should formalise, or was it never really strategic in the first place. Not every unlinked project should be stopped immediately, but every one deserves that conversation rather than a default pass.

Does an objectives-first approach slow down how quickly new projects get approved? It adds a genuine evaluation step where one may not have existed before, so some slowdown is likely, and that is largely the point. The projects that survive that step arrive with a clearer justification, which tends to make execution faster later, since fewer projects get quietly deprioritised or cancelled mid-flight once someone finally asks why they exist.

The practical takeaway

A portfolio built from the project list upward will always struggle to explain itself at board level, no matter how well each individual project is delivered. A portfolio built from objectives downward starts every project with its justification already attached. The order is not a detail. It is the difference between a PMO that reports on work and a PMO that can defend it.

See whether your portfolio still matches your strategy. Start your 14-day free trial, no credit card required.

Share this article
LinkedInCopy link
More from Project Director

Keep reading