Plan and Manage Resources

Introduction

This lesson covers task 4 of the Process domain in the July 2026 PMP Examination Content Outline (Process carries 41% of the exam). The outline asks you to define and plan resources based on requirements, and to manage them: physical resources (equipment, materials, facilities, licences, cloud capacity) and team resources (people and their skills). Questions combine resource logic with people skills, estimating and schedule analysis, and they appear in predictive, agile and hybrid forms.

After this lesson you will be able to derive resource needs from scope, build a resource management plan, use a responsibility assignment matrix and resource calendars, apply resource leveling and smoothing correctly, handle capacity in agile teams, and respond to over-allocation, shortages and conflicts in a scenario.

Learning objectives

• Derive resource requirements from scope, schedule and quality needs.
• Build a resource management plan, resource breakdown structure, RACI and resource calendars.
• Estimate resource needs with bottom-up, analogous, parametric and three-point methods.
• Apply resource leveling and resource smoothing and know their effect on the critical path.
• Plan capacity for agile teams using velocity, availability and focus factor.
• Acquire, develop and release resources and manage physical resources.
• Respond to over-allocation, skill gaps, and unavailability in realistic scenarios.

1. From requirements to resources

Resources follow work. You cannot decide who and what you need before you understand scope, quality targets and the delivery approach. A reliable sequence is:

1. Start from the scope (WBS or backlog) and the schedule's activities.
2. For each work package, list the skills, quantities of people, equipment, materials and facilities required.
3. Estimate effort and duration; compute resource demand per period.
4. Compare demand with what is available (resource calendars, existing commitments, procurement lead time).
5. Fill gaps by acquiring, hiring, borrowing, training or procuring from vendors.
6. Write the result in the resource management plan and keep it current.

Physical resources have different constraints from people. Equipment has lead times and maintenance windows; materials have lead times, storage and waste; a test environment may be shared; cloud capacity scales quickly but costs scale with it; licences have counts and expiry dates. People have skills, availability, holidays, time zones and motivation. Both appear on the exam.

Resource breakdown structure

A resource breakdown structure (RBS) is a hierarchical list of resources by category and type, for example: Labour (Developers: frontend, backend; Testers: manual, automation), Equipment (Test devices), Materials (...), Facilities (Lab). It differs from the WBS (which decomposes deliverables) and the organizational breakdown structure (which maps work to departments). The RBS helps with estimating, cost aggregation and spotting scarce categories.

Example: deriving needs for a warehouse automation project

A distribution company installs 40 conveyor sections and a sorting software layer in 20 weeks. From the WBS, the planner lists: 3 mechanical fitters for 12 weeks, 2 electricians for 8 weeks, 1 PLC programmer for 10 weeks, a crane for 6 days, a temporary storage area for 4 weeks, and a software team of 5 for 14 weeks. The crane is rented through a procurement process that takes 3 weeks, so the planner puts the order date on the schedule. The PLC programmer is scarce: the company has only one, who is also assigned 50% to maintenance. The planner marks this person as a constraint and plans a contractor as backup.

2. The resource management plan

The plan describes how resources are identified, acquired, managed and released. Typical content:

• Roles, responsibilities and authority levels.
• Project organization chart.
• Resource acquisition approach: internal assignment, hiring, contracting, negotiation with functional managers.
• Resource calendars and availability windows.
• Training needs and development plan.
• Team management: team agreements, ground rules, decision making, conflict handling.
• Recognition and rewards.
• Compliance, safety and sustainability considerations: working-time rules, health and safety, environmental constraints, energy use of equipment (the 2026 outline lists sustainability among the inputs to consider).
• Release criteria: when and how resources leave the project.

Responsibility assignment matrix (RACI)

A RACI matrix maps activities to people and defines for each one who is Responsible (does the work), Accountable (one person who owns the result and approves), Consulted (two-way input) and Informed (one-way). The rule most tested is that each activity has exactly one Accountable and at least one Responsible. Having two accountable people or none is the standard defect.

Note that a person can hold both A and R on the same row; that is valid. A row with two As is not.

Team charter and agreements

Team agreements (working hours, meeting etiquette, decision rules, definition of done) reduce conflict. In agile teams, the working agreement is owned by the team, not imposed by the manager.

3. Estimating resources

Resource estimating uses techniques also used for duration and cost:

Worked example: three-point effort and team size

Statement. A configuration task is estimated by an engineer at 10 days optimistic, 16 most likely and 28 pessimistic (person-days). The work must be complete in 4 weeks (20 working days). How many engineers are needed, assuming 80% productive availability?

Reasoning.

1. PERT estimate = (10 + 4 x 16 + 28) / 6 = (10 + 64 + 28) / 6 = 102 / 6 = 17 person-days.
2. Productive days per engineer in 20 days = 20 x 0.8 = 16.
3. Engineers needed = 17 / 16 = 1.06, so more than one. Rounding up gives 2, but the second engineer would be used at about 6%.
4. The better answer is one engineer plus a half-time support person, or extending the duration slightly.

Solution. About 1.1 full-time equivalents; assign one engineer and 10-20% of a second, or accept 21 working days.

Why other choices are weaker. Assigning two full engineers wastes capacity and money, and adds coordination overhead. Using the optimistic estimate (10 days) would underplan risk. Ignoring productive availability would make the plan unrealistic.

4. Resource calendars, over-allocation and optimisation

A resource calendar states when a resource is available: working hours, holidays, leave, other commitments, and shared-equipment bookings. A histogram of resource demand per period shows peaks above capacity (over-allocation).

Resource leveling

Leveling adjusts start and finish dates to respect resource limits or to avoid peaks and valleys. It is used when resources are over-allocated, scarce or committed at specific times. It often extends the schedule and can change the critical path, because activities are delayed until the resource is free.

Resource smoothing

Smoothing adjusts activities within their free and total float so that demand stays within limits and does not exceed them in a spiky way. It does not change the critical path, because it only uses float. The resource may not reach perfect optimization.

Example: leveling in practice

Two testers are the only people able to run security tests. Activity A (security test of module 1) and activity B (module 2) both start on day 30 and each needs both testers for 5 days. The schedule needs 4 testers on those days. Leveling moves B to day 35. Since B was on the critical path, the project end moves from day 80 to day 85. The project manager reports the 5-day impact to the sponsor with options: hire two contract testers (cost) or accept the delay.

Other optimisation options include crashing (adding resources to critical activities at a cost) and fast tracking (overlapping activities, increasing risk). Those belong to schedule compression and are covered in the schedule chapter, but they interact with resources: crashing needs additional resources, fast tracking needs people working in parallel.

5. Capacity in agile teams

Agile teams do not usually assign tasks by resource calendar from a manager. The team is stable, cross-functional and self-organizing, and capacity is a team property.

• Capacity: available person-hours or points in an iteration, after holidays, meetings and support work.
• Velocity: the average points completed per iteration, used to forecast.
• Focus factor: the share of time spent on sprint work, often 60-80%.
• Stable teams: moving people in and out damages velocity; prefer bringing work to the team.
• Dedicated vs shared members: part-time allocation across projects reduces focus and increases context switching.
• T-shaped skills: members with depth in one area and breadth in others reduce bottlenecks.

Example: sprint capacity

A team has 6 members, a 10-day sprint, a focus factor of 70%, and 6 hours per day of productive time. Two members are away for 2 days each. Available person-days = (6 x 10) - (2 x 2) = 56. Capacity = 56 x 6 hours x 0.7 = 235 hours. The team's average velocity is 34 points. With reduced capacity (56 of 60 person-days, 93%), a realistic forecast is about 32 points. The Product Owner selects the highest-value stories up to that number, and the team does not stretch beyond it.

A common error is to give a team more work because "the deadline is near". Over-committing reduces quality and morale, and trust in forecasts. The better move is to reduce scope, remove impediments or add capacity early (with the warning that adding people to a late project can slow it, because of onboarding and communication overhead).

6. Acquiring, developing and releasing resources

Acquiring. Negotiate with functional managers, other project managers and vendors. Pre-assignment (named in the charter or bid), virtual teams, and procurement are all valid. Document commitments, since verbal promises vanish when priorities change.

Developing. Training, coaching, mentoring, co-location or virtual collaboration tools, recognition, and team-building. Tuckman stages (forming, storming, norming, performing, adjourning) help diagnose team state; the leadership style should adapt, with more direction early and more delegation later. Skill gaps found during planning should be closed by training, pairing, hiring or contracting, depending on time and cost.

Managing. Observe, give feedback, track performance, resolve conflicts, and revisit assignments. Use an issue log for resource problems and update the plan when assumptions change.

Physical resources. Check delivery dates, storage, inspection on arrival, safety, usage logs, maintenance, insurance and disposal. Just-in-time delivery reduces storage cost but increases schedule risk if a supplier fails. Sustainability can matter here: choosing shared or energy-efficient equipment, reducing waste and planning returns.

Releasing. Release people when the work is done, so that costs stop and they can start new assignments, with handover of knowledge. Remember to release equipment, cloud instances and licences too; forgotten cloud resources keep billing.

7. Responding to resource problems

Worked example: over-allocation

Statement. A project has one database administrator (DBA), allocated 100% to your project in weeks 5 to 8, but the histogram shows 160% demand in week 6 because two tasks overlap. The tasks have 4 days of free float. The DBA is also required by operations for a patch window in week 7.

Reasoning.

1. Identify whether either task has float: yes, 4 days of free float.
2. Use resource smoothing first: shift the less critical task within its float so that demand drops to 100% without changing the end date.
3. Check the week 7 conflict with the DBA's functional manager; agree on the patch window and update the resource calendar.
4. If smoothing is not enough, level the schedule and report the effect to the sponsor.

Solution. Smooth within float, update the calendar, and escalate only if the end date moves.

Why the others are weaker. Asking the DBA to work overtime treats over-allocation as the individual's problem and risks errors. Adding a second DBA immediately costs money when float is available. Ignoring the peak assumes the work will somehow fit.

8. Common pitfalls and exam tips

Pitfalls

• Planning resources before the scope and schedule are understood.
• Confusing RBS, WBS and OBS.
• Two Accountable people in the RACI.
• Ignoring calendars, leave and part-time availability.
• Assuming leveling never changes the end date.
• Applying "add more people" to every late project.
• Forgetting physical resources, lead times and release of equipment.
• Treating agile team members as interchangeable resources to be moved around.

Exam tips

• Smoothing uses float and keeps the critical path; leveling can delay the end date.
• When people are over-allocated, first look at float and the plan; then negotiate; escalate when the constraint belongs to the organization.
• In agile scenarios, capacity and velocity are team-owned. The project manager removes impediments and protects the team from overcommitment.
• A resource conflict between functional managers is negotiated, and unresolved issues go to the sponsor.
• Always update the resource management plan, the risk register and communicate after a change.
• A skill gap discovered in planning is a risk and a planning input; address it with training or acquisition, not by hoping.

9. Mini case study

Situation. You manage a 6-month data centre migration. The plan needs 4 network engineers during weeks 10 to 14. The functional manager offers 3, because one engineer is committed to an audit. The migration weekend cannot move because of a contractual maintenance window with the customer. Two engineers are junior and have not performed this kind of cutover. Equipment (two core switches) has an 8-week delivery time and is ordered; the vendor reports a possible 2-week delay.

Questions. What do you do?

Commented solution.

1. Quantify the gap: one engineer short in weeks 10 to 14, plus skill risk on cutover.
2. Check options in order: negotiate with the functional manager and the audit lead for partial availability; use float or smoothing if non-cutover tasks can shift; contract an external engineer for the cutover weeks (needs procurement lead time, so decide now).
3. Close the skill gap: pair juniors with the senior engineer in a rehearsal in week 8 and run a dry run of the cutover.
4. Address equipment: ask the vendor for a firm date and a penalty clause, identify temporary loan switches, and add the delay as a risk with a trigger date (switches not shipped by week 6).
5. Protect the fixed maintenance window: the date is a constraint, so the response has to be on resources, not on the date. Report the options and costs to the sponsor, record the decision and update the plan.

Why not accept 3 engineers? It exposes a fixed window to an avoidable risk. Why not postpone the window? The contract forbids it. Why not wait for the vendor? Risk responses need to start before the trigger.

Key terms

• Resource management plan: describes how resources are identified, acquired, managed and released.
• RBS: hierarchical list of resources by category and type.
• RACI: Responsible, Accountable, Consulted, Informed assignment matrix.
• Resource calendar: availability of each resource over time.
• Resource leveling: adjusting dates to respect resource limits; may extend the schedule.
• Resource smoothing: adjusting within float to even out demand; critical path unchanged.
• Capacity and velocity: available effort and average completed points per iteration.
• Focus factor: share of time available for sprint work.
• Team charter: the team's values, agreements and ground rules.
• Tuckman ladder: forming, storming, norming, performing, adjourning.

Summary checklist

• I derive resource needs from scope, schedule and quality.
• I can build an RBS, a RACI with one Accountable per activity, and resource calendars.
• I estimate resource effort with bottom-up, analogous, parametric and three-point methods.
• I distinguish leveling from smoothing and know their effect on the critical path.
• I plan agile capacity from velocity, availability and focus factor and avoid overcommitment.
• I plan physical resources, lead times, usage and release.
• I respond to shortages, over-allocation and conflicts with negotiation, float, and escalation.

Official sources

• PMI, PMP Examination Content Outline (July 2026): https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf (opens in a new tab)
• PMI, PMP certification: https://www.pmi.org/certifications/project-management-pmp (opens in a new tab)
• PMI, PMP exam change: https://www.pmi.org/blog/pmp-exam-change (opens in a new tab)