Dear all,
In the parallel thread I published results of resource a leveling engine comparison, which I did on Microsoft Project, Primavera, Asta Powerproject, and Spider Project. However some people pointed out that my test results may be a bit “colored”, as I used Test Schedules from Vladimir Liberzon (Spider Project). Since Spider came to be by far the best out of my testing, Lord mentioned, that some other manufacture may be able to come up with the specially crafted schedule, where their tool would be better, then the ones of the competition.
Therefore I came to an idea to do a little project to compare resource leveling engines of different tools in a more structured and transparent way.
However to do this, we first need to define rules of the game. Therefore I have drafted an initial version of a document, which I called “Tests description and requirements to test schedules for automatic resource leveling functionality comparison test”.
Therefore I am kindly asking everybody, who is intersted, to do the following:
- Please comment if you think this is a worthwhile initiative.
- If your answer on the 1st question is yes, then please provide me your comments to the below document. Please note, that there are people on this site, who are hundreds times more experienced than myself in this subjects (I am just relatively experienced Microsoft Project user). Therefore I would really like to have your comments.
Regards.
Evgeny
========================================================================
Tests description and requirements to test schedules for automatic resource leveling functionality comparison test
1 Introduction:
Automatic resource leveling functionality is considered by many to be an essential feature of the scheduling software. However, unlike Critical Path calculation, there is no well-defined algorithm, which would always produce the most optimal result. Therefore different manufactures have a different implementation of resource-leveling algorithms, which often produce different result for the same schedule. Also often specific tool shows better results for one schedule, whilst losing to alternative tool on another schedule.
As a result of several discussions on the world’s largest planning community site ( www.planningplanet.com ), an initiative came up to run a little project to compare resource leveling algorithms of different scheduling tools with each other.
2 Purpose of this document
The idea is that selected tools will be tested on the set of Test Schedules, consequently outcomes will be published and analyzed. As a result both users as well as manufactures will be able see strong and weak points of resource leveling of different scheduling tools in specific situations. Hence users will be able to make an informed decision about usage of a specific tool; manufactures will be able to see strong as well as improvement points for their software.
The plan is to from one side make the tests as unbiased as possible and from the other side to allow different manufactures to show the strong point of their tools against competition by coming up with their version of a test schedule (provided it meets the requirements, agreed in this document).
This document will be used to:
- collect and select Test Schedules
- compare results of different tools, run on different Test Schedules
3 Scope of this document
- Description of tests, to be done on the “Test Schedules”
- Requirements for Test Schedules
4 Tests.
4.1 Shortest resource leveled schedule
- A Test Schedule will be loaded in a tool and resource leveling on all resources will be performed. The shorter the schedule, the better the result.
- No priorities (e.g. task ID) will be used. If tool has any default priorities, they will be deactivated.
- Splitting of tasks (if available in a tool), will be disabled.
- No tasks rearrangements will be done. If tasks are to be re-arranged – this will be a new Test Schedule.
5 Requirements for Test Schedules
5.1 Generic requirements
GR001 Test schedules shall be only targeted for testing of automatic resource leveling functionality, and not any other functionality, which may or may not be available to the scheduling tools.
GR002 Tests and test schedules shall be easy and transparent enough to be reproduced with minimal efforts.
GR003 Test schedule as well as leveling results shall be simple enough to be understood and assessed by a human.
GR004 To allow comparison between different tools, test schedule shall use most basic scheduling features, available to most (if not all) scheduling tools, which have automatic resource leveling functionality. This assumes, that some useful resource leveling features may deliberately not be included in testing for the sake of being able to cover a wider variety of tools.
5.2 Specific requirements
5.2.1 Size requiremens
SRSZ001 Schedule size shall not be more than 20 tasks
/* EZ Reasonsing:
- If it gets more, it will be difficult to understand for human
- 20 tasks is a limit of a trial version of Asta Powerproject
*/
SRSZ002 Schedule shall not have more than 7 resources to level
/*?? I took 7 out of my head, so I need an advise on what is the reasonable number?? */
5.2.2 General requiremens
SRGN001 Schedule shall have only Finish to Start links
SRGN002 Schedule shall not have variable resource assignments.
SRGN003 Schedule shall have fixed resource assignments (no skills)
SRGN004 All tasks shall be fixed duration tasks.
SRGN005 Every resource, assigned to work on a task, shall be required to work from the very beginning till the very end of the task.
SRGN006 Tasks shall not be splitable.
SRGN007 Resources, assigned to a task shall have the same percentage of assignment through the whole duration of a task (no curved or time-phased assignments).
SRGN008 Schedule shall have only one calendar, applicable to all tasks and all resources.
/* EZ: this is just to keep it simple. */
5.2.3 Delivery requirements
SRDR001 Schedule shall be submitted in the format ??TBD??
/* EZ: what format shall we chose not to be biased? One could think of Microsoft Project 2007 or Microsoft Project *.XML, but I personally had problem importing MPS XML file into Primavera. When I googled it, I found out that this seems to be quite often problem.
*/
Replies