Resource Plan
A resource plan records who is assigned to a project, in what role, for which periods, and at what percentage of their time. It converts a schedule into named people and days. Where a plan shows the work, a resource plan shows whether anyone is available to do it, and what that costs.
What it contains
The core of a resource plan is one row per person per assignment, with a start date, an end date and an allocation — usually a percentage of a working week, sometimes days per week. Around that sit the fields that make it usable: role, workstream, cost rate, whether the person is internal or contract, and which project or projects they are shared with.
Most plans also carry a time dimension across the columns — weeks or months — because the useful question is not "is this person on the project" but "is this person over-allocated in week 14". Displayed as a grid with the totals per person per week, the overlaps become visible without arithmetic. That is what the capacity planner is built around: allocations in, heatmap out.
Where the plan feeds a budget, the same rows carry a rate and produce a forecast cost, which is where a resource plan meets the budget tracker. People are the largest cost line on most IT projects, so the two views should reconcile.
How it is used
A resource plan is built at the point the schedule stabilises and maintained fortnightly or monthly after that. Three questions get asked of it. First, is anyone allocated above one hundred per cent in any week — the overlap that quietly turns into slippage. Second, which roles are unfilled against dates that are already committed. Third, what does the current allocation cost against the approved budget.
It also drives the conversations outside the project. Shared specialists — architects, DBAs, security reviewers, testers — are usually the scarce resource, and the plan is the evidence used to negotiate for them. At portfolio level the same data aggregated across projects is the constraint that portfolio reporting uses to sequence work.
Where it goes wrong
The most common error is planning at one hundred per cent availability. A full-time person does not deliver five days of project work a week: leave, line management, incidents, recruitment and other projects consume a share of it. Plans built on notional full availability are optimistic by a predictable margin, and the slippage looks like poor delivery rather than arithmetic.
The second is a plan that names roles rather than people. "Integration developer x2" is fine at estimating stage; carried into delivery it hides the fact that the two developers do not exist yet. Named allocations force the conversation.
The third is treating the plan as a one-off. It is built during mobilisation, agreed, and never updated as scope and dates move. Six weeks later it describes a project that no longer exists, and nobody trusts it enough to use it in a negotiation.
A fourth: peaks that were never modelled. Cutover weekends, UAT windows and hypercare all need people at intensities the steady-state plan does not show. The hypercare period in particular is often staffed from whoever happens to still be available.
Related terms
Capacity planning looks at total available supply against total demand, usually across projects; a resource plan is the demand side for one project. Allocation is the percentage of a person's time committed to a piece of work. Utilisation is the proportion of available time that is assigned. Run rate is what a resource plan costs per week or month. RACI assigns accountability for deliverables, not time.
Questions
How detailed should a resource plan be?
Weekly granularity is usually enough for delivery decisions. Daily allocation modelling adds maintenance effort that rarely changes the conclusion outside cutover periods.
What allocation percentage should be assumed for a full-time person?
That depends on the organisation. Recording the assumption explicitly matters more than the number, so that estimates and actuals can be compared later.
How does a resource plan relate to the budget?
Multiplying allocations by rates gives the labour forecast, which is the largest line on most IT projects. If the two views disagree, one of them is out of date.
Who maintains the resource plan?
Usually the project manager, with the PMO consolidating across projects. Line managers own whether the people are actually released.