The resource management plan for the payments release ran to eleven pages. A roles table with authority levels. A RACI. A section on bringing in a contract security reviewer for sprint 6. A resource calendar with every booked holiday. A rule for borrowed people: any request to move someone off the release goes to the delivery lead, who approves it if the work is not on the critical path. The confidence vote came in at four fingers.
In week five, the platform team asked for one of the two backend engineers “for two weeks” to help with a database migration. The plan had a rule for exactly this, and the rule was followed: the delivery lead checked, decided the work could wait, and said yes in a hallway. Ten minutes. Nobody asked what two weeks of that engineer would cost the committed date. The plan did not have a field for it.
What a resource management plan is for
A resource management plan says how a project will identify, acquire, assign, develop, control and release the people and equipment it needs. In PMBOK terms it is the main output of Plan Resource Management. Most versions cover the same ground: roles, responsibilities and authority; an org chart or RACI; how people are acquired and onboarded; the resource calendar of who is available when; training and team development; how conflicts between projects and shortages are resolved; and when people are released at the end.
It earns its place. Writing one forces the team to say who it is counting on, at what share, and when they are away. That roster is the capacity assumption behind the confidence vote, and getting it right is engineering judgment: which specialist is the real constraint, which loan is safe, which absence will hurt. That judgment is what the team commits on.
The plan governs a change. It does not price it.
The resource management plan has two limits once the vote is over.
It describes the team on the day it was written. The resource calendar may get an update when someone books leave. The rest rarely does. After the vote, people are loaned out, pulled onto incidents, out sick, or replaced by a new hire who is still ramping up. The team the plan describes and the team doing the work drift apart week by week.
Its change rules are procedural, not quantitative. The plan says who approves a reassignment and how a conflict between projects is settled. It does not say what the approved change does to the date. Two weeks of one backend engineer might cost the release nothing if their work has slack around it, or a full week if it sits on the critical path. Same rule, same approval, very different cost.
That is capacity change, the third of the three things that erode a committed release date. The other two, scope creep and dependencies surfaced too late, often come through the same door. The borrowed engineer comes back with a new dependency on the migration they helped finish.
Keep the plan. Put a number next to every capacity decision.
The fix is not a longer plan. It is pointing the plan at live inputs and reading every change against the date.
- Write the plan as you do now. Add one line: the committed date and the confidence level the team voted at, stated as the assumption this roster supports.
- Keep the resource calendar at the source. Time off goes against each person, per day, on the Jira accounts doing the work, and public holidays come from a calendar per team. A loan to another team is a time-off entry for the length of the loan, not a note in the plan.
- Add one step to the reassignment rule: record the change, then read the re-forecast before the person moves. The approver sees the cost in days, not just the procedure.
- At every sprint boundary, read one number: the gap in days between the committed date and the forecast at the confidence the team committed at.
An illustration, not customer data. A release is committed for 20 May at 85% confidence. At the vote, the 85% forecast sat at 16 May: four days of margin. In week five the backend loan is recorded as ten working days of time off. The 85% forecast moves to 23 May, three days past the commitment. The 50% forecast is 17 May, so the release reads amber (attention), not yet red.
Now the hallway conversation has a number in it. Shorten the loan to one week? Lend the other engineer, whose work has more slack? Move a could-have below the MoSCoW cut-line? 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 gets made before the engineer leaves, not at the release demo.
Where Advanced Release Planning fits
Advanced Release Planning for Jira does not write or store a resource management plan, and it is not a resource-management or HR system: it does not model roles, skills or allocation percentages. It reads what the plan’s capacity assumption rests on, at the source: time off recorded per person, per day, against the Jira accounts assigned to issues; holiday calendars per team; and the team’s delivered throughput and work in progress. The Capacity Awareness setting folds these into a Monte Carlo forecast. When availability changes, the committed date is re-forecast and the shift is reported in days. 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 your plan includes a load chart, see what a resource histogram can and cannot tell you about the date. If you keep the roster in a separate sheet, see what each field of a capacity planning template should reference. For the full list of what the app reads and what it does not, see the capacity change reference doc.
Key takeaways
- A resource management plan sets who works on the release, at what share, and how changes are approved. It is a fair input to the confidence vote.
- After the vote it describes the team as it was. Loans, incidents, absences and ramp-ups change the real team, not the document.
- Its change rules say who approves a reassignment, not what the reassignment costs the committed date in days.
- Record capacity changes at the source in Jira, read the re-forecast before approving them, and check the gap in days at every sprint boundary.
FAQ
What is a resource management plan?
A document that describes how a project will identify, acquire, assign, develop, control and release its people and equipment. In PMBOK it is the output of Plan Resource Management.
What goes in a resource management plan?
Typically roles, responsibilities and authority, an org chart or RACI, how people are acquired, a resource calendar, training and team development, how conflicts and shortages are resolved, and when people are released. Adding the committed date and its confidence level makes the capacity assumption explicit.
If a reassignment follows the plan, is the release date safe?
Not necessarily. Following the plan means the change was approved correctly. Whether the date holds depends on whose work moves and whether it has slack. Record the change and read the forecast at the committed confidence, in days.
Keep your resource management plan. 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.
1 Comment
Leave your reply.