Recorded Is Not Committed: Why a Dependency Is Not Managed Until Someone Has Accepted It
By Steven Gabris
Executive Summary
Dependencies are unavoidable in complex project and program delivery. A project may rely on another team, vendor, platform, approval or decision before it can complete part of its own work, and the larger the program becomes, the more of these relationships need to be coordinated.
Where organisations get into trouble is in assuming that a dependency has been managed because it has been identified and recorded. A dependency can appear in Jira, a RAID log, an integrated plan or a planning board, with somebody’s name against it, while the supplying team has not actually committed to the work, accepted the date, prioritised it against competing demands or understood the consequences of delay.
My view is that a material dependency should not be regarded as under control until there is a credible commitment behind it. The dependent project remains accountable for managing the dependency, while the supplying team owns the commitment it has made. Both need to understand the deliverable, date, priority, capacity, consequence and current confidence in delivery, with a clear route for escalation when that confidence begins to fall.
For delivery leaders, the useful question is therefore not simply whether dependencies have been identified. It is whether the commitments behind them have genuinely been accepted and remain credible.
Recording a dependency does not secure the commitment
Most organisations I have worked with are reasonably good at identifying dependencies. They emerge during planning, appear in RAID discussions and are captured in delivery tools, particularly when teams are working across multiple platforms, projects or business areas.
The weakness tends to appear after the dependency has been identified. A team may acknowledge that another project needs an API, a data feed, a security approval or some other deliverable, and that acknowledgement is often enough for the dependent project to continue planning as though the commitment has been secured. In practice, the supplying team may still be balancing competing priorities, may not have confirmed capacity, or may have interpreted the required date very differently.
This is particularly common during quarterly or big-room planning. The process is useful because it exposes where teams depend on one another, but the presence of a line on a dependency board can create more confidence than the underlying agreement deserves. People leave the session knowing that the dependency exists, yet the more important questions about priority, timing and delivery confidence have not always been resolved.
For me, the distinction is between visibility and commitment. Recording the dependency gives the program visibility. Acceptance by the supplying party gives the dependent team something it can credibly plan against. That commitment is what needs to be managed.
Acknowledgement can look like acceptance until delivery gets close
I have seen this play out on programs where the dependency was never hidden or overlooked. Everyone knew it existed, but the two sides did not have the same understanding of what had been agreed.
On one program, a delivery team required a data team to create APIs to an upstream system. The dependency had been identified and acknowledged, but ownership, priority and timing had not been established strongly enough. The consuming project was planning around when those APIs would be required, while the data team had other competing demands and had not prioritised the work with the same level of commitment that the project was assuming.
As the project moved closer to the point where the APIs were required, the difference between acknowledgement and commitment became much clearer. The dependency began creating delivery issues and unnecessary escalation that could have been addressed earlier if both sides had been explicit about the required date, priority, capacity and consequences from the outset.
What interests me about examples like this is that the dependency register itself was not wrong.
The dependency had been recorded and the right teams knew about it. The weakness was in the management discipline behind the record, because one side was planning against a level of certainty that the other side had not actually provided.
This is why simply asking whether the dependency has an owner can be misleading. A name beside an item tells you who has been associated with it; it does not tell you whether that person or team has accepted a clear commitment.
Accountability stays with the dependent project
The other issue I see regularly is an assumption that once another team has been named as the supplier, accountability for the dependency has effectively moved to them.
If Project A requires something from Project B, Project B should clearly own the commitment to provide what has been agreed. However, Project A still carries the consequence if that commitment is missed, which means its Project Manager, Delivery Lead or Program Manager remains accountable for managing the dependency through to completion.
That accountability includes making the requirement clear, confirming that the supplying team has accepted it, understanding how the date affects the wider plan, maintaining visibility of current confidence and escalating early where the commitment begins to deteriorate. Project B, for its part, needs to manage the work it has accepted and be transparent when priority, capacity or timing changes.
I describe the relationship as follows: the dependent project manages the dependency, while the supplying team owns the commitment. This avoids the familiar situation where each side assumes the other is managing the exposure. The dependent team believes it has handed the item across, while the supplying team sees it as one of several pieces of work competing for attention. By the time the difference becomes obvious, the dependency may already be affecting testing, sequencing or another milestone.
Dates need context, not just a field in a plan
A date against a dependency can also create false certainty if the consequence behind it is not understood.
If a team says that something is required by 15 October, the supplying team should understand why that date matters. A delay might move integration testing, block another workstream, affect a vendor window, extend the use of specialist resources or move something on the critical path. The significance of the dependency comes from those consequences, not from the date field itself.
This becomes particularly important when the supplying team has several legitimate priorities. Without understanding what happens downstream, it may reasonably treat the requested date as flexible. The dependent project may be treating exactly the same date as a hard commitment because subsequent work has already been sequenced around it.
Good dependency management therefore requires more than an agreed due date. Both sides need a common understanding of the delivery consequence so that priority and escalation decisions can be made with the right information.
A practical test for accepted dependencies
For significant dependencies, I would expect a delivery leader to be able to establish the following:
Owner — someone on the supplying side has explicitly accepted responsibility for the commitment.
Deliverable — both sides have the same understanding of what will be provided.
Acceptance — there is clarity on how the dependent team will know the deliverable is complete and usable.
Date — the required date has been discussed and accepted rather than simply entered into a plan.
Priority — the supplying team understands where the work sits against its other commitments.
Capacity — there is reasonable confidence that the necessary people and capability will be available.
Consequence — both sides understand what happens to the dependent delivery if the commitment is late, incomplete or cannot be met.
Current confidence and escalation — the commitment is reviewed often enough to identify deterioration early, with a known point at which intervention or escalation is required.
The amount of governance should be proportionate to the consequence. A minor sequencing dependency within a team should not require the same treatment as a dependency capable of moving a program milestone or affecting a critical path. However, where the consequence is material, informal acknowledgement and a name in a system are not sufficient evidence that the dependency is secure.
The evidence itself can take different forms. It may sit in Jira, an integrated program plan, meeting minutes, planning actions or a governance decision. I am less concerned about which tool contains the record than whether the underlying commitment has actually been made and is being actively maintained.
Dependency management happens in the cadence, not the register
Once a dependency has been accepted, it still needs management. Significant dependencies should form part of the regular delivery cadence, particularly where dates, capacity or competing priorities can change.
Owners need to provide meaningful updates, and those updates need to be followed up when they are missing or vague. If a supplying team’s confidence falls, the dependent project should understand the implications early enough to make a decision rather than waiting until the dependency has already become an issue.
This is where the distinction between a management tool and management itself becomes important. Jira, RAID registers, integrated plans and dependency boards provide valuable visibility and traceability, but they do not create the conversations, challenge or intervention required to keep a commitment credible.
For Program Directors and PMO leaders, I would therefore move beyond asking whether all dependencies have been identified. I would want to know whether the material dependencies have been accepted, whether the commitments remain credible, and whether the program is responding early enough when confidence changes.
A dependency with an owner, date and green status may still be poorly managed if nobody has tested whether the supplying team remains able and willing to meet the commitment.
Final point
Complex delivery will always involve dependencies, and in large enterprises those dependencies increasingly cross project, platform, vendor and organisational boundaries. The aim should not be to remove them, but to reduce the uncertainty around them before that uncertainty starts affecting the delivery plan.
A dependency becomes manageable when the supplying party has made a clear commitment and the dependent project continues to manage the exposure created by relying on it. Both sides need to understand what is being delivered, when it is required, how important it is, whether capacity remains available and what happens if the commitment begins to move.
That is a much higher standard than simply recording the dependency, but it is also a far more realistic picture of what good program delivery requires. Recorded is not committed.
For material dependencies, acceptance is where the management starts.
About Steven Gabris
Steven Gabris is an enterprise delivery and transformation leader with experience across financial services, payments, government and consulting. Through Gabris Group, he advises organisations on delivery governance, operating models and practical execution.
His work focuses on strengthening delivery confidence, improving accountability across complex initiatives and applying AI where it can support better project, program and organisational decision-making.
Comments