Portfolio Dependency Management: Stop Hidden Delays
The dashboard was green. Every workstream in a $60M transformation was on track and on budget, and the sponsor was confident. Then the data platform lead sent two lines on a Thursday afternoon. His team had pulled three engineers onto a regulatory fix, and the shared integration layer would land eight weeks late. By Monday, six workstreams that needed that layer were stuck. Not one of them had it on a risk register. The program lost two quarters, and the post-mortem found the cause in one sentence. We tracked dependencies inside each project, and nobody owned the seams between them.
I was running that PMO. That program taught me something I now tell every PMO leader I work with. Dependencies are not a project artifact. They are a portfolio asset, and the PMO is the only function positioned to own them. Your project managers see their own plan. They cannot see the platform team that serves six programs, or the vendor contract that gates four of them. Only the PMO sits high enough to see the whole web. If you do not own that view, no one does.
Why do cross-program dependencies stay hidden until they hurt?
Because each program logs them locally and optimistically. A program manager records the dates inside their own plan, assumes the other side is on track, and moves on. The dependency that crosses two programs belongs to neither schedule and shows up in neither status report. It lives in the gap, and the gap is exactly where no one is looking. By the time a green program turns red, the dependency that caused it has usually been drifting for weeks.
The fix is not more reporting. It is a portfolio-level discipline that treats the seams between programs as objects you deliberately manage. Here are the five disciplines I use on every engagement.
1. Map dependencies at the portfolio level, not inside each plan
Most PMOs store dependencies inside individual project schedules. That is where they go to hide. Build one portfolio dependency register that sits above every program, with one row for every link between programs. The test is simple. If a date in Program A moves, can you name, in 10 seconds, every program that feels it? If you cannot, you do not have a portfolio view. You have a stack of project views stapled together.
2. Give every dependency one named owner and one committed date
The $60M slip happened because the integration layer belonged to everyone and therefore to no one. Six program managers each assumed another was watching it. Every dependency needs a single accountable name, a person and not a team, and a single committed date, not a range. A dependency with two owners has zero. A dependency with a date range will always slip to the late end. Put the name and the date in the register and review them out loud.
3. Score dependencies by blast radius, not by project
Your risk scoring probably ranks risks inside each project. A dependency that gates one workstream and one that gates six should never carry the same weight. Score each by how many programs and how much budget sit downstream of it. I have watched teams pour attention into a high-visibility $2M risk while a low-visibility integration dependency holding up $30M of downstream work sat with a green dot. Rank by blast radius and your attention follows the money instead of the noise.
4. Run a dependency review on a fixed cadence, separate from status
Status meetings report the past. Dependency reviews protect the future, and they get crowded out when you bolt them onto status. Run a 30-minute portfolio dependency review every two weeks with the program managers in one room. One agenda. What changed, what is at risk, what needs a decision today. The first time I ran this with a client we surfaced nine cross-program dependencies in 40 minutes. Four were already late and no status report had flagged a single one.
5. Make the dependency view live, not a monthly snapshot
A register that updates once a month is a museum piece. By the time you read it, the dates have moved. This is where the right tooling earns its keep. In Smartsheet I build one portfolio dependency register with cross-sheet references back to each program plan, so when a predecessor date moves in a program schedule, the portfolio register reflects it the same day. Automated alerts fire to the named dependency owner the moment a linked date slips. An executive dashboard gives the portfolio steering committee one dependency heat map across the portfolio. The discipline is yours. The tool keeps it current between reviews, and clients who run it see a measurable lift in portfolio visibility, often around 50%.
Your one action for next week
Pull your top five programs into one room for an hour. Ask each program manager two questions. What are you waiting on from another program, and what is another program waiting on from you. Write every answer in one shared register with a name and a date against it. You will find at least three dependencies nobody was tracking. That single hour buys you more delivery certainty than another month of status reports.
If you want help building a portfolio dependency view that holds up under pressure, that is the kind of work we do in the PMO Value Blueprint, our focused three to eight week Assess engagement. Book a 30-minute conversation at calendly.com/pmoevolution. No sales pitch, just a working conversation about where your portfolio is leaking time.
On July 22, I'm going live on LinkedIn to walk through what's new and what it means for how a PMO runs day to day.
We'll cover:
ā˛¤ Smart Assist, the conversational AI now built into Smartsheet that summarizes a project, runs a risk health check, and takes action in chat.
ā˛¤ Smart Columns, which process every row automatically to summarize, translate, and read sentiment at scale.
ā˛¤ Dashboard Builder, where you describe the view you need, and AI assembles it.
ā˛¤ And the connection to Claude through MCP, so you can question your live portfolio in plain language without exports or copy-paste.
Bring your questions. I'll be answering them live.
I hope to see you there!
