The vendor said end of month.
Everyone in the PI planning room heard it. The payment provider’s new API would drop “end of month,” the integration stories were sized around it, and when the confidence vote went around the room, the team held up fours. That vote wasn’t wishful thinking — it was expert engineering judgment. The team knew the vendor’s track record, knew the integration surface, and priced the promise on the best evidence anyone had.
The problem: the promise wasn’t in the building. Six weeks later, “end of month” quietly became “mid next quarter.” The change surfaced in passing on a status call and reached the delivery lead thirdhand. By then the committed release date had been moving for weeks — and nothing in Jira had so much as flickered.
The dependency that doesn’t live in your Jira
Internal dependencies are hard enough, but they at least exist somewhere you can see: a ticket in another team’s backlog, an issue link, a string on the program board. External dependencies — the vendor deliverable, the partner’s API, the security sign-off, the hardware lead time, the migration owned by a business unit on a different tracker — often have no ticket anywhere. They live in an email thread and a statement of work.
That makes them the sharpest form of the second of the three things that erode a committed release date: dependencies surfaced too late. Scope creep at least happens inside your backlog, where someone might notice. A capacity change is usually announced. An external dependency erodes the date from outside your instance entirely. The burnup looks healthy, velocity is fine — and the release date is moving anyway, because a date you don’t control is sitting on your critical path, uninstrumented.
Give the promise a ticket
The fix starts almost embarrassingly simply: if your committed date depends on someone else’s deliverable, that deliverable gets a work item in your plan — a placeholder issue carrying the promised date, a named owner, and links to every piece of work that can’t start until it lands. This isn’t bureaucracy. It’s honesty about the true shape of the plan.
Once the promise is a work item, Release Management, Roadmaps, Portfolio PPM & Timeline treats it as the load-bearing element it always was. A hard link says the integration work literally cannot start until the vendor ships, so it participates in critical-path analysis — negative slack on that chain pushes the probable completion date later. A soft link records a sequencing preference without driving the path. The Critical Path view shows, as an ordered ribbon, whether the vendor’s promise is currently dictating your committed date. Blockers living in a different Fix Version — a platform team’s migration, say — appear directly in the path as cross-release context nodes instead of staying invisible until the next status meeting. And a ranked risk heatmap sorts what’s on or near the path, so the one external promise worth a phone call this week rises to the top.
Because the forecast underneath is dependency-aware Monte Carlo, the promised date isn’t decoration. When the vendor’s date moves, the committed date and its confidence band move with it — in days, the same day. Not at the quarterly review. Not in the retro after the launch slipped.
Renegotiate while it’s still a conversation
None of this second-guesses the room that voted fours. The confidence vote priced “end of month” because that was the best evidence the team had — the assumptions were theirs to own, and they owned them well. What the team was missing was the mechanism that notices when the evidence changes.
With the promise instrumented, a two-week vendor slip shows up as amber against the committed date while there’s still slack to resequence around it, scope to trim back to must-haves, or time to put the vendor’s new date on the record and reset the commitment deliberately. Like the SAFe program board, an external commitment is accurate on the day it’s written down; unlike a wall of string, an instrumented one keeps reporting. That’s the difference between renegotiating a date and apologizing for one — the same discipline that keeps a committed release date honest across teams, extended to the dependencies that never had a ticket at all.
See the whole dependency picture — including the parts you don’t control
External dependencies in project management are the risks your own tracker can’t see: you can’t sprint-plan a vendor, but you can make their promise visible, linked, and live. Release Management, Roadmaps & Portfolio does the arithmetic at Monte Carlo scale and keeps it current, so the team’s judgment stays the hero and the surprises stay small. See how release planning in Jira handles dependencies your team doesn’t own, read the feature documentation for the mechanics, or try Release Management, Roadmaps, Portfolio PPM & Timeline on the Atlassian Marketplace. Then put your next vendor promise on the plan — and find out what your critical path really looks like.
Leave a Reply
Your email is safe with us.