Resource plan templates: seeing who is overloaded before deadlines slip
The deadline slipped, and looking back, the reason is obvious. The same developer was carrying the final week of two projects at once, plus a support rotation nobody had written down. Every individual project plan looked fine. Nobody had put the plans side by side with the person as the unit.
That is the job of a resource plan. It is not a project plan with more columns. It flips the view so that people are the rows and time runs across, and the question it answers is whether the work assigned to each person in a given week is actually possible. For a small team running several projects, it is often the missing document that explains why schedules keep slipping even when each project is planned carefully.
This article covers what a resource plan template needs, how to fill it without inventing numbers, and when a spreadsheet stops being the right place for it.
What a resource plan is for
A resource plan answers three questions that project plans do not.
Who is overloaded, and when?
Project plans show tasks against dates. They do not add up what one person is carrying across every project. A resource plan does exactly that addition, so a week where one person has twice their capacity stands out before it arrives.
Who has room?
The opposite problem is just as costly. When a lead does not know who has capacity, new work goes to whoever is most visible or most reliable, which is usually someone already busy. A resource plan shows the quieter weeks and the underused people.
What happens if something moves?
When a client pushes a date back by two weeks, the effect on that project is obvious. The effect on everything else that person was going to do in those two weeks is not. A resource plan lets the lead see the knock-on effect before agreeing to the change.
What it is not
A resource plan is not a timesheet. A timesheet records hours that were worked. A resource plan projects hours or effort that will be needed. The two are related, because actuals from timesheets are the best way to improve future estimates, but mixing them in one sheet makes both harder to read.
It is also not a performance tool. If people suspect it is being used to judge who works hardest, they will stop reporting realistic numbers and the plan becomes useless.
The columns a template actually needs
Most resource plan templates found online include far more than a small team will maintain. The minimum that works is short.
| Column | Purpose | Example |
|---|---|---|
| Person | The row owner | A designer, a developer |
| Capacity per week | Realistic available time | 30 hours, not 40 |
| Project | Which project the work belongs to | Website rebuild |
| Task or workstream | What the time is for | Checkout design |
| Week columns | Planned effort per week | 12 hours in week 38 |
| Total per week | Sum across all projects | 34 hours |
| Over or under | Total compared with capacity | 4 hours over |
Capacity is less than the working week
The most common mistake is setting capacity to a full working week. Nobody spends a full week on planned project work. Meetings, email, support requests, reviews, and interruptions take a real share of every week. Many teams set project capacity somewhere well below contracted hours and then adjust after comparing plans with what actually happened. The right figure for a given team comes from its own records, not from a rule of thumb.
Leave and fixed commitments go in first
Before any project work is entered, block out holidays, planned leave, training, and recurring duties such as a support rotation. These are certain. Project estimates are not. Entering the certain items first stops them from being squeezed out later.
Effort units: hours, days, or points
Hours are easiest to compare with capacity. Half days are coarser but often more honest, because few people can estimate a task to the hour weeks in advance. Pick one unit and use it for everyone. Mixing units across rows makes the totals meaningless.
Filling the plan from real tasks
A resource plan is only as good as the estimates in it. The trap is filling it top-down, with a lead guessing how much of each person a project will need. The better approach builds it from tasks.
Start from the task list
If each project already has a task list with owners and due dates, the resource plan can be assembled from it. Each task gets an effort estimate from its owner. The effort is spread across the weeks between start and due date. Summing by person and week gives the plan.
Let owners estimate their own tasks
People who do the work estimate it better than people who assign it. They also commit more readily to an estimate they gave themselves. The lead's role is to question estimates that look far off, not to write them.
Spread effort realistically
A ten-hour task due in three weeks is rarely done evenly at a bit over three hours a week. It tends to happen in the week before the due date. Spreading effort evenly makes plans look smoother than reality. Placing most of it near the due date gives a more honest picture of crunch weeks.
Update it when tasks change
A resource plan built once at kickoff is out of date within a fortnight. The plan needs updating whenever a task is added, reassigned, or rescheduled. In a spreadsheet this is a manual step and the one most often skipped. This is the main reason spreadsheets struggle beyond a handful of people and projects.
A short worked example
Consider a designer with a planned capacity of 25 hours a week. Project A has three design tasks due over the next three weeks, estimated by the designer at 8, 10, and 6 hours. Project B has one large task of 20 hours due at the end of week two. A recurring support duty takes 5 hours every week.
Spread naively, the weeks look fine. Placed realistically, most of Project B's 20 hours falls in week two, alongside Project A's 10-hour task that is also due that week, plus the 5 hours of support. Week two now holds well over 25 hours, while week three is light. The fix is simple once it is visible: start Project B's task in week one, or ask whether Project A's second task can move to week three. Without the plan, the first sign of trouble would have been a missed date.
The example also shows why fixed duties go in first. The 5 hours of support are easy to forget because they never appear on a project task list, yet they are the one commitment that cannot be moved.
Reading the plan: spotting overload early
Once the plan exists, reading it well matters more than making it detailed.
Look for red weeks, not red people
A single week over capacity is normal and usually manageable. Three consecutive weeks over capacity for the same person is a warning. A resource plan should make streaks visible, not just individual cells.
Watch for single points of failure
If one person appears on the critical path of every project, the team has a dependency on that person regardless of their total hours. A holiday or illness in the wrong week will delay everything at once. The resource plan is where this shows up, because that person's row contains every project name.
Check the weeks around milestones
The weeks just before a milestone are where estimates are most likely to be wrong in the direction of more work. Review, fixes, and last-minute changes cluster there. A plan that shows a person at exactly full capacity in a milestone week is really showing them over capacity.
Compare plan to actual
Every few weeks, compare what the plan said with what happened. If timesheets or task records show that design work consistently takes longer than planned, adjust future estimates. Over a few months this turns guesses into calibrated numbers.
Resolving overload once you see it
Spotting overload is useful only if the team acts on it. There are a limited number of levers, and they are worth trying in roughly this order.
Move the date
If a deadline is internal or flexible, moving it is often the cheapest fix. The resource plan provides the evidence needed to have that conversation with a client or sponsor.
Move the work
Reassign tasks from the overloaded person to someone with capacity. This works only when the skills overlap. The resource plan shows who has room. Whether they can do the task is a separate question.
Reduce the work
Cut or defer scope. Not every feature needs to ship in the first release. Tasks explicitly moved to a later phase free capacity without anyone working longer.
Split the dependency
When one person is the bottleneck because only they can review or approve, the longer-term fix is to share that knowledge. This does not solve this month's problem, but it stops the same problem next quarter.
Accept it deliberately
Sometimes a crunch week is unavoidable. The difference between a planned crunch and an unplanned one is that the person knows in advance, other commitments are cleared, and the following week is lighter. The plan makes that possible.
Spreadsheet template or a tool
A spreadsheet template is a reasonable place to start, and for a team of three or four with one or two projects it may be all that is needed. The trade-offs appear as the team grows.
| Spreadsheet template | Task management tool with a resource view | |
|---|---|---|
| Setup | Minutes | Depends on existing task data |
| Source of data | Typed in separately | Built from assigned tasks |
| Keeping it current | Manual after every change | Updates when tasks change |
| Seeing tasks behind a number | Requires cross-referencing | Click through to the task |
| Cost | Usually free | Varies by tool and plan |
| Best fit | Very small, stable teams | Several projects, frequent changes |
The main weakness of a spreadsheet is that it is a second copy of information that already exists in the task list. Every reassignment has to be made twice, and the resource plan drifts. A tool that shows people against dates directly from assigned tasks removes that duplication.
If you already run projects on a board tool, check whether it has a view with people down the side and dates across the top. Feature lists such as /features usually describe it as a resource or workload view. The side-by-side table at /compare also shows which tools include which board types.
What to change first
This week, list every person on the team with a realistic weekly capacity, block out known leave, and add the next four weeks of assigned work from existing task lists. Look only for people over capacity for two or more weeks in a row, and resolve those first. If you want the resource view built directly from assigned cards, Pinateca includes it on the free plan for up to 5 people and 10 boards.
Q1. What is the difference between a resource plan and a project plan?
A project plan lists the tasks, dates, and owners for one project. A resource plan takes every project the team is running and adds up the planned work per person per week. The project plan tells you whether one project is on schedule. The resource plan tells you whether the people can actually deliver all the schedules at once.
Q2. How far ahead should a resource plan look?
For most small teams, four to eight weeks is a practical horizon. Beyond that, estimates are rough and plans change too often to be worth detailed entries. Longer-term planning can be kept at a coarser level, such as which projects will need which people each month.
Q3. Should capacity be set to the full working week?
No. Meetings, email, support, and interruptions consume part of every week, so planned project capacity should be lower than contracted hours. The exact figure depends on the team. Comparing plans with recorded actuals over a few weeks gives a figure grounded in how that team actually works.
Q4. Can a resource plan template work in Excel or Google Sheets?
Yes. A sheet with one row per person and project, week columns, and a total row compared against capacity is enough for a small, stable team. It becomes hard to maintain when tasks are reassigned often, because every change has to be made in both the task list and the sheet.
Q5. How often should the resource plan be updated?
Whenever work is added, reassigned, or rescheduled, and at least once a week in a short review. A plan updated only at kickoff stops reflecting reality within a couple of weeks. Building the plan directly from the task list removes most of the manual updating.
