Project vs. Program Schedules: What’s the Difference?

Everyone in the project management profession knows what a project schedule is—a time-sequenced list of tasks, activities, and milestones the project team must accomplish within a specified period of performance and budget in order to realize the goals of the project. So it stands to reason that, because a program is essentially a group of related (“component”) projects, a program schedule ought to include all of the tasks in the component project schedules plus the “higher-level” tasks that are essential to managing the program. Sounds simple enough, right? Well, as with all things in the world of management, it’s more complicated than that.

 

Programs have unique characteristics that present significant challenges to program managers and schedulers. Program managers often say, “It’s the things I don’t control, but are essential to the success of my program, that keep me awake at night”. He or she must carefully coordinate and negotiate the efforts of the extended program team, including the component project teams, due to the significant interdependencies between a program and its component projects. These interdependencies will likely be significant schedule risk areas for the program.

 

For example, a program to design and build a prototype of a new fighter aircraft could have a prime contractor responsible for integration and final assembly and several major subcontractors and suppliers, each of which is responsible for a critical subsystem such as the wing structure, mission avionics, engines, or weapons. The prime contractor’s final assembly will be behind schedule if the engine contractor does not deliver the completed engines on schedule, but regardless of where actual responsibility lies for a schedule delay, the prime contractor’s program manager will be held accountable.

 

What should a program manager do to mitigate these schedule risks? Apply his or her best leadership and persuasion skills to promote collaboration across the extended team, ensure that the component project organizations fully understand their responsibilities to the program, and motivate them do their best to live up to those responsibilities. The motivational approach could include negotiating incentive and/or penalty clauses for early or late deliveries into the components contracts.

 

From my perspective as a program scheduler, the two most common factors that cause significant challenges in managing program schedules are:

 

  • Programs have decentralized management structures; and
  • Programs may have a very large number of component-level tasks.

 

Let’s address the challenges resulting from the decentralized management structure first. Often, the component projects are managed by separate organizations, each with a great deal of autonomy. Component projects may also have interdependencies with other projects and programs that the program manager does not control, and these related projects and programs may have begun long before the program itself. Finally, the component project organizations are typically governed by contractual commitments to technical specifications and delivery dates. Each component manages its own work and schedule and periodically reports the status of assigned tasks, milestones, and deliverables to the program manager, but the reality is that the program manager has little or no control over a component project’s work priorities or how its resources are managed. At any point in time, a program manager may have very good reason to believe that delivery date commitments made at the start of the program are no longer realistic due to lack of progress or other causes. Nevertheless, component project managers will vigorously defend those commitments because of the legal and financial implications of failing to meet their contractual commitments. If the program manager’s attempts to negotiate a recovery plan with a component project manager fail, his or her only recourse may be to escalate the issue to higher management or the program’s sponsor for resolution.

 

From a program scheduler’s perspective, when component project tasks appear in program schedules, their start and finish dates (and corresponding progress toward completion) must match the information provided by their respective organizations. This business rule requires program schedulers to “lock in” the start and finish dates of component project tasks. Yet, higher management usually wants to focus on the critical path(s) or longest path(s), which requires that individual task dates be allowed to “float”. These conflicting priorities often force program schedulers to maintain two versions of their schedules. I work in Microsoft Project, and over the years I’ve developed some macros in Visual Basic for Applications (VBA) to help me deal with the challenge of managing “fixed vs. floating” dates. Even with this tool, it’s a difficult challenge to overcome.

 

Now let’s address the “very large number of tasks” problem. I once had a client who was managing a very large program—20 distinct, separately managed component schedules, averaging about 5,000 tasks each. At first, my client insisted I include every one of those 100,000 or so tasks in the program schedule. I had to use my best persuasion skills to convince the client how difficult (read “impossible”) it would be to manage that many tasks in a single file in Microsoft Project, or any other project management tool.

 

I recommend you not include every task from every component schedule in the program-level schedule, even for relatively small programs. I believe the principle of “you can’t see the forest through the trees” applies, so having more detail than necessary in a program schedule may obscure the “big picture”. Therefore, the program schedule should be a summary or intermediate-level schedule, emphasizing the key interfaces and interdependencies and containing sufficient detail to be traceable to the relevant section(s) of the component schedules. You can drill down through the component schedules when a more detailed analysis is required.

 

If you’re a Microsoft Project junkie like me, you’re probably thinking at this point, “Can’t you use cross-project (external) task links and inserted subprojects to model the relationships between component project schedules?” These methods work well in theory, but in my experience, external task links and inserted subprojects are difficult to maintain and integrate. They do not support critical path or longest path analysis, and they can lead to corrupted data and application failures. I prefer including component schedule tasks and deliverables as separate sections within the program schedule’s Microsoft Project file.

 

What are your thoughts on how to “herd the sheep” for a large program and coordinate the multiple projects that make up a program’s schedule?

 

Do Good. Have Fun. Add Value.

 

 

 

 

Microsoft Project and Visual Basic for Applications are trademarks of Microsoft Corporation

Leave a Reply

Your email address will not be published. Required fields are marked *