Strategy deployment is usually drawn as a tree: top to bottom. The connections that most often break run sideways, between functions whose targets depend on each other. A tree has no place to put them.
In this guide
Key Takeaways
- →A goal tree puts each objective under its parent, so dependencies between branches have nowhere to live.
- →Four kinds: input, capacity, sequence and shared result.
- →Ask during target negotiation what this target depends on that the owner doesn’t control.
- →Bring the other function in, record both sides, and show the dependency on both objectives.
- →A corrective action that commits another team’s work needs that team’s agreement.
- →A dependency nobody agreed to is a risk nobody owns.
Why the tree hides dependencies
A goal tree shows each objective under its parent. Services growth sits under the service division. The contract model it depends on sits under commercial. The emissions target sits under operations; the supplier conversions it depends on sit under procurement. In the tree, these pairs are in different branches with no visible connection.
So each function commits to its own target, and the dependency is discovered when one side misses and the other says it was never asked.
Four kinds of dependency
They behave differently, and the fix for each is different, so it is worth naming which one you are looking at.
| Kind | Example |
|---|---|
| Input | Service growth needs a contract model from commercial |
| Capacity | A site improvement needs engineering time from a central team |
| Sequence | A pricing change can’t launch until the new quoting system is live |
| Shared result | Two functions both move the same KPI; their contributions must add up |
Agreeing dependencies
- Ask during target negotiation: what does this target depend on that you don’t control?
- Bring the other function in, so it commits to its part as part of the same agreement.
- Record both sides: who committed what, by when.
- Make the dependency visible on both objectives, so both reviews see it.
- Escalate early when a dependency slips, rather than at the missed target.
A dependency nobody agreed to is a risk nobody owns.
The negotiation that first question belongs in is described in Cascading Goals vs Negotiating Them: Why Top-Down Cascades Fail.
Corrective actions across functions
Dependencies also arise mid-year, when something goes wrong and the fix needs another team’s work. The same principle applies: an action that commits another function’s time needs that function’s agreement, or it is a request that may never be fulfilled. In hoshin practice this is handled by reviewing a countermeasure A3 with everyone it commits; see When a Red Bowler Row Needs an A3 in Hoshin Kanri.
A worked example: a dependency map for one objective
Here is a hypothetical objective with four dependencies, each named with the function that owns it and the date it was committed to:
One objective, four dependencies, each named with the function that owns it and the date it was committed to.
| Target | Depends on | Kind | Committed by | Status in June |
|---|---|---|---|---|
| Services share 34% | Multi-year contract model | Input | Commercial, by 31 March | Late: legal review; North America target conditional |
| Services share 34% | Call routing to local centers | Sequence | Service operations, by 15 July | On plan |
| Services share 34% | Two service sales roles | Capacity | HR, by Q2 | Hired |
| Attach rate 30% | Quoting tool includes service contracts | Input | Pricing, by May | Done |
The late contract model was visible on both the services objective and commercial’s objective from April, so the services target’s condition was already understood when the region came in under 36%.
What an unagreed dependency costs
It costs a year. A target that quietly depends on another function’s work fails late, because nobody was watching the thing it was waiting for. By the time the miss is visible, the quarter in which it could have been fixed has gone, and the review becomes an argument about who should have asked whom.
Among published alternatives, OnStrategy lists $200 per month for unlimited users. i-nexus publishes a free Starter tier for up to five users and $28 per user per month at its Standard tier. The test for either is whether a dependency appears on both objectives, or only on the one that recorded it.
Profit.co publishes two plans, Essentials and Enterprise, quoting against modules and scale rather than a public seat rate, which matters here because the across direction only works when the function you depend on is also in the system. Catchball with required agreement sits in Essentials with OKRs and Goals, Balanced Scorecard, Hoshin Kanri and Strategy Roadmap. What Drives the Cost of Hoshin Kanri Software lists the rest to total.
Dependencies in Profit.co
In Profit.co, catchball sessions can include any function a target depends on, with agreement required from every participant, and countermeasure A3s are reviewed by everyone whose work they commit. See the strategy deployment software page.
Two mechanics carry the whole across direction:
- Required agreement. A session involving commercial cannot close until commercial has agreed its part, so the dependency is a commitment rather than an assumption.
- Visible on both objectives. The late contract model shows on commercial’s review as well as on the service division’s, which is what turns April’s slip into June’s understood condition instead of September’s surprise.
Dependencies between whole companies rather than functions work the same way, and are covered in Strategy Deployment for Multi-Entity Groups.
Free Product Demo
Map your strategy’s hidden dependencies
A 30-minute walkthrough, tailored to your team.
Book a free demo
What happens in the call
How your teams set goals, track progress and review results.
Strategy, performance, projects and engagement on one platform, with AI.
A practical path to align teams, execute faster and drive results.
Questions this article answers
Identify them during target negotiation, bring the function depended on into the agreement, record both sides’ commitments, show the dependency on both objectives, and escalate early when it slips.
Because they place each objective under its parent. Dependencies run between branches, so they have no natural place in the tree.
Yes, when they commit another team’s work. Without that agreement, the action is a request that may never be fulfilled.
Input, where one function needs something another produces; capacity, where it needs another team’s time; sequence, where one thing cannot start until another is live; and shared result, where two functions move the same KPI and their contributions must add up.
When it slips, not when the target is missed. The point of recording the commitment date is that the slip is visible months before the result it will affect.
