This month we’ll look into other ways of crashing the project and see how levelling can work across multiple projects.
Please do not be too concerned if the results you get on your PC are not identical to those in this article. Project uses an algorithm to decide which tasks are delayed and that could give different results depending on how you build the plan.
As a matter of interest, some 20 years ago, I attended the launch of Computer Associates' Superproject for Windows. At the end of the presentation I asked the presenter if he would tell us the algorithm that they used to determine the leveling process. He looked me in the eye and said: "That's propriety information - next question please?" This part of the scheduling engine is that which makes one product different from another, and thus a jealously guarded secret! However, one can make some educated guesses – Project obeys the logic linking and starts at the first minute of the project looking down the task list to see if there's any overallocation. It will then look at the slack and delay a non-critical task in favour of a critical task. If there is more than one non-critical task overallocated, it will delay the one with the most slack first. And so on... And then the trail stops - what if there are 2 critical tasks, which one gets delayed? My guess is the one with the highest Task ID as there is an option to level by ID Only. Now consider there being more that one resource assigned - which one gets delayed? Again my guess is the resource with the highest Resource ID. Changing the ID order of the Tasks or the order in which you enter the resources or make assignments can give different results. I'm sure you can see how complicated the algorithm can become with multiple resources assigned! Consequently, Project will only give AN answer which will need analysing to see if it’s acceptable. Nevertheless, this knowledge, plus the use of constraints and priorities, gives us plenty of scope for tailoring leveling to optimise our requirements should we so desire.
You must understand that Project is not an optimising tool; all it does is to delay tasks until the resources become available.
As promised, we’ll use a multi-project scenario to further our deliberations on levelling. You can go back to the project we worked on in Microsoft Project: 17 – Multiple Projects, where we consolidated the three projects into a master which we called ramps. Or you can recreate ramps by clicking on these three files to load up Project afresh with the same three aircraft modification programmes.
If you can’t remember the detail, follow 17 – Multiple Projects (it’ll be good practice!). Briefly, you will need to create a blank resource pool project. Open the three files into Project and, to work in the future, change the Start Date of A to 1 Aug 05, B to 8 Aug and C to 15 Aug, and share each with the resources in the pool (it is easier to manage if all of these files are in the same folder/directory). Then Window/New Window… and select the three projects you’ve just opened, add a project summary task and Save As… ramps. In the screen shot below, I’ve shown the summaries with Start and Finish dates showing for the bars.
Check the Resource Sheet is only showing one set of resources – if not, you must have missed the share with pool requirement.
So let’s level. Tools/Resource Leveling… to bring up the Resource Leveling dialog. Check that the settings are as the default in the screen shot below:
Now click Level Now.
Because we have only one of each resource, the project is extended into Jan 06. Again, don’t pass judgement on this as this might be quite acceptable. However, I think the owners would hope for something better! Last month we saw that for one aircraft we would need at least 2 of each trade to complete within the critical path. Let’s see what ramps would need. Remember how to do that? Level Now but with a check mark in the Level only within available slack selection. Then split the screen, view the resource graph in the lower screen, select the preparation task and see if you get a peak requirement of 6 Airframe, 7 Propulsion and 6 Electrical tradesmen. All aircraft finish on the same day – 22 Sep after 39 working days.
So there we have the extremes. I now have to make some assumptions which, in real life, would be the limitations imposed by staffing. Let’s assume we have 3 of each trade – change their Max. Units to 300% in the Resource Sheet. Clear levelling and deselect Level only within available slack.
That’s more like it! A 50 days Duration with a completion date of 7 Oct. It goes without saying, even if you arrive at an acceptable set of dates, you need to examine what Project has done to achieve these dates. Some of the delays may not be acceptable to you.
For example, in Aircraft C, Project has injected a 1 day split in Task 9 - RMod 341 whilst it awaits a resource – this might be unacceptable and you don’t want Project to do this. One way to prevent this is to give that task a greater priority than the others. Remember, the use of priorities has no effect on the project except when levelling. So double-click the task and in the Priority box, give it 501. Note that 500 is the default for every task, the range being between 0 and 1000 with the highest figure meaning do not level at all.
Now Clear levelling and in the Resource Levelling dialog, select Priority, Standard and Level Now.
The effect of the priority setting is to give that task the resources rather than any other, thus the split is removed and a re-allocation of resources is made, resulting in a changed end dates.
We could, of course, have prevented any splitting by removing the selection Leveling can create splits in remaining work.
Try it and see:
Yet a different set of dates!
You can also prioritize projects. Let’s say the owner wanted Aircraft B to be available first. Double-click on Aircraft B’s summary name and in the Inserted Project Information dialog, in the General tab change the Priority to 600 (or any figure greater than that for the other projects).
Now level again with the Priority, Standard setting.
Aircraft B now finishes first on 22 Sep and the completion date is 7 Oct. Setting project priorities overrules individual task priorities, such that all of the tasks in Aircraft B will be given preference over those in the other aircraft, though priority tasks in Aircraft B will be honoured, as will those the other Aircraft after aircraft B’s allocation.
The final switch at the bottom on the Resource Leveling dialog is Leveling can adjust individual assignments on a task. This switch, when on, allows a resource to leave the other resources working whilst it goes off and works on another task and then comes back again to finish it.
Try removing the check mark and then level.
We have removed some of Project’s flexibility when levelling, thus pushing out the end date to 10 Oct.
The settings available in the Resource Leveling dialog also include a setting: Look for overallocations on a…… basis. This allows local management to organize their work within the granularity set.
For example, if you set it to Week by Week it only considers a resource to be overallocated if it is assigned more than the standard weekly hours you have set in Tools/Options…/Calendar tab – 40 hours is the default. So if the overallocation is more than 40 hours, Project will delay tasks to reduce the figure to 40 or below. However, if the resource is assigned, say 10 hours per day for 3 days, Project will not delay tasks, but leave it to local management to sort it out by, for example, allowing overtime. These settings will help Project Managers from trying to over-plan or over-manage their projects.
We have seen the range of levelling options open to us, each of which will give a different result. Remember that Project only delays or splits tasks; it does not optimise your project. It is up to you to examine the results carefully to see if you can live with the result. If not, then you have to resort to resolving overallocations manually, perhaps by re-assigning resources or hiring in more.
For a change of direction, next month we’ll have a look at customizing view and tables.