team
A new piece of work arrives, and the honest answer is that the team is already full. Said in those words, it loses. Being full is a feeling, and a feeling is easy to overrule with enthusiasm, urgency or seniority. The same answer expressed as a number behaves differently: four hundred hours of committed work sits in the next four weeks, against three hundred and twenty hours of available time, and taking the new request means something already committed moves. That is not a refusal. It is a trade, stated in the form that lets someone else choose.
Capacity management tools exist to produce that second sentence. Everything else they do, the heat maps and the utilisation charts and the forecasting, is in service of it. Which makes the useful evaluation question narrow: what does this tool need from the team in order to produce a number that survives being questioned, and what does it charge for doing so.
Three quantities, and the first one is where almost every attempt goes wrong.
Available hours, not contracted hours. A full time person does not have forty hours of project work in a week. Subtract recurring meetings, the share of the week spent on support or interruptions, holidays and known leave, and the honest figure for most roles lands somewhere between twenty five and thirty two hours. The exact number matters less than measuring it once from real evidence instead of assuming it. A plan built on forty hours a week is not optimistic, it is arithmetically wrong, and it will be wrong in the same direction every time.
Committed hours, with dates. Estimates attached to work that has already been agreed, spread across the weeks it will actually happen in rather than the week it was requested. A task estimated at twenty hours that spans three weeks consumes capacity in three places.
The gap, per week and per person. Totals across a quarter hide everything. Capacity problems are almost always local: one person is the constraint in week three, while the team as a whole looks fine. Any tool or spreadsheet that reports only a team level percentage will produce a confident answer and miss the bottleneck.
A number containing all three is hard to argue with, because each part can be checked. A number missing the first is easy to dismiss, and deserves to be.
The data problem, not the tool choice, is what decides whether this works.
Capacity views need three fields on each piece of work: who is doing it, when it happens, and how big it is. The first two usually exist already in whatever tracker the team uses. The third often does not, and the temptation is to introduce estimating as a new ritual in a separate tool.
That is the mistake worth avoiding. Any capacity system that requires data to be entered twice, once where the work lives and once where the planning lives, will be accurate for about three weeks. The plan then quietly diverges from reality, and the divergence is invisible because the planning tool still renders a confident chart. A stale capacity chart is worse than no chart, because it gets used in decisions.
The rule to apply when comparing tools: the capacity view should be a by-product of how the work is already recorded. If the tool reads assignments and dates that people maintain anyway, the numbers stay close to true. If it needs its own bookings entered by a planner, someone has to own that job permanently, and that job is the real cost of the tool.
Estimates themselves can stay crude. Sizes to the nearest half day are enough for capacity work, because the decision being informed is whether a week holds four things or seven, not whether a task takes six hours or seven. Precision beyond that adds effort without changing any answer.
Dedicated capacity and resource scheduling tools price in a way that differs structurally from project tools, and the difference is worth understanding before a trial.
Float lists Starter at $7.00 per scheduled person per month and Pro at $12.00 per scheduled person per month, with an Enterprise tier described as best for teams of 100 or more seats, on its pricing page. The phrase to notice is scheduled person. The meter counts people who appear in the schedule, whether or not they log in, which matches how these tools are used: a planner schedules contractors and colleagues who never open the app.
Resource Guru is explicit about the same logic. Its pricing page lists Grasshopper at $5 per person per month, Blackbelt at $8 and Master at $12, and adds a separate price for other resources at $2.50, $4 and $6 respectively, with one, five and ten free placeholders included by tier. The page states that charging is based on the number of people added to the account, whether they log in or not and regardless of their permissions, and that non human resources and placeholders beyond the allowance are also billed. Meeting rooms, vehicles and equipment are resources in this model, which is genuinely useful for studios and field teams and genuinely surprising on the first invoice.
The other route is a capacity view bundled into a general project tool, where the cost appears as a tier jump for everyone. Asana places resource management on its Advanced plan, listed at $24.99 per user per month billed annually and $30.49 monthly on its pricing page, and describes that plan as being for teams that plan team capacity. The number to compare is not the tier price against the dedicated tool's price. It is the tier price multiplied by every seat in the account, since tiers apply account wide.
| Meter | What triggers cost | Fits |
|---|---|---|
| Per scheduled person | Anyone who appears in the schedule | Agencies scheduling contractors who never log in |
| Per person plus per resource | Everyone added, plus rooms, equipment and placeholders | Studios and field teams booking things as well as people |
| Tier upgrade on a project tool | Every seat in the account, not just planners | Teams that want one tool and already pay per seat |
| Fields in an existing tracker | Nothing extra | Small teams where assignments and dates already exist |
The fourth row is the one most small teams should price first, because it costs nothing and produces the same three quantities.
A capacity system earns its place the first time it turns a refusal into a choice. The format that works has three parts: what is committed, what the new request costs, and what would have to move.
In practice that sounds like this. The next four weeks hold three hundred and eighty hours of committed work against three hundred and twenty available. The new request is sixty hours and needs a designer, and the designer is the person already at a hundred and ten per cent in weeks two and three. So it fits if the smaller campaign moves to the following month, or if the deadline moves by two weeks, or if the scope drops the second landing page.
Three options, each with a number attached. Nobody has to trust anybody's instinct, and the decision moves to the person who owns the priorities, which is where it belongs. That is also why the number has to be defensible rather than precise: it will be examined by someone who does not want the answer.
Worth noting what this format avoids. It never says the team is at capacity, which invites the response that everyone is busy. It never claims the new work is unimportant. It states the arithmetic and offers the trade, and the loudest objection available against it is a change in priorities, which is a legitimate decision rather than an argument.
Every capacity plan degrades, and treating that as a failure is what causes teams to abandon the practice.
The main cause is unplanned work: support, bugs, client calls, the thing the founder asked for on Tuesday. Most teams guess this at ten per cent and most teams are wrong by a factor of two or three. Measuring it once is straightforward. For two weeks, log anything that was not in the plan at the start of the week, add up the hours, and divide by total hours. Whatever comes out, twenty per cent or thirty five, becomes a standing reservation in the plan rather than a surprise that eats committed work.
The second cause is that people move between projects mid week. A plan that assumes a person works on one thing at a time will be wrong for anyone who does not. The fix is not finer grained scheduling, which increases maintenance faster than accuracy. It is a weekly cadence: a short review that adjusts the coming two weeks and leaves the rest alone, because anything beyond a fortnight will change before it arrives.
The third cause is roles that do not exist yet. A plan that depends on a hire needs a placeholder, and a placeholder with a start date is honest in a way that an assumption is not. Both dedicated tools above support placeholders explicitly, which is a sign of how common the pattern is.
For a team under roughly fifteen people, the whole practice fits into the tracker that already exists, provided three fields are present on each task: an assignee, a start and end date, and a size. With those, a filtered view per person for the next two weeks answers the question. The arithmetic is a sum, and a sum does not need software.
The weekly routine takes twenty minutes. Review the next two weeks, list anyone above their available hours, decide what moves, and record the decision where the work lives rather than in a message. One number is worth tracking over time: the share of each week that turned out to be unplanned. When that number is stable, the plan becomes trustworthy, and a trustworthy plan is what makes the negotiation work.
A dedicated tool becomes worth its meter at the point where the schedule includes people who never log in, where equipment or rooms are booked alongside people, or where more than a handful of projects compete for the same specialists in the same weeks. Below that threshold, the gain is presentation rather than information. Confirming that the tracker can show assignments as a calendar and a timeline without duplicating the data is the cheapest first step, and that is a question about the features that ship on the entry tier rather than about buying a second tool.
Measure available hours honestly for one week, then add estimates to the work already assigned for the next two weeks and total it per person. That single comparison produces the sentence that turns a refusal into a trade, and it needs no new subscription. Teams whose assignments and dates already live in one place can see the whole picture as a timeline next to their boards, which is what Pinateca includes from the free tier upward.
Capacity management answers whether the work will fit in the time available, at the level of weeks and people. Resource scheduling assigns specific people to specific work at specific times, which is a finer grained job. Teams usually need the first to make commitments and the second only when several projects compete for the same specialists.
Dedicated tools in this category generally offer trials rather than free tiers, with Float and Resource Guru both charging per person added to the account. The free route is the tracker a team already uses: an assignee, a start and end date and a size on each task give the same three quantities without another subscription.
Fewer than the contracted hours, and the figure should be measured rather than assumed. After recurring meetings, support duties and leave, most roles land between twenty five and thirty two hours of project work per week. Planning on forty guarantees the plan is wrong in the same direction every time.
Unplanned work, usually underestimated by half. Logging everything that was not in the plan for two weeks gives a real percentage, often twenty to thirty five, which can then be reserved in the plan rather than absorbed by committed work. The second cause is trying to plan more than a fortnight in fine detail.
No. Capacity planning needs estimates of future work, not records of past hours. Time tracking is useful for billing and for calibrating estimates over time, and introducing both at once is the fastest way to get neither, since the daily cost of logging hours is what people resist.