Resource Planning

The Problem Was Visible Before It Arrived

The resource problems that hit during execution almost always have a planning-phase counterpart. Materials are ordered too late because no one tracked procurement lead times when building the schedule. A licensed specialist is needed in two places at once because two workstreams were scheduled in parallel without checking whether they shared the same person. A shared service that three teams each assumed exclusive access to is unavailable for the month the project needs it. A piece of equipment that has to be reserved four weeks in advance was never reserved at all. None of these are surprises in any meaningful sense of the word. The dependencies existed from the start. The specifications, the resource categories, the shared services, the lead times: they were all knowable during planning. What was missing was a systematic effort to find them before the schedule locked and commitments were made.

Resource planning is that search. It takes place during the planning phase when there is still room to adjust the schedule, revise the acquisition approach, and resolve conflicts before they are baked into a baseline. The output is a resource management plan that becomes the authoritative reference for every resource decision made during execution. It does not prevent resource problems entirely. Every project runs into them. What it does is reduce their severity, surface them earlier in the timeline, and preserve enough space for the team to respond deliberately rather than scramble reactively. A project that skips resource planning does not avoid resource problems. It defers the discovery until the moment when the schedule is tight, the team is already stretched, and there is no float left to absorb the surprise.

What "Resources" Actually Means

When project managers talk about resources, they typically mean people. That instinct is understandable. Human resources are the hardest to acquire, the most expensive to hire or contract, and the most difficult to predict across a multi-month project. But resource planning covers a broader category than headcount. Physical resources include materials, equipment, technology hardware, and facility space, all of which have lead times, specifications, and procurement sequences that belong in the plan. Organizational resources include shared services that other parts of the business own and control: procurement support, legal review, IT infrastructure, and facilities management. Failing to plan for non-human resources produces the same execution failures as failing to staff a role, because the project's schedule depends on all of them regardless of whether anyone formally tracked the dependency.

For a project like an office relocation, the materials dimension alone is substantial. A technology room fit-out requires cabling, connector kits, network racking, and climate control equipment, each with a specific quantity confirmed against an installation specification and a lead time that predates the installation window by weeks. Those are not items that can be ordered on short notice when the installation crew shows up. They require early procurement decisions that must be embedded in the schedule from the start. A resource management plan that covers only labor and leaves material procurement to be sorted out later will produce a schedule that looks complete on paper and fails the moment execution begins.

Managing Physical Resources Through Their Full Lifecycle

Physical resources introduce a set of management considerations that do not apply to human resources. A team member who joins the project late can be onboarded. Materials that arrive late, or that arrive but fail to meet specifications, cannot be onboarded. They must be replaced, returned, or substituted, each of which costs time the schedule may not have. Physical resource management begins before acquisition: the plan must account for procurement lead times that often extend weeks or months beyond the point when the need becomes obvious. Ordering materials "when we get to that phase" is a reliable way to discover that the lead time for a specific component exceeds the remaining schedule float.

Receipt and verification are the second management phase. Equipment that is accepted without inspection before it is integrated into work that depends on it becomes a downstream risk. Materials that pass a visual check but have not been tested against the installation specification may fail during installation. The physical resource plan should define how each significant resource will be verified upon arrival, who is responsible for that verification, and what the acceptance standard is. For complex equipment, this may mean a formal commissioning process. For bulk materials, it may mean a sample check against a specification sheet. For rented or leased equipment, it means confirming the condition meets operational requirements before the rental period begins and work is scheduled around it. Equipment that fails mid-project, with no spare inventory and no replacement lead time built into the schedule, is a planning gap that presents as an execution crisis.

The Resource Management Plan — Four Questions in Sequence

The resource management plan is built by answering four questions in order, and the sequence matters because each answer constrains the next. First: what does the project need? That means the complete resource inventory by type, category, quantity, skill level, and lead time. Every resource the project requires must appear here, not just the ones that are straightforward to acquire. Second: what does the project already have? That means identifying which resources are already committed, approved, or available from within the organization before any external acquisition effort begins. Starting acquisition before this step is answered means spending money and time on things the project already had access to. Third: how will the project acquire what it lacks? That means specifying the approach for each gap: hiring, contracting, internal borrowing from another team, or purchasing, with a named owner and a timeline for completing each acquisition. Fourth: who is accountable for what? That means assigning roles and responsibilities for every resource and every deliverable, so the team knows who performs each piece of work and who answers when a deliverable falls short.

Working these questions out of sequence, or skipping any of them, produces a plan with internal gaps. Acquisition strategies that do not match actual needs because the needs were never fully inventoried. Role assignments that cover some deliverables but leave others without a named owner. A plan that looks like a plan but does not function as one when execution begins. The resource management plan does not need to be long. It needs to answer all four questions clearly and specifically enough that a new team member reading it would know exactly what the project needs, how it is being acquired, and who is responsible for each piece.

Roles and Accountability — The RACI Matrix

Knowing who is on a project team is not the same as knowing what each person is responsible for. A project can have a complete org chart and still produce deliverables that fall into gaps, because two people each thought the other was handling something, or because a deliverable had a clear owner in the planning documents but that person changed roles mid-project and no one updated the assignment. The RACI matrix addresses this directly. It maps every significant deliverable or major activity against every relevant team member and assigns one of four designations to each intersection.

Responsible is the person who does the work. Accountable is the person who owns the outcome and makes the decisions. There should be exactly one accountable owner per deliverable: not one or two, exactly one. Consulted is the person who provides expert input before decisions are finalized. Informed is the person who receives updates on progress and outcome without being required to contribute. A well-built RACI prevents two specific failure modes. The first is duplicated effort: two people each assume the other is doing the work, and it does not get done until both discover the gap at the same time. The second is accountability gaps: a deliverable has clear contributors but no single owner, so when it falls short there is no one to escalate to. Both failure modes are common on projects where roles are discussed but never written down in a format that makes the assignments explicit and permanent.

The most consistent RACI error is having more than one accountable owner for a single deliverable. When two people share the A, each privately assumes the other is managing it. The deliverable has an apparent owner when things go well and no real owner when they do not. The discipline of enforcing a single A on every row surfaces organizational tensions and unresolved authority questions during planning, where they can be worked out through a direct conversation, rather than during execution, where the same tension surfaces as a blame discussion after something has already gone wrong. Building the RACI is often the first time a team has an explicit conversation about who actually owns each outcome, and that conversation itself is part of the value.

Resource Loading — Making Demand Visible

Assigning resources to activities on a schedule is the first step. Checking whether those assignments are feasible is a separate step that most teams skip. The assignment step names who will do a piece of work. Resource loading checks whether that person, piece of equipment, or shared service can actually deliver it, given everything else the schedule is asking of them during the same window. The two steps produce different outputs and catch different kinds of problems. A schedule with resource assignments but no loading check is a schedule that has named who will do the work without confirming the work can actually be done as written.

Resource loading takes the assigned schedule and projects each resource's demand week by week across the project timeline. The result almost always reveals conflicts. Two activities require the same specialist in the same week. A team member is assigned work that adds up to 140 percent of their available capacity during a critical phase. A shared service that three workstreams each assumed exclusive access to is needed by all three during the same month. The table below illustrates what this looks like in a loading check: highlighted cells are weeks where the assignment exceeds the resource's available capacity and requires a response before execution begins.

Loading is not a commentary on how hard anyone is willing to work. A 140 percent allocation does not mean the person is lazy or inefficient; it means the schedule as written asks them to do more than one person can deliver in the available time. Finding that in the loading check means the problem is still solvable through planning. Finding it during execution, when the schedule has no float and the team is already committed, means the same problem is now significantly more expensive to solve.

Resource Leveling — Resolving the Conflicts Loading Finds

When resource loading reveals an overallocation, leveling resolves it. Several options are available, each with a consequence. The first is delay: push one of the conflicting activities later in the schedule, using whatever float exists to spread the demand over time. This works when float is available and the delay does not affect the critical path. The second is split allocation: reduce the resource's hours per week on an activity and accept that the activity will take longer to complete. This resolves the overallocation but extends the duration, which may ripple forward into dependent activities. The third is additional resource: bring in another person, piece of equipment, or contracted service to absorb the demand the existing resource cannot cover. This resolves the loading conflict at a cost: the additional resource has a price, and there is often onboarding or coordination time that affects the schedule even as it relieves the original overallocation. When none of those three resolves the conflict cleanly, other approaches include resequencing discretionary dependencies to create separation between competing demands, substituting the over-allocated resource with another who has available capacity, or contracting the activity out to an external provider.

The uncomfortable fact about resource leveling is that it sometimes extends the project's end date. That is a significantly better outcome than refusing to acknowledge the overallocation during planning and discovering the same problem during execution, when float is gone, the team is already committed, and the sponsor is expecting progress rather than replanning conversations. Leveling during planning is an honest accounting of what the resource pool can actually deliver and what the schedule needs to reflect. The same conversation during execution costs more, takes longer, and produces worse outcomes, because by then the options for delay and redistribution have already been consumed by the work that ran before the problem surfaced.

The Reference Point That Makes Adjustment Possible

Resource planning during the planning phase creates a documented baseline: what was assumed, what was committed, and what each resource was expected to deliver across the project timeline. When execution diverges from that baseline, which it will, the plan tells the project manager exactly where the gap opened, how large it is, and what was originally assumed in that space. A project without this baseline is managing by feel. It can observe that something is going wrong, but it cannot measure how far off it is from what was originally planned, because there was no original plan expressed precisely enough to compare against reality.

The resource management plan does not prevent change. It provides a reference point precise enough to change from deliberately. When a team member leaves mid-project, the plan identifies what activities that person owned and what skills the replacement must cover. When a material order is delayed, the plan shows which downstream activities depend on that delivery and how much schedule float is available before the delay becomes a critical path problem. When scope changes, the plan provides the basis for calculating what additional resource the change requires and what that will cost. Managing without a resource plan means every adjustment is made from memory and inference rather than documented planning logic. That distinction, between a controlled adjustment from a baseline and an improvised response to conditions that were never formally understood, is where resource planning delivers its real value.

What's Next

The next chapter, Communications Planning, moves from the internal question of who does what to the broader question of who needs to know what, when, and through which channel. A resource plan and a RACI matrix define accountability. A communications plan ensures that accountability is exercised in an environment where the right people have the right information at the right time to act on it.

Reflect

• Where in a current or recent project do resource dependencies exist that were never formally documented? What did it cost when those dependencies surfaced during execution rather than during planning?
• How does your team currently build RACI matrices? Do they consistently enforce a single accountable owner per deliverable, or do some rows carry shared or unassigned accountability?
• When was the last time your project ran a resource loading check on the schedule before execution began? What did it reveal, or what might it have revealed if it had been done?
• What is the difference, in your experience, between a project that discovers a resource constraint during planning and one that discovers the same constraint during execution? What changes about the options available to the team?