A launch can look healthy inside every team's task list and still be impossible to deliver. Engineering is waiting for approved copy, marketing is waiting for a working demo, and support does not know which behavior the demo will show. Each team sees its own work; nobody sees the handoffs.
A dependency mapping workshop brings those handoffs onto one board. The output is an agreement about what one team needs from another, when it is needed, and what happens if it is unavailable.
What a dependency map should show
A dependency exists when work cannot proceed as planned without an input, decision, capability, or resource from elsewhere. A designer needing approved product claims is a dependency. Two designers attending the same meeting is not necessarily one.
Atlassian's dependency mapping play considers affected systems, risks, ownership, and ongoing coordination. For a cross-team launch, turn that broad view into explicit handoff agreements. Include upstream inputs your team consumes and downstream work that depends on your output.
A timeline answers when activities are scheduled. A RACI matrix clarifies participation and decision responsibility. The dependency map answers a different question: what must be available before this work can advance? You may need all three, but they should not repeat one another.
Prepare a workshop around one outcome
Choose a boundary such as “release the new customer onboarding experience,” not “map the whole company.” Write the intended release date and the parts explicitly outside scope at the top of the board. If the date is tentative, label it tentative. Otherwise participants may optimize around a commitment nobody actually made.
Invite people who can confirm the handoffs: a representative from each delivering or receiving team, plus the person who can resolve scope and timing conflicts. Ask them to bring real constraints—review queues, planned leave, environment access, and vendor lead times. A meeting consisting only of project coordinators may produce an attractive map of unconfirmed promises.
Before the session, draw one horizontal lane per team. Place the final outcome on the right. Reserve a separate area for unresolved questions so an argument about one date does not stop the entire exercise.
Map backward from the outcome
Start with the receiving team. Ask, “What must you have in hand to complete this?” Continue upstream until the next requirement is either within that team's control or outside the workshop boundary. Working backward makes missing prerequisites easier to notice than brainstorming every task from memory.
Write deliverable cards with verbs and concrete nouns: “approve onboarding claims,” “publish test endpoint,” or “confirm escalation route.” Connect the supplying card to the receiving card. Put a short label on each arrow: “approved copy,” “test credentials,” or “signed-off policy.” Define the arrow direction in a small legend and use it consistently.
Not every arrow means the same thing. Mark hard prerequisites separately from work that can begin with a provisional input. A draft screenshot may let a writer start a guide, while final screenshots are required before publication. Showing that distinction creates options without pretending the dependency has disappeared.
Worked example: launching a self-service trial
Consider a hypothetical software team preparing a self-service trial. Product owns the offer, engineering implements access, marketing publishes the signup page, and support prepares for customer questions. The first map contains a circular argument: marketing wants screenshots of the completed trial, while engineering wants the final page wording before finishing the trial rules.
The team separates the offer decision from visual assets. Product can approve the rules first; marketing can draft the page with placeholders; engineering can deliver a test environment before production release. The map now shows smaller, verifiable handoffs.
| Handoff | Supplier → receiver | Acceptance condition | If it slips |
|---|---|---|---|
| Trial rules | Product → engineering and marketing | Duration, access restrictions, and end-of-trial behavior approved | Escalate scope decision before implementation continues |
| Test environment | Engineering → marketing and support | Named test account can complete signup and cancellation | Continue text drafts; hold final screenshots and training |
| Customer-facing explanation | Marketing → support | Published wording matches implemented rules | Use reviewed draft internally; do not distribute obsolete copy |
| Escalation route | Support → launch owner | Contact and coverage agreed for launch day | Reduce rollout scope or move launch decision |
The dates for these handoffs should come from the people doing and receiving the work. The workshop cannot create capacity by drawing an earlier deadline.
Turn important arrows into agreements
For every handoff that could affect the outcome, record a supplying owner, a receiving owner, the needed-by date, the expected delivery date, and the acceptance condition. Keep the two dates separate. Their difference exposes a conflict that a single “due date” can hide.
Have the receiving owner restate what will count as usable. “API ready” could mean a published specification to one person and stable production access to another. A useful agreement might instead say, “The test endpoint returns the agreed example payload, and the integration team can authenticate.”
When dates conflict, consider a smaller input, a mock, a sequence change, or a scope reduction before simply escalating pressure. Record consequential tradeoffs in a decision log. The dependency board can link to the decision without becoming a second meeting transcript.
Find the dependencies that deserve attention
Look for one supplier feeding many receivers, a long chain with no timing margin, a handoff nobody accepts, and an external dependency whose date is only an assumption. Also inspect cycles: sometimes they reveal iterative collaboration, but sometimes neither side knows who must act first.
Do not label every dependency critical. Explain the consequence beside the risky arrow: “Training cannot start,” “Security review must restart,” or “Launch can proceed without this report.” Those statements are more useful than a wall of red cards. A map alone does not calculate a project's critical path; that requires durations and scheduling logic.
Keep the map useful after the meeting
In Boardmix, arrange the trial example in four lanes: Product, Engineering, Marketing, and Support. Use shapes for deliverables and labeled connectors for handoffs. Connect approved trial rules to the test environment and signup-page copy, then connect the test environment to screenshots and support rehearsal. Add the supplying owner, receiving owner, and acceptance condition beside each important arrow. Open Boardmix to build the map, and link the work items your team already maintains.
Review the map when an input changes, a delivery date moves, or a receiver rejects a handoff—not only at a scheduled status meeting. Ask affected receivers what the change does to their work. Update the project plan when the answer changes the sequence or scope. A completed arrow should mean the receiver has what it needs, not merely that the supplier has sent something.
