Real-Life MS Project: Dependencies and Leveling

Alex S. Brown, PMP IPMA-C

Microsoft Project is a widely-used scheduling tool. Its quirks and complications are a huge drain of time on the Project Management community. This series will go beyond tips and tricks to discuss solutions to real-life problems, to save time for its many users.

Most Project Managers have learned a specific method to build dependencies between tasks and to build a resource-leveled schedule in MS Project. It is a relief to find something that works. Fear of upsetting a working schedule is great. We stick with what works even while cursing its shortcomings. Project Managers have choices, though, and choosing the best method for the project at hand is the best way to save time and reduce frustration.

Three Methods Plus One

There are three solid methods to build a plan, plus one that appears in MS Project marketing. Each method offers different ways to build dependencies and level resources:

  • The “easy” way: enter tasks, then key in start dates to make the resources level. Point-and-click simplicity!
  • The “dependency-driven” method: every task that every person does is joined in a start-to-finish chain. MS Project encourages this approach.
  • The “traditional” approach: build a work breakdown structure (WBS), draw a network diagram, estimate task duration and cost, assign resources, and resource-level the schedule. Only by exploring hard-to-find settings can the Project Manager find the keys to unlock this method. This article puts all those keys in one place. Full disclosure: this author favors the traditional approach.

There is a fourth method, featured in MS Project marketing and help files: create your plan, add resources and dependencies, and run the “auto-resource-leveling” algorithm. The author cannot recommend this method, except to create a quick estimate of the project end date. The software puts tasks in a very strange order. A variety of seasoned users have provided the following advice over the years:

  • “You will see it on the menu. Never, ever click automatic resource leveling.”
  • “I do not like to use it. If you want to use it, always save your plan before clicking the button. You never know what it will do to your schedule.”

If anyone has had success with this feature, please e-mail me.

[Added after publication: A helpful reader, Lynn Frock, PMP, has reported success with automatic leveling. He has used it on single projects and also to balance resources across a portfolio of more than 15 projects in a resource constrained environment. He maintained this portfolio for over two years, with no more than a couple of work days spent each month. Lynn found that accurate, resource balanced schedules can be created and maintained. These schedules make efficient use of available resources and allow good time/cost/scope trade-off decisions. He found that this approach saved time planning and re-planning project schedules, particularly to see the effect of adding new resources and new projects. He offers an Advanced MS Project class that teaches the technique. His company provides assistance with planning, training, mentoring leaders, and implementing scheduling systems as well. Visit his website at http://www.lynnfrock.com/ for more information.

I have new hope for this feature. Once I get some time to explore and apply this feature myself, I will write a feature on this technique. It is still fair to say that this feature requires caution. A solid approach, like the one Lynn has developed, is important to use it successfully.]

The “Easy” Way

  • Gantt View of twelve tasks, each appears as a simple milestone. The milestones are spread evenly across a three-month period. A typical ‘Easy’ Gantt chart

The first method is the easiest to use. It is great for a simple, milestone-based plan or a high-level plan. First key in all the tasks in the WBS. Do not enter any dependencies; assigning resources and work effort is optional. Enter the duration for each task, and set zero duration for all milestones.

By default, each task starts on the project start date. Enter the correct start date for each task. Pick start dates that allow predecessor tasks to finish in time, and that level your resources.

Advantages: quick and easy to enter. For a project with less than 50 tasks, this method is the shortest way to get from WBS to schedule. The more information the Project Manager enters, the more useful MS Project reports are, but almost everything is optional.

Disadvantages: the burden of tracking dependencies and resource allocations falls entirely on the Project Manager. Simple projects are good candidates, with few dependencies and simple use of resources. The only value of MS Project is to produce reports, though. Drawing and spreadsheet programs often do a better job, using less time and less money.

The “Dependency-Driven” Way

The Project Manager can drive every date with dependencies. Dependencies can even force resource leveling. First activate the “auto-link tasks” feature of MS Project in the Options dialog box. Build the WBS for the project. If one person performs several tasks, enter them in order. Allow MS Project to link task #1 to task #2 to task #3, and so on. Assign resources to each of the tasks. Break the dependencies only when you change resources. For instance, resource A will perform tasks #1 to 7. Resource B will perform tasks #8 to 12. Break the dependency between 7 and 8, and leave 1 to 7 linked together, as well as 8 to 12 linked together.

  • A very wide network diagram of twelve tasks, showing tasks one to seven linked in a row, and eight to twelve linked in a row below. Task twelve is dependent on task three as well. A dependency-driven network diagram shows who is working on what; logical dependencies can be hard to find

For this method, task duration is absolutely required, and work estimates are strongly encouraged. MS Project will calculate the end date for each task. The chains of dependent tasks are resource leveled, so long as all resources put 100% of their available time on each task from start to end. Create milestones to mark resource start dates, and make their first assignment dependent upon the milestone. If the milestone start-date changes, all future tasks will neatly roll forwards or backwards in time. Enter work calendars for each resource, and MS Project will schedule tasks around vacation time. As actual work time changes start and end dates, all tasks in the plan assigned to the affected resources will roll forward and backward.

Disadvantages: MS Project constantly changes dates. The Project Manager must monitor the plan closely, watching for unwanted automatic adjustments.

Resource leveling only works if each resource is assigned one full-time task at a time. Resources that perform more than one task simultaneously are frustrating to schedule.

Advantages: Schedule problems are relatively easy to diagnose; follow chains of work through the schedule. Dependencies are easy to remember because they match the work assignments.

Even if the real-life project execution does not match the rigid dependencies in the plan, MS Project often adjusts the remaining work in a sensible, resource-leveled fashion. For example, a resource starts both task #1 and task #2 in the same week, even though the schedule has #2 dependent on #1, finish-to-start. The remaining work on task #2 automatically scheduled after task #1 is 100% complete.

A Project Manager can also add logical (a.k.a. “hard”) dependencies, and MS Project will enforce them. For instance, if resource B cannot start task #12 until resource A completes task #3, MS Project will force the start-date for task #12 to slip if the finish date for #3 slips. Resource-driven dependencies and required dependencies appear identical in the tool. To keep track, add a column called “Unique ID Predecessor” to the Gantt view. Track the unique ID for all hard-dependencies either in the task description (i.e. “(4389)” at the end) or in a text field for each task.

MS Project starts assignments when resources are available. If task #1 ends 4.25 hours into Monday’s schedule, task #2 will put exactly 3.75 hours in on Monday, to make an eight-hour day. It automatically keeps resources fully allocated.

The “Traditional” Way

The third method provides the highest level of control. It enforces dependencies and shows resource allocation clearly without making a lot of automatic schedule changes. Start with a basic WBS, with no dependencies. Add resources, work estimates, and duration for each task.

  • A very tall network diagram. At the left is a Start milestone linked to eleven tasks, stacked top to bottom to the right. Only one task, number three, has a dependency; number twelve must follow it. Number twelve is to the right of three. All the tasks except three link to a Finish milestone to the far right. A traditional network diagram shows only logical dependencies, helping a manager evaluate scheduling and resource assignment alternatives

Create a network diagram. Create two milestones: “project start” and “project finish.” Anything that can truly start at any time should be dependent upon “project start”. Anything that can happen anytime up until the last minute is a dependent task of “project end”. In between these two tasks, every task should be part of a chain that starts with “project start” and ends with “project finish”. Use milestones to draw together large number of dependencies. For instance, if five tasks must complete before four other tasks can begin, create a milestone with a descriptive name, like “assembly complete”, with the five tasks as predecessors and the four tasks as successors.

These dependencies should not be affected by resource assignments, so they should remain fairly static throughout the execution phase. By contrast, the dependencies in the second “dependency-driven” method change every time a resource is reassigned. This network diagram is a useful, lasting map to the project. It shows the unchanging relationships between tasks.

The Gantt view of the plan will show an optimistic end-date for the project. Tasks are scheduled without any regard for resource limits. Adding leveling delays will even out the workload.

Leveling delay lets a project manager precisely manage the start and end of every task without adding dependencies and without fixing the start date. Leveling delay is a hidden field that exists at two places: the task level and the resource-assignment level:

  • Task level is the easiest to apply, but the hardest to manage. Simply add the “Leveling Delay” column to the Gantt chart view, or use the “Leveling Gantt” view. Enter the number of hours or days delay, and the entire task shifts out in time. Unfortunately, the delay must be in ELAPSED days or hours. Elapsed days do not honor holidays and non-work time. A project manager must often adjust these delays manually as task start and end dates shift.
  • Resource-assignment leveling delay can be entered for each resource assigned to a task. It can be entered in work-hours or work-days. It provides flexibility to level out any imaginable work. If two people are assigned to a task, but only one is over allocated by 4 hrs, delay the over allocated resource by 4 hrs. The other resource’s start date is unaffected. To delay the entire task, though, every resource assigned to the task must be delayed. Make maintenance simpler; allocate one and only one resource per task.

Leveling delay is measured from the dependencies of the task. For instance, if task #4 and task #5 are both dependent upon task #3, ending on Monday, they will both begin on Tuesday with no delay. Putting a two-day delay on #5 will make task #4 start on Tuesday and #5 start on Thursday. If the end-date of #3 moves to Tuesday, they will both roll forward to Wednesday and Friday start-dates.

By combining units (% allocation) and leveling delays, a project manager can accurately represent complex work. People can work multiple tasks simultaneously, participate in multiple chains of dependent tasks, and still work all available work hours, and not one hour more.

This method helps the manager walk step-by-step through the PMBOK method of creating a schedule and a budget: first WBS, then network diagram, duration estimates, cost estimates, and so on. The other methods add that same information to the schedule for each task, as each task is added. Each entry immediately ripples through the schedule. The “traditional” method lets a manager enter each PMBOK deliverable one at a time. The full schedule appears only after the last step is complete. Both methods involve all the PMBOK processes, but the “traditional” method makes it easier to focus on each dimension of the project (scope, time, cost, and so on) one at a time.

Disadvantages: This method is labor-intensive. It is time consuming to create an organized network diagram for a large project. It is easier to create dependencies to force work to occur in a certain order, instead of calculating leveling delays and entering them for each task. The project manager must adjust delays every reporting period.

Advantages: Unmatched control over the schedule and dependencies. Creates a human-readable network diagram. Step-by-step process creates a schedule following PMBOK recommendations. Separates decisions about dependencies from decisions about resource assignments and resource leveling. Supports arbitrary execution of separate tasks by a single resource or by multiple resources.

Milestones and hard-dependencies control MS Project’s rescheduling of work. If work happens early or late, MS Project only adjusts dates when milestone dates change.

The Project Manager has full control. Maintenance of any schedule is time consuming; with this method schedule updates are more predictable and consistent.

Pick Your Tool, Pick Your Poison…

Maintaining a schedule is hard work. None of these methods is a silver bullet. By picking the right method, though, the Project Manager can focus time and energy. Each method uses some MS Project features and hides others. Each manager can pick the right approach for each situation.

Feel free to blend all the approaches above. Often times a single project has a different need for each phase. A single MS Project file can use all of these techniques. When you pick your tools, though, you also pick your poison. The next time you are frustrated while trying to update a schedule, remember that you have choices; perhaps you chose poorly last time, and perhaps it is time to rethink your approach.

51 Responses to “Real-Life MS Project: Dependencies and Leveling”

  1. Alex Brown says:

    It depends on how you are doing your resource leveling. If you use the method described in the article, and use dependencies to create a resource-leveled plan, then there is no way to tell the difference between a real dependency and one that you entered for a resource constraint. I suggest using a note or comment field to keep track of them, if you cannot easily figure it out from the context.

Leave a Reply