Exercises for Modeling Tough Scheduling Problems

Alex S. Brown, PMP IPMA-C

These scenarios were designed as exercises to lead a large-group workshop on scheduling. Work through these exercises in your favorite scheduling software. There is no right or wrong solution; their purpose is to explore possibilities. By experimenting with different techniques, a project manager learns the details of scheduling software better. When faced with a real schedule, the project manager can select the best technique for the situation and for the software in use.

There is also an article available with ideas for possible solutions and some theory about how expert schedulers tackle these types of problems.

Sample scenarios help to illustrate, teach, and discuss abstract scheduling concepts. These concrete examples can help managers learn and apply these principles. By experimenting on a small schedule, a manager can learn the pros and cons of different techniques.

In these examples, “duration” is the minimum possible duration for a task in days. “Work” is the number of work hours estimated to complete the task. Milestones have the abbreviation “(MS)” in their task name. Milestones have zero work and zero duration.

Basic Scenario

A manager has six tasks, each of which can be done simultaneously; there are no hard dependencies. The manager has three people available to perform the work. The task list appears as follows:

Task Duration (days) Work (hours) Resource Predecessor

To start, assume all three resources are available 40 hours per week, and a week is five workdays.

Resource Leveling

Most software will show dates that are too optimistic after entering the raw data above. The use of project resources (A, B, and C) must be leveled, so they are used no more than 40 hours per week. Scheduling options include:

Keep the dependency relationships as defined above

  • Manually “fix” start dates for each task to make the resources level over time
  • Allow all tasks to start on day 1, but change the allocation of each resource to create a level use of resources – in other words, adjust the time-per-day that each resource spends on each task until the end dates all match
  • Adjust the time-phased work assignments for each task until the resource usage for each person is level (procedure will vary with each software package)

Introduce “soft” dependencies

  • Keep the work for “A” as is, since the two five-day tasks add up to 40 hours already
  • Make “Construct #3″ a predecessor for “Construct #4″, so that “B” has a level set of work – 32 hours over 4 days
  • Review the work for “C” and find a way to reschedule it, possibilities include
  • Split “Construct #5″ into two tasks – one with 8 hours work for one day, and a second with 8 hours of work for one day; put a mandatory delay of 3 days between them to keep the overall duration of five days, and schedule “Construct #6″ between these two, new, one-day tasks
  • Spread the work for “Construct #6″ over four or five days, so it becomes a level set of work that can be done simultaneously with “Construct #5″

Enter this scenario into your scheduling software a few different ways:

  • Which method gets an accurate, level schedule the most quickly?
  • Which method lets the manager set the start and end dates most flexibly?
  • Which way do you typically use?
  • Have you discovered any new techniques that might work better than your usual approach?

Representing Hard and Soft Dependencies

In the scenario above, use dependencies to force the schedule to be resource-leveled. The task list becomes:

Task Duration (days) Work (hours) Resource Predecessor

In your scheduling software, consider the following questions:

  • The hard dependencies for the schedule are no longer documented in the schedule clearly. Where will you document them now?
  • According to your scheduling software, what is the critical path? Do you agree with the software?
  • Assume that “Construct #4″ becomes a four-day task with 32 hours of work. The critical path will then run through “Construct #3″ and “Construct #4″. Many people would say that these soft dependencies could be broken, so the critical path should not change. Do you agree?

Managing Quickly-Changing Work Assignments

In the exercises above, you created several versions of the same schedule, each using different techniques and features of your scheduling software. Apply the following changes to each schedule:

  • Resource “A” is only available for 20-hours per week, and you cannot change which tasks are assigned to “A”. Forecast the new end-date.
  • You now discover that you can substitute any resource for any other resource, but it will add an extra, eight hours to the work for any task that you switch. Optimize the schedule, with “A” at a 20-hour workweek.
  • Assume that “B” volunteers to work 60 hours per week to get this project done. Optimize the schedule, following the two rules above.

After applying the changes to several schedules, answer some questions:

  • Which schedule was easiest to change? Was it the easiest one to build initially or one of the others?
  • While applying these changes, did your scheduling software unexpectedly shift dates? When? Why?

Making Schedules Easy-To-Maintain During Project Execution

Week one of the project is now complete. Team status reports show:

Task Resource Status Actual Work Remaining Duration (d) Remaining Work (h)

Apply these actuals to different versions of the schedules, as created in the earlier exercises. Review the new end-dates and the resource utilization for each resource for the remaining work. Answer some questions:

  • Was this a new experience, applying actuals and creating an updated forecast? If so, what new techniques did you learn?
  • After applying actuals to different versions of the same schedule, how many different end-dates resulted? Which ones were the most accurate? Which ones were the easiest to change and to make realistic?
  • While applying changes, did your scheduling software unexpectedly shift some dates around? When? Why?
  • Resource “B” started “Construct #4″ before “Construct #3″. How did your scheduling software respond to that?
  • How does your software reschedule work that is started but not completed? Not started?


After running these exercises, review

  • Which techniques did you usually use before? What are their strengths and weaknesses?
  • Which of these tasks do you usually perform weekly? Monthly? Daily?
  • Which scheduling techniques make schedule entry easiest? Which make maintenance easiest? Which strike a balance?
  • Which techniques do you now plan to use in the future?
  • What did you learn about your scheduling software that you did not understand before?

Future Development

These examples illustrate a schedule with parallel opportunities. Develop a sample schedule with serial dependencies, and examine the behavior of scheduling software when:

  • Tasks are completed in the expected order
  • Tasks are completed out-of-order
  • Tasks with many dependencies end late
  • Tasks with many dependencies end early
  • Tasks use dependency relationships other than “finish-to-start”, including “start-to-start”, “finish-to-finish”, and “start-to-finish” (not all software supports all these relationships, and some software has flaws in their support for unusual relationships)