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”
“Leveling Hierarchy, Part 1”
“Leveling Hierarchy, Part 2”
“Understanding Split Task Options”
“Preparing to Level”
“Resource Leveling: It’s Time to Level Your Schedule”
“Resource Leveling: The Leveling Cycle”
“Resource Leveling: Recommendations”
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.
- The Work Breakdown Structure (MPUG.com)
- Work Breakdown Structure Method (Toolbox.com)
- Prince2 Product Based Planning (Prince2Primer.com)
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 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.
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.
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.