Most schedule management plans are written once, approved at kickoff, and filed next to the charter. The section that matters most after the team commits to a date is the one almost nobody re-reads: the control thresholds. They decide how a slip gets noticed. And in most plans, they are written in a unit that notices it a month late.
What a schedule management plan is
A schedule management plan is the project document that sets how the schedule will be built, maintained and controlled. In the PMBOK Guide (sixth edition) it is the output of the Plan Schedule Management process, and it typically covers:
- the scheduling method and tool;
- release and iteration length, for adaptive work;
- units of measure;
- the level of accuracy, meaning the acceptable range around duration figures;
- schedule model maintenance: who updates the schedule, and how often;
- rules of performance measurement, such as percent complete or earned value;
- control thresholds: how much variance triggers action;
- reporting formats.
Project schedule management then runs on top of that plan. Every later conversation about the date leans on decisions made here, before anyone voted.
Written before the vote, read after it
Then comes the commitment. In SAFe it is the PI planning confidence vote; elsewhere it is the release planning session where the team says “we can land this by 14 November.” That vote is expert engineering judgment. The team knows which items are bigger than they look, which throughput window reflects how they work now, and who will actually be on the release. The schedule management plan does not replace that judgment. It decides how the organisation will know if the judgment stops holding.
That is where the trouble starts. The date rarely fails at the vote. It fails in the weeks after, through the three things that erode a committed release date: scope creep, dependencies surfaced too late, and capacity changes. None of them waits for the reporting cycle.
The control threshold problem
Most plans write their thresholds as a percentage or an index: schedule variance beyond 10% of plan, or a schedule performance index below 0.9. Both are reviewed at the status meeting, usually monthly. Both have known blind spots. Schedule variance is expressed in budget units, not days. SPI drifts back toward 1.0 as a project nears completion, whether the date holds or not. Neither one says where the committed date now sits.
An illustration, not customer data. A team commits to 14 November at 85% confidence. In week three, six items join the release during refinement. A dependency on the platform team surfaces that nobody had linked. One engineer is out for two weeks. At the monthly review, SPI reads 0.94: inside the threshold, so the release stays green. Meanwhile the forecast has moved. The P85 date is now 25 November, eleven days past the commitment, and 14 November holds at roughly 60% confidence. The plan worked exactly as written. It just measured the wrong thing, at the wrong interval.
Rewrite the plan’s sections in days
You do not need a new document. You need several sections of the existing schedule management plan to point at a live reading instead of a periodic one:
- Level of accuracy: state the range as a confidence band (P50, P85, P95) and name the level the team commits at. Most teams use P85.
- Schedule model maintenance: the forecast reruns whenever scope, issue links or capacity change, not when someone opens the schedule file.
- Control thresholds: write them against the committed date. Watch when the gap grows by a number of days the team chooses. Attention when the committed date falls below P85. Escalate or renegotiate when it falls below P50.
- Reporting formats: quote the reading (committed date, today’s confidence, gap in days, and which of the three drivers caused it) rather than a colour someone assigned.
This pairs with the baseline. The schedule baseline fixes the reference; the plan’s thresholds say how far from it is too far. On the scope side the same pattern applies: of the six project scope management processes, only control scope runs after the vote, and it needs the same reading in days.
Where Advanced Release Planning fits
Advanced Release Planning for Jira does not write or store your schedule management plan. It supplies the reading the plan’s thresholds can point at. It runs a Monte Carlo forecast over your team’s real Jira throughput and the issues in the Fix Version, records the committed date against its P50/P85/P95 band, and tracks scope creep, late dependencies and capacity changes against that date, in days, as they happen. Release status follows the band: on track at or after P85, attention between P50 and P85, at risk below P50. The team still owns the assumptions: which throughput window, whose capacity, what is in scope. The app does the arithmetic and keeps it current. The schedule management plan reference doc maps each plan section to what the forecast supplies.
Key takeaways
- A schedule management plan is written before the commitment and decides how a slip will be detected.
- Thresholds written as percentage variance or SPI, reviewed monthly, miss erosion that happens between reviews.
- Write the thresholds in days against the committed date, at a stated confidence level.
- The confidence vote stays the team’s judgment. The plan’s job is to show, early, when that judgment needs revisiting.
FAQ
What goes in a schedule management plan? The scheduling method, units of measure, level of accuracy, update rules, performance measurement rules, control thresholds and reporting formats. Agile plans also state release and iteration length.
Is a schedule management plan the same as a project schedule? No. The schedule is the dates. The plan is the rulebook for building, updating and controlling those dates.
What is a good control threshold for a release? One stated in days against the committed date at a named confidence level, checked continuously, for example: attention when the committed date drops below P85.
See the committed date and its live confidence band in Advanced Release Planning, or install it from the Atlassian Marketplace.
1 Comment
Leave your reply.