Resource Utilization Calculator
Calculate resource utilization as the percentage of available hours actually allocated to project work. Use it to identify under- or over-utilization of staff, balance workloads, and optimize team capacity planning.
Last updated: May 2026
Compare with similar
About this calculator
The calculator returns utilization as a percentage. The formula is: Utilization (%) = (Allocated Hours / Total Available Hours) × 100. Variables: Allocated Hours is the hours assigned to project/billable/productive work in the period; Total Available Hours is the total work hours in the period (typically 40 hrs/week × number of weeks, minus paid time off, sick leave, holidays). Edge cases: 100% utilization is mathematically possible but operationally undesirable — it leaves zero capacity for meetings, professional development, sick leave, hiring/onboarding support, peer mentoring, and the inevitable unexpected work. Sustainable utilization targets vary by role and industry: consulting firms typically target billable utilization 70–80% (to leave room for non-billable activities); software engineers should be 70–85% on coding (to leave room for meetings, code review, mentoring); designers and creative professionals 60–75% (creativity work has higher variance and requires think time). Above 90% utilization is usually a sign of imminent burnout or hidden under-investment in non-billable activities (training, process improvement, technical debt) that catches up later. Below 60% suggests either over-staffing or poor work allocation — both worth investigating. Tracking utilization at team and individual level reveals which people are over-burdened (turnover risk) and which have capacity for stretch assignments. It also helps identify staffing-vs-revenue alignment: a consulting firm with 60% utilization across the board is over-staffed; one with 95% has been over-promising and is heading for quality problems.
How to use
Example 1 — Standard consulting team. Total available hours per consultant for a quarter (13 weeks × 40 hrs - 1 week PTO × 40 hrs) = 480 hours. Allocated to billable projects = 360 hours. Step 1: utilization = (360 / 480) × 100 = 75%. Verify ✓. 75% is the sweet spot for most consulting firms — high enough to be financially healthy (each consultant covers their fully-loaded cost plus margin), low enough to leave room for proposal writing, training, internal projects, and unplanned client emergencies. Example 2 — Software development team. Total available hours per developer for a 2-week sprint (10 days × 8 hrs) = 80 hours. Allocated to sprint development tasks = 64 hours. Step 1: utilization = (64 / 80) × 100 = 80%. Verify ✓. 80% on development is good — leaves 16 hours for meetings (standups, planning, retrospective, demo), code reviews of others' work, on-call interruptions, and learning. Teams pushing 95% utilization on coding consistently produce more bugs, accumulate technical debt, and have higher burnout rates within 6–12 months.
Frequently asked questions
What is a healthy utilization target?
Depends on role and industry. Consulting firms (Bain, McKinsey, BCG): target 65–80% billable utilization for consultants, with senior partners at 30–50% (their time is mostly business development and management). Boutique consulting: 70–85%. Software engineering: 70–85% coding time, with the rest for code review, meetings, learning. Creative professionals (designers, copywriters): 60–75% — creative work needs think time, false starts, and exploration. Customer service / call centers: 80–90% on calls — these roles are highly transactional. Sales: utilization measured differently (calls/day, meetings/week) but typically 60–75% of time on outbound activities. Healthcare clinical: typically 80–90% scheduled patient time (very high by other standards). Universally: above 90% utilization is a warning sign for burnout and quality problems; below 50% suggests over-staffing or poor work allocation. The Bureau of Labor Statistics publishes industry productivity data; the Society for Human Resource Management (SHRM) publishes utilization benchmarks by industry annually.
What is the difference between utilization and productivity?
Utilization measures the PERCENTAGE of available time spent on intended work — it's a denominator question. Productivity measures the OUTPUT per unit time — it's a numerator question. Two consultants both at 80% utilization may produce very different value: one generates $500/hour of client value (productive), one generates $200/hour (less productive). High utilization with low productivity (busy doing the wrong things) is a common pathology. Conversely, lower utilization with high productivity (focused effort on high-value work) often beats higher utilization on low-value work. Key takeaway: never optimize utilization in isolation — pair with output measures (revenue per consultant, story points delivered per sprint, customer satisfaction, code quality, defect rate). Some research on knowledge work suggests OPTIMAL utilization is actually 65–80% because higher utilization eliminates the slack time needed for thinking, problem-solving, and quality work. Donald Reinertsen's 'Principles of Product Development Flow' presents extensive queuing-theory evidence that pushing utilization above 80% causes throughput collapse (due to queuing effects) — sometimes called the 'utilization paradox.'
What are the most common mistakes when interpreting utilization?
The biggest is optimizing for maximum utilization without considering quality, sustainability, or output value — this is the path to burnout, defects, and missed opportunities. Mature operations target sustainable utilization (typically 70–85%) rather than maximum. The second is using total available hours that includes non-productive time (meetings, training, breaks); the denominator should be hours actually available for project work after subtracting necessary non-project activities. The third is not adjusting for role — applying a 90% target uniformly across consultants, engineers, and designers misses that different roles need different utilization patterns. The fourth is ignoring variance — average utilization of 75% might hide one person at 100% (burning out) and another at 50% (under-utilized); look at distribution, not just average. The fifth is treating utilization as a person quality metric (lazy vs hardworking) when it usually reflects work allocation and pipeline management problems that managers, not individuals, must solve. The sixth is short-term optimization at long-term cost; pushing utilization to 95% for a quarter to meet a goal often produces 60% utilization the following quarter due to burnout-driven turnover.
When should I NOT use utilization as the primary metric?
Skip utilization as the primary metric for highly creative work (R&D, design, strategy) where output quality matters more than time spent; measure outcomes instead. Avoid it for executive or senior leadership roles where the value lies in decision quality, strategic direction, and people development — not in 'hours billable.' Do not use it as the sole metric for hourly workers under variable scheduling; their problem is often UNDER-utilization due to inconsistent shifts, not overwork. Skip it for support functions (HR, legal, finance) where the work demand fluctuates and 100% utilization is unrealistic; use response time and quality measures instead. Do not use utilization to compare across companies or industries without adjusting for definitions — what counts as 'billable' or 'productive' varies enormously. And do not let utilization become a target without also measuring quality, burnout indicators, customer satisfaction, and turnover — Goodhart's Law applies: 'when a measure becomes a target, it ceases to be a good measure.' Many consulting firms have learned this the hard way through high turnover when chasing utilization metrics.
How does utilization interact with team size and project scheduling?
Queuing theory (foundational research by Donald Reinertsen, applied to software development by David Anderson and others) shows that utilization above 80% causes wait times to grow exponentially. At 50% utilization, average wait time is 1 unit; at 80%, 4 units; at 90%, 9 units; at 95%, 19 units; at 99%, 99 units. This is why airports with 95% gate utilization have hours of delays while those at 80% run smoothly — the math is the same for any service system, including knowledge workers. For project work, this means: (1) Don't try to schedule a team to 100% utilization across multiple projects — the inevitable variance will cause some projects to wait excessively; (2) Add capacity (or reduce work-in-progress) when utilization consistently exceeds 80%; (3) Build in explicit slack for handling unplanned work, training, and recovery from blockers; (4) Use Kanban WIP limits to bound work-in-progress, which automatically limits effective utilization to sustainable levels. The counterintuitive result: deliberately running at 75% utilization produces more total throughput than running at 95% because waiting time consumes the gains. Most organizations massively under-invest in this principle and end up perpetually delivering late despite working long hours.