Integrated Master Schedule: Programme-Level View for PgMP®

An integrated master schedule is a networked, logic-driven schedule in which tasks and milestones are linked by dependencies. The US Department of Defense (DoD) describes it as "an integrated, logically driven, networked-based schedule that is vertically and horizontally traceable" (DoD IMP/IMS Preparation and Use Guide, May 2023, Change 1 October 2024). In that guide the schedule serves a single contract. At programme level the same idea is applied across projects.

The plan terms matter here. An integrated master plan (IMP) is a different document. The DoD guide describes it as an event-based plan, a hierarchy of events, accomplishments and criteria, and calls it "a summary-level document compared with the IMS". The IMP says what must be achieved. The IMS says when and in what order the work happens.

The programme IMS holds the information that decides whether the programme's dates hold, and nothing else. We recommend carrying milestones, cross-project links, shared resource constraints, gate dates and benefit dates. Task-level detail stays in the project schedules.

Pulling every task from every project into one network looks thorough, but it makes the schedule impossible to maintain. Each refresh then needs a full re-check of logic that the project managers already own.

The roll-up must hold in both directions. The DoD guide shows the principle: durations set at the lowest level "will roll up to show the overall duration" of the higher-level element, and a subcontractor's schedule "should contain no Tasks or activities that are not part of" the prime contractor's schedule. For a programme, we recommend the equivalent test: every milestone in the programme IMS must carry the same date as in its project schedule at each refresh. If the dates differ, one of the two schedules is wrong.

A cross-project dependency is a link where a milestone in one project must happen before work in another project can start or finish. Record each one as a single line with six fields: the sending milestone and its project, the receiving milestone and its project, the type of link and any lag (a deliberate wait), an owner on each side, the date last confirmed, and who approves a change.

Two points make these links useful.

• Link milestones, not tasks. A link from "data certified" in one project to "integration test starts" in another is stable. A link between two individual tasks breaks whenever either project re-plans.
• Name the approver before you need one. When a link moves, the project manager of the sending project cannot be the only person who decides, because the cost lands in another project. We recommend that changes touching a link go to the programme manager or the programme's change body (the group that approves changes).

Cross-project links are also where the Program Management Plan should state the refresh rhythm: how often the project schedules feed the programme IMS and on which cut-off day.

Benefit dates belong in the programme IMS because a programme exists to deliver benefits, and a benefit usually arrives some time after the last project delivers. A schedule that ends at delivery cannot tell you whether the benefit date is safe.

PMI's PgMP® Examination Content Outline (March 2024) builds this into the programme work. The charter is to include "high-level benefits and their realization, timing" (Domain II, Task 1). The programme roadmap is built using, among other inputs, the benefits realization plan, the plan that sets out which benefits arrive, when, and who owns them (Task 3). Benefits Alignment is its own domain, 11% of the exam (PMI PgMP® Examination Content Outline, March 2024).

Our Program Roadmap page shows how to build the sequence backwards from benefit dates. The programme IMS then turns that sequence into dated logic. We recommend building the roadmap first and the schedule second: if the schedule comes first, the benefit dates tend to be whatever the project dates produce.

A slip in one project moves the benefit date week for week until the chain's spare time is used up, then the target is missed. The numbers below are our model, with invented figures, so you can follow the arithmetic and replace them with your own.

Setup. A programme has three projects and one benefit, measured in weeks from programme start.

• Project 1 (data migration) runs weeks 0 to 20. Milestone M1, "data certified", falls at week 20.
• Project 2 (platform) builds from week 0 to 16. Its integration test starts at the later of build end and M1 plus a 2-week lag, and lasts 8 weeks.
• Project 3 (branch rollout) starts with an 8-week pilot straight after the test, then a 12-week rollout.
• The benefit starts 4 weeks after rollout ends. The target date is week 56.

Baseline. Test starts at the later of 16 and 20 + 2, which is week 22, and ends at 30. The pilot ends at 38 and the rollout at 50. The benefit starts at week 54. Float (spare time before a target is missed) is 56 − 54 = 2 weeks.

Slip M1. While M1 is week 14 or later, the benefit start equals M1 + 34 (2 + 8 + 8 + 12 + 4).

Assume Project 1's own commitment is week 24 (our assumption). At a 3-week slip it finishes at week 23 and reports on time. The programme view shows the benefit missing its target by a week. This is the case the programme IMS exists to catch.

The same logic shows where slips are harmless. Project 2's build ends at week 16, but the test cannot start before week 22, so the build can slip by 6 weeks with no effect on the benefit date. Cross-project logic is what tells the programme manager which slips matter and which do not.

Use the rule: the benefit start moves by the number of weeks the milestone slips, and the target is missed by the slip minus the float, if that is above zero.

A candidate can describe it if they pass the eight checks below, each of which is a test with a clear pass or fail. These eight checks are our recommendation for testing whether you can describe a programme integrated master schedule. They are not a PMI list. They support the outline's Task 9, which asks candidates to "establish the program management plan and schedule by integrating plans for constituent projects/components" so that variances can be forecast, monitored and identified, and Task 10, which covers levelling (adjusting the schedule so resources are not over-allocated) to gain synergies among constituent projects. Program Life Cycle Management, the domain these tasks sit in, is 44% of the exam (PMI PgMP® Examination Content Outline, March 2024).

The sequence of phases and gates that the schedule must respect is set out on our Program Management Life Cycle page.

Our PgMP Self-Paced Mentorship Program provides structured learning, application guidance and exam preparation. It covers the exam's Program Life Cycle Management domain (44% of the exam) through studio-recorded video modules, recorded Q&A sessions, application guidance, 1,000+ exam-preparation questions with detailed explanations and mind maps. As of November 2026 it is listed at US$549 per enrolment; pricing varies by programme and market. Our PgMP® Certification Training page shows what that fee buys.

A free discovery or eligibility consultation is available before you enrol; you can reach support to arrange it. Our programmes prepare you for PMI's examination; they do not award PMI certifications. When you are ready, enrol through the Augment Consultancy course store.