Stephen Turner
Akash Kumar
Jordan Lee
Taylor Scott
Project-manager meetings: turn dependencies into clear next steps
Project managers can use coordination meetings to pin down what work depends on, who will respond and when a decision is needed. The useful output is a dependency and escalation record that lets teams act between meetings.
Before the meeting: find the dependencies that change the plan
Go through your project board. Pick the items where one team needs an input, sign-off or decision from another. Invite the people who can resolve them, not the whole project. For each, write down:
- The task that's waiting.
- What it's missing.
- Who provides it.
- The latest useful date for a response.
Give every dependency and handoff an owner
Atlassian's dependency-mapping play gives every dependency an owner and reviews the map regularly so it stays current.
Roles and responsibilities aren't the same thing. A job title doesn't say who owns every task. Atlassian's roles exercise helps teams find work nobody owns. In a project meeting, check who owns the handoff itself, especially when both teams assume the other will arrange it.
During the meeting: test readiness, don't collect reports
Ask what the receiving team needs to start or finish. A document marked done may still lack the example, access or review the next team needs. Agree what “ready” means together. “Needs confirmation” beats marking something resolved because someone sounded hopeful.
Keep ownership small and specific. The person chasing an answer may not be the person who can decide. Confirm both when it matters.
End each item with the next response and when you'll revisit it. Go deep on solutions only with the people doing that work.
Example: a dependency before a launch rehearsal
A fictional team is preparing a customer onboarding rehearsal. Training needs a working account. Operations needs a confirmed support process.
The launch owner must decide whether the rehearsal can go ahead. Saying all three teams are busy doesn't show the order things must happen in.
A compact record like this does. The checkpoints are relative to the example, not a fixed schedule.
| Waiting work | Dependency and next owner | Escalate if |
|---|---|---|
| Training rehearsal | Account specialist verifies the test account before the rehearsal invite | Access is still unconfirmed at the invite deadline: PM asks the launch owner whether to move the rehearsal |
| Support walkthrough | Operations lead supplies the named support contact and response route | Nobody accepts the support handoff: PM requests a staffing decision |
| Launch readiness decision | PM brings the two open conditions to the launch owner | Launch owner confirms proceed, reduce scope, or reschedule |
Escalate with a choice, a consequence and a decision owner
An escalation explains what can't be solved at the working level. State the decision needed, the real options, the cost of waiting and who can decide. Separate a delay you've seen from a forecast about a later milestone.
For the rehearsal, the question might be: “Should we run a walkthrough with a prepared recording, or move the live rehearsal until test access is confirmed?” Include each option's limits. Don't imply the PM can approve scope or staffing changes unless they actually can.
After the meeting: confirm, then update the plan
Put agreed actions in your existing work system and link the dependency record. Ask the receiving team to confirm the input is usable when it arrives. Close a dependency when it's accepted, not when a file is sent. If an action changes, update the checkpoint.
If you record the meeting in Bridge, its notes list the action items assigned in the discussion. They also show up in the Action items list on Home. Compare them with your dependency record first. A captured action is a draft until its owner confirms it.
Use the next meeting for changed dependencies and open decisions, and keep routine status in writing. This doesn't replace a full project plan or approval process. It makes one recurring coordination problem easier to see.