Cross-Project Dependency Management: How GWR Tracks Gives and Gets at Scale

What Is Project Dependency Management?

Project dependency management is the practice of identifying, recording, and tracking deliverables, decisions, services, or inputs that one project, team, or organisation needs from another. It gives project managers and PMOs early warning of delays, a clear owner for every handoff, and a single source of truth for how projects across a portfolio actually connect.

In the rest of this guide, I want to walk you through why that matters at scale, what good dependency management actually looks like in practice, and how Great Western Railway (GWR)  built theirs from scratch using Wellingtone’s Accelerator+ and Power BI.

This guide focuses on managing dependencies across a whole portfolio, once they leave a single project plan. If you want the fundamentals first, including the four dependency types (finish-to-start, start-to-start, and so on) and a generic dependency log template, see our companion guide, How to Manage Project Dependencies: A Practical Guide.

Watch webinar recording with GWR

What Counts as a Project Dependency

A dependency is a deliverable, activity, decision, service, or input provided by another project, team, supplier, or organisation.

In my experience, most disagreements about dependency management come down to scope, not principle. That’s why I like to keep this definition deliberately broad, in two directions.

• It isn’t only a thing. A decision waiting on a board, or a service someone else operates, counts just as much as a physical deliverable.
• It isn’t only another project. Teams, suppliers, and entire external organisations sit inside the definition. If your register only tracks project-to-project deliverables, you are capturing perhaps half your real exposure.

For me, the defining characteristic is simple: you need it, and you don’t control it. Everything else in this guide exists to manage that gap.

We consider dependency management a bit of a dark art. We talk a lot about getting a helicopter view of the portfolio, but this is one of the practices that gets skipped over as project management matures.
Emma-Ruth Arnaz-Pemberton, Wellingtone

Dependencies vs Assumptions: What Is the Difference

I see this go wrong a lot: a dependency turns into a catch-all label for anything that might affect delivery. It shouldn’t. An assumption is something you’re accepting as true for planning purposes. A dependency is a specific deliverable, activity, decision, service or input that has to land at a particular point. Keeping that distinction clear is what keeps a register actionable, and it’s also where dependency and risk management overlap: an uncertain dependency might turn into a risk, but the dependency itself still needs an owner, an agreed date, and someone actively managing it.

Why Dependency Management Matters at 90+ Projects

George’s team manages more than 40 project managers, over 90 projects, and at least 15 external or interface projects affecting day-to-day operations. At that scale, dependencies aren’t exceptions to deal with as they crop up, they’re the connective tissue holding the portfolio together. The external interfaces carry the sharpest risk: 15-plus projects sitting outside your governance with the power to disrupt how the business runs. You can’t direct them. You can only see them coming, or not.

GWR set out to do three things: create visibility, so surprises become forecasts; build accountability, so every dependency has a named giver and receiver rather than a shared assumption nobody owns; and prevent conflict, so two projects don’t quietly plan around two different versions of the same date.

That’s ultimately about understanding your wider delivery ecosystem, not just the client receiving your work, but every project, service, supplier or organisation that depends on it. Taking that broader view is what exposes downstream impacts before a date moves or a deliverable changes underneath you.

A director asked me a really good question: where do I see all of this stuff? How is it being mapped out? Can I see it on a map? The answer, at the time, was no, we don’t know.
George Hart, Head of PMO – Great Western Railway

The Common Starting Point: No Framework, No Visibility, No Governance

Dependency management existed, but there was no organisation-wide framework, visibility or governance.

Honestly, that’s the situation most organisations are actually in, and I think it’s worth naming precisely, because it changes what you do about it. The problem isn’t that people were ignoring dependencies. Experienced project managers track them instinctively, they always have. The problem is that the tracking stayed local. Every project held its own picture, in its own format, with its own idea of what counted and who owned it. Nothing rolled up. Nothing could be challenged. Nobody could see the pattern across ninety projects, so nobody could act on it.

Once you diagnose the gap as framework, visibility and governance, rather than effort, you stop reaching for another round of asking people to be more rigorous, and start building a shared register with shared rules instead. That’s the shift that actually moves the needle.

What Good Dependency Management Looks Like in Practice

I like that GWR didn’t define the destination as a system. They defined it as six things project managers should routinely do.

• Identify dependencies during planning, not after they slip.
• Link dependency deliverables to schedules.
• Review dependencies frequently.
• Update forecasts as soon as dates change.
• Escalate critical dependencies early.
• Ensure schedule changes follow formal change control.

This, for me, is the most portable idea in the whole approach. You can deliver a tool in a quarter. Those six behaviours are the actual capability, and they take a lot longer to embed. Identifying dependencies during planning, rather than at the first sign of slippage, is what makes the whole discipline preventative rather than reactive. Linking them to schedules is what stops the register drifting off into its own parallel universe. And change control on date moves is what makes an agreed date actually mean something.

The PMO doesn’t sit in a dark room and work out how this should work. We worked with people in the project space across the business, project managers, heads of delivery, and some exec members, to build this together.
george hart, gwr

Moving From Reactive to Trusted: What It Actually Takes

George summed the whole shift up as moving from reactive dependency management to a proactive, embedded and trusted capability. And when I asked what actually made that happen, the answer came down to a few words: communication and education.

Embedded means the discipline lives inside your normal delivery routines, not bolted on alongside them. Trusted means people actually have enough confidence in the data to make decisions from it. That’s the point where a dependency register stops feeling like admin and starts being genuinely useful. Technology can support that shift, but it won’t create it on its own. Communication, education and consistent use are what do that.

Apart from a carrier pigeon, we used every form of communication and education we had: user guides, one-to-one sessions, drop-in sessions, and tutorial videos.
George Hart, Head of PMO – GWR

GWR’s Five-Phase Journey

GWR built this over roughly a year, in five phases, moving from an initial assessment right through to the ongoing improvement cycle it still runs today.

The Four Pillars of Mature Dependency Management

GWR describe dependency management now as a recognised discipline that supports proactive decision-making and delivery confidence. It rests on four components, and I’d stress they only work if you build them together. A register without governance goes stale within a quarter. Governance without reporting never reaches the people who can actually unblock things.

The bit I always point people to is tucked inside the governance pillar: dedicated resource. This isn’t a capability you can run in the margins of someone’s other job.

How to Agree Ownership Between Giver and Receiver

In practice, it’s usually the receiving project that spots the dependency first, because they’re the ones feeling the need. But the giving project or team is the one responsible for producing it. So ownership can’t just be resolved with a label. The giver and receiver need an actual conversation: what’s being provided, when, to what quality, how progress gets communicated, and what happens if confidence changes. Get that handshake written into both plans and you create shared accountability, without muddling responsibility for delivering it with responsibility for monitoring the impact.

What Data Every Dependency Record Needs

A dependency record is only useful if it answers one question for me: who owes what to whom, by when, and how confident are we, really?

Two of these fields do a disproportionate amount of work, in my view. The threshold turns a binary on-track-or-late judgement into an agreed tolerance, so escalation only fires when the movement genuinely matters. And the next update date, agreed the moment the dependency is logged, turns chasing into a scheduled commitment rather than a nagging email. Automated notifications to the receiver, plus reminders as things change, keep the record alive without anyone having to police it.

It’s also worth being clear whether a dependency relates to a whole project outcome or just one component, task or decision. That distinction matters more than people expect when you’re agreeing dates and tolerances: a project can stay on schedule overall while one critical component another team needs slips past an acceptable threshold.

And where a dependency looks uncertain or threatened, I’d always record the mitigation actions alongside it, assigned and reviewed, not off in a separate document. That way mitigation stays connected to the dependency it’s protecting, and you can actually confirm whether agreed actions got done and whether they moved delivery confidence in the right direction.

Making the Register Easy to Use and Hard to Ignore

Input runs through Microsoft Accelerator+, so people are capturing dependencies where they already work, rather than in some separate system. Output is where the credibility gets earned, in my opinion: reporting drills all the way down from business level to delivery group to individual project, in both chart and table views, with separate give and receive perspectives. When a giver can see their own commitments and a receiver can see what’s coming in, data entry stops being a chore and starts being something people actually check because it helps them.

If things change, the system is clever enough to pick it up and notify the people who are affected.
George Hart, Head of PMO – GWR

What’s Next: An Integrated Change Register

The natural next step, and George touched on this too, is an integrated change register giving a single view of change across the whole network, covering both supplier and customer. That’s the natural maturity curve: once you trust your internal dependencies, the external interfaces are where the surprises are still hiding.

We are soon to merge with Network Rail, who manage all the track. We need one integrated change register with a map, so you can search a location and date range and see everything happening there. It gives us a bigger picture than we can provide today.
George Hart, GWR

Keeping the Process Proportionate for Project Managers

The concern I hear most often is the extra effort this asks of project managers, especially the ones juggling delivery alongside another role. I don’t think the answer is to water down the discipline. It’s to keep the process proportionate: capture only what actually supports a decision, connect it to plans and reviews you already run, automate reminders wherever you can, and save governance attention for the dependencies that are critical or getting worse.

And the benefit to individual project managers has to be visible too, otherwise why would they bother. A process that’s actually useful gives them:

• Earlier warning of changes
• Fewer repeated chasing conversations
• Clarity on who is expected to act
• Evidence to support escalation when it’s needed

If all people feel is extra admin, engagement drops off fast. But if they can see the process is protecting their delivery dates and giving them a stronger hand in conversations with sponsors, keeping people engaged gets a lot easier.

When to Start Identifying Dependencies

I’d always start identifying dependencies at project inception, through proper structured conversations about required inputs, outputs, decisions, suppliers, interfaces and affected teams. But it shouldn’t stop there. New dependencies keep surfacing as plans get more detailed and the environment shifts, so identification needs to stay part of planning, review and change control for the life of the project.

How to Measure Whether Dependency Management Is Working

I’d judge whether this is working by outcomes, not by how many records exist in the system. The measures I’d actually look at are:

• The proportion of dependencies with agreed giver and receiver ownership
• The percentage linked to delivery plans
• The timeliness of updates
• The number escalated before they affect milestones
• The age of overdue mitigation actions
• Trends in late or conflicting handoffs

And I’d always sense-check that against qualitative feedback from project managers themselves: is this actually reducing surprises, and is it helping them make better decisions?

Key Takeaways

If you take nothing else away from this, here’s what I’d want you to remember:

• Define dependencies broadly. Include decisions, services, and suppliers, not just deliverables between projects.
• Justify the work with scale, not principle. The numbers make the argument on their own.
• Diagnose the gap correctly. It’s usually framework, visibility and governance that are missing, not effort.
• Express success as behaviours. Identify, link, review, update, escalate, and follow change control.
• Invest in communication and education. This is what moves a register from reactive to trusted.
• Stand up system, process, governance and reporting together. With real, dedicated resource behind them.
• Capture thresholds and update dates. So escalation is driven by data rather than instinct.

Getting Started: Your Next Steps

My advice? Start with one delivery group, or a portfolio area you can actually get your arms around. Agree a common definition, map your most important gives and gets, set up the giver-receiver handshake, and connect critical dependency dates to your project plans. Review it regularly, check whether it’s actually reducing surprises, and refine before you try to scale it any further.

Technology like Accelerator+ and Power BI can give you the shared register, automation and reporting to sustain this. And investing in your people, through relevant APM qualifications, reinforces the planning, governance, risk and stakeholder skills that make dependency management actually work in practice, rather than just on paper.

How Technology Supports Dependency Management

Technology isn’t the capability itself, its job is to make the framework, behaviours and governance you’ve already agreed easier to apply consistently. Used well, it’s what moves dependency management from local tracking and reactive chasing into an embedded, portfolio-wide discipline. Used badly, it’s just a shared spreadsheet with extra steps.

At GWR, three things do the heavy lifting:

• A central dependency record. Accelerator+ brings status, giver, receiver, type, event date and RAG status into one shared view, so teams can see what they owe, what they’re waiting on, and where a change might create conflict elsewhere in the portfolio.
• A live link to the plan. Accelerator+ takes dependencies down to task-to-task relationships, pulling planned start and finish dates for the giving and receiving tasks directly from Microsoft Planner Premium to inform RAG status. That keeps the register aligned with the real schedule instead of drifting into a separate administrative record, so when a date changes, you see the impact in context.
• Reporting people can act on. Power BI turns that data into views for every level, from portfolio-wide exposure down to the specific gives, gets and delivery confidence ratings that need attention, while project teams keep a practical view of their own commitments.

This is where the four pillars meet: Accelerator+ handles the system and process, governance decides how information gets reviewed and acted on, and Power BI gives you the reporting to challenge and decide. None of it replaces clear ownership, regular review or communication, but it removes the effort of maintaining visibility by hand.

Frequently Asked Questions