Campaign operations workshop / 5 MIN READ
Make the campaign dependency a two-way agreement
Specify what another team must provide and what your campaign owes in return.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-06
A dependency is not resolved because another team’s name appears in a plan. Both sides need to agree on the required output, the conditions for using it and the consequence if it changes.
What you will leave with: A dependency register with acceptance conditions, counterpart owners and escalation signals.
Use this when
- Campaign work relies on product, support, venues or partners.
- Dates slip because teams disagree about what was promised.
This is not an instruction to impose deadlines on teams that have not accepted the work.
Name the exchange rather than the department
Atlassian’s dependency guidance names affected systems, risks and owners. Make the campaign application concrete by describing the actual exchange between teams.
Write what your team needs, what the other team needs from you and why the timing matters. “Need product” is not useful; “need the approved service eligibility list before writing regional invitations” is. Identify whether the dependency is information, access, a decision, a resource or completed work. Different types need different acceptance checks, and an informal conversation may not settle all of them.
Confirm both sides understand done
Describe the minimum output that makes the next task possible. Include the relevant scope, format, approver and any restrictions on use. Ask the counterpart to confirm or correct the description rather than treating your plan as their commitment.
Discuss partial delivery honestly. A draft eligibility list may help prepare a layout but cannot authorize a public claim. Mark what can proceed provisionally and what must wait for approval. Avoid hiding a dependency by starting irreversible work on an assumption. If the other team cannot provide the requested output, identify the actual constraint and decide whether to change scope or sequence.
Make changes visible before they spread
Agree how the counterpart will report a material change and who receives it. A date shift, policy revision or product limitation can affect several downstream tasks. List those affected outputs so the team can assess the consequence quickly rather than rediscovering the chain during a crisis.
Choose review points around the decisions that depend on the output. Do not create meetings just to ask whether people are still working. Ask for the evidence needed to confirm readiness, or an early statement that the assumption no longer holds. Make escalation about the decision at risk, not about publicly blaming the supplying team.
Close the dependency with an acceptance check
When the output arrives, verify that it meets the agreed conditions and is approved for the intended use. The receiving team owns this check; a file upload alone does not prove the dependency is complete. Record any exceptions and decide whether they block downstream work.
If the campaign changes, notify the counterpart about obligations that are no longer needed. Close unused requests rather than leaving people working on stale requirements. Preserve a short record of the agreement and its outcome. The register should be a practical coordination tool, not a permanent list of every interaction between departments.
Make the reasoning concrete.
A fictional training campaign depends on a partner confirming which regional offices can host demonstrations. The campaign team starts invitations using a tentative list.
Treat the draft as delivery
Opening: Proceed because the partner has sent a spreadsheet.
Hypothesis: Design and scheduling can move ahead.
Risk: Tentative locations may be advertised as confirmed venues.
Separate provisional from approved
Opening: Use the draft for planning but block invitations until the agreed venue confirmation arrives.
Hypothesis: The team preserves useful preparation without overstating readiness.
Risk: Some public activity may need to wait or narrow its scope.
The two owners agree which fields establish venue readiness and when changes must be reported. Invitations are released only for confirmed locations, with remaining regions kept out of scope.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
Exchange
What does each team need to provide?
Acceptance
What makes the output usable and approved?
Provisional use
What can proceed on a draft and what must wait?
Change signal
How will a material change reach affected owners?
Closure
Who verifies completion or cancels an unused request?
Watch for the wrong conclusion.
- Listing a department instead of an accountable counterpart.
- Treating a draft as permission for public use.
- Accepting delivery without checking downstream usability.
Your next action
Choose one external dependency and ask the counterpart to confirm the output, acceptance condition and change-notification route.
Sources & scope
The workflow, worksheets and hypothetical examples are original editorial analysis. Sources support only the identified principles. No measured business results or named human reviewer are claimed.
- Atlassian Team Playbook: Dependency Mapping →Primary framework-publisher guidance · Supports: Dependency mapping names affected systems, risks and responsible owners; the campaign handoff sheet is original editorial analysis.