This Guest paper, originally published at the 2012 PMI Global Congress Proceedings in Vancouver, Canada, was submitted for publication in February 2021
It is copyright to Eric Uyttewaal, 2021.
Published here May 2021

Introduction | When Can You Call a Program "In Control?" 
Why Break a Program Down into Subprojects? | Work Breakdown Orientations: Good and Bad
Consequences of Breaking a Program into Subprojects | Hunting for the Critical Path in an IMS
Dealing with Sharing Resources across Programs | Simulating the Critical Path
In Summary: Our Recommendations and References

Why Break a Program Down into Subprojects?

From past experience with other companies, ProjectPro has come across several program schedulers that desperately try to contain all tasks in one, large schedule. One person we met was even looking after a program schedule with 33,000 tasks. These overworked people often argued that they did not have enough people proficient enough to handle schedules of 1,000 tasks. In other cases, people argued that the software does not deal well with cross-project dependencies that come with multiple subprojects. They seemed convinced that keeping all tasks in one schedule was the only way it would work.

Figure 1: A snapshot of inter dependences on a schedule representing several concurrent projects
Figure 1: A snapshot of inter dependences on a schedule representing several concurrent projects

Figure 1 shows how a large number of dependencies across several projects entered in the same program can almost drown the individual project schedules.

Here are more reasons why it makes sense to break up a program schedule into multiple subproject schedules:

  1. Delegate to a scheduler who is closer to the work. You can delegate the responsibility for the schedule to people who are "closer to the fire." In theory, people who are closer to the work being done should be able to report on it better. In practice though, you have to make sure that these people are well trained in the scheduling software and follow scheduling guidelines.
     
  2. Multiple people need to update the program schedule. MS Project is a single-user application and, if it is determined that more than one person owns (sections in the) schedule, you are better off breaking it down. Otherwise, somebody will only have access to the schedule on Sunday.
     
  3. People are in different countries, in different time zones, and speaking different languages. Even though the time zones make it easier to schedule access to one file, the different countries require local calendars (local work weeks, national holidays), language and schedule communications. All these make it more practical to divide the schedule into multiple sub schedules. The SanDisk program was partly performed in Israel and California. Israel has a workweek running from Sunday through Thursday, whereas California's work week is Monday through Friday. The scheduled holidays were a major difference.
     
  4. You have more than 2,000 tasks in the program schedule. A schedule with 2,000 tasks is a full-time job in our mind. If you have more tasks, you have to break the program schedule up into more than one subproject schedule.

SanDisk already had the program broken down into eight sub schedules.

When Can You Call a Program   When Can You Call a Program "In Control?"

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page