Every project management package has a button that fixes an over-allocated schedule. Microsoft Project calls it Level Resources. Primavera calls it resource leveling. You click it, the bars slide right, the red goes away, and you get a new finish date. What none of them tell you is how far that new date sits from the best one available.
I went looking for someone who had actually measured it. I found a paper from 1999 — and then noticed something strange about what happened to the topic afterwards.
What the button is actually doing
The first two stages of project planning are cheap. You build the network of activities and precedence links, then run a forward and backward pass to get earliest and latest start times. That is the critical path method, it assumes you have unlimited people, and it is fast because the problem is easy.
Then the software draws a resource profile — how many people each day — and, if demand never exceeds capacity, you are finished. It almost never doesn’t. So there is a third stage: schedule the thing subject to the crew you actually have. That step is NP-hard, which means no commercial package is solving it exactly, and none of them claim to.
What they do instead is a priority rule. Rainer Kolisch, writing in Interfaces, describes the method as three choices stacked together: a loading direction (schedule everything as early as possible, or work backwards from the due date), a scheduling scheme (serial or parallel), and a priority rule to pick which activity goes next when several compete — minimum slack, shortest processing time, minimum latest finish. Panwalkar and Iskander had catalogued more than a hundred such rules by 1977.
Which combination is inside your software is proprietary. Kolisch says so plainly, and it is the reason the study exists at all: since you cannot inspect the method, the only honest way to judge it is to measure what comes out.
Seven packages, 160 problems, one known answer
The setup is the part I like. Kolisch generated 160 project instances under a fractional factorial design, varying the number of activities (10, 20 and 30), the number of constrained resources, how scarce those resources were, how many of them each activity demanded, and how densely the precedence network was linked. Then he solved every instance with a branch-and-bound procedure that returns the provably shortest schedule, and got optimal answers for 153 of the 160.
So he had a right answer to compare against. He then ran all 160 through each of seven packages that were popular at the time — Artemis Schedule Publisher, CA SuperProject, Microsoft Project, Primavera Project Planner, Project Manager Workbench, Project Scheduler 6 and Time Line — using default settings and full leveling. That is 1,120 schedules, each with a known best possible finish date sitting next to it.
Across all of them, the median schedule came out 3.57% longer than optimal. The mean was 5.79%. The packages landed exactly on the optimum 45% of the time. And the worst single result in the set was 51.85% above optimal.
A median of 3.57% is not a scandal. On a twelve-month build it is about two weeks. Two weeks of general conditions, two weeks of crane rental, two weeks of a superintendent’s salary — but two weeks, not two quarters. If that were the whole story I would have read the paper and moved on.
The number that should bother you
It isn’t the whole story, because the averages hide where the misses happen.
Kolisch varied a parameter called resource strength, which is essentially how tight your crew is relative to what the work demands. At 0.7 — comfortable staffing — Microsoft Project came in 2.79% above optimal. At 0.2 — genuinely short-handed — the same package came in at 9.76%. Artemis went from 7.07% to 14.71%. Time Line, the most stable of the seven, still slid from 3.59% to 5.86%. All seven degraded, consistently, in the same direction.
The same pattern shows up when you add activities (Microsoft Project: 2.36% on ten-activity problems, 6.91% on thirty) and when more of the work competes for the same scarce resources.
Read that back slowly, because it is the finding that matters. The leveling heuristic is at its best when resources are plentiful — which is precisely the situation where you do not need to level anything. It gets worse as the squeeze gets real. You are relying on it most heavily at the exact point it is least trustworthy, and because it hands you a clean Gantt chart either way, there is nothing on screen to tell you which case you are in.
I have some sympathy here, because I have shipped tools that behaved beautifully on the easy case and then embarrassed me on the hard one. My own free shift scheduler ran happily for months until the sample problems got big enough that a long solve started tripping the host’s five-second health check and taking the whole app down with it. Small instances, no symptoms. Real instances, a mess. The difference is that I could go and find that out. You cannot open up Project and ask it which priority rule it just used on you.
And then the literature stopped talking about it
Here is the part I did not expect. I keep a tagged index of the back catalogue of Interfaces (now the INFORMS Journal on Applied Analytics) — 1,419 papers from 1970 to the current issues, each labelled by the kind of problem it actually solves. It is the journal where practitioners write up what they did at real companies, so it is a decent proxy for what the field was being paid to work on.
Project and maintenance scheduling accounts for 55 of those 1,419 papers. The share peaked in the 1990s at 5.5% of everything published. In the 2010s it ran at 2.9%, and this decade so far it is 2.0%. Roughly half of what it was.
Meanwhile healthcare scheduling went from literally zero papers before 2000 to two dozen since, and assignment and matching problems roughly doubled their share. The field did not run out of energy. It moved.
My read — and this is my interpretation, not something the data proves — is that project scheduling did not go quiet because it got solved. It went quiet because it became a product category. Kolisch himself notes that nobody could evaluate this capability before the 1990s, because the packages did not offer it. So the sequence runs: the feature appears, somebody measures it once, it becomes a checkbox on a comparison page, and the practitioners who would have published about it go and work on something that still looks like an open problem.
The measurement never got repeated at scale in the same venue. The heuristic stayed.
Who actually has this problem
The industries attached to those 55 papers are not the ones you would guess from a Google search. Electric utilities, automotive, defense, highways, aerospace, shipbuilding, heavy construction. Pavement management. Nuclear dismantlement. Generator maintenance outages.
There is one thread in there I find hard to look away from: General Motors published on scheduling its cold-weather vehicle tests, Ford published on scheduling crash tests, and Volkswagen published on its pre-production centre. Three car makers, the same resource-constrained scheduling problem, spread across sixteen years. These are organisations with the budget to buy any software they want, writing up the fact that they had to go build the schedule properly themselves.
Search for resource leveling today and you get explainers written by project management SaaS companies for people managing knowledge work. Nothing wrong with those, but they are aimed at a reader whose constraint is attention, not a reader whose constraint is that there are three electricians and the switchgear only arrives once.
What has actually changed since 1999
Kolisch’s benchmark solver had an hour of CPU time per problem on a 40 MHz machine with a maths coprocessor, and that was enough to prove optimality on 153 of 160 instances. A constraint solver on a current laptop chews through problems that size in seconds. I went through this comparison in detail when I swapped solvers on my lineup optimizer and watched an eight-fold speedup fall out of nothing but a better engine.
So the reason your scheduling software still runs a priority rule is not that exact methods are out of reach. It is that the priority rule was chosen back when they were, and nothing since has forced the question. (Which is a very ordinary way for software to end up the way it is — the fastest thing that worked in 1994, preserved in amber.)
That is the gap the next tool in this series goes at, and it is now live. The project scheduler takes a task list, durations, predecessors and how many people you actually have, and answers two symmetric questions with the same model: work within my crew — when does it finish? Or keep my date — how many people would it take? Not a priority rule. An actual optimizer, free, in the browser, no signup.
The second question is the one I would not go back to a spreadsheet without. Feed it a renovation that wants five people for a fortnight when you have three, and instead of quietly sliding bars it tells you the size of the crew your date is actually asking for, and what the finish becomes if you keep the crew you have. It also says which kind of answer you are holding — proved optimal, or the best it found before the clock ran out. After everything above, that line felt worth putting on screen. If you want the same idea pointed at different problems, the staff scheduler and the route optimizer are next door. And if you want to read the study yourself rather than take my summary for it, it is Kolisch, R. (1999), “Resource Allocation Capabilities of Commercial Project Management Software Packages,” Interfaces 29(4), 19–31.
Twenty-six years later, nobody has told the guy with three electricians.
Things that I use, like, and am affiliated with:
Mint Mobile offers great cell phone service for $15 flat, get $15 off using the link. Get discounted phones with service activation and no contract.
I never spend money before I check Mr Rebates or Rakuten to get cashbacks, rebates, discounts, coupons or cheaper gift cards.