Guild of Project Controls: Compendium | Roles | Assessment | Certifications | Membership

Tips on using this forum..

(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?

(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.

resource levelling

8 replies [Last post]
Chris G.
User offline. Last seen 7 years 32 weeks ago. Offline
Joined: 14 Jul 2006
Posts: 28
Groups: None
hello everybody...

i just started in planning and this may sound easy for most of you guys but i do hope you could give some piece of advice/knowledge and expertise regarding this matter...

just want to know on how, when and rules of resource levelling...

tanx in advance...



Omar Grant
User offline. Last seen 12 years 36 weeks ago. Offline
Joined: 25 Sep 2005
Posts: 71
On construction projects (EPCM) I will normally level resources within their Free Float only. Modern projects are usually so time-constrained by clients that Total Float is usually minimal and lengthening activity durations can produce sub-critical paths easily. Of course - if we could more frequently ’relieve’ the schedule with a realistic project completion date then levelling would be that much easier!
Chris McKay
User offline. Last seen 14 years 2 weeks ago. Offline
Joined: 12 Nov 2007
Posts: 3

I’m new on here, but James Barnes’ reply caught my attention so I joined up. You have verbalized my thoughts on resource leveling, especially in a plant turnaround situation. We are running P5 at our company, and most of our sites have had mixed success with scheduling, that being not-so-great and out and out bad.

I have an Operations background, and have been part of the field execution activities. What I have seen is that not only is there a culture of people not believing in the schedule, but that culture is perpetuated not only by us fumbling to build good schedules, but by poor understanding of EVA and poor application of resource leveling. What I see in the end is that people in the field end up doing their own leveling (which they are actually somewhat good at).

What is absolute in scheduling, if done properly, is the hard logic. What the guys in the field want is "What is the list of my priorities??" and "What is coming at me in the coming shifts".

We seem to hang ourselves in the following areas:
1) We partition our resources by area in the field, but we don’t level that way in the software. Thus there is confusion where resources should go between areas.
2) We hand out a leveled, current shift schedule at 100% capacity utilization, and hand out leveled look aheads. When they can’t do something today, they use the look ahead to pick other jobs to do (which is good)….but you can’t tell what is hard and soft logic, so the guys try to get jobs going that aren’t even ready to do yet!
3) Critical mass….in a turnaround, the majority of your work has no relationship to other activities….just the “plant down” and “plant startup” milestones. So, those jobs you put off that have lots of float come back to haunt you once they add up to a point where you don’t have enough resources to complete them in time!! I don’t thing Primavera does any Critical Mass calculations for you (let me know if this is incorrect!).
4) Added work (from inspections) really adds more dynamic to everything….

Base lining with a leveled schedule lets you know resources required (loading and peak) and the rate at which work should be done. I agree (and will do) this. Beyond that, I’m trying to find a way to give out shift schedules that are well prioritized and have Critical Mass as a consideration….and I think that Resource Leveling has limited application here.

To Paul Harris:

Paul, you suggested several techniques for resource levelling, but none of them can be used in the real projects except the software levelling.

Resourced schedules of construction projects usually consist of thousands activities and thus manual leveling is the hard task that shall be repeated each time when something changes (for an example actual data are entered). It is impossible. Besides it is very unlikely that the resulting schedule will be optimal.

Applying relationships to activities sharing the same resources may lead to unreasonable delays when project data will change (and no project will be executed in full accordance with the initial plan).

The only real method is software levelling. You wrote that
“…this option does not maintain a critical path it should not be used when a contract requires a critical path schedule to be maintained. The Leveling function may be used to establish an optimum scheduling sequence and then Sequencing Logic applied to hold the leveled dates and to create a critical path.”
The software will calculate Resource Critical Path (or Critical Chain). The contracts here may include the agreed contract schedule. This schedule will show Critical Chain and there is no need to add unnecessary links that may prevent to optimize resource usage in future.
In any case the contract schedule and the working schedule that is used for resource assignments are not the same. And resource levelling is necessary for this working schedule.
Do you agree?

To James Barnes:


In the sequence of steps that you decribed you prioritized your works before trying resource leveling applying higher priorities to critical path activities. This may lead to the very poor schedules! I can describe some examples if necessary. You shall use the software capabilities before any manual actions. This way you will be able to compare the results and choose the best solution. You wrote that your software sometimes produce nonsense sequencing. You are lucky if you notice it because it is very hard in the large schedules. In any case manual leveling will not work and using the software is inevitable. Try to find the software that is reliable.
I don‘t understand why to “Constrain dates of levelled items” and then “Remove levelling constraints”? Why do you need not levelled daily updated plan? Daily plans are used for resource assignments and thus they shall be levelled. Team on the ground flexibility may lead to the wrong sequencing with bad consequences.
You wrote that “The problems start to arise if the levelled plan is deviated from too much.” I am sure that it will definitely happen in any project. In any case if you use the schedule for resource assignments you will recalculate it (with resource levelling) daily as we do in construction and turnaround projects.

Chris G.
User offline. Last seen 7 years 32 weeks ago. Offline
Joined: 14 Jul 2006
Posts: 28
Groups: None
Tanx guys...its still a bit complicated for me but anyhow i have an idea now to start with...hope you guys wont get tired in giving your advice/tips...

James Barnes
User offline. Last seen 36 weeks 3 days ago. Offline
Joined: 6 Sep 2007
Posts: 241
I am intrigued by the fact that Paul (whom I absolutely accept as an expert in these matters) doesn’t have a silver-bullet solution. Damn! I had asked a similar question a few weeks back, but with no substantive response. Paul’s post does provide a nice breakdown of the main techniques that I am aware of.

Which one you choose will depend on the nature of your work, especially as it pertains to how much "Long Float" work you have. My industry is an extreme example. In Equipment maintenance turnarounds, most of the work (overhauling a valve or inspecting a vessel, for example) is achievable independant of the rest of the project. We end up with a few critical or near critical paths (usually a large piece of equipment or a plant modification sub-project) but the majority of the work forms a Critical Mass rather than a Critical Path. Thus we have a LOT of levelling to do.

Paul’s point about constrained dates is correct, that you have issues with maintaining a view on your critical path. Sequencing logic we have found to be unsatisfactory because we just have too much to level and the nature of the logic is difficult to determine during execution (eg; did that valve come out after that pipework because it needed to (Hard logic) or because we chose to sequence it that way (soft logic)) Various parties (not just contractors) love to pick on perceived "incorrect logic" as a reason for plan abandonment, so we try and avoid it except in well defined cases (order of exchanger bundle pulling for example). It would be nice of P3 could flag soft logic links but I’m not aware of a way to do this.

The approach we take;

- Develop all "hard" logic and resourcing
- Decide on specific "soft" logic cases and sequence those
- Prioritise the works. Critical and near critical paths are obviously top, equipment dismantling for inspection is next, equipment reassembly is last (to allow max time for any unforseen repairs). An area or workpack priority is laid on top of this.
- Level following priorities. Ideally this is done manually, but often software based first folowed by a full scope item by scope item check and re-arrange which takes a LONG time but it worth it to avoid nonsense sequencing that software levelling can sometimes throw up.
- Constrain dates of levelled items
- Issue for comment and approval
- Set baseline
- Remove levelling constraints. Thus your target (baseline) plan is levelled but your daily updated plan isn’t
- Daily 3 day lookaheads indicate 3 things;
1. Critical and near critical items
2. Planned works (following the levelled target planning)
3. a list of "logically achievable" work allowing the teams on the ground some flexibility if they come up against a problem with the planned work or (*shock*) finish it early ;-)

This is not ideal but the best we’ve come up with so far. The problems start to arise if the levelled plan is deviated from too much, a "ruck" of planned work appears ahead of the Data date that can only be cleared by relevelling (not an easy thing to do when you’re on a 24 hour update cycle) However, for the Levelled work, we track on an overall earned hours basis by discipline. eg, the fact that you didn’t take the valves out in the levelled order is ok, so long as the valves are coming out at the rate planned. If any specific Scope item becomes near critical due to hard logical constraints, then the updated plan will automagically pick it out as it’s FF or TF decreases.

I’d be interested to hear any other approcaches to Critical Mass planning as it is always the part that bites us in the bum
Paul Harris
User offline. Last seen 1 year 46 weeks ago. Offline
Joined: 11 Apr 2001
Posts: 611
I like many people view resource leveling as part of a boarder subject of resource optimization.

There are several methods of resolving resource overload problems before leveling is considered:
• Revising the Project Plan. Revise a project plan to mitigate resource conflicts such as changing the order of work, contracting work out, prefabricating instead of site fabrication, etc.
• Duration Change. Increase the task duration to decrease the resource requirements, so a 5-day activity with 10 people could be extended to a 10-day task with 5 people.
• Resource Substitution. Substitute one resource with another available resource.
• Increase Working Time. Accelerate the working time of a project task, which may release the resource for other tasks.

After resource overloads or inefficient use of resources have been identified then the schedule may also have to be leveled to reduce peaks in resource demands. The process of leveling is defined as delaying activities until resources become available. There are several techniques of delaying activities and thus leveling a schedule:
• Turning off Automatic Calculation and Dragging Activities. This option does not maintain a critical path and reverts back to the original schedule when recalculated. This option should not be used when a contract requires a critical path schedule to be maintained as the schedule will no longer be calculating correctly.
• Constraining Activities. A constraint may be applied to delay an activity until the date that the resource becomes available from a higher priority activity. This is not a recommended method because if the higher priority activity is delayed the schedule may become unleveled.
• Sequencing Logic. Relationships may be applied to activities sharing the same resource(s) in the order of their priority. In this process a resource-driven critical path will be generated. If the first activity in a chain is delayed then the chain of activities will be delayed. But the schedule will generally not become unleveled and the Critical Path maintained. In this situation a successor activity may be able to take place earlier and the logic will have to be manually edited.
• Splitting work around peaks that may not be easily moved.
• Software Leveling Function. The Leveling function will level resources by delaying activities without the need for Constraints or Logic and will find the optimum order for the activities based on nominated parameters. Again, as this option does not maintain a critical path it should not be used when a contract requires a critical path schedule to be maintained. The Leveling function may be used to establish an optimum scheduling sequence and then Sequencing Logic applied to hold the leveled dates and to create a critical path.

Paul E Harris
Eastwood Harris Pty Ltd, Melbourne, Australia
Planning and Scheduling Training Manual & Book Publishers & Consulting

Rodel Marasigan
User offline. Last seen 10 hours 16 min ago. Offline
Joined: 25 Oct 2006
Posts: 1639

That’s a very interesting topic and requires a deep knowledge of understanding of what the real purpose of resource levelling.

Ref: Project Management—A Systems Approach to Planning, Scheduling, and Controlling, Eighth Edition by Harold Kerzner.
Ref: Project Planning Techniques by Parviz F. Rad
Ref: Project Planning and Scheduling by Gregory T. Haugan

There are two network replanning techniques based almost entirely upon resources: resource levelling and resource allocation.

�� Resource levelling is an attempt to eliminate the manpower peaks and valleys by smoothing out the period-to-period resource requirements. The ideal situation is to do this without changing the end date. However, in reality, the end date moves out and additional costs are incurred.

�� Resource allocation is an attempt to find the shortest possible critical path based upon the available or fixed resources. The problem with this approach is that the employees may not be qualified technically to perform on more than one activity in a network.

In addition to Andrews views, scheduling is not merely the process of assigning calendar dates to the completion of activities of the project, however. It also is the art and science of developing a predicted delivery or completion date for the project by way of developing a logical sequence structure for the project’s activities. The foundation of the scheduling process is the logical sequence of the elements of the schedule network, and this sequence serves as the basis for planning, resource allocation, and resource levelling.

The most common decision rule in resource-levelling heuristics is to allocate resources to critical path activities first, then to the other paths depending on the heuristic chosen. In some project management software, there may be no choice in the matter. Some, for example, give priority to activities based on early start dates, and others give priority to the criticality or amount of slack. The more upscale project management software gives the user several options in choices of decision rules. Many of those systems provide resource levelling, a feature that averages out available resources to determine task duration and generates a levelled schedule for comparison.

Resource levelling provides valuable information to the planner to assist in developing a workable schedule considering the availability of labor resources. A key aspect of critical chain project management is the heuristics used to allocate resources.

The proper setup of WBS & RBS enables to assign more accurate resources for every task/ activity in a network.

Hope this help,

Andrew Dick
User offline. Last seen 5 years 45 weeks ago. Offline
Joined: 14 Feb 2007
Posts: 295
You have just asked for the meaning of life.

Unfortunately the answer is not as simple 42.

The question you have asked will be best answered by many people covering many topics, suggestions, theoretical ifs, buts and maybes.

The process of resource levelling is a very complex one as it requires not only a detailed understanding of the project/s on which you intend to carry this out on but also the foundation data of you scheduling tool, resources, codes, activities, hourly burn rates, calendars, default selections etc, etc, etc, all need to be set up just right.

I would suggest that there will be a long line of replies to this question of yours which will leave you wondering if the process is worthwhile.

In a nutshell you should keep the data as simple as you can but still allowing the required level of data, you should document anything you do in setting up the system, and any subsequent assumptions or changes.

I have tried for a long time to achieve the ideal world of resource levelling and have found that there are many variables going against you.

At the current time I’m using P5 to generate some data across 4 projects from a common parent resource structure based on our company’s resources that we have available to our project office. the theory is based on a document I put together which outlines the basic simple setup for the foundation data.

you can access this paper at the following link

If you like I can send you a slightly updated version if you send me your e-mail address.

In closing I would also add