An effective IMS schedule review confirms more than whether the file opens and passes a metric screen. Before customer delivery, the scheduler should verify contractual compliance, status integrity, network logic, critical and near-critical paths, baseline traceability, earned value integration and the contents of the delivery package.
Use the checklist below as a structured pre-delivery review. However, start with the contract. A scheduling practice becomes a customer requirement only when the contract, Contract Data Requirements List (CDRL), Data Item Description (DID), statement of work or other incorporated direction requires it.
Start the IMS Schedule Review With the Contract
Do not begin by running a generic schedule-health report. First, determine what the customer expects to receive. The required file type, reporting period, coding, narrative content and submission date can vary by agency, contract and negotiated tailoring.
For a Department of Defense contract using the Integrated Program Management Data and Analysis Report (IPMDAR), review the applicable CDRL and the incorporated version of the DID. The DoD IPMDAR Implementation and Tailoring Guide explains that the IPMDAR can include the native schedule, Schedule Performance Dataset and performance narrative. Still, the guide does not replace the specific requirements incorporated into the contract.
Likewise, the requirements in DFARS 252.234-7002 apply only when the clause is included in the contract. The clause addresses timely, reliable and verifiable earned value management information, among other EVMS obligations. It does not create a universal schedule-delivery checklist for every federal contract.
Confirm these delivery requirements
- CDRL number, DID revision and applicable tailoring instructions
- Reporting period and required submission date
- Required native scheduling-tool format and any supplemental data format
- Schedule level, work breakdown structure and required coding fields
- Required calendars, resources, rates or other supporting data
- Required baseline, forecast and variance information
- Schedule narrative or performance narrative content
- File-naming, security, marking and transmission instructions
- Customer-approved exclusions or reporting thresholds
Create a compliance matrix if the delivery has several requirements. That simple step prevents a technically sound schedule from becoming a rejected data item because the team used the wrong reporting date, omitted a required field or submitted an unauthorized format.
Pre-Delivery IMS Schedule Review Checklist
The following sequence moves from basic configuration to management analysis. It also reduces rework because later checks depend on the status, calendars and network being correct.
1. Protect the source file and identify the review version
Save a controlled review copy before making corrections. Record the file name, revision, extraction date, reporting period and software version. Then recalculate the schedule using the program’s approved settings.
Also confirm that the reviewed file matches the file intended for delivery. Teams sometimes analyze one version and transmit another after a late change.
2. Verify the status date and reporting calendar
Confirm that the schedule uses the correct status date, also called the data date in some tools and environments. The status date separates recorded progress from forecast work and supports consistent performance analysis.
Next, compare it with the accounting calendar, reporting cutoff and required delivery period. Review how the IMS status date controls schedule analysis if the program has inconsistent cutoff practices.
Check the time component as well as the displayed date. A date stored at the start of a workday can produce different results from one stored at the end of the day.
3. Confirm scope, WBS and coding completeness
Review the schedule against the statement of work, contract work breakdown structure, product structure, control account plan and major deliverables. The schedule should contain enough detail to model the authorized work and support meaningful status and forecast analysis.
Then test required codes for blank, invalid or inconsistent values. Typical fields include work breakdown structure (WBS), organizational responsibility, control account, work package, contract line item, integrated product team and subcontractor identifiers.
The coding structure should support traceability without changing the underlying logic. See how to structure an IMS using the WBS for a broader discussion of schedule organization.
4. Review status integrity task by task
Filter the schedule for incomplete work before the status date and unstarted work with planned starts in the past. Also identify actual starts or finishes after the status date, missing actual dates and completed activities with remaining duration or work.
For in-progress activities, confirm that the remaining duration represents the current forecast. Do not allow the scheduling tool to preserve an obsolete finish merely because the team updated percent complete.
In addition, investigate out-of-sequence progress. Determine whether the work truly occurred outside the planned sequence or whether the predecessor status, relationship or actual date is wrong. The scheduler should document legitimate exceptions rather than automatically changing logic to make the warning disappear.
A consistent status process is covered in how to status an Integrated Master Schedule.
5. Test network logic and external interfaces
Identify detailed activities without predecessors or successors, excluding justified start and finish points. Then review dangling starts, dangling finishes, redundant relationships, excessive lags and unusual relationship types.
Logic should model the work, not force a preferred date. Therefore, inspect hard constraints and other date controls that can override the network. Microsoft documents how constraint types affect calculated dates in its definition of Microsoft Project constraints.
Pay special attention to external dependencies. Government-furnished equipment, customer approvals, subcontractor deliveries, test facilities and predecessor contracts can drive program completion even when they sit outside the contractor’s direct control. Represent each interface clearly and identify its responsible owner.
6. Check durations, milestones and calendars
Review long-duration activities against the contract’s criteria and the program’s documented scheduling practices. A long duration is not automatically wrong. However, it may hide measurable handoffs, risk or performance that the team should plan separately.
Confirm that milestones have zero duration and represent specific events. Avoid using a milestone as a substitute for unplanned work. In addition, inspect calendars for unexpected holidays, incorrect workweeks, excessive working time or assignments to the wrong calendar.
If the schedule uses resources, confirm that assignments and availability support the planned durations. The GAO Schedule Assessment Guide treats durations, resources, sequencing and traceability as connected elements of a reliable schedule.
7. Validate the critical path
Do not accept the scheduling tool’s critical flag without analysis. Trace the driving sequence to each major contractual or program milestone. The path should form a continuous and technically credible chain of work.
Confirm that remaining duration, calendars, constraints, lags and external dependencies explain the forecast finish. Then compare the path with the prior reporting period. A changed critical path may be valid, but the team should understand why it changed.
Use the process in performing critical path analysis in an IMS to distinguish the calculated path from the path management should actually monitor.
8. Review near-critical paths and total float
A customer delivery should not imply that only one path matters. Identify paths with limited schedule flexibility and determine which milestones they threaten. The applicable near-critical threshold should come from the contract, program procedure or a documented internal convention.
Also examine negative float, unusually high float and abrupt float changes. Negative float signals a conflict between the network forecast and an imposed date. High float can indicate valid flexibility, but it can also expose missing logic, distant constraints or disconnected interfaces.
For practical monitoring techniques, see near-critical path schedule monitoring.
9. Compare the current schedule with the baseline
Verify that the approved baseline remains intact unless the program processed an authorized change. Review baseline start and finish dates, baseline duration, current forecast dates and milestone variance.
Next, trace major changes to approved change-control records. Look for unexplained baseline edits, deleted baseline tasks, added scope without budget alignment and current activities that no longer map to the baseline structure.
Do not reset baseline dates merely to reduce variance before delivery. Variance shows where execution differs from the approved plan. Removing it without authorization weakens both schedule control and earned value analysis.
10. Reconcile the IMS with EVMS and other reports
If the program uses an Earned Value Management System (EVMS), confirm alignment between the IMS, control accounts, work packages and time-phased performance measurement baseline. Schedule status should support the earned value claimed through the same reporting cutoff.
Investigate cases where the schedule shows no physical progress but the cost system reports earned value. Also review completed schedule work with no corresponding earned value, mismatched control account codes, inconsistent forecast dates and unexplained differences between the schedule and estimate to complete.
The goal is not to make two systems display identical fields. Instead, confirm that they describe the same scope, status and forecast.
11. Confirm risk, opportunity and mitigation visibility
Review open risks and opportunities with the program risk manager. The schedule should include authorized mitigation or handling work when that work consumes time, creates dependencies or affects forecast milestones.
However, do not insert arbitrary padding into activity durations. Schedule contingency, management reserve and risk-response activities have different purposes. Apply them according to the program’s approved process.
NASA describes schedule assessment, maintenance, control, documentation and communication as connected schedule-management functions in its Schedule Management Overview. That connection matters because an analytically sound schedule still requires documented assumptions and clear communication.
12. Review the complete delivery package
Finally, compare the native schedule with every exported report and dataset. Check activity counts, status date, project finish, key milestones and critical path results. An export failure or stale report can create differences even when the native file is correct.
The narrative should explain significant movement, current driving paths, major risks, corrective actions, baseline changes and material differences from the previous submission. Keep the explanation concise, but make it specific enough for the customer to reproduce the analysis.
Fictional Example: A Constraint Hides the Real Driving Path
The fictional Sentinel Bay Radar Upgrade program plans to deliver its qualification unit on September 18. During the pre-delivery review, the scheduler finds that the delivery milestone carries a Must Finish On constraint dated September 18.
The schedule shows zero float to the constrained milestone. However, the actual network forecast from environmental qualification finishes on September 29. A separate government-furnished test adapter milestone also lacks a predecessor, so its effect does not reach the qualification path.
The team removes the unjustified hard constraint from the working copy, connects the adapter delivery to test setup and recalculates the network. The valid forecast becomes October 6. The scheduler then documents the 18-day variance, identifies the test adapter as a contributing interface and supports the program manager’s recovery discussion.
Passing a metric threshold would not have found the full management issue. The useful review combined constraint analysis, logic validation, interface ownership and critical path interpretation.
Common IMS Review Failure Modes
- Treating metrics as acceptance criteria: A health-check score can prioritize investigation, but it cannot prove that the schedule is complete, executable or contract compliant.
- Correcting symptoms without finding causes: Deleting constraints or adding logic only to improve a report can make the network less accurate.
- Reviewing only the critical path: Near-critical paths, external interfaces and high-risk work can become driving before the next update.
- Ignoring the narrative: The customer needs management interpretation, not just a schedule file.
- Using an inconsistent status cutoff: Misaligned schedule, cost and subcontractor dates create unreliable variance analysis.
- Changing the baseline before delivery: Unauthorized baseline changes conceal performance rather than explain it.
- Submitting an untested export: Always reopen or validate delivered files and compare them with the reviewed source.
Recommended Final Signoff
Use a documented signoff that identifies the reviewer, review date, file revision, unresolved findings and disposition authority. At minimum, obtain confirmation from the lead scheduler and program-controls manager. Add the program manager, control account managers or contracts representative when the findings affect contractual dates, baseline control or customer commitments.
Open findings do not always prevent delivery. However, the team should understand their effect, document the disposition and avoid representing an unresolved issue as compliant or corrected.
IMS Schedule Review FAQ
Is a schedule-health report enough for customer delivery?
No. It can identify suspect conditions, but the review must also address contractual requirements, scope, status, logic, critical paths, baseline control, EVMS alignment and delivery-package consistency.
Who should approve the IMS before submission?
The contract and program procedures should define formal approval. As a practical minimum, the lead scheduler and program-controls manager should review it. Material forecast or commitment changes may also require program management and contracts involvement.
Should every schedule warning be corrected?
No. Some conditions have valid technical or contractual reasons. Investigate each material exception, correct genuine defects and document justified exceptions. Do not change accurate planning merely to improve a metric score.
When should the review begin?
Begin detailed checks soon after the status cycle closes. Do not wait until the transmission deadline. Early review gives control account managers and technical leads time to correct source data and validate the forecast.
A disciplined IMS schedule review should leave the program with more than a deliverable. It should produce a schedule that management can use to explain current status, defend forecast dates and act on the work that truly drives customer commitments.