Resource levelling challenges. Time optimisation.

Resource levelling challenges. Time optimisation.

A recent LinkedIn poll and discussion revealed that planners/schedulers rarely use automatic resource levelling. They prefer to level resources manually or leave the resource constraint challenge to someone else. As some of you have expressed curiosity regarding the poll results, I have decided to expand on this topic in more detail and explain resource levelling challenges.

The resource-constrained project scheduling problem

The project resource levelling challenge is known as the resource-constrained project scheduling problem (RCPSP).

RCPSP is a classic optimization problem in project management. In this problem, the objective is to schedule a set of tasks within a specified time frame while considering the limited availability of resources.

Projects’ optimised delivery is achieved when the optimum use is made of the critical resources and the flow of work is harmonised. This was the primary focus of Henry Gantt’s work when he developed his famous Gantt chart and it was also the mission of Kelley and Walker when they developed the original CPM system. Not long after, the Program Evaluation and Review Technique (PERT) and the Critical Path Method (CPM) were invented, RCPSP surfaced, capturing the worldwide attention of researchers worldwide due to its broad practical relevance and intriguing combinatorial complexity. RCPSP takes into account both tasks (activities) dependencies and limited availability of resources to execute a project.

In 1975, Professor Leonid Kantorovich, USSR, and Professor Tjalling C. Koopmans, USA, received the Nobel Prize in Economics for their contributions to the theory of optimum allocation of resources.

A search on The European Journal of Operational Research yields 741 articles dedicated to RCPSP, 257 of which were published in the last 5 years. The high volume of articles dedicated to RCPSP doesn’t relate to Generative AI breakthroughs. Unfortunately, recent exponential progress in Generative AI doesn’t help to progress with the resource-constrained project scheduling problem, as planning is a different domain of human and artificial intelligence.

At the same time, the first AI-based systems that help optimise resource constraint schedules were developed in the 80th. Some of the planning tools today could also be used for RCPSP, but as we can see below, not all of them have sufficient quality algorithms.

The history of levelling algorithms is a fascinating story that remains ongoing and warrants a dedicated post.

RCPSP demonstration

To demonstrate the challenge, I have developed a simple scheduling fragment. The schedule has nine activities grouped into three streams, and one full-time skilled resource is required for each activity.

Three types (skills) of resources (Team A, Team B, and Team C) are needed to deliver this work.

Let’s analyse resource demand:

The project needs three ‘Team A’, two ‘Team B’, and two ‘Team C’. If they are available, the final milestone will be delivered in 120 days. The critical path is Activity 1, Activity 2, and Activity 3.

However, the developed schedule is feasible only if the required demand is available.

Let’s assume that only one ‘Team A’, one ‘Team B’, and one ‘Team C’ are available.

To be able to develop a feasible schedule, additional resource dependencies (resource logic) need to be identified. We aim to find a combination of resource dependencies that give us the shortest overall project duration. We will discuss RCPSP with other optimisation criteria in future posts.

There are three ways to perform levelling:

  • Automatic: use a built-in scheduling algorithm
  • Manual: level resources manually
  • Semi-automatic: use an automatic scheduling algorithm but manually configure adding priorities to point algorithms in the right direction.

There are multiple ways to sequence activities, and we must try them all to find the optimal solution. As the example is relatively simple, it is possible to do so. Still, it will be a time-consuming exercise. Real-life schedules have more activities and resources. The overall number of combinations depends on the number of activities and resources and grows exponentially, so even with very powerful computers, it is impossible to find the results of all combinations for even relatively small scheduling fragments.

Automatic resource levelling

Microsoft Project, Primavera P6 and Spider Project can perform resource levelling. Microsoft Project and Primavera have one optimisation method, and Spider Project has five methods.  

Option 1

Microsoft Project, Primavera and Standard method in Spider Project gave us the same result: 168 days.

Microsoft Project


Spider Project

The solution calculated in Spider Project and Primavera is identical. Let’s analyse it:

  • Almost all activities are on the resource-critical path;
  • Activities from the original critical path (A1, A2, A3) are still critical;
  • Team A and Team C don’t have idle time:
  • Four resource dependencies added:

Option 2:

Alternative levelling methods (‘Optimisation’ or ‘Optimisation Plus’ in Spider Project) found an alternative way to order activities:

  • This solution has fewer activities in the resource-critical path. Three of them have positive total float;
  • Activities from original critical path (A1, A2, A3) are still critical;
  • ‘Team A’ and ‘Team B’ have idle time:
  • Three resource dependencies added:

This option requires only 144 days for completion. It is on 24 days (14%) shorter than the Option 1.

Does this mean that the ‘Option 2’ also requires fewer funds? It is logical to assume that quicker should mean cheaper, but until we calculate it, we can’t be sure. We will test this hypothesis in future posts.  

Manual levelling

I asked my LinkedIn community to try to perform resource levelling manually, provide results, and advise on the time they spend on the optimization. Almost all participants found the 144-day solution and advised that it takes about 15 minutes to find the solution.

This scheduling fragment is actually VERY easy to level. As the first activity in the second stream (Activity B1) has a much longer duration than activities A1 and C1, it looks logical that starting from Activity B1 is not the best idea. Then there are only two options left: start from A1->C1 or C1->A1. It reduces the number of starting options from six to two.

One the options (C1->A1->B1) gives a better result. Additionally, it levels Team B.

Now, all we need to do is delay Activity B3. It gives us the 144-day result.

However, accomplishing this task proves challenging for standard built-in levelling algorithms. Microsoft Project applied A1 -> C1 -> B1, Primavera and Spider Project applied A1 -> B1 -> C1 solutions to start. The Optimization (Spider Project) method recognizes that starting from activity C1 yields the optimal solution.

 Automatic vs Manual levelling

Through this experiment, I have tried to demonstrate that even a simple scenario could be too complex for a planning tool. Participants in the experiment discovered a better solution compared to those automatically calculated by Microsoft Project or Primavera. Experienced planners who use these systems know that automatic resource levelling is a ‘never touch’ function, as the duration of the schedule is likely to be far from optimised.

At the same time, manual resoucre levelling is a practical option. It can be applied as an exception, not the rule. Exceptions are related to linear projects with one obvious critical (but limited) skill or only for small scheduling fragments. Still, for cost optimization all resources need to be optimised, not only those that impact critical path.

In all other circumstances, manual resource levelling is not a viable option. As previously mentioned, the challenge lies in the exponential growth of combinations, rendering manual levelling impractical for broader scenarios.

If we add only three new activities to the reviewed example, Activity A4, Activity B4, and Activity C4 (Team D), it takes much longer to find an optimised solution manually.

Resource volatility

Another reason why manual levelling is not a practical option is resource volatility. Conducting a one-time optimisation is not sufficient, as resource demand and supply are subject to constant fluctuations.

Demand is volatile due to variance in performance and accuracy in planning. Even if the required resource quantity is stable, time when resources are needed are likely to be different from the original plan. Supply is volatile due to demand from other activities (or even projects) and unplanned changes (broken equipment, sick leave, etc).

Project Delivery optimisation must be performed after each reporting cycle to ensure the project’s plan is still optimised and feasible.

In our example, altering the calendar of one resource may trigger a change in resource logic.


When project conditions are changed to perform new levelling three steps need to be performed:

  • Remove all resource dependencies;
  • Find a new optimisation solution;
  • Add new resource dependencies.

Each step is time-consuming, especially when a planning tool doesn’t provide an opportunity to classify dependencies. This obvious feature is missing in Microsoft Project and Primavera P6.

It is a big help when a planning tool can perform these steps automatically. 

Optimised vs near-optimised

Once the result is calculated, we can not be certain if the proposed option is the best possible solution. To confirm this, we would need to examine all possible combinations. Even advanced RCPSP AI-powered systems can only identify near-optimized solutions, meaning that there is no guarantee that a better solution doesn’t exist. However, if a proposed solution is better than the project team that can find it manually, it is beneficial to use it.


  • The resource-constrained project scheduling problem (RCPSP) presents a complex mathematical challenge. While scientists continuously generate ideas to tackle this challenge, many of these ideas do not find practical implementation yet.
  • Different software packages produce different results for the same projects when resources are limited. Popular scheduling tools often fall short in effectively optimizing resource-constrained schedules. 
  • Resource volatility adds another layer of complexity, requiring ongoing optimisation to adapt to fluctuating demand and supply.
  • A recent LinkedIn poll highlighted the infrequent use of automatic resource levelling by planners/schedulers, who often opt for manual methods or delegate the task altogether.
  • The software that calculates the shortest resource-constrained schedules may save a fortune for its users. 

Alex Lyaschenko

PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma