team
A resourcing template gets searched for at a specific moment. Someone has asked whether the team can take on a piece of work starting in three weeks, and the honest answer is not known. The task list says what is outstanding. It does not say who is already full.
Most downloadable templates answer a different question. They produce a beautiful grid of names against weeks, filled with percentages that were typed in once and never updated, and they are abandoned within a month. The ones that survive share a property: they compute something. Capacity minus commitment equals what is left, and the number changes when the plan changes.
Before choosing columns, it helps to name what the template is for, because resource planning gets used for three incompatible jobs and a single grid cannot serve all three.
Can the team take this on? A capacity question, asked weeks ahead, answered at the level of a person and a week. This is the one that causes the search.
Who is overloaded right now? A triage question, asked about this week, answered by looking at assignments rather than forecasts.
What did the work actually cost? A reporting question, answered from time records after the fact, and impossible to answer from a plan.
The third job needs timesheets and does not belong in a resourcing template at all. The second is better answered by the tool the team already works in, because forecasts go stale and assignments do not. A resourcing template should be built for the first question only, and it should be allowed to be approximate. A forecast that is roughly right and current beats one that was precise in July.
A working template has five kinds of column and nothing else. Extra columns are where these things go to die.
Person and role. One row per person, not per task. If the same person appears twice because they work on two projects, the arithmetic for that person stops being visible, which is the entire point.
Gross capacity for the period. The hours or days in the period, before anything is taken out. For a full-time person and a five day week this is a constant, and keeping it as a column rather than a formula means part-time and shared people fit the same grid.
Deductions. Booked leave, public holidays, fixed internal commitments such as a standing meeting block or a support rotation. Anything already spoken for before project work is considered.
Net capacity. Gross capacity minus deductions. This is the number that should be compared against commitments, and it is the number almost every abandoned template leaves out.
Committed work, one column per project. The amount of this person's net capacity already promised to each active piece of work, in the same unit as capacity.
The template then computes two figures per person per period. Remaining capacity is net capacity minus the sum of the commitments. Load is the sum of the commitments divided by net capacity, expressed as a percentage.
Those two numbers answer the question the reader came with. Remaining capacity says whether the work fits. Load says how close to the edge the person already is, which is the information that decides whether a yes is safe.
Coordination is work. Reviewing someone else's output, answering questions, onboarding a contractor and attending the meetings that keep a project aligned all consume the same hours as delivery, and none of it appears on a task board as an assignment.
The fix is not to estimate it. It is to measure it once. Pick a past month, count the hours a senior person spent on work that was not their own deliverable, and carry that figure forward as a standing deduction for that role. It will be larger than expected, and it explains most of the cases where a plan that added up on paper slipped anyway.
The unit decides how much maintenance the template needs, and the common mistake is choosing a finer unit than the decision requires.
| Unit | Good for | Cost |
|---|---|---|
| Percentage of a person per week | Deciding whether work fits at all | Least maintenance, cannot answer cost questions |
| Days per week | Teams where work is naturally day-shaped | Moderate, needs updating when scope changes |
| Hours per week | Billing, fixed-price quoting, regulated work | Highest, and precise numbers invite false confidence |
For the question this template exists to answer, percentage of a person per week is almost always enough. Half a person for four weeks is a decision anyone can make. Nineteen hours a week for four weeks is the same decision wearing a disguise, and it costs more to keep accurate.
Weekly buckets also beat daily ones for forecasting. Work does not arrive in day-shaped pieces, and a daily grid multiplies the maintenance by five without improving the answer. Keep daily detail for the current fortnight if the team needs it, and plan at the week level beyond that.
Take a team of five with a four week window ahead, planning in percentages. Gross capacity per person is 100 percent of a week. One designer has a week of leave booked in week three, which is a 25 percent deduction across the window. A senior developer carries a support rotation worth 20 percent every week. Both facts go in the deductions column, not in anyone's head.
Net capacity for the window is therefore 5 people times 4 weeks, or 20 person-weeks, minus 1 week of leave, minus 0.8 person-weeks of support, which leaves 18.2 person-weeks.
Committed work across two live projects sums to 15 person-weeks. Remaining capacity for the window is 3.2 person-weeks, and load across the team is 82 percent.
The new request is estimated at 4 person-weeks and has to be done by the end of the window. The grid has already answered the question: it does not fit, and it misses by roughly a week of one person. That is a far more useful answer than no, because it names the size of the gap. The conversation becomes a choice between moving the date by a week, dropping something worth a week from a live project, or adding a person for a week, and all three options are now priced.
The same grid also catches the pattern that costs the most. A team at 82 percent load looks comfortable and usually is not, because the remaining 3.2 person-weeks are not distributed evenly. If two of the five people are at 100 percent and the slack sits with a person who cannot do the work in question, the team has no usable capacity at all. Load per person is the figure to read, and a team average is the figure that misleads.
Three kinds of person do not fit a simple name-against-week grid, and each one has a fix that keeps the arithmetic honest.
People shared with another team. A developer who belongs half to platform work and half to a product group has a net capacity of 50 percent from the product group's point of view, not 100 percent with a note attached. Put the other team's claim in the deductions column and treat the remainder as the whole person. A grid that shows 100 percent capacity and relies on someone remembering the split will promise that person twice.
Part-time and compressed schedules. These are the easy case as long as gross capacity is a column rather than a formula. A three day week is 60 percent gross, and every downstream figure follows without a special case. The failure mode is templates that hard-code a full week, which force part-time people into a footnote.
Contractors and anyone with a lead time. Capacity that can be bought is not the same as capacity that exists. A contractor who takes three weeks to start is unavailable for the window most requests concern. Keep potential capacity in a separate block below the grid, clearly labelled, and never let it total into remaining capacity. Mixing the two is how a team commits to a date on the strength of a person who has not been contacted yet.
There is a fourth problem that is not a row at all. If only one person can do a particular kind of work, that person's remaining capacity is the team's remaining capacity for it, and the team total is irrelevant. A single skills column, marking who can take which class of work, turns a misleading average into a usable answer. It is the cheapest column in the template and the one most often missing.
A spreadsheet is the right place to start, and it fails in three predictable ways.
It goes stale because it is a separate artifact. Commitments live in the plan, capacity lives in the grid, and every change has to be entered twice. The second entry is the one that stops happening, usually in the third week.
It cannot show what is behind a number. A cell says 60 percent. It does not say which tasks make up that 60 percent, so a conversation about reducing someone's load turns into an archaeology exercise.
It has no idea when work moves. A task slipping by a week should move the commitment into the following week automatically. In a grid, someone has to notice and retype it.
The tools that solve this read capacity from the same records that hold the work, which is why resource views tend to sit on the upper paid tiers. As published in September 2026, Asana places resource management on its Advanced plan, identifying who is overloaded within one portfolio, and puts organisation-wide workload and capacity planning on Enterprise. ClickUp includes native time tracking from its Unlimited plan at $7 per user per month billed annually. monday.com starts at two seats and three boards on its free plan, with timeline and Gantt views beginning on Standard.
That pricing pattern is worth understanding rather than resenting. Automatic capacity views require the tool to hold estimates, assignments and dates on every item, which is a discipline most teams have not established yet. A spreadsheet grid maintained weekly by one person is a legitimate answer for a team of six, and it is a better answer than an unused feature on a plan nobody has bought.
The middle path is to keep the arithmetic in a grid and keep the commitments visible in the tool the team already opens, so that a board, a Gantt view and a calendar show the same items and the grid only has to carry capacity and deductions.
Build the five columns for the next four weeks only, with one row per person, and put the leave and the standing commitments in before any project work. Read load per person rather than the team average, and update it once a week at the same time as the plan review. If the two artifacts drift apart within a month, the commitments need to move into the tool the team works in rather than the grid: Pinateca is free for up to five people and ten boards, with board, Gantt and calendar views over the same cards, which is enough to keep assignments and dates in one place while the capacity arithmetic stays in the grid.
Five kinds of column and nothing more: person and role, gross capacity for the period, deductions such as leave and standing commitments, net capacity, and one column per active project for committed work. The template then computes remaining capacity and load per person. Anything else tends to be reporting dressed up as planning.
Percentages of a person per week are enough to answer whether work fits, and they cost the least to maintain. Hours are necessary when the output feeds billing, a fixed-price quote or a regulated record. Planning in hours when the decision only needs percentages produces precise numbers that go stale faster.
Four to six weeks for most teams, with weekly buckets. Beyond that the estimates are guesses and the grid becomes a maintenance burden that nobody reads. Longer horizons are better handled at the level of a project needing roughly one or two people, rather than a named person against a named week.
Usually because net capacity was never calculated. Leave, holidays, support rotations, meetings and the coordination work senior people absorb all consume capacity before project work starts. A grid that compares commitments against gross capacity rather than net capacity overstates what the team can take on by a wide margin.
A spreadsheet is good enough while one person updates it weekly and the team is small. It fails when the commitments in it have to be maintained separately from the plan the team works in, because the second update is the one that stops happening. That is the point at which capacity should be read from the same records that hold the tasks.