Resource levelling: what it is, how it works, and when to use it

I spent the best part of a decade in client services, and have seen firsthand how resource planning can make or break your team and projects. If there is one thing I have learned, it is that most project delays do not start with bad estimates or unclear scope. They start with a resource plan that looks fine on paper but falls apart the moment two projects need the same person on the same day.

Resource levelling is how you fix that gap between what the schedule assumes and what your team can actually deliver. In this guide, I will walk you through what resource levelling is, the techniques that work in practice, a step-by-step process you can follow, and common mistakes I have seen teams make repeatedly.

What is resource levelling?

Resource levelling usually starts with the same scenario: you open your project schedule, everything looks achievable, and then you realize your lead developer is assigned to three deliverables on the same Tuesday. That is the problem resource levelling exists to solve.

The PMBOK Guide defines resource levelling as "a technique in which start and finish dates are adjusted based on resource constraints with the goal of balancing demand for resources with the available supply." In plainer terms, it means rearranging your schedule so no one is expected to do more work than they physically can in a given time period.

In professional services, the definition needs a sharper edge. You are not just scheduling tasks inside a single project. You are balancing people across multiple client engagements simultaneously, each with its own deadline, scope, and billing structure. Resource levelling in this context means looking across your entire portfolio, spotting where the same person is overcommitted, and making deliberate trade-offs. You might delay a deliverable, reassign a task, or bring in additional capacity. The goal is the same as the textbook version: balance demand with supply. But the stakes are higher because every scheduling decision directly affects utilization rates, revenue, and client relationships.

Why resource levelling matters for professional services teams

Before I joined Teamwork.com, I watched the same pattern play out at every agency I worked in. A project manager would build a plan, assign resources based on availability in a spreadsheet, and declare the project "staffed." Two weeks later, a senior designer was working late every night, a junior copywriter had nothing to do, and the client was asking why the review cycle was behind schedule.

The cost of getting resource levelling wrong goes far beyond missed deadlines:

• Revenue leaks from underutilization. When resources sit idle because work was not distributed evenly, you are paying for capacity you are not billing. Teamwork.com's How To Prove Value Beyond Price report found that the high-value position for operations managers is to "optimize utilization" and "plan capacity realistically." The low-value position, the one most teams are stuck in, is "manual scheduling" and "reactive firefighting." The difference between those two positions often comes down to whether you have a levelling process. If you want to quantify what your current utilization rate is actually costing you, the utilization rate calculator can show the gap in minutes.

• Delivery risk from sustained overallocation. Assigning someone to 120% capacity for a week might feel necessary. Keeping them there for a month leads to mistakes, rework, and eventually attrition. According to a McKinsey study on resource allocation, companies that actively manage resource allocation outperform peers by 40% in total returns to shareholders. Overutilised team members do not just slow down; they start cutting corners on quality, which creates a ripple effect that hits the client relationship.

• Client trust erodes. When you miss a milestone because a resource conflict was not resolved in time, the client does not see a scheduling problem. They see a team that cannot deliver. In my experience, the agencies that retained clients longest were the ones who spotted resource conflicts early and communicated proactively, even when the news was "we need to push this deliverable by two days."

• Burnout compounds quietly. Research from the American Psychological Association found that nearly 60% of employees report negative effects from work-related stress, including low energy and lack of motivation. In professional services, where billable hours drive revenue, the margin between "productive" and "burned out" is dangerously thin. Resource levelling is one of the most direct ways to keep that margin healthy.

Resource levelling vs. resource smoothing: what is the difference?

One of the most common questions I hear is whether you need resource levelling, resource smoothing, or both. The short answer: they solve different problems, and most teams need both at different stages of a project.

Resource levelling is corrective. You use it when your plan demands more from a person or team than they can deliver. The trade-off is that adjusting dates to match capacity often pushes the project finish date out.

Resource smoothing is optimising. You use it when the overall capacity is sufficient but the distribution is uneven. For example, a team member has 50 hours of work in week one and 10 hours in week two. Smoothing redistributes tasks within the existing float so the workload is steady, without changing the deadline.

In practice, the two techniques work in sequence. You level first to resolve hard conflicts (someone assigned to two projects at once), then smooth to eliminate the peaks and valleys. If you are not familiar with the related concepts, Teamwork.com has glossary breakdowns of resource allocation and resource loading that cover the full family of techniques.

When to use resource levelling (and when not to)

I have seen teams reach for resource levelling when the real problem was something else entirely: unclear scope, missing dependencies, or a project plan that was never realistic to begin with. Resource levelling only works when the plan itself is sound and the issue is genuinely about resource constraints.

Use resource levelling when:

• A team member is assigned to multiple tasks or projects at the same time and cannot complete both without overtime

• A critical resource (a specialist, a piece of equipment, a shared environment) has limited availability that conflicts with the schedule

• Your project plan assumes capacity that does not exist, for example, scheduling a full-time developer on three concurrent projects

• You have completed resource allocation and discovered that demand exceeds supply for certain roles or time periods

Do not use resource levelling when:

• The project scope is not defined. Levelling a schedule built on vague requirements is a waste of effort because the schedule will change as soon as scope is clarified.

• Task durations are guesses rather than estimates. If you do not have reasonable effort estimates, adjusting dates will not solve the underlying uncertainty.

• The real issue is insufficient headcount. If your team is chronically under-resourced for the volume of work coming in, levelling will keep pushing deadlines out indefinitely. The fix is a capacity-based intake process, not a scheduling adjustment.

Understanding when to apply the technique (and when to address the root cause instead) is the difference between effective resource management and an endless cycle of rescheduling.

Resource levelling techniques you should know

In my experience, choosing the right levelling technique depends entirely on what is constrained: time, resources, or budget. There is no single approach that works for every situation, and the best project managers combine multiple techniques.

Critical path method (CPM)

The critical path method identifies the longest sequence of dependent tasks in your project, which determines the minimum possible duration. Tasks on the critical path have zero float, meaning any delay extends the entire project. Understanding your critical path is the foundation for effective levelling because it tells you which tasks you absolutely cannot move and which have scheduling flexibility.

Critical chain method

The critical chain method builds on CPM by adding a crucial factor: resource constraints. Where CPM assumes unlimited resources, the critical chain method recognises that a person can only work on one task at a time and adjusts accordingly.

The key difference is the use of buffers. Instead of padding individual task estimates, you add a project buffer at the end of the critical chain and feeding buffers where non-critical paths merge into the chain. This approach produces more realistic schedules because it accounts for the reality that your senior strategist cannot simultaneously write a proposal and run a client workshop, no matter what the Gantt chart says.

Fast tracking

Fast tracking means running tasks in parallel that were originally planned to happen in sequence. You can use it when two tasks have a partial overlap, for example, starting the design phase while the content brief is 70% complete rather than waiting for full sign-off.

The risk is rework. If the content brief changes significantly after the designer has started, you may lose the time you were trying to save. I have found that fast tracking works best when the parallel tasks have low dependency and when the team communicates frequently. Before fast tracking, map out exactly which deliverables from the upstream task the downstream task actually depends on. If the answer is "only the first section," you can safely start the second task early. If the answer is "all of it," fast tracking is a gamble.

Crashing

Crashing means adding resources to a critical-path task to compress its duration. The classic example: a copywriter needs five days to write a report, but you only have three days. You bring in a second writer, split the sections, and finish in three days.

The trade-off is cost. Every additional resource adds expense, and there is a point of diminishing returns where adding more people actually slows things down (coordination overhead, onboarding time, style inconsistency). Crashing makes sense when the deadline is immovable and the budget can absorb the additional spend.

Choosing the right technique

The technique you choose depends on your constraints. Here is a quick decision framework:

How to level resources: a step-by-step process

When I was first learning to level resources at an agency, I treated it as a one-off activity, something you do once during planning and then forget about. That approach fails because resource availability changes constantly. Here is the process I use now, refined over years of managing multi-client portfolios.

Step 1: Map resource capacity and project demands

Start by documenting each team member's actual available hours per week. Not their contracted hours; their realistic capacity after accounting for meetings, admin, internal projects, and time off. Then map every project task against the people assigned to it. With tools like Teamwork.com's Workload Planner, this step takes minutes instead of hours because you can see everyone's current assignments and available capacity in a single view.

Step 2: Identify the critical path

For each active project, determine which sequence of tasks defines the minimum project duration. These are the tasks you cannot move without extending the deadline. If you are managing multiple projects, the critical path analysis needs to span your entire portfolio, not just one project in isolation.

Step 3: Calculate float on non-critical tasks

For every task that is not on the critical path, calculate how much scheduling flexibility exists. Float is the buffer you have to work with when rearranging the schedule. The formula is straightforward: late start date minus early start date, or late finish date minus early finish date.

Step 4: Choose a levelling strategy

When you find an overallocated resource, you have four options: delay a non-critical task (use float), reassign the task to another team member with the right skills, add resources (crashing), or reduce the project scope. The right choice depends on which constraint matters most: time, cost, or quality.

Step 5: Apply adjustments to the schedule

Make the changes in your project management tool. Shift start dates, reassign tasks, update task dependencies. Ensure that every change propagates correctly through the schedule so downstream tasks adjust automatically.

Step 6: Communicate changes to stakeholders

Any schedule change that affects a deliverable date needs to be communicated to the client and the internal team. In my experience, proactive communication ("we are shifting this deliverable by two days to ensure quality") always lands better than reactive explanations after a missed deadline.

Step 7: Monitor and re-level as needed

Resource levelling is not a one-time event. Set a cadence, weekly for active projects, to review capacity and re-level as new work comes in, priorities shift, or team members become unavailable. If you want a structured framework for ongoing capacity planning, we have a full guide that covers the process in detail.

When Community Link Consulting moved from spreadsheet-based resource planning to Teamwork.com, they replaced their manual process of handwritten notes and individual check-ins with a centralised view of team capacity. The result was a resource planning process that actually kept pace with their growth instead of holding it back.

What resource levelling looks like in practice

I find that resource levelling clicks faster when you see it applied to real scenarios. Here are three situations I have encountered repeatedly across agencies and consulting firms.

Example 1: Delaying a non-critical task

A UX designer is assigned to create wireframes for Project A (critical path, due Friday) and update the style guide for Project B (not time-sensitive). Both tasks are scheduled for the same week, pushing the designer to 150% capacity. The levelling action: delay the style guide update to the following week, using its available float. The designer stays at 100% capacity, Project A hits its deadline, and Project B is unaffected because the style guide had a two-week buffer.

Example 2: Extending the timeline

A development team has three sprints planned over six weeks, but the lead engineer is going on leave for one of those weeks. Without that engineer, sprint two cannot start on schedule. Rather than overloading the remaining developers, the project manager extends the timeline by one week and staggers the sprints. The client is informed early, the team works at a sustainable pace, and the quality of the final delivery is maintained.

Example 3: Crashing a critical-path deliverable

A consulting firm needs to deliver a final report to a client by end of month, but the data analyst assigned to it is also finishing a separate engagement. The deadline is immovable. The project manager brings in a freelance analyst to handle the data modelling while the internal analyst focuses on the narrative and recommendations. The additional cost is justified by the contract value and the relationship at stake.

Example 4: Reassigning across skill sets

Two account managers are running parallel client onboarding projects. One account manager is at 130% capacity this week while the other is at 60%. The operations lead identifies that two of the overloaded manager's tasks (client questionnaire setup and kick-off deck customisation) can be handled by the underloaded manager with minimal ramp-up. By reassigning those two tasks, both managers land between 80% and 95% for the week, and neither client experiences a delay.

Common resource levelling mistakes (and how to avoid them)

Over the years, I have seen the same mistakes trip up operations teams. Here are the five that cause the most damage.

1. Levelling without visibility into actual capacity. If you do not know how many hours each person is truly available (after meetings, admin, and other commitments), your levelling is based on fiction. The Project Management Institute's Pulse of the Profession consistently finds that poor resource management is among the top causes of project failure. The fix: use a tool that shows real availability, not just contracted hours.

2. Ignoring task dependencies when rescheduling. Moving a task to a later date seems simple until you realise three downstream tasks depended on its output. Always trace the dependency chain before rescheduling anything. One shifted task can cascade into a week of delays if the dependencies are not mapped.

3. Over-relying on crashing. Adding resources to compress timelines works in the short term, but doing it repeatedly signals a systemic planning problem. If you are crashing every project, your initial estimates or resource allocation process needs an overhaul. I have seen teams where crashing became the default rather than the exception, and the compounding cost eroded their project margins entirely.

4. Not communicating schedule changes to stakeholders. Silently shifting a deliverable date and hoping no one notices is a recipe for broken trust. Every schedule change should trigger a stakeholder update within 24 hours. This is especially critical in client work, where the client's own plans may depend on your delivery date.

5. Treating levelling as a one-time activity. Resource availability changes constantly. People get sick, priorities shift, new projects land. Build a weekly review cadence into your operations rhythm. The teams that level continuously deliver more predictably than those that level once and hope for the best.

How Teamwork.com helps you level resources without the guesswork

In my role at Teamwork.com, I get to see how our customers solve the exact resource conflicts we have been discussing throughout this guide. Here are the features that make levelling practical instead of theoretical.

Workload Planner gives you a colour-coded view of every team member's capacity across all active projects. You can see at a glance who is overallocated (red), who has room (green), and who is approaching their limit (amber). Instead of digging through spreadsheets, you spot conflicts the moment they appear.

Resource Scheduler lets you drag and drop assignments across team members and projects. When you need to reassign a task from an overloaded designer to one with availability, it takes seconds. The schedule updates automatically, and every dependency adjusts in real time.

AI Smart Scheduler takes the manual work out of levelling. It analyses task dependencies, resource availability, and project priorities, then suggests schedule adjustments that resolve conflicts while keeping critical-path tasks on track.

AI Utilization Summary surfaces real-time utilization data so you can see the impact of your levelling decisions immediately. Instead of waiting until month-end to discover that a team was running at 45% utilization, you see it as it happens and can intervene.

Portfolio reporting connects your levelling decisions to business outcomes. You can track utilization rates, project margins, and delivery timelines across your entire portfolio, giving you the data to justify resource decisions to leadership.

FAQ

What is resource levelling in project management?

Resource levelling is a technique that adjusts task start and finish dates to resolve conflicts caused by resource overallocation. It balances the demand for resources (people, equipment, materials) with their actual availability, often by delaying tasks or extending project timelines to prevent any single resource from being assigned more work than they can handle.

What is the difference between resource levelling and resource smoothing?

Resource levelling resolves overallocation by adjusting schedules, which may extend the project deadline. Resource smoothing redistributes work within the existing timeline to eliminate workload peaks and valleys without changing the finish date. Levelling addresses resource constraints; smoothing addresses uneven distribution.

Can you use resource levelling in agile projects?

Yes. Agile teams apply resource levelling during sprint planning and backlog refinement. When a team member is overcommitted for a sprint, the scrum master can move lower-priority items to the next sprint or redistribute tasks across team members with available capacity, which is levelling in practice.

How does resource levelling affect project timelines?

Resource levelling often extends project timelines because it delays tasks until the assigned resource is available. The trade-off is intentional: a longer but achievable timeline is more reliable than a compressed schedule that leads to burnout, rework, and missed deadlines.

What is the difference between resource levelling and crashing?

Resource levelling adjusts schedules to match resource availability, typically extending timelines. Crashing adds resources to shorten timelines, increasing costs to meet deadlines faster. Levelling prioritises sustainable workloads; crashing prioritises speed at the expense of budget.

What are the three methods of resource levelling?

The three primary methods are the Critical Path Method (identifying scheduling flexibility by mapping task dependencies), fast tracking (running tasks in parallel to compress the schedule), and crashing (adding resources to critical-path tasks to reduce duration). A fourth method, the critical chain method, extends CPM by incorporating resource constraints and buffers.