A resource plan template needs five fields: person, client or project, planned hours per week, the weeks the allocation runs, and a planned-vs-tracked status column. The template is the easy part — what makes a resource plan work is that the last column is filled from tracked time every week, not from someone's memory of the plan.
Quick Answer
Build the plan as a table: one row per person per client per week, with a per-person total row compared against available hours. Then compare planned to tracked hours weekly — either manually or by importing the plan into Rize Resourcing, which shows the two side by side automatically.
The Template
One row per person per client per week, plus a total row per person against available hours — that is the whole structure.
| Person | Client / Project | Planned hrs/wk | Weeks | Tracked vs planned |
|---|---|---|---|---|
| Mia | Acme retainer | 10 | Oct–Dec | 11.5 / 10 (+15%) |
| Mia | Cobalt fixed fee | 10 | Oct–Nov | 9 / 10 (−10%) |
| Jordan | Acme retainer | 5 | Oct–Dec | 5.2 / 5 |
| Jordan | Brightline retainer | 6 | Oct–Dec | 8.4 / 6 (+40%) |
| Sam | Brightline retainer | 4 | Oct–Dec | 3.5 / 4 |
| Jordan total | — | 11 | — | 13.6 / 11 — over |
Three rules that keep the template honest:
Hours, not percentages. "Jordan is 30% on Brightline" survives until Jordan takes PTO. Hours are what the client consumes and what the invoice reflects.
Available hours, not contracted hours. A person's row total should be compared to contracted hours minus PTO, holidays, and fixed internal time. A plan that assumes 40 available hours is over-allocated before the week starts.
A status column that is actually filled in. The tracked-vs-planned column is the point of the template. If it is empty, the document is a forecast.
The Staffing Plan Math Behind It
Sum the client-side of the plan, then check it against the team's real available hours — the gap in either direction is the staffing signal.
Add up every client's planned weekly hours. That is demand. Then sum each person's available hours minus fixed internal time. That is supply. Three outcomes:
Demand > supply: the plan is over-committed — cut scope, push timelines, or hire. This is the case for raising prices too: if you are structurally over-committed, the work is priced below its demand.
Demand ≈ supply: fine, but fragile — one resignation or one new client and the plan breaks. Track utilization per person so the slack lands deliberately instead of evenly.
Demand < supply: bench capacity — decide whether it funds business development, internal work, or whether the staffing plan is ahead of the sales pipeline.
Why the Spreadsheet Version Fails
A spreadsheet resource plan dies at the comparison step — the planned side is static and the actual side requires someone to re-export timesheets every week.
The failure pattern is always the same: the plan is built carefully in week one, the comparison column gets filled once, and by week four the spreadsheet is a snapshot of a plan nobody is running. Meanwhile the actual work drifted — a client ran hot, a project slipped, and the document that was supposed to catch it was three exports stale.
The fix is keeping both sides live. In Rize, Resourcing imports the plan from CSV — the same columns in the template above — and shows planned allocations beside automatically tracked hours in Tracked Time, per member per week, with working days, holidays, and PTO accounted for. The comparison runs itself.
Keeping the Plan Honest: The Weekly Review
Review planned vs tracked weekly per person and per client; a gap above ~10% for two consecutive weeks gets re-based, rebalanced, or re-scoped.
Three questions, in order:
Which client ran hot? A retainer at 140% of its weekly allocation for two weeks is a scope conversation — the tracked hours are the evidence. See resource planning for retainer agencies for the re-scoping process.
Which person is over? Someone consistently above planned load is either misallocated or overloaded — rebalance before it becomes attrition.
Which estimate was wrong? Work that always takes 50% more than planned is not an execution problem, it is a planning error — update the template.
For the capacity side of this picture — whether the team has enough hours at all — see capacity planning and the utilization rate calculator.
