Resource planning for multiple projects: how to run one plan

A designer works on four client projects in the same week. Each project manager has a plan that books her for 15 hours. Each plan looks reasonable on its own. Together they add up to 60 hours for someone contracted for 37.5, and nobody sees the problem until Thursday, when two deadlines are already at risk.

Resource planning for multiple projects is the work of keeping every project your team touches in one plan, organised by person and by week, with a clear rule for who gets a person when two projects want them in the same week.

This guide covers how to build that one plan, how to set the priority order for shared people, how to handle a project that slips into the next one, and how to review it each week.

Why per-project plans fail when people are shared

Per-project plans fail because each project manager plans as if they have a person's full attention. A project manager books a developer for 20 hours on her project and has no reason to check the other three projects that developer is on. Every individual plan is correct. The total is wrong.

Teams usually find the problem in one of three forms:

• Hidden overbooking: the bookings for one person add up to more than their contracted hours, and the team finds out when the work is late.
• Invisible slack: someone has 10 free hours next week, but no project manager knows, because each one only looks at their own project.
• Slips that carry over: a client delays one project, and the person's hours on it land in a later week that is already booked for another project.

A business with two or three projects can hold all of this in one person's head. Past five or six concurrent projects with shared staff, the head stops being a reliable tool, and the team needs one plan that everyone can read.

The one-plan rule: people as rows, weeks as columns

The fix is one plan for the whole team, laid out with people as rows and weeks as columns. Each cell holds the hours booked for that person in that week, split by project. Project views still exist, but they are filters on the same plan, not separate documents.

In the illustration above, Maya's week 3 shows 46 hours against 37.5 contracted. In four separate project plans, nobody would have spotted that. In the grid, it is the only red cell on the page.

A workable cross-project plan has five columns of information for every booking:

Keep tentative bookings in the same grid, marked differently. A project you expect to sign next month competes for the same people as signed work, and the plan is only useful if both are visible together.

Set a priority order before the first conflict

Decide which project gets a shared person before two project managers ask for the same week. When the team agrees the rule in advance, nobody has to argue each conflict from scratch. Without one, the loudest client or the most senior project manager wins by default.

A priority order that most teams can apply in a few seconds:

1. Contracted deadlines with penalties or launch dates. Work tied to a fixed external date goes first.
2. Fixed-fee work already past 70% of budget. Every extra hour comes straight out of margin, and a delay usually means more hours, not fewer.
3. Retainers with an agreed monthly allowance. The client has paid for the hours, and a client who misses out on paid hours loses trust faster than one whose project date moves.
4. Time-and-materials work. The client pays for every hour, and dates on this work tend to have more room.
5. Internal and pipeline work. Pitches, internal projects and tentative bookings give way to everything above.

The order itself matters less than having one that everyone accepts. Write it down, share it with every project manager, and have the person who owns resourcing apply it when two bookings collide.

What happens when one project slips

When one project slips, the hours booked on it move into later weeks, and those weeks usually already belong to another project. The slip is one problem. The collision two or three weeks later is a second problem, and most teams only find that one when it arrives.

Here is a worked example. Sam, a developer, is booked 30 hours a week on Project A for weeks 1 and 2, then 30 hours a week on Project B from week 3. The client on Project A delays their content by two weeks. Sam's Project A hours move to weeks 3 and 4. Sam now has 60 hours booked in each of those weeks.

The project manager on Project A has three honest options:

The wrong option is the silent one: leave both bookings in place and hope Sam works 60-hour weeks. When the plan shows the collision on the day the delay is announced, the project manager can choose between the three options with two weeks of notice instead of two days.

Plan roles before you plan names

For work more than three or four weeks out, book a role instead of a named person. A placeholder such as "Senior designer" holds the hours, the skill and the cost rate until someone confirms who will do the work.

Booking roles first helps in two ways. With placeholders in the plan, you can read demand by skill across all projects and see whether you need another senior designer next quarter before any single project manager raises it. You also avoid locking in names too early, when the person you assumed would be free may well be on a different project by then.

Swap placeholders for names two to three weeks before the work starts, once the near-term schedule is stable.

Run a 30-minute weekly resource review

Hold a weekly review to keep the plan accurate. Without one, bookings go stale within a fortnight and people stop trusting the grid. A short, fixed agenda works better than an open discussion:

1. Red cells first. Go through every person booked over their available hours in the next three weeks, and decide on each one in the meeting.
2. Slack next. List anyone under 60% booked for the next two weeks and match them to work that is waiting.
3. Tentative work. Confirm or remove tentative bookings for pipeline that has moved.
4. Slips reported since last week. Trace each one forward and check the weeks it lands in.
5. Placeholders due for a name. Assign people to placeholder roles starting within three weeks.

Keep the review to the project managers and the person who owns resourcing. Decisions on client dates go to the account owner after the meeting, with the options already worked out.

Signs your multi-project plan is working

You can tell the plan is working when conflicts surface weeks ahead instead of days. A few practical checks:

• Overbookings are found in the weekly review, not reported by the person who is overbooked.
• Project managers check the shared plan before promising a date to a client.
• The plan matches reality: the hours people log each week are close to the hours they were booked.
• Nobody keeps a private spreadsheet of who is on what.

The last check is the most honest one. If a project manager still maintains their own copy, the shared plan is missing something they need, and it is worth asking them what.

Where Pike fits

Pike keeps every project in one capacity grid, with people as rows and dates as columns. Time off comes out of each person's available hours automatically, and you can book by total hours, hours per day, or a percentage of someone's capacity. Placeholder users hold skills, cost and bookings until a hire or a named person takes over. The resource planning features page shows the grid and the allocation options.

To check your numbers before changing tools, the free capacity calculator calculates available hours for a team from contracted hours, time off and non-billable time. For the steps that come before the multi-project plan, read the guides on resource allocation and resource capacity planning.

See every project your team is booked on in one grid: book a 15-minute walkthrough.

Frequently asked questions

How do you do resource planning for multiple projects?

Put every project into one plan with people as rows and weeks as columns, and record booked hours per project in each cell. Compare each person's total against their contracted hours minus time off, agree a priority order for shared people, and review the plan for 30 minutes each week.

What is the best way to track people across several projects?

A single cross-project grid is the most reliable way. Separate project plans each look correct while the person's total runs past their contracted hours. In a grid by person and week, you can read the total for every person on one screen.

How do you prioritise projects that share the same people?

Agree the order in advance. A common order is fixed external deadlines first, then fixed-fee work close to budget, then retainers, then time-and-materials work, then internal and pipeline work. The person who owns resourcing applies the order when two bookings collide.

Can you manage resource planning for multiple projects in a spreadsheet?

A spreadsheet works for a small team with a handful of projects. Past five or six concurrent projects, most teams fall behind on keeping bookings, time off and slips up to date, and project managers start keeping their own copies. That is usually the point to move to a resource planning tool.

How far ahead should a multi-project resource plan go?

Plan named people two to three weeks ahead and roles up to three months ahead. Near-term weeks need names because the work is about to start. Later weeks change too often for names to hold, and with role placeholders you can still read demand by skill without locking anyone in.