Portfolio Prioritization Process

The most popular advice on portfolio prioritisation is to build a scoring matrix and rank the projects. I think that starts in the wrong place. A beautifully ranked list is useless if the same people are required to deliver everything on it.

I treat the portfolio prioritisation process as a capacity and governance problem, supported by scoring. Leaders need to decide what deserves investment, what the organisation can deliver, and what evidence would justify changing those decisions. Without those connections, prioritisation becomes a workshop rather than a management discipline.

Why Scoring Is the Easy Part of Portfolio Prioritisation

Scoring individual initiatives is straightforward compared with approving a deliverable combination. Each sponsor can present a credible business case. The leadership team still has to establish whether those business cases rely on the same people, suppliers, systems and management attention.

Consider a hypothetical leadership team approving a collection of strategic projects. Later, the delivery leads discover that several need the same data engineering squad, others depend on a shared vendor, and benefit accountability is unclear. Nobody made an obviously irrational project decision. Leaders evaluated the projects separately.

Individually attractive doesn't mean collectively deliverable

Public-sector evidence illustrates why strategic appeal isn't enough. At the end of March 2025, the Government Major Projects Portfolio contained 213 projects, with £996 billion in whole-life costs and £742 billion in monetised benefits, yet only 14% were rated Green for delivery confidence, according to the NISTA annual report for 2024–25.

I wouldn't treat that as a direct benchmark for a scale-up. I would take the governance lesson seriously: expected benefits and confidence in delivery are different judgements. A leadership team needs both before committing scarce resources.

A high-scoring project isn't automatically the right project to start next.

A value-versus-effort matrix can support discussion. It can't establish whether the portfolio overloads a specialist team or assumes that a supplier can deliver incompatible commitments simultaneously. Those questions require named resource owners and a consolidated view of demand.

Start with the decisions, not the spreadsheet

I expect a prioritisation review to answer distinct questions:

• Investment merit: Which outcomes justify spending money and leadership attention?
• Execution feasibility: Which combination can the organisation deliver without undermining existing commitments?
• Decision durability: Which assumptions would make the approved combination wrong?

The roadmap should communicate those choices rather than disguise unresolved conflicts. RapidNative's product roadmap best practices is a useful companion resource when translating portfolio decisions into product planning.

My starting point is a single portfolio register containing proposed and active work. If leaders assess new requests without seeing existing commitments, they aren't prioritising the portfolio. They're adding to it.

The Four Tests Every Initiative Must Pass

A scoring model fails when it rewards eloquence. Sponsors learn the vocabulary, benefits get restated under three criteria, and the portfolio approves more work than the delivery system can carry. I keep the test set small and make every answer expose either evidence or capacity.

The Government Functional Standard for Project Delivery names strategic fit, expected benefits, efficient use of funds and risk as evaluation tests, with stakeholder views and existing project performance also considered. Commercial teams can use that foundation without copying government process.

Score the claim, then audit the load

Strategic fit needs a mechanism, not a slogan. If the initiative supports retention, the sponsor should say which customer behaviour changes, why this work causes that change, and what would make the belief false.

Expected benefit needs an owner outside the delivery team. A launched portal is an output. Lower service demand, faster cycle time or reduced rework is an outcome. The owner has to be able to confirm the change after release, otherwise the benefit is theatre with better formatting.

Efficient use of funds is where I force the capacity question into the room. Implementation cost is only the entry price. I want internal effort, ongoing operation, adoption support and the opportunity cost of the same people doing other work. A proposal can beat a matrix and still fail because it needs the same data engineer, operations lead and supplier window already committed elsewhere.

Risk has to be specific enough to kill the idea. A disciplined risk identification process should name the assumption that breaks the business case, the dependency that could arrive late, and the exposure left after mitigation. Generic concern lists create comfort. They do not create judgement.

My rule is blunt: fail one test and the initiative stops, improves or waits. Do not let a strong benefit score compensate for an unnamed owner, and do not let urgency launder weak evidence. Remove overlapping criteria so sponsors cannot earn the same point twice, publish scoring definitions before submissions arrive, and require a written rationale beside every number. The score should make disagreement easier to locate, not give the loudest sponsor a cleaner way to win.

A Five-Stage Gated Funnel That Stops Pet Initiatives

Scoring tells you which proposal is strongest. It does nothing to stop a senior sponsor's weak idea reaching the table anyway. Gates do that. I run intake as a five-stage funnel where each gate can return, hold or kill a proposal, and where no sponsor skips a gate because of title.

The government guidance on managing a portfolio prescribes categorisation, investment assessment, multi-criteria analysis and financial, resource, technical-capability and duplication checks before authorisation. I run the same logic as an operating funnel.

1. Register and categorise. The portfolio lead logs the request, its sponsor and its purpose. Mandatory obligations get separated from discretionary spend, and the mandatory label itself gets challenged. An obligation can be unavoidable while its proposed solution remains negotiable.
2. Screen for minimum evidence. Problem, intended outcome, initial cost assumptions, resource demand, benefit owner. Incomplete submissions go back. The portfolio lead never fills gaps on a sponsor's behalf, because that hides exactly the weakness the gate exists to expose.
3. Score against the agreed tests. Strategy, finance and delivery representatives assess whatever survives the screen. They record disagreements rather than averaging away a material uncertainty. A disputed assumption is decision-relevant information.
4. Validate the combination. This gate tests whether the shortlist survives contact with operational reality. Finance checks whole-life cost and funding availability. Functional leaders confirm skills, timing, technical feasibility and competing commitments. The portfolio lead hunts for duplication.
5. Authorise, defer or reject. The accountable executive decides with explicit conditions. Approval records funding, committed resources, delivery sequence and review requirements. Deferral records what must change before the proposal returns.

For SaaS teams tightening proposal quality at stage 2, Orchory's effective brief examples for SaaS help sponsors describe the problem and scope more clearly. The commercial and capacity evidence still has to come from the sponsor.

Stage 4 deserves more attention than it usually gets. Two business units proposing different customer-data platforms is a combination problem. Scoring both proposals harder does nothing about it. The useful moves are combining discovery, clarifying ownership or rejecting duplicate scope outright.

Gate discipline: Missing evidence means return for clarification, never conditional approval with an implied start date.

The funnel earns its keep at stage 4, not stage 3. Scoring ranks ideas. Validation decides whether the combined portfolio is deliverable at all. I won't let scheduling start until resource owners have confirmed availability, because a start date assigned before that confirmation is an aspiration wearing a date's clothing.

When Capacity Beats Strategy in the Prioritisation Decision

Consider a hypothetical scale-up choosing between a platform migration and several customer-facing product bets. All depend on the same backend specialists. The migration has the strongest long-term business case, but the product work addresses immediate customer friction.

Approving everything doesn't preserve strategic ambition. It leaves the engineering lead to make portfolio decisions informally through staffing choices, delayed reviews and incomplete work.

Find the constraint beneath the business cases

I start by asking the backend lead to identify the actual constraint. It might be implementation effort. It might instead be architecture decisions, security review or production-release ownership. Adding general engineering capacity won't necessarily relieve a specialist bottleneck.

Then I map the shortlisted work against that constraint:

• Strategic contribution: Which outcome does each option advance, and what happens if it waits?
• Cross-team load: Who must contribute beyond the named delivery team?
• Dependencies: Which work enables other outcomes, and which work merely competes with them?
• Operational demand: What capacity is already required for service reliability, support and unavoidable maintenance?

I use capacity planning methods to make these commitments explicit. Doczen's resource-allocation guide is another useful reference when teams need to diagnose resource allocation issues.

The wider infrastructure context reinforces the importance of this distinction. The UK Government's 2025 Infrastructure Pipeline identified around 780 public and private projects worth approximately £530 billion over the following decade, explicitly connecting pipeline visibility with industry planning for skills, technology and capacity.

Choose the combination, not the winner

In the scale-up scenario, I would test alternatives rather than force a binary choice. Could the migration begin with architecture discovery while product work uses delivery capacity? Could a limited platform change remove the immediate constraint? Could customer-facing scope be reduced without losing its intended benefit?

The answer depends on the dependencies. If the platform is a prerequisite, sequence it first. If it isn't, the lower-ranked product initiative may be the better next investment because it leaves room for other valuable outcomes.

As an initial planning guardrail, I recommend leaving 15–20% of a constrained resource unallocated after operational commitments. That's my proposed starting policy, not a research-backed optimum. Adjust it using actual interruption levels and delivery evidence.

The principle matters more than the percentage: don't approve a portfolio that requires uninterrupted availability from people who also keep the business running. Leaders must own the trade-off instead of asking delivery teams to absorb it.

Linking Approved Initiatives to OKRs Without the Theatre

A portfolio can score well and still fail at delivery if its OKRs promise outcomes the approved work cannot support. Tie quarterly commitments to funded initiatives and the capacity assigned to them. Strategy sets the outcomes; the portfolio shows which work has backing to pursue them.

Start with the outcome, then connect the investment. Each approved initiative should contribute to a primary Objective and a measurable Key Result. Several initiatives can support one Key Result. Creating a separate Objective for every project only disguises a list of work as strategy.

For an onboarding improvement, the Objective might describe a better customer experience. The Key Result should measure a change such as completion rate or time to first value, using an agreed baseline and measurement window. “Release the new journey” is a delivery milestone, not evidence that customers benefited.

Record the connection where portfolio decisions are made:

The business owner remains accountable for the benefit; delivery leads own execution. That separation prevents a common failure: teams report completed work while nobody answers whether the investment changed the outcome.

OKR alignment should connect leadership priorities to team contributions without forcing every team to copy the same wording or accept a target it cannot influence.

Use check-ins to test three things: whether the outcome is moving, whether the investment's assumptions still hold, and whether a decision or changed commitment is needed. A team may deliver its plan while the customer result stays flat. Treat that as evidence to examine the investment hypothesis, not as a reason to celebrate task completion.

Review confidence monthly, while leaders still have time to respond. A red Key Result calls for a decision conversation, not automatic cancellation or a quiet status update. OKRs govern the portfolio only when leadership acts on what they reveal.

Reprioritisation Triggers and Who Has the Authority to Act

Prior approval isn't a permanent entitlement to resources. I want every significant investment treated as an explicit bet, with documented assumptions and conditions for continuing.

The Public Accounts Committee found that benefits-realisation plans for government major projects were not sufficiently rigorous or professional, and identified the absence of a centrally mandated review after projects had operated long enough to demonstrate realised value in its report on delivering value from government investment. My recommendation is to make continuation and post-implementation value reviews explicit requirements, rather than optional good practice.

Define the trigger and the evidence together

A trigger should identify a decision that needs reconsideration. It shouldn't merely generate another escalation email.

I recommend using consecutive red check-ins as an automatic review trigger, with the precise threshold agreed before delivery begins. A sudden loss of funding or a critical dependency failure shouldn't wait for that pattern.

Assign decision rights before pressure arrives

The convenor gathers evidence. The accountable portfolio executive decides whether to continue, restructure, change sequence, pause or stop. Functional leaders validate whether the revised option is deliverable.

I separate routine adjustments from decisions that change the investment. A delivery lead can adjust tasks within an agreed mandate. Moving scarce capacity between strategic outcomes requires portfolio authority.

That distinction belongs in the organisation's decision-making frameworks, alongside escalation routes and delegated limits. If authority remains ambiguous, sponsors can protect their own work while nobody resolves the overall conflict.

Stopping an initiative isn't an admission that the original decision was foolish. Continuing after its assumptions fail is a new decision.

Every review should record the evidence considered, the option chosen, the accountable owner and the implications for other commitments. A pause must release resources explicitly. Otherwise, teams can remain nominally assigned to work that leadership believes has stopped.

I also retain benefit ownership after project closure. Delivering the output doesn't establish whether the organisation received the value that justified its investment.

The Operating Cadence That Keeps the Portfolio Honest

I recommend a monthly portfolio health review, a quarterly re-score and an annual strategic reset. These serve different decisions. Combining them into a sprawling status meeting makes each less useful.

For the monthly discussion, I suggest a 60-minute timebox focused on exceptions, delivery confidence, capacity consumption and dependency health. That's a meeting-design recommendation, not an industry benchmark. OKR evidence should be prepared beforehand.

The Operating Cadence at a Glance

The Green Book appraisal framework supports comparing a longlist against objectives and critical success factors before narrowing the options. I use that discipline at the annual reset rather than rolling every existing commitment forward.

An effective operating rhythm should leave leaders with usable records:

• Portfolio register: Comparable evidence and accountable owners.
• Scored shortlist: Decisions with supporting rationale.
• Capacity map: Shared bottlenecks and confirmed commitments.
• Reprioritisation log: What changed, who decided and why.

I help leadership teams build a portfolio prioritisation process that connects strategic choices, realistic capacity and accountable OKR delivery. To resolve competing commitments and establish a decision rhythm your organisation can run, book a conversation.