Project Management

Debunking four resource leveling myths

Andy Makar explains why these four resource leveling misperceptions or mistakes he has encountered are inaccurate.

Resource leveling is the process of ensuring the demand for project resources doesn't exceed the availability of project resources. Project managers run the risk of missing key dates or communicating inaccurate completion dates when a schedule is missing resource leveling.

Experienced project managers and newly minted PMPs know the importance of resource leveling, yet I often see meticulously detailed project schedules with resources assigned 120 hours in a 40 hour workweek. The more audacious project managers tell me to just trust them even though they have significantly overallocated resources. These project managers assure me the work will get done on time, but if the project schedule is intended to be a realistic model of future events, the schedule needs to accurately reflect resource constraints. Even if all of the tasks are well defined, a schedule with unrealistic resource expectations is still a bad plan. Project managers can also be reluctant to level the schedule since it may extend the timeline or adjust milestones beyond desired due dates.

In future posts, I'll demonstrate how to effectively resource level in Microsoft Project 2010. Before we start with the techniques, it is important to understand some of the misconceptions about resource leveling.

Myth 1: Automatic resource leveling should be avoided

The automatic resource leveling option in Microsoft Project is algorithm based, and the frequent observation is that automatic resource leveling extends the project schedule to an unrealistic finish date. The reality is the algorithm in Microsoft Project's scheduling engine looks at several factors, including task order, resource constraints, and task priority, when resource leveling. An algorithm-based leveling solution doesn't take into consideration the priority and work order preferences that manual, human-based leveling provides.

Automatic resource leveling can be used correctly by specifying the right leveling options and clarifying expectations upfront. There is also an option to level only within the slack of the current project schedule; this option will look to level within the current schedule's slack without extending the end date. It may remove overallocated resources entirely, but it is a first step in using automatic resource leveling.

Myth 2: Resource leveling isn't required on outsourced projects

On projects where the majority of tasks are outsourced to another team or a set of vendors, resource leveling should still be considered within the client project team. Each of the deliverables and milestones produced by the outsourced vendor will still require effort from the internal client team to verify the deliverables are accurate. Quality reviews, deliverable reviews, management status updates, and executive briefings and training all require internal client resources that have an impact on the employee's schedule and availability. Resource leveling within the client team still needs to be considered; otherwise, the project manager will have 100 hours of review work expected in a 40 hour workweek.

Myth 3: It is okay if the project manager is overallocated

Another mistake I see in schedules is accepting overallocation for the project manager. Some teams assume the project manager has unlimited capacity since she is providing oversight and not directly contributing to the project deliverables. However, project managers typically have administrative and contractual responsibilities to review deliverables, prepare for tollgate or milestone gate reviews, and distribute key communications; plus, project managers can also get overwhelmed when issues, risks, and communication needs don't line up neatly in a project schedule.

These tasks can be set up as dependencies to achieving key milestones and need to be planned and allocated accordingly. It is important to allocate a reasonable resource availability and level accordingly so project managers have the time to approve and support project administration activities.

Myth 4: Resource leveling is just too hard to learn

Resource leveling isn't difficult to implement, as long as the project manager understands the approach and the expected results. Resource leveling will usually delay a task or split a task until a resource is ready to work on the task. With Microsoft Project 2010, there are three approaches to resource leveling: automatic, manual, and leveling with the Team Planner view. None of the methods are difficult to implement, but it does take time to understand and tweak.

More in this series

About

Dr. Andrew Makar is an IT program manager and is the author of How To Use Microsoft Project and Project Management Interview Questions Made Easy. For more project management advice visit http://www.tacticalprojectmanagement.com.

7 comments
jmbelden98
jmbelden98

One of the most common errors that I see is related to scope control and resource leveling. Those of you that work on major projects know what I am talking about. Scope adjustments happen all of the time and incorporating them back into your plan is a critical component of managing and adjusting. I often times see the same time-lines trying to be held even though the scope has demonstratively changed. For a deeper understanding of this situation and more visit. http://www.upperedge.com/wp-content/uploads/2011/07/ue_whitepaper_gaincontrol_6_16_11.pdf

PulseFactor
PulseFactor

One very common mistake made by project managers attempting their first resource leveling exercise is to precisely model reality. Today's tools, MS Project included, allow a scheduler or PM to set up Resources with various work schedules, vacations, sick leave, and more. This results in an enormous amount of time getting the schedule set up and as any PM or scheduler knows, nothing goes precisely according to schedule. Then it is a maintenance nightmare. It is better to allow for a certain degree of inaccuracy (because it is a prediction of the future that is going to happen anyow) and keep it simplified. How simple? That will vary by project and individual and budget -- but don't try to use every option available because it usually results in a less accurate schedule than a more accurate one.

viveka
viveka

Automated resource leveling works very well when you have planned the project that included elapsed time and effort time. Not otherwise. I have rarely seen planning at this granularity. And the second issue is project plans are padded arbitrarily (no metrics or policy for padding). Garbage In, Garbage out. This causes PMs to overload, make unrealistic projections, etc. Project planning is a science. Project Management is an art.

IainBegg
IainBegg

More often than not, resources are not dedicated 100% to a single project. They may have business as usual duties or they may be shared across more than one project. In my opinion Resource Leveling at the Portfolio level is far more important than at the Project level and it is a management skill requiring judgement and compromise on a continual basis rather than an automated push-button solution. Sure, MS-Project helps us to understand the problem and it's good at highlighting conflicts but it is just a tool and it makes the assumption that your estimates are perfect - in the real world they aren't so continual monitoring and adjustment is needed.

robinfgoldsmith
robinfgoldsmith

Most project management concepts and tools, including resource leveling and its various implementations in MS-Project and similar tools, are based on construction projects where laborers are essentially interchangeable. For such projects, task dependencies are the only factor affecting schedule; and resource leveling is meaningful. On the other hand, most projects that most of us are likely to be involved in have both task and resource dependencies. That is, it makes a difference who the individual is that performs a task. If that individual is already busy, the task that individual must perform cannot be started until that individual actually is available. When tools define the critical path, they address only task dependencies but fail to take such resource dependencies into account. Resource leveling also fails to recognize that who does certain work has additional ramifications beyond mere loading. Together, these failures to recognize and adequately address resource dependencies lead to erroneous and deceptive critical path and schedule definitions that will be the undoing of even the most conscientious project manager.

Fairbs
Fairbs

Of the three leveling methods mentioned, what are people's preferences? Is it a good idea to do all three methods and compare the results to come up with a 'best fit'? I'm a little leery of using automated methods in Project from using it in the past. It may be that it has been improved. Lots of good insight in the article.

BALTHOR
BALTHOR

We'll take all you got!