The precedence diagram from planning week is still pinned in the release channel. Forty-one boxes, fifty-three arrows, every one typed: mostly finish-to-start, plus a few start-to-start arrows with a two-day lag where the API team and the front-end team agreed to overlap. The team traced the longest path through it and voted four fingers on a 9 June release.
Four weeks later the diagram has not changed. The work has. Three dependencies nobody drew now exist in Jira as “blocks” links, and one of the start-to-start overlaps turned out to be finish-to-start: the front end could not begin until the API contract was final. Nothing on the diagram is wrong. It is just old.
What the precedence diagramming method gets right
The precedence diagramming method (PDM) is the standard way to draw a project network. Each activity is a box, which is why it is also called activity on node (AON), and each arrow is a logical relationship from a predecessor to a successor. There are four types: finish-to-start (the default, and by far the most common), start-to-start, finish-to-finish, and the rare start-to-finish. Any arrow can carry a lead, which lets the successor overlap the predecessor, or a lag, a deliberate wait between them. Run the critical path over the diagram and you get the sequence that dictates the finish.
Drawing one is expert engineering judgment. Deciding that the data migration must finish before cutover, that two streams can safely overlap by two days, that testing can start when development starts but cannot finish until development finishes: those are calls only the people doing the work can make. A precedence diagram is good evidence for a confidence vote.
Why the diagram stops at the vote
A precedence diagram describes the dependencies known on the day it was drawn. After the vote, three things happen to it, and none of them shows up on the page.
New arrows appear. Dependencies surface in refinement, in a cross-team sync, in a failed integration build. They go into Jira as issue links. The pinned diagram does not get a new arrow.
Arrows change type. A start-to-start with a lag was a bet that two pieces of work could overlap. When the overlap fails, the arrow is really finish-to-start, and the successor waits for the whole predecessor.
Arrows move onto the critical path. An arrow that had room around it at planning loses that room as nearby work slips. It quietly becomes the arrow that sets the date.
That is dependencies surfaced too late, the second of the three things that erode a committed release date. The other two compound it: scope creep brings new boxes and new arrows, and a capacity change stretches every box on the chain.
And even a freshly redrawn diagram does not answer the question the business asks: what does this arrow cost the date, in days, at the confidence we committed to?
Keep the diagram. Price the arrows in days.
The fix is not redrawing the precedence diagram every week. It is putting each arrow where the forecast reads it, and reading the date there.
- Draw the diagram at planning as you do today. Then record every arrow as a Jira issue link between the real work items in the release’s Fix Version, and record the committed date with the confidence level the team voted at.
- Mark each link hard or soft. A finish-to-start arrow where the successor truly cannot begin is hard. An overlap or a sequencing preference stays soft until someone confirms it is a real gate. Standard Jira links carry no lead or lag, so the judgment behind them lives in the hard/soft choice.
- When a new dependency appears, or an overlap fails and a soft link becomes a gate, change the link the same day. Do not wait for the next diagram.
- At every cross-team sync, read the gap in days between the committed date and the forecast at the committed confidence, and look at which links sit on the path currently dictating the date.
An illustration, not customer data. A release is committed for 9 June at 85% confidence. At the vote, the 85% forecast sat at 5 June: four days of margin. By week four, three new hard links have been added in Jira (an API contract owned by the platform team, a migration that must finish before cutover, a security review) and one soft overlap has been reclassified as hard. The 85% forecast is now 13 June, four days past the commitment. The 50% forecast is 8 June, so the release reads amber (attention), not yet red.
Now the sync has a decision with a number on it. Pull the security review forward? Split the migration so cutover waits for only part of it? Move one feature to the next release? Renegotiate the date with the business now, while there is margin to trade? Each option is the team’s call, and so is every assumption behind the forecast. What changes is that the call happens in week four, not at the go/no-go meeting.
Where Advanced Release Planning fits
Advanced Release Planning for Jira does not draw a precedence diagram, and it does not ask for activity durations, leads or lags. Jira issue links record that one item blocks another; they carry no lag, so the app produces no forward-pass dates and no float table. It reads what the diagram points to: the Fix Version as the scope boundary, Jira issue links as the dependency network, and the team’s delivered throughput and capacity settings as the delivery rate. Hard links take part in critical-path analysis; soft links are recorded but do not drive the path. The Critical Path view shows the ordered sequence of work currently dictating the committed date, including blockers that live in another team’s Fix Version, and a hard link added in Jira enters the path the next time the forecast runs. The committed date carries its confidence band (50%, 85%, 95%) and stays current as scope, dependencies and capacity move. The team sets the assumptions: which throughput window, whose capacity, what is in scope. The app does the arithmetic at Monte Carlo scale and keeps it live. Green at or above P85, amber between P50 and P85, red below P50.
If you run a critical path over your diagram, see why the critical path method finds the longest chain once. For the four relationship types in Jira terms, see project dependencies. For what the app reads and reports, see the dependency-aware planning reference doc.
Key takeaways
- The precedence diagramming method draws activities as boxes and typed arrows (FS, SS, FF, SF) with leads and lags. It is sound engineering judgment and a fair input to the confidence vote.
- After the vote, new arrows appear, overlaps fail and arrows drift onto the critical path. The diagram shows none of it.
- Even an up-to-date diagram does not say what an arrow costs the committed date in days.
- Record every arrow as a hard or soft Jira issue link in the Fix Version, and read the gap in days at the committed confidence at every cross-team sync.
FAQ
What is the precedence diagramming method in project management?
PDM is a way of drawing a project network in which each activity is a node (a box) and arrows show the logical relationships between activities. It is also called activity on node (AON).
What are the four dependency types in a precedence diagram?
Finish-to-start, start-to-start, finish-to-finish and start-to-finish. Each can be adjusted with a lead (overlap) or a lag (wait). Finish-to-start is the most common; start-to-finish is rare.
Can Jira issue links hold a lead or a lag?
Standard Jira issue links record that one item blocks another; they do not carry a lead or a lag. Use hard links for real gates and soft links for sequencing preferences, and read the effect on the release as a gap in days at the committed confidence.
Keep your precedence diagram. Add the number it is missing. See the committed date and its live confidence band in Advanced Release Planning, or start a free trial on the Atlassian Marketplace.
2 Comments
Leave your reply.