Resource Management Plan: Template and a 12-Week Example

What a resource management plan covers

The plan describes how a project will acquire, develop, use, control and release its resources. Its main job is setting expectations: everyone knows, in writing, what they give to the project and when. A complete plan usually holds the seven parts listed below.

The RBS should cover six types of resources, not only people: time, materials, people, equipment, money and data.

It is not the same as the project management plan. The project management plan covers the whole project: scope, schedule, cost, quality, communication and risk. The resource plan is one part of it and answers a narrower question: do we have the right people and means at the right time, and what do we do if we don't?

• A resource breakdown structure (RBS).
• An org chart.
• A resource calendar.
• A RACI matrix.
• A few resource KPIs, such as planned against actual hours.
• A training plan.
• Budget tracking.

Which version of the plan do you need?

Pick the format before you start writing. A plan that is too heavy for the project never gets updated.

The 12-week example below uses the full version, because two of its six people are shared with other teams.

• Two-page plan, for a small project: one team, no shared people, a few weeks of work. Keep the RBS, demand in hours, the calendar and a short list of risks. Skip the formal RACI if everyone sits on the same team.
• Full plan with RACI and calendar, when people are shared: as soon as one person splits time between projects, or several teams deliver parts of the work, you need every section of the template below. The shared percentages, the RACI and the conflict rules are what protect your dates.
• One-page view, for leadership: built from the full plan, never instead of it. Phases on a timeline, who works in each phase, the peak weeks, the open gaps and the decisions you need from them.

How to build the plan in six steps

The order matters: demand first, then supply, then the match between them.

One exception to the order: people who start in week 1 must be confirmed before kickoff. Confirm them first, then run the six steps for everyone else.

• Step 1, map the schedule: list deliverables and their dates. Without dates, hours mean nothing.
• Step 2, break down resources: build the RBS by category: people by skill, equipment, software licenses, materials, budget, data access.
• Step 3, estimate demand: hours per role, per week. Use past projects when you have them.
• Step 4, check real capacity: plan people at their productive hours, not their contract hours. Meetings, support and admin take time on every team.
• Step 5, close the gaps: for each gap, record a decision: hire, contract, train, move a date or reduce scope.
• Step 6, allocate and confirm: name a person for each task, write the RACI and get the team leads' agreement in writing.

Resource management plan template

Copy these sections into your document and fill each one. Keep it short enough that a sponsor reads it in ten minutes.

• Project summary: goal, dates, sponsor, project manager.
• Resource breakdown structure: each resource by category, with skill or specification.
• Demand: hours per role and per week, total hours per role.
• Capacity: each person's productive hours per week and any share with other projects.
• Selection criteria: how you choose staff, contractors and vendors.
• Roles and RACI: who is Responsible, Accountable, Consulted and Informed for each deliverable.
• Resource calendar: who works when, with holidays and roll-off dates.
• Training: who needs what before which date.
• Budget tracking: planned against actual hours or cost, reviewed weekly.
• Risks and backup plans: what can go wrong with each key resource and the response.
• Change process: who approves a change in allocation and how it is logged.
• Release plan: when each resource leaves and what is handed over.

Resource management plan example: a 12-week website rebuild

Here is the template filled for a company website rebuild. The numbers are an example to adapt, not a benchmark.

Team and hours. Productive capacity is planned at 32 hours a week for a full-time person. The project manager, designer and lead developer were confirmed before week 1.

Total planned: 912 hours, with a contingency of about 90 hours held by the sponsor, not spread across the team.

Other resources. Staging server ready by week 3, design software licenses for the designer from week 1, access to the analytics account for the writer by week 4, a test device list for QA by week 9.

• Project manager: 12 h a week for 12 weeks, 144 h.
• Designer: 32 h a week, weeks 1 to 5, 160 h.
• Lead developer: 32 h a week, weeks 3 to 12, 320 h.
• Second developer, shared 50% with the mobile app team: 16 h a week, weeks 5 to 10, 96 h.
• Content writer, shared 50% with marketing: 16 h a week, weeks 4 to 9, 96 h.
• QA contractor: 32 h a week, weeks 10 to 12, 96 h.

Example RACI and resource calendar

RACI for three deliverables. Design system: designer Responsible, project manager Accountable, lead developer Consulted, marketing Informed. Page content: writer Responsible, marketing lead Accountable, designer Consulted, project manager Informed. Launch: lead developer Responsible, project manager Accountable, QA contractor Consulted, sponsor Informed.

Resource calendar, week by week. The list below shows the people on the project, project manager included, and total planned hours.

Design and development overlap in weeks 3 to 5 for handover. The designer rolls off at the end of week 5, so every design question must be closed by then.

• Weeks 1 and 2: 2 people, 44 h a week.
• Week 3: 3 people, 76 h.
• Week 4: 4 people, 92 h.
• Week 5: 5 people, 108 h. This is the peak, because design hands over while development, content and the second developer are all active.
• Week 6: 4 people, 76 h.
• Week 7: 3 people, 60 h, because the second developer is back on the mobile app.
• Weeks 8 and 9: 4 people, 84 h a week.
• Week 10: 4 people, 92 h, as QA starts and the second developer finishes.
• Weeks 11 and 12: 3 people, 76 h a week.

Example: the gap found in week 3

The mobile app team has a release in week 7 and wants its developer back full time that week. Decision, approved by both leads: the second developer works 0 hours on the website in week 7, then 24 hours in weeks 8 and 9 instead of 16.

Week 7 loses 16 hours, weeks 8 and 9 get 8 hours back each, so the 96 hours planned for this role stay intact and the project total stays at 912 hours. The cost is a lighter week 7, which is why the plan puts content work and internal reviews there.

Handling shared people and resource conflicts

Conflicts are where most plans break, and many templates skip them. When two projects want the same person, decide by rule, not by who shouts loudest. Write the rule into the plan before work starts.

Keep a short conflict log with the date, the people, the decision and who approved it. When the same conflict comes back three times, the issue is capacity, not scheduling, and it belongs in a staffing discussion.

• Priority order: the portfolio ranking decides, set by leadership, not by the project managers.
• Fixed share: a shared person gets a fixed weekly percentage per project, changed only through the change process.
• Swap, don't stretch: if one project needs more hours, it gives back hours in another week, as in the week 7 example. Nobody goes above planned capacity for more than one week in a row without the sponsor's approval.
• Escalation clock: a conflict not solved between leads within two working days goes to the sponsor.

Risks and backup plans

Each key resource needs a named risk and a response. The list below covers the example project.

Five habits keep these risks small: validate scope early, work in short cycles, say openly when a resource is at risk, check availability every week and flag delays as soon as you see them. Each one shows up in the Friday review: planned hours against actual hours, open conflicts, risks that changed.

• Lead developer unavailable: documentation updated weekly, second developer briefed on the core code by week 6.
• Budget cut mid-project: scope ranked in advance, so the lowest ranked pages drop first.
• Contractor starts late: contract signed by week 7, access requested by week 9.
• Writer pulled back to marketing: content for the top pages written first, so a pause hurts less.

Presenting the plan to leadership or a client

Leadership does not want the full spreadsheet. Show the one-page view: phases on a timeline, who is on the project in each phase, the peak week, the open gaps and the decisions you need from them. Put the asks first: approve the contractor, confirm the shared developer, hold the contingency.

For a client, show the same timeline with roles instead of names, plus the dates when their input is needed. Then keep the plan alive. Update it every week during delivery, version it, and send a short note when allocations change. A plan last updated in week 2 is no longer a plan.