Resource Leveling: Recommendations

Welcome to the final article in the “Resource Leveling” series. If you’ve read the prior articles, you may have noticed a lack of recommendations. I did that purposely to keep those articles focused on the “black and white” aspects of tool functionality and so that I could present recommendations all together in one final article, after covering all functionality.

Keep in mind, a recommendation is something that is advised or suggested. It’s not a rule, a requirement or something that must be followed. However, it is generally based on experience.

The WBS is K-E-Y

As a project manager, you hold your own destiny. How you structure the schedule directly impacts your ability to maintain the schedule, which in turn drives any level of project schedule frustration and anxiety for the remainder of the project. Look at the images below. Both schedules contain the same tasks, the same resource assignments and the same dependency relationships. But which schedule looks easier to level, maintain or debug?

The work breakdown structure (WBS) is the only difference between the two prior samples. It’s a key aspect in the creation of a good, PM-friendly schedule. And the creation of a good WBS involves three disciplines: planning, organizing and reducing complexity. Let’s look at each area.


Want more? Watch Daryl Deffler’s two-part webinar series on resource leveling, now available, on demand.

Read Daryl’s articles in this resource leveling series here:
“Scheduling vs. Leveling”
“Problem Indicators”
“Leveling Mechanics”
“Leveling Hierarchy, Part 1”
“Leveling Hierarchy, Part 2”
“Resolution Options”
“Understanding Split Task Options”
“Leveling Fields”
“Limitations”
“Preparing to Level”
“Resource Leveling: It’s Time to Level Your Schedule”
“Resource Leveling: The Leveling Cycle”
“Resource Leveling: Recommendations”

Also, download a resource leveling “cheat sheet” in PDF format!


Planning

Planning starts before the first task is added to the schedule. It means understanding the project’s product (final deliverable) and developing a “deliverable-oriented” hierarchical work decomposition, also known as the WBS. This is a key discipline in the creation of a project schedule that will be easier to both manage and maintain. If you’re not familiar with this facet of project planning, here are several links, all of which provide multi-step systematic approaches for decomposing project work.

An overly simplified hierarchical work decomposition is illustrated in the following diagram. In the Deliverable Breakdown chart, “House” is the final deliverable. It’s broken down into smaller deliverables such as a basement, first and second floors, a roof and landscaping. Each of these smaller deliverables has a scope definition and its own set of deliverables. This breakdown process would continue until all deliverables are within a manageable scope and size. But for this discussion, we’ll end the breakdown at the second level.

When the work decomposition process is completed, the deliverable breakdown translates directly into the project schedule WBS or, in Microsoft Project parlance, the summary tasks.

Organizing

Organizing occurs as the schedule is being built in Project. It means arranging the deliverables and tasks in a logically structured and readable manner.

When possible, organize WBS levels (Summary Tasks) following the project work flow. Early deliverables should be at the top of the schedule; deliverables at the end of the project should be at the bottom. This will create a readable top to bottom, left to right schedule flow. The left sample below shows pre-organizing and the right sample shows post-organizing.

All tasks within a WBS (summary task) level should contribute to the creation of the WBS-level deliverable. If tasks are part of another deliverable, such as the “Driveway Installed” example below, move those tasks under the appropriate WBS level.

Minimize Complexity

Minimizing complexity also occurs as the schedule is being built. It means applying techniques to help make future project maintenance, such as leveling, simpler. This is where understanding scheduling and leveling will help you avoid future problems.

Minimize dependencies. Use only enough dependency relationships to create the correct schedule flow. Don’t add useless or redundant dependency relationships. The left image below shows the minimal dependency relationships required to create a simple Tasks A-D waterfall. The right image includes useless/redundant relationships between tasks A-C, A-D and B-D. These create extra maintenance and confusion and should be removed.

Don’t let Project interpret what it thinks the work sequence should be. Tell it. All tasks should have at least one predecessor and successor except project start and project end. Without a predecessor, Project will schedule a task to start as close to immediately as possible. Conversely, without a successor, Project assumes the task can finish anywhere from the current Status Date to the end of the project. Scheduling and leveling results will be much more predictable when Project is specifically told each task’s predecessor and successor.

Avoid schedule construction techniques that cause scheduling and leveling complexity/issues. These are items identified in prior articles such as manually scheduled tasks, priority 1000, hard coded constraints and manually entered work contours. There are valid scenarios where these should be used, but use of these should be an exception rather than the rule.

Strive for one task, one resource. The more resources assigned to each task, the more complicated scheduling and leveling will be. While this may not be feasible on every task, try to assign only the resource producing the task deliverable. With that in mind…

It’s OK to add tasks and shift work into them if they help you organize and manage the schedule. For example, add support tasks for roles that perform functions such as code reviews, work product approvals, and general consulting. These roles don’t directly produce the task deliverables, but they do have some involvement with the task work. In the sample below, rather than adding Janet, Joe and Rachell to module tasks 1-5, they were given a support task. This allows Bob and Sue to be the only resource assigned on their tasks, which in turn makes scheduling/leveling simpler.

Avoid hard date constraints such as “Must Start On” which are inflexible and tend to be at the core of later schedule issues such as inaccurate completion dates and work stuck in the past. Use soft constraints such as “Start No Earlier Than,” which Project can move later in the timeline as part of the Update Project function.

Avoid items that create more work for you such as fixed duration, manually scheduled and Priority 1000 tasks. These are tasks that you, the project manager, must MANUALLY monitor, maintain and manage for the duration of the project.

Scheduling and Leveling Options

Many organizations have scheduling and leveling option guidelines. If your organization does, use those. If not, my suggested leveling-related option settings are shown below. They’re a suggestion and a starting point. But depending upon the types of schedules you create and how you use the tool, you may find that other options provide better results. If you do, I salute you as this means you now understand and control the tool.

There are two scheduling options that impact leveling. These are highlighted in the sample below, along with my suggestions for which are checked and unchecked.

The remaining leveling options are contained in the Resource Leveling window. These are shown in the sample below along with my suggested starting points.

Final Thoughts

Don’t be frustrated if you don’t fully understand leveling on day one. It’s a complex process and it will take time to learn and understand. But stick with it. The long-term benefits far outweigh the work to learn it. With that said, here are a few last thoughts on leveling:

Don’t level until you’re ready. Use pre-leveling views such as those in the “Preparing to Level” article to find and remove all possible construction and scheduling issues before leveling.

Leveling is an iterative process. Expect it and plan for it. After you’ve built a moderately complex schedule, it could take you dozens of iterations to find and remove the initial leveling issues.

Don’t be afraid to experiment, but do it in a structured manner that allows easy recovery — meaning, one change at a time. Undo is your friend, but remember, Save clears the undo list.

Not all over allocations need to be fixed! How critical is the resource to the project completion date? How much is the overallocation? Is the resource overallocated on one day but not the entire week? These types of questions will help you determine if the overallocation needs to be fixed.

No More Curtains

Understanding can overcome any situation, however mysterious or insurmountable it may appear to be.
— Norman Vincent Peale

There’s a scene in the Wizard of Oz where Toto pulls back the curtain to reveal that the real wizard is just a guy pulling levers, twisting dials, pushing buttons and yelling into a microphone. In this series, we’ve followed Toto’s lead and pulled back the resource leveling curtain to examine all those mysterious leveling components such as the mechanics, the leveling hierarchy, resolution options and overrides. And now that we’ve examined everything, I hope you’ve found that it isn’t really all that complicated.

I also hope in this learning journey that you’ve discovered something else: You pull the schedule levers, you twist the schedule dials and you push the schedule buttons. In other words, you are the wizard.

Next Webinar

Common Issues in PM: Over-booked and Mismanaged Resources

Written by Daryl Deffler
Daryl Deffler is currently employed by a large insurance company where he provides project management, project scheduling tool, process, and standards consulting for an enterprise project management office comprised of about 200 project managers. He has over 25 years in the IT project management field with experience managing small projects to large programs. During this time he has also developed and taught classes in both project management and scheduling tools such as Microsoft Project 2013, Primavera and ABT Workbench. He has been employed in the IT industry since 1979 in additional roles, including software development, technical support and management across mainframe, midrange and PC platforms.
Share This Post
Have your say!
00
2 Comments
  1. Sonam;
    I’ve been out of MS Project for over a year now and don’t have a copy to look at so I’m basing my feedback on memory.
    I have a couple thoughts.
    1) Open all 20 projects together. Select all 20 from the project list and then open. You should get something that looks like a temporary master project with all 20 individual projects “stacked” on top of each other in the same view. Try leveling all 20 projects at the same time in this one view. You may get better results.
    2) This one’s a bit more complicated. Its a combination of resource assignment max units and dependency relationships.
    For the dependency aspect of this, within one schedule, dependencies should not allow Bob for example, to work on more than one task simultaneously. His enterprise max units will, for example be 100%, and if the dependencies allow, project will schedule Bob to work on up to 5 tasks at the same time in the same schedule. Using dependencies to restrict Bob to only work on one task at a time in the schedule guarantees that Bob would only be allocated in that schedule up to his task assignment level (lets says 20%), which allows him to then be scheduled on other tasks in other projects concurrently, utilizing the remaining 80% in other schedules.
    For the resource assignment units aspect of this, if Bob, for example is expected to work 5 project simultaneously, then Bob should have a task level resource assignments units not exceeding 20%. This should be on every task assignment. Note that while you can override the resource level Max Units to, for example, 20%, Project will reset that value back to 100% the next time the schedule is re-opened.
    3) As a suggestion, I’d remove the fixed duration on each task so that the resource availability (units, calendar, etc.) will drive task duration. Trying to manually control even just some of the the scheduling and leveling aspects of project leads to a lot of pain,frustration, and manual management of the project schedule. ,
    4) The root cause of the issue is projects running simultaneously. Can management make a decision on the individual project priorities? For example, Project C is top priority and if we could only get one project done, this is it. Then Project F, may be second priority, etc. This would allow you to simply schedule the resources to get the tasks done as quick as possible in each schedule, allowing the Project Priority to control leveling sequence. Highest priority projects would finish much sooner, rather than many projects finishing later.
    The second question is why do ALL the resources need to work simultaneously on 5-6 projects? Can you split resources across the top 2-x projects? Meaning Joe, Sam, and Fred are on Project 1, Bill, Jane, and Sally are on Project 2, etc. This removes many of the scheduling issues you’re encountering and provides an added benefit of allowing the resources to stay focused on the same project.

    Without knowing exactly what the projects are, what the skill sets are that are being shared, etc, it’s difficult to tell you specifically how to fix it. I hope these ideas help give you some ideas. Good luck.

    Daryl

  2. Sonam;
    Unless your entire project online environment only consists of your 20ish projects, leveling across all projects is almost impossible because you have no control over project priorities and resource usage in projects managed by other PMs. Hence my #1 suggestion in the prior response. But as you’ve found, that doesn’t always work. Not knowing anything about your individual schedules, resource usage, or work flows, here’s a couple more thoughts;
    1) Try setting individual task priorities within the schedules as well. For example the highest priority schedule has all tasks set to task priority of lets say 800. The second priority project has all tasks set to 750 (any number less than 800), and so on. You can do this quickly in the projects using the fill down function I believe.
    Note that your leveling priority may need to be changed to Priority Standard (if memory serves).
    2) Try using cross schedule dependencies. For instance Schedule 1 is the entry point for all work orders. Work Order #345 arrives. A WBS is created in Schedule 1 for WO345 which only contains the work for 345 done in schedule 1. Then a new WBS and tasks are added to schedule 2 for WO345. A cross schedule dependency link is then created between those same work order WBS levels from schedule 1(Predecessor) to schedule 2 (successor). And so on across all the schedules.

    Another option is a phased testing approach to see where the leveling process is breaking. Meaning, does the #1 project level OK by itself? If so, open the #1 and #2 projects together and see if that levels OK. And so on and so on.
    Depending on when the leveling starts to break may tell you which project is the issue and which project may need a deeper look. That may help you understand what questions to asks which in turn lead to the solutions. For example, may Bob is used full time in schedule 1 and schedule 10. When 10 is added, leveling has issues because Bob is now used full time in both.
    But also consider that there may be a limitation internally to Project that you’re hitting. For example leveling works fine with Projects 1-9 but when 10 is added, leveling breaks. Is that because Project 10 has issues or is there some internal issue that appears when ANY 10th project is added. For example open schedules 1-9 plus #11 (not 10) and see if the same leveling issues occur.
    I mention this because I’ve run into issues where the actual character length of the combined project schedule names exceeded an internal field size of say 500 characters (I don’t remember the real limit) that project used to store the concatenated names of all the open schedules. When the concatenated names got to long…the process broke.

    If leveling is still not working, you may simply have too complex of an environment (#schedules, resource use, etc). Find ways to simplify the scheduling environment. My best advice for any aspect of Project is that simpler is always better from both a PM perspective and a “having Project work right” perspective. For example, What is the reason for 20 schedules? is it a valid reason? Could this be just 1 schedule? How is the work organized in the schedule(s)? Is it an organization that matches process/work flows and allows dependency usage between process steps or is it random tasks that you’re hoping Project will magically organize and sequence for you? Any structure you can add, helps Project do it’s leveling job better.

    I’m not coming up with any more thoughts at this point.
    I hope this helps
    Daryl

Leave a Reply