Spare hours cannot always be added together
A resource plan compares the work required with the availability of people and other resources.
The team has 37 planned hours in total and 37 hours of tasks. Everything appears to fit. But the designer needs 21 hours with only 19 available, while the developer and editor each have an hour spare. Those two hours cannot automatically be transferred to the designer: skills, access and work sequence differ.
We will examine an illustrative plan for a small event page. All estimates are hypothetical, used to check the arithmetic and decisions. There is no promise of hourly precision: a resource plan helps identify constraints and revisit them as facts emerge.
- Overall total
37 hours available, 37 planned: the balance looks perfect.
- By specialist
The designer is overloaded by 2 hours; someone else's spare hour cannot replace the required skill.
Define the period and resources
Start with one week or another clear window. Clarify who is genuinely available to the project then. An employee's full working week is not equal to time for your project: meetings, other commitments, absences and ongoing support also take time.
You may need premises, equipment, budget or access to an external system as well as people. Not everything has to be converted into hours. A studio's bottleneck might be one camera on a particular day; development might depend on access to a test environment.
Our example counts only the time of three specialists. We assume other conditions are available. Remember this model limitation: a neat hours table does not prove the whole project is ready.
Completed availability calculation
| Specialist | Allocated to project | Meetings and absence | Buffer | Planned capacity |
|---|---|---|---|---|
| Designer | 30 h | 7 h | 4 h | 19 h |
| Developer | 20 h | 6 h | 3 h | 11 h |
| Editor | 12 h | 3 h | 2 h | 7 h |
| Total | 62 h | 16 h | 9 h | 37 h |
For the designer: 30 − 7 − 4 = 19 hours. A buffer is not already known work; it preserves the ability to respond to uncertainty. Its size here is illustrative. In a real plan, use the nature of the project and observations from previous periods.
Do not subtract the same meeting twice. If the initial 30 hours already excluded meetings, subtracting them again distorts availability. Briefly explain where the initial figures came from alongside the table.
Avoid hiding buffer in every estimate while also adding a large separate allowance unless the team understands the approach. Separating base work from uncertainty makes the discussion more transparent.
Match work with the required skills
The plan needs 21 hours of design, 10 of development and 6 of editing. The total is 37, but the designer is two hours short. If the developer needs the design before the end of the week, the problem may be worse: an overall weekly balance does not show dependency order.
- Design
21 h of work against 19 h capacity: a 2 h shortfall.
- Development
10 h against 11 h: 1 h spare, but a finished design is needed.
- Editing
6 h against 7 h: 1 h spare that cannot replace design.
Break a large estimate into understandable results: structure, main screen, form states and final review. This shows what can actually be moved or simplified. Do not divide into minutes: false precision does not reduce uncertainty.
Check parallel work too. One specialist cannot do two activities simultaneously, even if both are assigned to the same day and look short in total. Waiting for an answer may consume calendar time without active hours. Distinguish these two types of duration.
Three ways to resolve a shortfall
The first option is to cut design scope by two hours: for example, use an approved existing template instead of a new decorative block. Check that the useful outcome and required states are preserved.
The second is to move an optional part to next week if its absence will not break the launch. The third is suitable help, including time to transfer context and review. You cannot simply assign design work to a free editor without assessing skills and consequences.
In the illustrative plan, the team chooses an existing template and removes two hours of optional graphics. The new design scope is 19 hours. Total work becomes 35 hours against planned capacity of 37; the two hours in other roles remain spare capacity for those roles, rather than a universal resource.
What if the estimate changes?
Additional form states are discovered midweek. Update remaining work and availability for the rest of the period. Do not compare a new full estimate with the old full capacity: some time has already been spent and some work completed.
Preserve the reason for the change: a new requirement, underestimated complexity, absence or external delay. This helps improve the next plan. Recording every deviation as “ran out of time” loses useful information.
- What is already complete and needs no rework?
- How much work remains for each skill?
- What availability genuinely remains before the checkpoint?
- Which dependencies changed?
- Which decision is needed: scope, date, help or accepting risk?
Update the resource plan after significant changes, without requiring a full recalculation after every small revision. Choose a level of detail that reveals decisions, and avoid making tracking a separate project.
Where to save the working result
In Sinqly, you can create a “Check the team's weekly workload” task and add the availability calculation, shortfall by role and chosen decision in its description. This example does not assume a built-in resource planner; registration is free.
Check before approval
Ask everyone to confirm availability and work scope. Check that the same person has not been promised full-time to several projects. Then inspect critical dependencies and when intermediate results are needed, rather than only the overall weekly total.
The final question: what will we change first if urgent new work appears? If the answer is “try to do everything”, the plan has no decision for a real constraint yet. Name the part that can be cut or the point when commitments must be reconsidered.
A project plan with stages and dependencies adds an outcome sequence to the resource calculation.
More questions to clarify
Does a resource plan need a Gantt chart?
No. For a small project, a table of availability, work and dependencies is enough. Choose the tool according to task complexity.
What is the correct buffer percentage?
There is no universal percentage. Consider uncertainty, work type and past deviations. The article uses a hypothetical illustrative buffer.
Can we plan 100% utilisation?
You can write such a plan, but it leaves no room for changes or unplanned commitments. Understand and explicitly accept this risk.
Was this helpful?
Rate the article and tell us what was missing. Your feedback goes to the Sinqly team and will not be published on the site.
Sources and notes
- Atlassian: resource planning
- The suggested process reflects editorial practice; it does not promise identical results for everyone.
Project plan: build it from the outcome to the next task
How to create a workable small-project plan: outcomes, activities, dependencies, dates and review points. An illustrative open-class launch without complex tools.
Kanban WIP limits: how to limit unfinished work
What counts as work in progress, how to choose an initial limit and how to handle blockers. An editorial queue example and a way to assess changes without promises of magical speed gains.
The critical path: a simple project calculation
Find the longest chain of dependent activities and understand which delays will move the whole project. A small worked example calculated by hand, without specialist software.