Make a dependency explicit before it becomes a surprise
A working agreement between a team that needs something and the team that provides it
A dependency agreement is a short, shared record of one handoff between two teams. It is not a project timeline. It answers four questions: what is needed, what must be true for it to count as delivered, who owns each commitment, and when to raise it with both team leads.
The example on this page is fictional. Northstar Analytics is building a reporting prototype and depends on the Data Platform team for a validated sample dataset. Every section below shows how that one agreement is written.
What a complete agreement contains
A static summary of the essentials. These are reference points for writing the agreement, not checkboxes, a certification or a sign-off.
- A defined deliverable: what is handed over, in what form, and where it will be found
- Acceptance conditions the requesting team can verify when it receives the deliverable
- Role-based ownership: who requests, who supplies, and who records changes
- An agreed escalation trigger that names the point at which both team leads are brought in
What is needed, and the conditions for delivery
A request is testable when someone other than the author can say whether it has been met.
"Send the data when it's ready." Neither team can tell when the handoff has happened or whether it is usable.
- No named fields, so the supplier guesses what is meant
- No delivery location, so the requester has to chase
- No acceptance test, so problems appear after the prototype is built
"Data Platform provides a sample dataset with the agreed fields, in the shared project workspace, after both teams confirm the field definitions."
- Fields are listed by name and meaning before work starts
- The delivery location is the shared project workspace
- Northstar Analytics checks that the agreed fields are present and that the field definitions match before accepting
Worked example: the completed agreement
Fictional sample for the Northstar Analytics reporting prototype. Dates are left relative so the sample does not imply a real schedule.
| Commitment | What it says | Owner role |
|---|---|---|
| Deliverable | Validated sample dataset with the 12 agreed fields, delivered as one file | Supplying-team lead |
| Delivery condition | Both teams have confirmed the field definitions in writing before extraction starts | Both team leads |
| Delivery point | Shared project workspace, in the folder named for the prototype | Supplying-team lead |
| Acceptance | Requesting team checks fields and definitions against the agreed list and replies accepted or not accepted | Requesting-team lead |
| Change record | Any change to fields, format or delivery point is written into the agreement with its impact | Project coordinator |
| Review | Both leads look at the agreement at each weekly project sync until delivery is accepted | Project coordinator |
Escalation triggers and the next handoff
Raise it with both team leads together, early, and in writing
An escalation is a prompt to decide, not an accusation. Agree the triggers when the agreement is written, so nobody has to decide in the moment whether a problem is big enough to mention.
Raise the dependency when any of these happens
- The delivery condition cannot be met, for example the field definitions are still unconfirmed on the day extraction was due to start.
- The required scope changes, for example the requesting team adds fields that were not in the agreement.
- The delivery point is at risk, for example the shared workspace folder is moved or access is withdrawn.
Example
Midway through the work, Data Platform finds that the "customer segment" field is defined differently in two source systems. That is a field definition changing after agreement. The supplying-team lead tells both leads the same day, work on that field pauses, and the project coordinator records the options and their impact on the prototype. The requesting team decides whether to accept the revised definition, change the request or move the delivery point. The request is never changed silently.
Who does what
- Whoever notices the trigger posts it to both team leads in the project channel.
- The project coordinator convenes the discussion and records the decision in the agreement.
- The team leads decide the change and update their own plans.
If a decision needs more authority than the two leads hold, the project coordinator takes it to whoever sponsors the project, as set out in your project's governance.