Automatic resource leveling proven to completely fail in construction

Resource workload optimization: from the phantom of automatic leveling to visual resource optimizers.

The idea of the “red button” has again proved to be a phantom, this time for resource leveling.
Professional project managers have always faced the problem of resource workload optimization. Thus, the problem considers drawing up schedules with a maximum resource workload and prevention of resource overloading at the same time. And it is, actually, the art of using schedule optimization techniques subject to resource workload that makes a difference between a professional scheduler and a beginner.
 However, it is time to recognize, that in the market of so called project management tools  intended to  resolve  all these problems, a ”100 %  automatic  resource leveling” soap bubble has appeared. And it is even not some specific suppliers of algorithms to blame,  but the fact  that despite the aggressive advertising less than  1 % of users were able to deploy such systems, while the commercials made them splash out for new panaceas again and again.
 It is very interesting, however, that the soap bubble of automatic resource leveling in Russia was blown by an ordinary building project manager from Ufa. He has used specific and simple examples to publicly prove not just the ineligibility of resource leveling for a specific project management system, but the fact that the whole idea was no more than a mathematical abstraction very far from real practice. If you didn’t have a chance to learn these useful practical instructions before, you can find them in this article.
The results of the opinion poll among the users of project management programs have shown that realizing automatic resource leveling as a fake became already common with the majority of professionals. Therefore AxProject has offered the tools of new generation known as visual resource optimizers, which debuted in AxProject Professional, v.3.0.   

How a builder has proved resource leveling to be a mathematical abstraction to the developer of project management systems

The obvious argument against resource leveling is in the impossibility of resource workload optimization to be fulfilled just by pushing one magic “red button”, which is supposed to do the job. The reality is often far too complicated to be modeled by these algorithms. Moreover, the complexity of their setup makes the whole sense vanish, as the effort needed for it is much higher than one for the process of manual resource conflict settlement.  
Very often systems of automatic resource leveling are sold through forums since the complexity of their adjustment forces the supplier to look for professional schedulers there. However, in one of such cases they stepped on a mine. A professional scheduler being a builder has proved in a conclusive way the inconsistency of the idea of automatic resource leveling. His argumentation was so convincing that it has quickly spread among professionals. Therefore the vendor had to find a way to erase this discussion. The managers of the forum have agreed to erase only the vendor’s replies, leaving the arguments of an expert which are easily found through Google. These arguments became even more valuable since they do criticize the whole idea of automatic resource leveling, not just some specific realization of resource leveling of some specific vendor. To make the arguments of an expert given in the discussion easier to understand, we shall briefly state the questions put by the vendor.

 "Automatic resource leveling is fraught with consequences"

In the forum, in reply to the inquiry of a new user, the vendor starts advertising automatic resource leveling when he receives a critical remark from a practicing builder who calls it an abstraction unable to model the reality adequately.

The BUILDER: As practice shows, you can’t entrust resource leveling to the program. It is impossible, for it is fraught with consequences. There do arise such decisions which seem to be quite fair within the limits of the task, but prove to be absolutely inapplicable to the reality. There are too many factors which this algorithm (no matter how perfect it is) is simply unable to consider.

"No model will ever be able to consider all the logic of reality"

The vendor approves that his algorithms of resource leveling are perfect, while the builder gives an example to ridicule the operation of the algorithm in reality.

The BUILDER: There are too many factors. And it is inexpedient to hammer them all into a machine. For example, there are two objects and one expensive tool. If that seems appropriate to the algorithm of resource leveling, than the latter will teleport this tool between the two objects nearly a hundred times a day, until you "explain" to it that transportation is never instant and costs money. Or it will send workers to a zone with recently filled floors, or will pack more than eight workers in one room at once, and stuff…

 "Other examples from life which are difficult to model with existing software"

The vendor tries to approve that the given example with the necessity of teleportation and people sent to walk on stiffening concrete is an exemption from the rules, and that no problems arise usually. The practicing builder shows that it is exactly usual with resource leveling to behave abnormally and that the model of resource leveling is imperfect from the very root. Again he uses examples to support himself.

The BUILDER: Some more life situations which are complex for modeling with existing software.

  1.  An object is divided into zones. It is only possible to get to zone B from zone A, but there have recently been established levels for filling in concrete. If it is even possible for a group of people to pass, then carrying bulky materials can cause hurting the levels. It can’t be allowed.
  2.  You can pass to an object only under admission. Some workers do have it, and some – don’t.
  3.  The works take place at an operating enterprise. Some works are characterized by strong noise and are advised to be carried out at night. Though, if the noise is temporary, nobody will suffer. How can you put it into a program?

“Automatic resource leveling is an “artificial” solution”

The vendor tries to simplify the task for the algorithm of leveling so that it could solve it, while the practicing builder calls it an “artificial” solution and goes on giving examples which show that it is a mathematical abstraction, not the reality. The builder also stresses the point that the attempt to set up a leveling algorithm lacks the effect of a “red button”, making the user put enormous effort into setting it up.

  1. The resources can be delivered at any moment. It’s just that the hard driver of the optimizer should know that it’s desirable not to start the works which demand bulky resources. And it should take into consideration the geometry of the object as well. You can’t find it anywhere yet.
  2. Noisy work is the one that is done with noisy instruments. If the tools or the technology is suddenly changed, than the optimizer should keep this fact in mind during the future run. Alas. Well, I do agree that most of the given situations can possibly be resolved with existing software. But the out coming project is doomed to have so many additional restrictions, fictitious resources and communications that users will be glued to fat Tips&Tricks Manuals.

More problems showing that the algorithm of leveling is no more than an abstraction

The vendor tries to state that the data directories of his algorithms are universal and are able to reflect absolutely any project specificity. The builder proves the opposite.
The BUIDER: Right. And how do you reflect the “bulkiness” of the resource in your data directories? And how will the change of such a resource quality influence the process of schedule optimization?
I didn’t set up a problem.  I simply gave a private example right after the general one. In any way, a “zone” is just a part of the building object characterized by the common nature of the works done in it. Why should it be added into the multiresource? I do agree that the model is an invaluable instrument in making administrative decisions. But as any instrument it has a number of restrictions. The main one is “a model is a logical abstraction”. Does your model take into consideration the deterioration of tools? The need of your workers to rest? Is the space of the room where you keep the tools taken into the account? The tools’ size themselves? Or maybe the geometry of the construction object? If you say “yes” to these and a couple of other my questions, then surely I will recognize your model adequate to the reality. ”So there are millions of dimensions”. It is true only if the optimization considers the whole project. If the floating “focus” is used, then during an epoch only a part of a chromosome is optimized, thus, the dimensions will be much fewer (the direction of the optimization should go from start to finish. The criterion function should correctly take into consideration the project specificity as well). Though, talking about 10000 tasks projects, even this approach will demand monstrous computing resources.


Automatic leveling can solve only very specific tasks but it’s useless as a complex solution.

 The vendor tries to specify the task, thus showing that his algorithm can level materials and work with calendars. The builder shows that in reality leveling of materials will fail and that the calendars are not reliable enough to be handled by the machine. 

  1. Anyway, what are we going to get if we switch from bulky sacks with solution to small ones in the whole project? Or vice versa? The whole project will have to be reconsidered in search of the places where such a change is significant.
  2. Right.  And what if one and the same instrument in one zone of the object can make noise at any time (cellar), and in another – only after 6 p.m. (in areas close to office premises)? “…The manager’s task is to create such a model that reflects the reality”. Any model inherently is only an abstraction reflecting the essentially important characteristics of the object of modeling. You can’t bring reality into it, and why should you? “The creation of a computer model of the project is a creative process”. In the ancient times when there were not enough tools and knowledge, even the creation of a cold weapon was a creative process. When the machines emerged, people were freed to solve more important problems. The same stuff is about creating project models – it is yet a creative process.”

 Why consider only what product suppliers are trying to sell? 

The VENDOR:”If you mean schedule optimization– have you seen it anywhere else than in (the advertised product)?”
The BUILDER: Why consider only what the mass market has to offer?
The discussion, as we see, was closed by the straight offer to buy the product and the builder’s refusal together with a wish to consider the alternatives.
It should be mentioned that the practicing builder has shown convincing examples on all the faults of a 100% automatic resource leveling:
The impossibility of leveling algorithms to model the reality in all its complexity ends up with automatic creation of plans rather of a comic sense than useful for actual work.

Huge efforts required for setting up the leveling algorithm and constant corrections made to the model during the project work make no sense as manual resource management conflicts are much easier and less effort-consuming to settle.
The alternative to automatic resource leveling is AxProject’s visual resource optimizers which work according to a different scenario responding to the critics of earlier methods.

 AxProject Visual resource workload optimizers

 Although the fact that the idea of automatic resource leveling has flopped is clear even to an ordinary builder, the problem of an efficient resource optimization still remains.
The inquiry among schedulers shows that the failure of automatic resource leveling is obvious practically to everyone. At the same time there is a growing interest to instruments that allow the scheduler to interact with the program so that the resources are optimized with a minimal effort.
Thus, the idea of visual resource optimizers was born. In AxProject, they first appeared in version 3.0.
The idea is that the main resource leveling scenario is based on the ability of the program to visualize the specific places where optimization is needed with the help of a wide range of graphical means.  The program’s interface is designed in a way for the scheduler to give instructions to the program concerning the use of resources during the operation just by a double click of a mouse.
Actually the work with a visual resource optimizer is quite similar to a strategy game, where you, the scheduler, manage tasks with a mouse and give commands to the program on which decision should be taken.
The scheduler in this scenario of resource optimization manages the process 10 times faster than when setting up huge forms with automatic leveling parameters. The results of automatic leveling must also be checked otherwise you may face comical situations described by our practicing builder. Old project managing systems simply have no means for visualization of “suspicious” places. The scheduler has to do tiresome and monotonous work checking all the operations.
AxProject Professional, on the contrary, has visual indicators which point to where your attention is needed.
AxProject has several visual resource optimizers. The main ones are:

  •  “Red Men” – this icon indicates the task having a resource conflict with a suggestion to use the conflict managing master.
  •  “The visual resource optimizer of all the project resources” (Team Planner) – this tool allows the scheduler to analyze resources and gain optimal usage of ones by managing tasks with a mouse.

Find out more about AxProject features

Comments are closed.