Comparison of resource levelling algorithms of different Project Management tools

For related discussions about Asta PP resource leveling:

www.planningplanet.com/forums/asta-powerproject/576477/asta-pp-resource…

www.linkedin.com/grp/post/45942-6006039263202803718

I was told that when sample projects were leveled by Asta resources assigned to activities were scheduled to work at different time. As the result activity durations become longer. It is like the car is used separately from its driver, the car was assigned without a driver and the driver was used without his car.

My contact did not find Asta option to assign resources together as the team (crew).

Mike, is it true? What did they miss? I don't believe that Asta is not capable of modeling simple team work.

Patrick

You said - The problem with most software is the assumption the duration is fixed - it is not, the quantity of work is fixed, the duration is a function of the resources allocated (but the relationship is complex).

Spider project can tackle the issue very easily with the use of production type activities whose duration is determined by the allocated resources, their production rates and the total volume of work.  

1. Production can be done by individual teams working on separate shifts and can be done by a combination of several teams.
2. Teams selection can be done among a pool of several teams that share common skills with or without same production rates.
3. For some basic software, skills and materials are just an ID label different to the functionality Spider associate with these names. 
4. As things change with activity progress the original resource assignments can cahnge, the team you use for the same activity on winter might be different to the team you use on summer and their production rates per unit time can be substantially different. Usually these are standard crews with different labor and equipment composition each with different output per day.
5. The team you use at night migh be less productive than the one working during the day.

I do not know of software other than Spider Project that can model activity duration as a function of the assigned resources productivity, it is a no brainer for us but not available everywhere. 

I was reluctant to go with very simple models but it was agreed to go low because most commercially available software cannot dream about modeling duration as a function of the resources allocated, a function that in many cases is linear but at other times it is not and for this we use skills for whole crews.

So we agreed to compare resource leveling capabilities without considering the other resource assignment variables Spider can handle very easily.

Maybe we can agree that software unable to model activity duration as a function of assigned resources is not good enough.

Best Regards

Rafael

Regarding the schedule GENETIC01, when I download it, then Spider complaints that file is corrupted and I can't open it. Can you reload it?

I downloaded myself the file and it works so it should not make any difference if I upload the same thing, I suspect it might be due to the Spider version you are using.  Try downloading again, try updating your Spider version and let me know, even if a demo version try updating it.

Thank you very much for testing Project Easy and letting me know, I do not have P6 nor MSP.

Best Regards,

Rafael

Patrick,

it looks like we live and work at different markets.

First problem that you mentioned does not exist and is not directly linked with resource leveling capabilities. 

And every owner wants to save time and money by proper use of available resources.

Those who are not interested in this loose time and money of somebody else.

The problem with most software is the assumption the duration is fixed - it is not, the quantity of work is fixed, the duration is a function of the resources allocated (but the relationship is complex). No one in the general commercial market is looking at optimisation, see the presentations at: http://www.mosaicprojects.com.au/Resources_Papers_152.html

Evgeny,

I want to take my time to congratulate you for your effort.  For some mysterious reason software comparison has been absent in recent years.

I am curious about your results for Project Easy with MSP and P6.  Is it possible you are still looking for MSP and P6 prioritization rules?  I thought you was to use default rules. I only have and use Spider Project.

Best Regards,

Rafael

Johannes,

Thank you.

Best Regards,

Rafael

Hi Raphael and Evgeny

I have ran the the leveling test GENETIC01 on P6 R8.4. I have 32 days without leveling and 49 days with leveling. The standard leveling option, activity leveling to "normal", was the shortest. I could not find an leveling criteria that could improve the 49 days.

<span>New Gallery 2015/4/11</span><span>originaldate</span><span> 4/11/2015 8:52:04 PM</span><span>width</span><span> 1152</span><span>height</span><span> 815</span>

regards Johannes

You can try Project EASY.

Thank Evgeny,

I cannot wait to see how P6, MSP and Spider results for GENETIC01 compare.  A small job, not very complicated but good as a jump start.

Best Regards,

Rafael

Ok, Raphael. So how much are those six days that are the difference between MSP and Spider worth? $60,000? $600,000? 18 human lives?

Y'know, it's bad enough that people die because it akesmore time than expected to develop a new drug. or build a new hospital, or respond to a disaster or dig a potable water well. But when the delay is caused by a computer algorithm, that is truly sad.

Fraternally in project management,

Steve the Bajan 

I got a duration of 43 days at a single click, no need to mess with prioritization rules.

http://www.mediafire.com/download/o4p6vludc93l3pq/RD603.001.sprj

Goinjg back to Basics, my next test schedule I call

GENETIC01

What is the best you can you get with MSP, P6 and Spider?

Best Regards,

Rafael

Vladimir,

I agree, but wanted to point out resource leveling is not just about renewable resources by challenging others daring to try the impossible, to try modeling resource leveling of other resource types using renewable resources.

I believe some people do not even know the difference between consumable and renewable resources and both matter.  Even fewer realize that spatial resources can be modeled via consumable resources, most do not know the concept and believe they will never have a need to model spatial resources.  

A year ago I was involved on a claim that was finally agreed using common sense but it was a perfect case for modeling spatial resources.  It was about a vocational school and because of unforeseen underground conditions a building was relocated causing all sequence to be changed.  Scheduling was tied to prefabricated elevated slab forms that must remain on each building until concrete work is finished, these are spatial resources.  Changing [justifying] the logic was a nightmare while spatial resource modeling takes care of it at a single click of the mouse, well two clicks.  It happened twice that a change in building sequence was in order.

Focusing only on renewable resources is myopic.

Best Regards

Rafael

Rafael,

at https://www.linkedin.com/groups/Resource-Leveling-Very-Interesting-Thre…;Paul Harris suggested to consider different leveling options comparing software leveling capabilities. It could be an interesting but separate discussion. Paul listed some options that may be considered and his list is not full.

But it is still interesting to compare resource consrained schedules created by different packages when leveling setting and requirements are the same. Evgeny suggested to try different software for most simple settings (FS links, no splittings, no materials, etc.), the settings that every scheduling software shall support. Later we may discuss other leveling requirements and how different packages meet them. Creating a full list of potential requirements is an interesting task.

The package that produces better (shorter) schedules can save a lot to its users. Let's start from the most simple case and then consider other leveling options, each one in the separate discussion.

Because of the delivery schedule you cannot do all activities starting from day one, at some point you will run out of brick resources so after Adjust activity schedules to remove overallocations the duration will be 29 days.

Feel free to make an excel table and calculate bricks availability day by day.  BTW in this case allowing splitting does not makes any difference although frequently it does. 

What did you got with MSP after resource leveling?  

Hi Steve,

Spider Project calculates the costs of delays. But I agree with you that this test shall focus on #1. Cost of time deserves separate discussion.

Best Regards,

Vladimir

I suppose we can agree ancient Egyptians would have to tackle resource leveling issues so the following problem might have been a regular routine.

Depending on the Pharaoh Dynasty bricks installation would not be allowed to be split, more advanced dynasties would realize it makes sense.

How long it would take to finish the three brick installation activities using MSP, during the two dynasties? Nothing new, perhaps ancient, they just had the abacus and could figure it out.

I would limit my use of such benchmark schedules to develop portions of overall resource leveling and then would look to see how it fits within the overall tool, but in modern times, after the abacus they are not good enough by themselves to evaluate the overall performance of resource modeling tools.

Hi, all.

I tend to agree with Vladimir that it's good that the problems are relatively simple. It's also good that they are relatively "standard" for testing algorithms. If a s/w package simply doesn't have sufficient functionality to digest the schedule, that's an important shortcoming -- but it's also a separate issue. I think that the "cleaner" you can keep this discussion by limiting it to a standard set of problems that any s/w should be able to do, the better.

When it comes to resource leveling, there are IMO three things that it's important for any s/w to be able to do:

1. Adjust activity schedules to remove overallocations. The judgement about how well it does this, in terms of delaying completion, is very important and what this test would be about.
2. Turn the time units of the delay into value/cost units, i.e., the impact of the delay on the ROI/NPV/EMV for measure ofdrag and drag cost of thedelaying factors. This would be very simple with the (a) the computation of resource availability drag (RAD) and (b) inclusion of an input field that allows the user to designate how much varying the completon date wil limpact the project's expected value. But does any s/w allow this? Vladimir, does even Spider allow this? Because it seems to me that including the functionality to monetize the cost of the lost time is the ultimate format for showing the importance of a superior leveling algorithm. That's why I urged Evgeny to include a column with a dollar amount based on a $1,000/day in time cost (or $10,000/day or whatever you like).
3. Finally, the s/w must include the ability to EASILY AND QUICKLY tie the delays, and the time cost for each delay, to the specific factor causing it. If I had a smallish project (say, 500 activities), a s/w package whose leveling algorithm produces an inferior (i.e., longer) schedule BUT THAT EASILY AND QUICKLY showed the delaying factors and the cost of each might be preferable to me to one that initially produced a shorter schedule but didn't aid much with the analysis and quantification. 

For purposes of this test and any paper based on it, I think it is best to focus just on #1 -- but I also think it would be good to include data showing the potential impact on ROI, just for those ironheads who don't get the point. ("Oh, but it's good if the s/w gives me more time! I'll probably need topush back the deadline anyway!")

I'm quite excited about this.

Fraternally in project management,

Steve the Bajan 

Evgeny,

Gargantuan 02 would be:

Task A - Evgeny - 10 days; 

Task B - Vlad - 10 days; 

Task C - Evgeny - 5 days; 

Task D - Vlad - 10 days;



Tasks A and C will have "Start" as predecessor. 

Task B will have A as predecessor. 

Task D will have C as predecessor. 

Tasks B and D will have "Finish" as successor.



Best Regards,

Rafael

Vladimir,

I am talking about simple things such as SS and FF relationships.  Does it meets the criteria or shall also be banned from such comparison just because MSP is so primitive you have to tweak the schedule?  I am not sure the tweaking to model SS and FF links to same activity using additional milestone dummies will yield same resource leveling within MSP, not sure about SS and FF relationships when not tied to the same activity, it happens.  What is complex about FF and SS relationships?

What is complex about the gargantuan I showed before?  It only have FS relationships, a single resource with availability of five across the board. Does it meets the criteria?

The results depend on how challenging the set is and based on the gargantuan it looks like the selection is not very challenging. 

Best Regards

Rafael

Rafael,.

these sets of projects are well known benchmarking tool. It is good that they do not include anything complex because any tool can be used with these simple examples. In other case it would be hard to compare resource leveling capabilities of different packages just because most of them do not include advanced features.

Just look at construction project in Spider Demo: it models working in two shifts, requires material leveling. I don't know other packages that include these features and so Spider Project schedule cannot be compared with the schedules created by other packages just because they cannot create any feasible schedule for this project. And there are other features like variable resource assignment, cost leveling, etc. that have no analogues in other tools.

So it is reasonable not to make a set of test projects too complex and include only those features that every PM software shall definitely support. This test does not try to compare functionality but just resource leveling algorithms. It would be nice if PP participants will try the packages they are using with the same projects adding data to Evgeny's table.

I am starting my own set and decided not to rule out schedules good for the Abacus, my first I call it the gargantuan.  See the following figure.

With Spider I can get out of the box the 7 days duration, MSP answer is 9 days or 28.6% longer than Spider.

Evgeny,

I downloaded J120 folder but it looks like the set is quite primitive, of the times where CPM relationships were limited to SF relationships, just take a look at the links table, also multiple relationships between two activities [usually SS and FF] are lacking, just look at the predecessors column an look for activities with multiple reference to same activity code.

These testing sets were developed decades ago for the limited functionality of CPM of the 60's, to me they are a joke, in order for the comparison to be valid as per today tools it must consider more complicated models, more complicated relationships. Good only to compare Ford Pinto models, a red Pinto versus a green Pinto.

Unfortunately some lazy academics are still stuck with decade old models and are not taking the time to develop something more up to date. Other simply do not want to rule out MSP limited functionality in fear of loosing some audience, for them it is all about publish or perish. 

Do you have something better, more up to date?

Best Regards,

Rafael

Hi, Evgeny.

I think it will be very important to get similar data on as many s/w packages as possible --Primavera, Asta, PlanView, Safran, etc.

Since I am not really knowledgable of any of them, I cannot help. But good luck.

Fraternally in project management,

Steve the Bajan

Evgeny, this is awesome!

My only issue is that, as wonderful as it is that you are doing it and publishing your results here, I'd love to see you do a more thorough study, testing more packages, and posting your results in Harvard Business Review, Project Management Journal, or some equally prestigious international publication.

I have some further comments:

• I would love to see you include an additional column for delay cost, using a standard of $1,000 (or euros or roubles or rupees or yen or whatever) for every day the project is longer than the unleveled duration. (In Total Project Control (TPC) terms, this would be the resource availability drag cost (RAD Cost) for the resource insufficiencies causing the delay (and thus value reduction). That would seem to me to make the point of the study even more dramatic. ($1,000/day seems like a reasonable and minimal round number.)  
• One of the important things that it has always seemed to me that a resource-leveling algorithm should do is to list, in descending order, the drag cost of the resource bottlenecks, i.e., how much each is costing. I would be curious if any leveler has that functionality, because your study would make the value of such a computation VERY clear!
• If you are not going to do try to publish the results of this study in a prestigious journal (and I really,really hope you will consider this), would you be willing at least to publish it as guest blog at my TotalProjectControl website? :-)

Under any circumstances, I am going to a mention and link to this tread on PM discussion groups on LinkedIn.

Thanks again, Evgeny.

Fraternally in project management,

Steve the Bajan