Most cross-functional programs identify their dependencies during planning, mapping which workstreams depend on others for inputs, deliverables, or resources. But acknowledging dependencies is not the same as managing them. A dependency list tells the team what connections exist; it doesn’t specify what happens at each connection point: what gets handed off, in what format, by when, and what “done” means for the sender and “ready to receive” means for the receiver. Handoff Contracts close this gap by defining the terms of each exchange with enough specificity that both workstreams can plan, execute, and verify the handoff without assumptions.
What a Dependency List Captures (and What It Cannot)
A Dependency Diagram captures: Workstream A depends on Workstream B for a deliverable. The list may include timing (when the dependency must be fulfilled) and consequence (what happens if it’s missed). This is useful for program-level visibility; the program manager can see the network of connections and identify the dependencies on the critical path. The dependency list doesn’t capture: what exactly Workstream B will deliver to Workstream A, in what format, at what level of completeness, and how Workstream A will verify that what it received matches what it expected. This missing layer is where integration failures originate. Both workstreams know the dependency exists. Neither has specified the terms. Each operates on assumptions about what the other will provide, and those assumptions diverge because each workstream interprets the dependency from its own perspective. The format assumption. Workstream B delivers data in a spreadsheet. Workstream A expected an API feed. The data is the same; the format is not. Workstream A can’t consume the deliverable without transformation work that wasn’t planned. The completeness assumption. Workstream B delivers a data set that’s 80% complete, expecting to fill in the remaining 20% in the next sprint. Workstream A expected the complete data set, begins work based on the 80%, and discovers the gaps only after building on top of them. Making the invisible visible describes why assumption divergence between workstreams is one of the most common sources of integration failure. The dependencies are visible; the assumptions about what happens at each dependency point are not.
What a Handoff Contract Contains
For each dependency that requires a deliverable to move from one workstream to another, the handoff contract specifies: The deliverable. What’s being handed off, described with enough specificity that both sides agree on what it is. “The data migration output” is insufficient. “The migrated customer records dataset, including fields X, Y, and Z, validated against the source system with a discrepancy rate below 2%” is specific enough to govern. Completion criteria. What “done” means for the sending workstream. The sending workstream isn’t finished until the deliverable meets these criteria. Completion criteria prevent the pattern where a workstream marks a deliverable as complete while the receiving workstream considers it incomplete. Acceptance criteria. What “ready to receive” means for the receiving workstream. The receiving workstream verifies the deliverable against these criteria before beginning its own work. Acceptance criteria prevent the pattern where a workstream begins work on a deliverable that doesn’t meet its requirements. Timing. When the handoff occurs, expressed as a specific date or as a dependency trigger (e.g., “within 3 business days of Workstream B completing Milestone X”). The timing should be agreed to by both workstreams and reflected in both workstreams’ plans. Escalation pathway. What happens if the handoff is late, incomplete, or doesn’t meet acceptance criteria. The escalation pathway specifies who’s notified, what the resolution process is, and what the fallback plan is if the handoff can’t be completed on time. The architecture nobody builds identifies handoff contracts as the most frequently skipped component of program architecture. Teams invest in governance models, decision routing, and workstream definitions but leave the actual points of exchange between workstreams unspecified.
How Unmanaged Handoffs Become Integration Failures
The distance between a dependency list and handoff contracts produces two categories of integration failure. The specification mismatch. The sending workstream delivers something different from what the receiving workstream expected. Both workstreams fulfilled their own plans; the mismatch exists because the plans were built on different assumptions about what “the deliverable” included. Resolution requires one or both workstreams to rework their deliverables after the fact. A related pattern is the quality gap: the sending workstream delivers something that meets its internal definition of complete but doesn’t meet the receiving workstream’s definition of ready to consume. The deliverable exists but can’t be used, and the receiving workstream must either accept a lower quality input or wait for the sending workstream to bring it up to the required standard. The timing collision. Both workstreams planned their schedules independently. The sending workstream’s delivery date doesn’t align with the receiving workstream’s need date. The gap may be days or weeks. The receiving workstream either waits (delaying its own milestones) or proceeds without the input (creating risk that rework will be needed when the input finally arrives). Programs that failed with good plans documents integration failures across both categories. In each case, the dependency was known; the handoff terms were not.
What “Complete” Looks Like
Handoff contracts are complete when they pass two tests:
- Both sides have reviewed the contract, and the contract is specific enough to verify. A handoff contract written by only one workstream reflects only one workstream’s assumptions. Both the sending and receiving workstreams must review and agree to the completion criteria, acceptance criteria, and timing. A person who wasn’t involved in writing the contract should be able to read it and determine whether the handoff has been successfully completed. If verification requires interpretation or judgment calls, the contract isn’t specific enough.
- The escalation pathway is realistic. The fallback plan for a missed or incomplete handoff is actionable. “Escalate to program leadership” is a routing instruction, not a plan. “Program leadership re-sequences the receiving workstream’s plan to accommodate a two-week delay while the sending workstream completes the deliverable” is an actionable fallback.
The governance problem nobody talks about explains how handoff contracts connect to governance. Your handoff points will either have contracts specific enough to prevent assumption divergence, or your team will discover the mismatches during integration, when the cost of resolution is highest.
Go Deeper: The Architecture Blueprint
This article covers one dimension of the Architecture Blueprint, the third of nine artifacts in the Planning & Roadmapping method. The Architecture Blueprint answers the board question: “How is this structured?” Explore the full Architecture Blueprint → Want us to build this with you? Book a consultation →
Keep Reading
New to the Architecture Blueprint? Start with the foundations:
Ready to benchmark your work against best-in-class? See what excellence looks like: