How to Get a Job For Project Managers

Learn how to write resume and interview

Leadership for Project Managers

Learn how to lead and drive project success.

Project Management with AI

From a beginner to project management professional.

Agile Project Management and SCRUM with AI

Learn to run Scrum and Agile with AI.

Resource requirements

Resource requirements is an analysis technique used to determine the types, quantities, skill levels, and timing of people, equipment, materials, and facilities needed to perform project work. It converts the WBS and schedule into time-phased demand to support planning, acquisition, and cost estimation.

Key Points

  • Defines what resources are needed, in what quantities, with which skills, and when they are required.
  • Derived from the WBS, activity attributes, and the current schedule or roadmap.
  • Covers labor and non-labor resources, including equipment, materials, facilities, and services.
  • Creates time-phased demand that supports budgeting, staffing, procurement, and resource leveling.
  • Includes explicit assumptions, calendars, productivity rates, and constraints.
  • Iterative and progressively elaborated as scope, estimates, and availability change.

Purpose of Analysis

The purpose is to ensure the project has the right resources in the right quantities at the right times to execute planned work. It enables realistic schedules and budgets, guides acquisition and procurement decisions, highlights bottlenecks, and informs trade-offs such as make-or-buy or sequencing changes.

Method Steps

  • Review scope and WBS to understand deliverables and work packages.
  • List activities and activity attributes, including duration assumptions and dependencies.
  • Identify resource types per activity: roles, skills, equipment, materials, facilities, and services.
  • Estimate quantities and skill levels needed per activity, using historical data and productivity rates.
  • Determine timing and usage profiles (full-time, part-time, effort per day, quantity per period).
  • Apply calendars, shifts, and availability constraints for teams, equipment, and facilities.
  • Aggregate activity-level needs into a time-phased view (e.g., weekly resource histogram).
  • Compare demand to known supply; note gaps, peaks, and conflicts.
  • Document assumptions, risks, and alternatives (e.g., acquire vs rent, different skills, sequencing).
  • Review with stakeholders and update the resource plan, estimates, and schedule as needed.

Inputs Needed

  • Scope baseline and WBS with work package details.
  • Activity list, activity attributes, and preliminary schedule or roadmap.
  • Resource breakdown structure, role definitions, and skill matrices.
  • Organizational and resource calendars, shifts, and location constraints.
  • Historical data, productivity rates, and benchmarks.
  • Cost rates for labor, equipment, and materials.
  • Risk register, assumptions log, and known constraints.
  • Procurement strategy, supplier lead times, and contract terms if applicable.

Outputs Produced

  • Activity-level resource requirements (types, quantities, skill levels, timing).
  • Time-phased resource demand (e.g., histograms or heat maps).
  • Lists of long-lead and critical-skill resources.
  • Updates to the resource plan, RAM/RACI, and resource calendars.
  • Inputs to cost estimates and budget based on resource rates and usage.
  • Assumptions, risks, and basis-of-estimate documentation.
  • Recommended options for addressing gaps (leveling, resequencing, outsourcing).

Interpretation Tips

  • Focus on periods with demand spikes; these often drive schedule risk.
  • Check critical-path activities for scarce skills or single points of failure.
  • Validate that demand aligns with calendars, holidays, and maintenance windows.
  • Assess feasibility against actual supply; propose alternatives where gaps exist.
  • Translate demand into cost using rate cards to confirm budget realism.
  • Revisit requirements after major scope or schedule changes and after learning from actuals.

Example

A project identifies 120 person-days of specialized testing over 6 weeks, two test environments, and 40 units of consumables. Aggregating by week shows a peak need of 5 testers in week 3, but only 3 are available. Options considered include shifting two activities, contracting 2 testers for weeks 2-4, or extending the schedule by one week. The analysis informs the cost impact and the recommended option.

Pitfalls

  • Listing only roles without quantities, timing, or skill levels.
  • Ignoring non-labor needs such as environments, tools, and materials.
  • Using single-point estimates without ranges or productivity assumptions.
  • Not accounting for calendars, learning curves, or ramp-up time.
  • Failing to aggregate and compare demand to actual availability.
  • Omitting long-lead items and supplier lead times.
  • Weak stakeholder review, leading to late surprises and rework.

PMP Example Question

A project schedule is approved, but the team suspects a mid-project bottleneck due to a scarce specialist role. What should the project manager do next to address this risk?

  1. Create a RACI matrix to clarify responsibilities.
  2. Perform resource requirements analysis to quantify time-phased demand for the specialist and compare it to availability.
  3. Submit a change request to increase the budget for staffing.
  4. Decide to outsource the specialist work immediately.

Correct Answer: B — Perform resource requirements analysis to quantify time-phased demand for the specialist and compare it to availability.

Explanation: You need data on when and how much of the specialist is required before choosing solutions such as leveling, resequencing, or outsourcing. The analysis informs, rather than assumes, the corrective action.

AI Systems with Claude, for Scrum Masters and Project Managers

Most AI pilots in project management do not fail on the model. They fail because somebody pointed the thing at a decision instead of at a task. This course is built around that distinction, and around the work that follows once you get it right.

Eight teaching sections, taught against one running project from the first lecture to the last. You watch a system get built, then you build the same one against your own sprint. Nothing here is a demo that works only on the example.

You finish with five working systems and you keep them. The sprint report machine turns your board export and standup notes into the report you currently write by hand. The retro intelligence system tells you what the team keeps saying, not just what it said this time. The stakeholder comms engine drafts the update in the register the audience expects. The backlog health monitor flags the quiet decay nobody has time to check for. The risk and dependency tracker follows the chains that actually bite.

Seventy-six working files ship with it, across four sections, so every system is built against real sprint data rather than material invented for a slide. Four sprints of retrospectives, board exports, standup notes, backlog and risk data.

Explore the Course


Run the drill before the incident runs you

Design, run and prove OT drills and tabletop exercises before an incident tests your team. OT Incident Drills and Exercises includes 24 lessons and practical exercise materials, delivered through HKSM Courses for US$47 one-time. 30-day money-back guarantee when 50% or less of the course has been consumed.

Explore the Course