Most projects are logic-constrained projects (or, if I might suggest, wrongfully treated as such). A logic-constrained project has a duration only determined by logic (i.e., the network of dependencies).¹

As I explained previously in this series of articles, once you have all dependencies, the Most‑Critical Path in the network then determines the duration of the project. For an explanation of this new concept of the Most-Critical Path, please read A Better Microsoft Project: Background Color in D * U = W Fields to Communicate which Fields are Protected and Editable, which concluded our recommendations for Time Modeling.

In this fourth article, we will venture into workload modeling and discuss resource-constrained scheduling. A schedule is resource‑constrained when its activities require more resources than are available for (part of) the project duration. In a resource-constrained schedule, the duration of the project is often determined by one or more bottleneck resources (the ones that are in least supply relative to demand for them). When tasks are plenty and resources are slim, schedules tend to extend, and projects take longer than the logic by itself would suggest. If you manage a resource-constrained project, you will often artificially delay activities as to not overwork (or burn out) your team members.

Let’s consider what typically causes projects to be resource-constrained:

Any project that uses labor as a primary input is resource-constrained. Examples are software development, new product development, pharmaceutical clinical studies, telecommunication, research and development, education, and government projects.
Any project that needs a lot of raw materials that are hard to find, hard to get in the right specification, or hard to receive on‑time is resource-constrained. The latter has been prevalent lately and labeled as ‘supply-chain problems.’ Material constraints are common in construction projects, such as bridges, roads, buildings, and plants. Projects in aerospace and robotics can also be material-constrained.
Any project that needs a lot of capital or one that must hustle for finances (government!) is resource-constrained. After all, money should also be treated as a resource to the project. If you view money as such, you can explore how different funding timetables will impact the project schedule. Many projects in the defense industry and in government are money-constrained.

The current supply chain problems, caused by COVID-19 and Russia’s invasion of Ukraine, have turned many more projects from logic-constrained projects into resource-constrained projects.

In all releases of Microsoft Project, so far, I believe Microsoft only delivered half of the functionality needed for resource-constrained scheduling when they programmed only the workload levelling algorithms. They also needed several iterations of this functionality before they got it right; it is a very complex subject matter after all.

I was first introduced to the complexity of workload leveling by David Curling, the late founder of what is now called the PM World Library, who presented the following puzzle in the early 1990’s to our project management community: What is the shortest possible schedule in the following project?

When David posed this challenge, the leveling feature of Microsoft Project 1995 was using only one algorithm: Schedule the least-Total-Slack-task-first. As you can see in the following table, Microsoft was badly beaten by all its competitors, even though, ironically, none of them exist any longer. I scheduled this simple example in four different project scheduling applications and ran their workload leveling function:

As you can see, Microsoft Project produced the longest schedule of 32 days, whereas all its competitors produced the shortest possible schedule of 19 days, a significant defeat. Upon further research with other examples, it also became clear to me that Microsoft Project 1995 only used a single algorithm for workload leveling, whereas CA‑SuperProject used multiple algorithms to find the tightest schedule. Starting with the 2010-release, Microsoft Project could find the 19‑day shortest version of the schedule. Running these tests taught me that no single workload‑leveling algorithm could always find the shortest‑possible schedule in all resource-constrained schedules. I was surprised by this finding because, at first glance, the Least-Total-Slack-first algorithm seems the most-logical: Schedule those tasks first that have the least amount of schedule flexibility (Total Slack or buffer), and the most-logical algorithm must be the best, right? In the previous example, we see that another algorithm (shortest-task-first) is necessary to find the shortest possible schedule. In other words, workload leveling is more complex than I thought. I suspect this is true for most people.

At around the same time that I was testing this, a realization started to dawn on me. It was that Microsoft had only done the least amount of work to find a minimum‑viable product to sell on a mass‑scale—one with only the feature of workload leveling. Then, they made money on it, but stopped further investment in the product. They sell the product worldwide (which few companies can) on a massive scale (software products can be reproduced infinitely at no cost), so the price can be kept low to keep competition out while also maximizing their profits. Microsoft was the first to develop this successful business formula.

I daresay this is ‘lazy,’ and I use the term deliberately here because Microsoft provided only half the solution that is needed for resource-constrained projects. If you have ever looked at the Critical Path in a workload-leveled schedule, you would immediately see that the software is lacking. You may not be as much of a geek as I am, so here is the workload-leveled version of the previous example with the Critical Path highlighted in red:

You can see that only two tasks, ‘6 Activity E’ and ‘7 Activity F,’are colored red and highlighted as critical. The Critical Path is incomplete and, essentially, useless. It only explains about half of the project duration, whereas proper a Critical Path would explain the entire project duration. We need a complete Critical Path that covers the entire project duration here—what I’d call a “Resource-Critical Path.”

A Resource‑Critical Path takes logical dependencies AND resource dependencies into account. The Resource‑Critical Path for the same example would look like this (output was created with PathsPro, an add-in for Microsoft Project from ProjectPro):

The activities that truly explain why this project lasts 32 days are:

Activity A had the least Total Slack before leveling because of its 12 duration (longest).
Activity C performed by resource Ab as well that is resource-dependent on Activity A.
Activity D that is logically dependent on Activity C.
Activity E performed by resource Bo as well that is resource-dependent on Activity D.

As you can see, a Resource-Critical Path consists of logical dependencies and resource dependencies, the latter are the ones that Microsoft Project never could identify. That is the second half of the complete solution needed for resource-constrained schedules.

In 1959, James Kelley of Remington Rand and Morgan Walker of DuPont developed a technique to analyze a network of dependencies called the Critical Path Method (CPM). He made the assumption that projects have access to unlimited resources and deliberately chose not to deal with the complexities of resource constraints and workload leveling. It was a smart assumption at that time, because we now realize how complex workload leveling is. It was also a reasonable assumption when launching an entirely new concept. This concept of ‘Critical Path’ would eventually conquer the entire world in the following decennia.

Today; however, I must ask: Does your current project have access to unlimited resources? Mine never do and never will. In current times, with cut-throat competition that comes from all corners of the world, projects always need to be delivered as soon as possible and resources will always be in short‑supply. Under these circumstances, this assumption of “unlimited resources” is no longer viable. Like they eventually always do, assumptions make an “ass” out of “u” and “me” (long‑form for “assume”). Kelley & Walker’s assumption has outlived its time.

In 1999, I started publishing about resource-constrained scheduling in PM Network from PMI with the article, Take the Path that is Really Critical. Ten years later, I started an international working group to define the next edition of the Critical Path theory, called Critical Path 2.0. Critical Path 2.0 had to consider logic-constrained AND resource-constrained projects. If you are interested in deeper reading on this topic, I recommend reading the working group’s final proceedings published here. I felt an urgent need to address the emerging reality of more projects turning into resource‑constrained projects. The need for Critical Path 2.0 is stronger now than it has ever been.

Going back to Microsoft! As early as 2000, I started publicly asking Microsoft to add the Resource-Critical Path feature to Microsoft Project in my textbook, Dynamic Scheduling with Microsoft Project 2000. I repeated this request in later editions under the same title, and again in my new textbooks Forecast Scheduling 2010, 2013, and 2018.

Here are my requests again:

Recommendation #4A: In Project for Desktop, add a Resource-Critical Path feature to (or acquire and integrate the PathsPro add-in).
Recommendation #4B: In Project for the web, add workload leveling AND Resource-Critical Path features.

You may be asking, what is this PathsPro you’ve referenced, Eric? Well, in 2012, I decided to hire a programmer and build this complete Critical Path feature myself in the form of an add-in to Microsoft Project that we called PathsPro. It took one year to complete. More info is available here, should you be interested. PathsPro does an amazing job of finding the Most-Critical Path in just about any schedule:

Resource-constrained schedules
Schedules in which advanced features are known to break the Critical Path 1.0, such as date constraints, task- and resource calendars, elapsed durations, and others (explained in the second article of this series)
Multiple-project schedules with dependencies between the project schedules, called Links between Projects in Microsoft Project also known as program schedules or Integrated Master schedules (IMS)
Resource-constrained programs schedules (IMS) (See our SanDisk case study, which demonstrates PathsPro solution for this most challenging group of projects/programs, here)

Click here for the SanDisk case study, which demonstrates the PathsPro solution for this most challenging group of projects/programs.

Again, readers, please let me and Microsoft know what you think of these recommendations in your comments below. Do you support these requests or not, and why?

¹Dependencies are relationships between the activities in the project that are necessary from a practical point of view.