Step 10

Govern Dependencies, Capacity, and Tradeoffs

In Brief — Individual project health does not add up to portfolio health. This step examines the portfolio as a system — tracking dependencies across projects, capacity across teams, and change saturation across the organization simultaneously. The problems that sink delivery programs rarely originate inside a single project. They originate in the space between projects, where nobody was looking.

What’s Actually Happening

Three projects are competing for the same two architects. Nobody knows this because each project team sees only their own resource allocation.

One project is waiting on a system integration that another project was supposed to complete six weeks ago. The integration project is running late for reasons that were visible in its RAID log two months before the missed date. Nobody who could have intervened was looking across both projects at the same time.

The business analyst who is the only person in the organization who understands both the source and target system for a critical data migration is being pulled in four directions simultaneously. Each project manager knows this person is stretched. None of them knows what the other three projects are asking of them.

The organization approves new work regularly. It has no view of what the approval does to the system of work already in motion. Individual projects are managed. The portfolio is not.

This is the difference between project governance and portfolio governance. Project governance asks: is this project on track? Portfolio governance asks: what is happening across all of it, and what does the combination add up to for the organization?

Why This Step Exists

Because the portfolio is a system, not a collection of independent projects.

When work is managed only at the project level, the interactions between projects are invisible. Dependencies that cross project boundaries are nobody’s job to track. Shared resources are managed by whoever asks for them most recently or most loudly. The cumulative load of change being placed on the organization — on its people, its systems, its management capacity — is never seen as a whole because no individual project team has visibility to the whole.

The results are predictable and consistent across every organization that manages projects without portfolio governance. Shared resources become bottlenecks that nobody planned. Critical dependencies surface through missed dates rather than through active management. The organization approves an amount of work that looks manageable in a budget spreadsheet and is not executable with the actual humans available to do it.

Portfolio governance is the discipline that changes that. Not by adding more oversight to individual projects, but by adding a view that no individual project can produce: the view across all of them simultaneously.

What Good Looks Like

The governance forum has, in every session, a portfolio-level view that is separate from and complementary to the project-level status reviews.

The portfolio view shows: what work is in flight, what the dependency map looks like across projects, what the capacity utilization looks like for the critical shared roles and teams, what the change saturation level looks like for the parts of the organization being asked to absorb the most change, and what the tradeoffs are if a new approval or a scope change is added to the current portfolio.

When a new project is being considered for authorization, the capacity view is updated before the authorization decision is made. The governance forum sees the effect of the new commitment on the existing portfolio before it approves it, not after.

When a project misses a milestone or requests additional resources, the portfolio view shows whether that event creates cascading effects on other projects. The governance forum can make an informed decision about whether to absorb the impact, adjust the affected projects, or escalate the tradeoff to leadership.

The organization stops discovering conflicts after they become crises. It starts seeing them while there is still room to act.

How to Do It

Build a dependency map for the active portfolio. Not a list of project dependencies — a map that shows where dependencies cross project boundaries. For each cross-project dependency, name: what is needed, which project needs it, which project is responsible for producing it, and when. This map is updated at each governance cycle.

Build a capacity view for the critical shared roles and teams. Not a project-level resource plan — a portfolio-level view of demand against supply for the resources the portfolio depends on most heavily. This does not require a sophisticated resource management system. It requires a rough-cut view: across all active and authorized projects, what are we asking of our architects, our senior business analysts, our key operational SMEs? Compare that to what is actually available. The gap is the portfolio’s hidden risk register.

Build a change saturation view for the parts of the organization being asked to change. Different business units are absorbing different amounts of change from different projects simultaneously. When multiple projects are targeting the same team, department, or user population, the cumulative load may exceed what that group can absorb and sustain. The saturation view makes that visible before projects are launched, not after adoption fails.

Bring these three views — dependency map, capacity view, saturation view — to the governance forum alongside individual project status. The conversation shifts from “how is each project doing?” to “how is the portfolio performing as a system and what adjustments do we need to make?”

What Breaks When You Skip It

Conflicts are managed as crises rather than as foreseeable events.

Two projects discover their shared dependency two weeks before the date it was needed. A key resource is simultaneously required at full capacity by three projects. The operations team that was supposed to accept a new system at go-live is in the middle of two other transitions and is not ready. Each of these situations was visible weeks or months in advance in the individual project plans. None of them was visible across projects because nobody was looking across them.

The organization develops a pattern of firefighting that it mistakes for normal operations. Every quarter, there are surprises. Resources are reallocated urgently. Timelines shift. Executives make judgment calls about which project takes priority when two projects compete for the same people, made without the information needed to make those calls well.

The deeper cost is confidence. When leadership cannot predict what the portfolio will produce — because the portfolio is not actually managed as a portfolio — trust in the governance model erodes. Leaders stop believing that governance improves decisions and start managing through relationships again, because relationships at least produce some visibility into what is happening.

The Gotchas

Capacity management is treated as an HR or IT function. The portfolio’s capacity constraints are most often not about headcount — they are about specific skills, specific knowledge, and specific relationships that exist in a small number of people. A hiring plan that adds generic headcount does not solve the problem of having two systems that only one person in the organization fully understands. Capacity management at the portfolio level is about the specific constraints that the specific work requires. That view lives in the EPMO, not in HR.

The dependency map never gets updated. The map is built once during portfolio setup and then ignored as projects move and shift. Dependencies change as delivery progresses. New dependencies are created by scope changes. Others are resolved. The dependency map needs to be updated with the same regularity as the project status reports — which means someone owns that update as a standing responsibility.

Change saturation is treated as an OCM concern, not a portfolio concern. The portfolio governance forum approves new work based on budget and resource availability. The effect of the new work on the organization’s capacity to absorb change is someone else’s problem — usually OCM’s, usually too late. Change saturation needs to be a portfolio criterion at every governance session, not a problem discovered after adoption fails.

Portfolio tradeoffs require leadership authority. Resolving a conflict between two projects that need the same resource at the same time is not a decision the EPMO can make alone. The portfolio governance model needs to define who makes these tradeoff decisions and how quickly. A portfolio conflict that sits unresolved for two weeks while people figure out who has authority is a governance failure.

Where the Disciplines Show Up

→ Decision Discipline: Portfolio tradeoffs are decisions, not recommendations. The governance forum needs the authority to stop, defer, or redirect work — not just to flag that conflicts exist. When a dependency conflict, capacity constraint, or saturation risk is surfaced at the portfolio level, the forum must be able to act, not only to advise.

→ Change & Absorption: The saturation view is the primary OCM input to portfolio governance. When the organization is being asked to absorb more change than it can sustain, the governance forum needs to see that and act on it. Approving more work than the organization can absorb is a governance failure that produces adoption failures across multiple projects simultaneously.

→ Enterprise Fit: Cross-project dependencies often have architecture implications. Two projects building integrations to the same system using different approaches may be creating technical debt and future incompatibility that neither project team sees. The portfolio view is where those architecture-level conflicts become visible.

→ Evidence: The portfolio view is the evidence base for evaluating whether the governance model is improving organizational outcomes. Are conflicts being caught earlier? Is capacity being managed more effectively? Are tradeoffs being made explicitly rather than discovered as crises? Tracking these outcomes over time is how the EPMO demonstrates value to leadership and continuously improves the governance model.

→ Political: Portfolio tradeoffs directly affect stakeholder interests, and the stakeholders who lose in a tradeoff decision will look for alternatives to accepting it. When the governance forum defers one sponsor’s project to protect another’s resource needs, the deferred sponsor needs to understand why — before the decision is announced publicly. Political discipline means consequential tradeoff decisions are pre-socialized with the affected parties before the forum convenes to confirm them. The meeting where the tradeoff is formally decided should not be the first place the losing sponsor hears about it.

The Key
Portfolio governance begins when leaders can see what one decision does to the rest of the system.

Not what one project is doing. What adding, changing, or stopping one project does to every other project, to every shared resource, and to the organizational capacity being asked to absorb all of it simultaneously.

You know this step is working when the word “capacity” appears in every approval conversation — not as an afterthought, but as the first constraint checked. When a leader brings a new request to the governance forum and someone asks “what does this do to everything we already have in flight?” before discussing the merits of the new request, portfolio governance is operating as designed.

The Artifacts

T28 — Dependency Map

A visual and tabular record of all cross-project dependencies in the active portfolio. For each dependency: what it is, which project is the producer, which project is the consumer, the required delivery date, the current status, and the risk level if it slips. Updated at every governance cycle.

T29 — Capacity View

A portfolio-level demand-versus-supply snapshot for the critical shared roles and teams the portfolio depends on. Not a full resource management plan — a decision support tool that shows where demand exceeds supply and which projects are creating the conflict. Updated at each governance cycle and before each new authorization decision.

T30 — Portfolio Tradeoff Summary

A one-page document that captures the portfolio-level decisions made in each governance cycle: what was adjusted, what was deferred, what resource conflicts were resolved and how, and what tradeoffs were escalated to executive leadership. This document builds the institutional memory of how the organization makes portfolio decisions over time.