# Resource Management Plan: [Project name]

> Plan for the people, skills and equipment the project needs: requirements
> by role and period, team structure, RACI, acquisition and onboarding,
> capacity against demand, training and release. Based on common project
> management practice. Replace every `[bracketed]` value and every row
> marked *Example*.

<!--
Guidance: How to use this template
- Derive demand from the schedule and WBS, not from headcount wishes. Every role
  should trace to work packages.
- Agree availability in writing with line managers; a name in a plan is not a
  commitment.
- Show capacity against demand per period so gaps are visible months ahead.
- Treat personal data with care: keep only what the project needs and restrict access.
-->

| Field | Value |
|---|---|
| Document ID | [RP-PROJECT-001] |
| Project | [Project name] |
| Version | [0.1] |
| Owner | [@project-manager] |
| Approved by | [@sponsor, @resource-manager] |
| Related | [Schedule SCH-001, WBS-001] |
| Last updated | YYYY-MM-DD |

## 1. Approach

<!-- Guidance: Explain how resources are estimated, secured and managed, and who has authority over them. -->

Resource demand was estimated from the work packages in [WBS-001] and the activity durations in [SCH-001]. Internal staff are allocated by their line managers through [resource management process]; external staff are contracted through procurement. The project manager directs day-to-day work; line managers keep responsibility for performance reviews and well-being.

## 2. Resource requirements by role and period

<!-- Guidance: Show FTE per role per month or quarter. Include equipment and facilities if significant. -->

Demand in full-time equivalents (FTE) by month:

| Role | Skills required | Jan | Feb | Mar | Apr | May | Jun | Source |
|---|---|---|---|---|---|---|---|---|
| *Example:* Project manager | Hybrid delivery, vendor management | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 0.5 | PMO |
| *Example:* Business analyst | Process mapping, KYC regulation | 1.0 | 1.0 | 0.5 | 0.5 | 0.2 | 0 | Operations |
| *Example:* Developer | TypeScript, REST integration | 0 | 2.0 | 3.0 | 3.0 | 1.0 | 0.5 | Vendor |
| *Example:* Tester | Test automation, accessibility | 0 | 0.5 | 1.0 | 2.0 | 1.0 | 0.2 | QA pool |
| *Example:* Change and training lead | Adult learning, communications | 0.2 | 0.5 | 0.5 | 1.0 | 1.0 | 0.5 | HR |
| [Role] | [Skills] | [x] | [x] | [x] | [x] | [x] | [x] | [Source] |

Non-staff resources:

| Resource | Quantity | Period | Owner |
|---|---|---|---|
| *Example:* Test environment (cloud) | 2 instances | Feb to Jun | [@tech-lead] |
| *Example:* Training room | 1 room, 20 seats | Apr to May | [@facilities] |
| [Resource] | [n] | [Period] | [@owner] |

## 3. Team structure

<!-- Guidance: Show reporting lines inside the project. Keep it consistent with the governance section of the project management plan. -->

The project team is organised by workstream.

```mermaid
flowchart TB
  PM["Project manager"] --> BA["Process workstream (BA lead + 1)"]
  PM --> TL["Platform workstream (tech lead, 3 vendor developers)"]
  PM --> QA["Test workstream (test lead + 1)"]
  PM --> CL["Change workstream (change lead + trainers)"]
```

## 4. RACI matrix

<!-- Guidance: One Accountable per row. R = Responsible, A = Accountable, C = Consulted, I = Informed. Too many C entries slow decisions. -->

Responsibilities for key deliverables and decisions:

| Deliverable or decision | Sponsor | Project manager | BA lead | Tech lead | Test lead | Change lead | Operations head |
|---|---|---|---|---|---|---|---|
| Project management plan | A | R | C | C | C | C | I |
| Target process design | I | C | R | C | I | C | A |
| Platform build | I | A | C | R | C | I | I |
| User acceptance testing | I | A | C | C | R | I | C |
| Training delivery | I | A | C | I | I | R | C |
| Go-live decision | A | R | C | C | C | C | C |

## 5. Acquisition and onboarding

<!-- Guidance: State how and when each role is secured, and the onboarding steps so people are productive from day one. -->

Resources are acquired according to the plan below.

| Role | Method | Lead time | Request by | Status |
|---|---|---|---|---|
| *Example:* Developers (3) | Vendor contract, named team | 6 weeks | YYYY-MM-DD | Contract signed |
| *Example:* Tester (additional 0.5 FTE) | Internal QA pool request | 3 weeks | YYYY-MM-DD | Requested |
| [Role] | [Method] | [Lead time] | YYYY-MM-DD | [Status] |

Onboarding checklist for each new team member:

- Access to repository, issue tracker, chat channel and test environments, approved by the system owners
- Briefing on objectives, plan, ways of working and the RAID log
- Security and data protection induction where personal data is handled
- Buddy assigned for the first two weeks

## 6. Capacity versus demand

<!-- Guidance: Compare committed capacity with demand. Any gap needs an action with an owner and date. -->

Committed capacity is compared with demand per month; negative values are gaps.

| Role | Month | Demand (FTE) | Committed capacity (FTE) | Gap | Action |
|---|---|---|---|---|---|
| *Example:* Developer | Mar | 3.0 | 3.0 | 0 | None |
| *Example:* Tester | Apr | 2.0 | 1.5 | -0.5 | Request from QA pool; fallback: extend UAT by 5 days |
| *Example:* Business analyst | Feb | 1.0 | 0.6 | -0.4 | Backfill operations duties for 4 weeks |
| [Role] | [Month] | [x] | [x] | [x] | [Action] |

Utilisation is checked to avoid planning people above sustainable load:

$$\text{Utilisation} = \frac{\text{Allocated hours}}{\text{Available hours}} \times 100\%, \quad \text{target} \le 85\%$$

## 7. Training and development

<!-- Guidance: List skills gaps in the team (not end-user training, which belongs in the change plan) and how they are closed. -->

Skills gaps in the project team are closed as follows.

| Skill gap | Who | Training | When | Cost |
|---|---|---|---|---|
| *Example:* Accessibility testing | Testers (2) | Two-day practical course | Before test stage | 1,600 EUR |
| *Example:* Identity service API | Developers (3) | Vendor workshop | Build week 1 | Included in contract |
| [Gap] | [Who] | [Training] | [When] | [Cost] |

## 8. Team management and recognition

<!-- Guidance: Describe how performance input, conflicts and recognition are handled for a matrix team. -->

The project manager provides written performance input to line managers at the end of each stage and when a team member leaves the project. Workload conflicts are raised at the weekly project board; unresolved conflicts follow the escalation path in the communication plan. Contributions are recognised at stage gates and in the closure report.

## 9. Release plan

<!-- Guidance: Plan how and when people and equipment return, including knowledge handover. Late release planning damages relationships with line managers. -->

Resources are released when their work is complete and knowledge has been handed over.

| Role or resource | Planned release | Handover required | Release to | Notified by |
|---|---|---|---|---|
| *Example:* Vendor developers | YYYY-MM-DD (end of hypercare) | Code walkthrough, runbooks to IT operations | Vendor | 4 weeks before |
| *Example:* Business analyst | YYYY-MM-DD | Process documents to operations owner | Operations | 2 weeks before |
| *Example:* Test environments | YYYY-MM-DD | Data deleted per retention policy | Infrastructure | 2 weeks before |
| [Resource] | YYYY-MM-DD | [Handover] | [Destination] | [Notice] |

## Standard and licence note

Based on common project management practice for resource planning,
responsibility assignment (RACI) and team management. This template is
original text written for this collection. Template licence: MIT.