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.

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

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

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

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 

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

Rafael,

at https://www.linkedin.com/groups/Resource-Leveling-Very-Interesting-Thread-45942.S.5990883937872809985?view=&gid=45942&item=5990883937872809985&type=member&commentID=discussion%3A5990883937872809985%3Agroup%3A45942&trk=hb_ntf_COMMENTED_ON_GROUP_DISCUSSION_YOU_FOLLOWED#commentID_discussion%3A5990883937872809985%3Agroup%3A45942 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.

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

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

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.

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