Stop Ranking Projects: Why Portfolio Planning Should Start Top Down

Imagine an executive named Victor walking into the annual planning cycle with 137 project requests and enough money to fund five.

Every request is critical. Every request is urgent. Several are transformational. An impressive number are “AI-enabled.” Nearly all claim to be strategic.

The people proposing them are not being dishonest. Each leader can see a genuine problem. Each has customers, employees, risks or aging systems demanding attention. From where that leader sits, the proposed project really does look essential.

Victor’s problem is that he does not manage one department’s priorities. He must make a coherent decision for the enterprise.

So the organization creates a scoring spreadsheet. It assigns points for strategic alignment, financial value, risk, urgency and executive sponsorship. Teams refine their business cases and learn how to maximize their scores. After weeks of analysis, the spreadsheet provides a mathematically respectable explanation for selecting the projects that already had the most organizational support.

That is not strategy. It is a contest among proposals. Loud voices drown out actual strategic needs.

Bottom-up planning is usually proposal-up planning

Most organizations describe their planning process as a combination of top-down direction and bottom-up participation.

Executives announce strategic priorities: improve the customer experience, reduce operating costs, use data more effectively, increase resilience and perhaps “embrace AI.” Business and technology leaders then respond with proposed projects. Those proposals rise through committees until someone assembles them into a portfolio.

This sounds inclusive and pragmatic. It also creates a structural problem.

The organization begins the planning process with solutions, not goals.

Each proposal arrives with a sponsor, a preferred scope and an argument for why it supports the strategy. The planning conversation becomes a comparison of predetermined answers rather than an investigation of what the enterprise most needs to change.

Richard Rumelt has observed that “most corporate strategic plans have little to do with strategy.” In his McKinsey interview on strategy, he distinguishes strategy from long-range resource planning and argues that management must turn ambiguity into challenges people can address.

A list of aspirations followed by 137 funding requests does not accomplish that. It pushes the ambiguity downward and asks every department to interpret the strategy independently.

The resulting portfolio may contain individually defensible projects while remaining collectively incoherent.

Begin with what the enterprise must become able to do

Top-down portfolio planning asks a different sequence of questions:

1. What strategies has leadership actually committed to?
2. What outcomes must those strategies produce?
3. Which business capabilities are most important to producing those outcomes?
4. How capable are we today?
5. Where are the consequential gaps?
6. What coherent changes would close those gaps?

A business capability describes something the enterprise must be able to do. It is more stable than an organization chart, more outcome-oriented than a system inventory and less temporary than a project list.

That stability makes the capability model a powerful planning surface.

Suppose a company wants to increase digital revenue. Leaders might initially receive proposals for a redesigned checkout, a new CRM platform, an analytics environment, mobile improvements, marketing automation and several AI projects.

Capability-based planning pauses before judging those proposals. It asks which capabilities are necessary to deliver the strategy: digital commerce, customer insight, personalization, product management, contact-center operations or something else. It then compares current and required maturity.

The heatmap that emerges is not a decorated project list. It is a picture of where the enterprise’s ability to execute its strategy is weakest.

The Open Group describes capability-based planning as supporting prioritization and investment decisions while improving alignment between programs and strategic outcomes. Its role-based guidance for business architecture explicitly connects capability perspectives with product, portfolio and program planning.

This is where top-down planning earns its place. It does not mean that senior executives invent every project. It means that the enterprise decides where change is needed before departments compete over how the money should be spent.

Do not simply select the five highest-scoring projects

Once the important capability gaps are visible, the organization still should not jump directly to ranking the existing proposals.

A significant gap may require pieces of several projects. Two proposed projects may address the same underlying need. A popular proposal may improve a capability that is healthy enough already. A less glamorous change in process, information or stewardship may be more important than another technology implementation.

The right answer may be five programs that reorganize the useful parts of 20 proposals.

That distinction is fundamental. A portfolio should not merely reward the five best-written requests. It should concentrate investment on the changes most likely to strengthen the capabilities required by strategy.

Research published by the Project Management Institute on strategic portfolio alignment describes portfolio management as selecting and continually steering projects according to predefined strategic targets. Strategic alignment is not a label applied once during intake. It must shape portfolio establishment and ongoing decisions.

Top-down planning therefore establishes the architecture of the portfolio: the outcomes sought, the capabilities involved, the gaps that matter and the programs needed to close them.

Then bottom-up knowledge improves the plan.

Bottom-up thinking still matters

Top-down planning has a deservedly poor reputation when it becomes detached from operational knowledge.

Executives do not see everything. Architects can misunderstand how work is performed. Capability assessments can contain stale assumptions. The people closest to customers, processes and systems frequently discover changes that central planning never anticipated.

Henry Mintzberg and James Waters placed deliberate and emergent strategy at opposite ends of a continuum. Their research argued that realized strategy is usually some combination of the two. Mintzberg later summarized the idea neatly: “strategies can form without being formulated.” The original argument is available in their paper, “Of Strategies, Deliberate and Emergent”.

Bottom-up insight must therefore be preserved—but insight is not the same thing as an automatically fundable project.

A proposal from within the organization is evidence. It may reveal an unrecognized weakness, opportunity, dependency or emerging strategy. The appropriate response is to test what the proposal teaches us, not to accept its framing without question.

This is where a Benefit Dependency Network becomes especially valuable.

Use a BDN to interrogate proposed work

A Benefit Dependency Network connects intended outcomes with the changes and enablers expected to produce them. Depending on the vocabulary being used, the network might connect strategies, objectives, benefits, programs, projects, systems and technologies.

In a bottom-up planning process, begin with a proposed project and trace backward:

• What business change will it enable?
• What measurable benefit should that change produce?
• What objective does the benefit support?
• Which strategy requires that objective?
• What other projects, systems or organizational changes are necessary?
• What happens if one of those dependencies is missing?

The Northern Ireland Department of Finance describes a benefits dependency network as a one-page cause-and-effect model showing how project outputs and new capabilities lead to business benefits. Its benefit-modelling guidance emphasizes documenting relationships among enablers, operational improvements and benefits.

This tracing process exposes several common portfolio problems.

Some projects have no credible path to a strategic outcome. Some depend on business changes nobody has funded. Some duplicate enablers already proposed elsewhere. Some provide infrastructure needed by several programs and should be treated as shared investments. Others reveal a legitimate need that the original capability assessment missed.

The BDN gives bottom-up proposals a fair hearing without permitting every proposal to declare itself strategic.

Use both models—but give them different jobs

Capability models and Benefit Dependency Networks should not compete for ownership of the planning process.

They answer different questions.

The capability model asks:

Where must the enterprise become stronger?

The BDN asks:

How will these proposed changes produce the intended result?

The capability model supplies breadth and prioritization. The BDN supplies causality and traceability. One identifies the terrain on which investment is needed; the other tests whether a particular route can cross it.

A disciplined planning cycle can therefore work as follows:

1. Clarify the small number of strategies leadership has actually chosen.
2. Identify the capabilities essential to those strategies.
3. Assess current and required maturity.
4. Select the gaps consequential enough to justify investment.
5. Shape those gaps into coherent program objectives.
6. Map bottom-up proposals and dependencies through a BDN.
7. Combine, revise, defer or reject proposals according to the resulting evidence.
8. Revisit the capability assessment when bottom-up knowledge exposes something new.

Useful EA’s Capability Modeler can make the first half of that reasoning visible through strategy relationships, maturity gaps, heatmaps and proposed programs. Its Benefit Dependency Network tool can then map the second half across objectives, programs, projects, systems and technologies.

The tools are not the point. The point is to stop confusing a collection of requests with a strategy.

Direction from the top, evidence from the bottom

The argument for top-down planning is not an argument for executive omniscience. Nor is it an argument against local initiative.

It is an argument about sequence and accountability.

Leadership must choose what the enterprise needs to accomplish that different from today. Architects must translate those goals into required capabilities and maturity gaps. People throughout the organization must contribute evidence, ideas and delivery knowledge. Proposed investments must demonstrate a credible path back to the outcomes the strategy requires.

Plan top-down. Learn bottom-up. Fund the work only when both views tell a coherent story.

The next time 137 project requests arrive for five available investments, do not begin by asking which five proposals should win.

Ask which capabilities the strategy requires, where those capabilities are weak and what coordinated changes would make the enterprise stronger.

That is a more difficult conversation than scoring projects.

It is also far more likely to produce a portfolio worth funding.