To find which team is holding up a product launch, start with the next launch acceptance milestone and trace its unfinished dependencies backward. For each handoff, ask whether the input is ready, who owns the next action and what prevents it. Name the blocked step before attributing the delay to a department.
Map the actual launch dependency chain#
Write down the conditions required for launch: product readiness, security approval, commercial terms, support preparation or customer acceptance. Use the conditions that apply to your launch rather than a generic checklist.
For each unmet condition, identify its predecessor work. A team marked late may be waiting for another team’s decision, and the earliest visible delay may sit outside the launch board entirely.
Ask four questions at each handoff#
- Has the receiving team agreed what a ready input contains?
- When did that complete input become available?
- Who owns acceptance or the next decision?
- What other commitments compete for the same capacity?
Record a blocked reason specific enough to test. “Waiting on Engineering” is weaker than “Technical review cannot start until the data-retention decision is approved.”
Example: support readiness depends on a product decision#
In a hypothetical launch, Support has not finished training and appears to be the blocking team. Inspecting the training task shows that a behavior decision is still open. Product is waiting on legal guidance, while Legal has not received the required customer scenario.
The first action is to provide that scenario and assign the decision date. Escalating Support would add pressure at the wrong step. The launch lead should update the affected training and release commitments after the decision is made.
Choose an action that changes the handoff#
Repair missing inputs when the work is not ready. Assign ownership when a decision has no owner. Agree a queue order when a shared team has competing ready requests. Consider added capacity when prioritized, complete work still waits beyond what the team can handle.
Save the handoff baseline and review whether the dependent milestone moves. Do not equate an escalation message or an extra meeting with removal of the blocker.
Inspect dependencies in Commandix#
Commandix supports predecessor dependencies and blocked reasons, with project views for reviewing the work. Constraints can help investigate a shared delay across several items. Confirm its suggested explanation with the teams involved. A person or team shown in the analysis is not automatically at fault.
Related guide: A checklist for repeatedly missed project deadlines.
Frequently asked questions#
Who should own a cross-team blocker?#
Assign one person with authority to coordinate the decision. The task owner and the manager who can resolve a competing priority may be different people.
What if several teams are blocking launch?#
Map the dependency order and identify which ready action can unblock the next milestone. Some delays are independent and should remain separate in the plan.