Resource capacity planning

You show, person by person and week by week, whether the work fits the people, before the overload shows up as missed dates and tired staff. The standard: capacity is real (contracted hours minus leave, holidays and the work that never stops), demand includes day-to-day work as well as projects, and every overloaded week comes with options the owner can choose between.

When to use

• "Can we take on the Smith project in November?"
• "Ana says she's swamped. Is she?"
• "Do we need to hire, or just reshuffle?"
• "Plan the team's next quarter."
• Monthly, or whenever a new project is about to be agreed.

What you need

• The people: role, contracted hours per week, working pattern, and any standing duties (support rota, management, admin).
• Leave and public holidays for the period: calendars connected on the Connections page (Google Calendar, Outlook), the HR or leave system if connected, your own browser signed in by the owner, or a list from the owner. Public holidays for each person's region from the holidays package or web_search.
• Demand: day-to-day work (hours per week per person, from timesheets or an honest estimate by the person), and project work from the plans (see project-plan-and-timeline), by week and person or role.
• Where the team tracks work, if connected (Asana, Jira, Linear, Trello, ClickUp, Notion), to read assignments.
• The owner's planning targets for utilisation by role, or agreement to use the defaults below.

Method

1. Set the horizon and grain: weeks, for the next 8 to 13 weeks. Further out, plan by role, not by person.
2. Capacity per person per week = (contracted hours minus leave and public holidays) x plannable share. The plannable share leaves room for meetings, email, interruptions and learning. Common planning targets: around 75% to 80% for individual contributors, 60% to 70% for managers, 50% to 60% for people on support or on-call duty. Use measured figures from timesheets if the business has them.
3. Demand per person per week: day-to-day work first (it never stops), then each project's hours from its plan. Ask the people doing the work to check their own rows (ask_teammate).
4. Utilisation = demand / capacity, per person per week. Build the workbook with execute_code (tested code in references/capacity-workbook.md), with a colour heat map: over 100% red, 90% to 100% amber, 60% to 90% green, under 60% pale (spare capacity or missing demand). Tie the formulas to a Python recompute.
5. Read the heat map.
   • Red weeks: who, which weeks, by how many hours.
   • Sustained amber (3 weeks or more): a risk even if never red.
   • A person red while a colleague with the same skills is pale: a reassignment.
   • Weeks where capacity is zero but demand exists (leave clashing with a deadline).
   • Skills bottleneck: one role red across many weeks means the plan is limited by that role, whatever anyone else does.
6. Generate options for each overload, with their effect in hours and on dates:
   • Resequence: move non-critical tasks within their float (see project-plan-and-timeline).
   • Reassign to someone with the skill and room.
   • Reduce day-to-day load temporarily (pause a report, rotate support duty).
   • Buy in help: contractor or agency, with cost and lead time.
   • Cut or defer scope, or move a deadline.
   • Hire, if the overload is structural (the same role red for most of the horizon). Limit work in progress: starting fewer projects at once usually finishes all of them sooner.
7. Recommend and record. Put the options and your recommendation to the owner. Never commit people's time, change their assignments or tell them their priorities changed without the owner's go-ahead. Once decided, update the plan and the workbook.
8. Refresh monthly or when a project is added, with cronjob; keep last month's version to compare planned against actual hours, and adjust the plannable share if people consistently deliver less or more than planned.

Output

• capacity-plan-<period>.xlsx: People (hours, plannable share, leave by week), Demand (person, work item, hours by week), Utilisation (heat map), Role summary (capacity vs demand by role and week), Options.
• A show_card with the overloaded people and weeks, and the top options.
• A short note for the owner:

Capacity, 12 Oct to 28 Dec (12 weeks)

Overloaded
  Kim (IT): 116% for 6 of the next 8 weeks; leave 23 Nov and 30 Nov while 18 h/week of
  system work is planned. The new-system project is limited by Kim.
  Jo (Ops lead): 123% from 23 Nov when the warehouse move starts alongside the system project.

  Ana (Ops): on leave the week of 2 Nov with 29 h planned.

Room
  Lee: 50% outside the system build, 83% during it; Ops skills overlap with Ana.

Options
  1. Start the warehouse move 2 weeks later (uses Jo's room after the system goes live). No cost.
  2. Contract IT help for 6 weeks at about 18 h/week. Cost <quote>. Keeps the 18 Nov date.
  3. Ana's leave week: move her 14 project hours into weeks where the task has float; cover her
     15 h of order processing with Lee's 5 spare hours plus a temp or Jo.
Recommendation: 1 and 3 now; decide on 2 by 20 Oct if Kim's tasks slip.

Checks before you finish

• Capacity subtracts leave and public holidays for each person's region.
• Day-to-day work is included, not only projects.
• People confirmed their own demand rows, or the rows are labelled as estimates.
• The workbook's formulas match the Python recompute.
• Every red cell is either explained by an option or listed as unresolved.
• Nothing was assigned, moved or promised to anyone without the owner's decision.

Pitfalls

• Planning people at 100%. Meetings, email and interruptions are real; there is no slack for surprises.
• Ignoring day-to-day work. Projects get planned; the inbox does not stop.
• Treating hours as interchangeable. A writer's free hours do not help an IT bottleneck.
• Adding people late to fix a crunch. New people need onboarding from the people who are already overloaded.
• Planning far ahead by name. Beyond a quarter, plan by role.
• A plan nobody checks against actuals. Compare planned and actual hours monthly.

See also

• project-plan-and-timeline, cross-timezone-scheduling, operations-metrics-dashboard.