An IMS schedule health check should test whether the Integrated Master Schedule is complete, logically sound, current and suitable for forecasting. Before the assessment, the scheduler should finish the status cycle, verify the data date, preserve an audit copy and confirm the assessment criteria. The team should also resolve data errors that misrepresent the schedule without changing valid logic merely to improve a metric.
Preparation matters because an assessment tool can calculate percentages, but it cannot determine whether the schedule reflects the program’s real execution plan. A schedule may pass several automated checks while still omitting scope, using weak logic or producing an implausible critical path. Conversely, a valid program condition may trigger a threshold and require explanation rather than removal.
First, confirm what the assessment will evaluate
Do not assume every schedule review uses the same rules. The customer may apply the Defense Contract Management Agency (DCMA) 14-point metrics, the Government Accountability Office (GAO) scheduling best practices, agency-specific criteria or a tailored combination. The contract, Integrated Program Management Data Analysis Report (IPMDAR) requirements, data item description, statement of work and customer instructions determine what must be delivered.
The DoD Risk, Issue, and Opportunity Management Guide describes the DCMA metrics as a tool for assessing schedule quality, structural integrity and overall health. However, the familiar thresholds are diagnostic goals. They do not automatically become contractual acceptance criteria unless the contract or incorporated direction makes them applicable.
Likewise, the GAO Schedule Assessment Guide organizes reliable scheduling around four broad characteristics: comprehensive, well-constructed, credible and controlled. Its ten best practices extend beyond metric compliance. They address scope, logic, resources, duration realism, critical path validity, schedule risk analysis, status discipline and baseline control.
Before touching the file, document:
- The governing contract clauses and schedule data requirements.
- The assessment method, thresholds and calculation definitions.
- The required native file, exchange format, reports and supporting narratives.
- The reporting period and official schedule status date.
- Any approved tailoring, exclusions or program-specific conventions.
- Whether the assessment covers the full IMS or a defined schedule subset.
IMS schedule health check preparation checklist
1. Preserve the submitted schedule configuration
Create a controlled copy before making corrections. Record the native filename, software version, extraction date, status date and baseline version. Also retain the pre-correction file so reviewers can trace each change.
Run the assessment from a stable copy rather than a live schedule that users continue to edit. If the IMS uses external links, shared resource pools, macros or custom fields, document those dependencies. Otherwise, the reviewer may receive a file that calculates differently from the program’s working version.
2. Complete the normal status cycle
A health assessment should not compensate for an unfinished monthly update. Collect status from control account managers (CAMs), subcontractors and functional leads. Then enter actual starts, actual finishes, remaining durations and approved forecast changes according to the program’s scheduling procedure.
Verify that the IMS has one valid and clearly defined data date. The IMS status date separates reported performance from forecast work. Therefore, actual progress should generally fall on or before that date, while incomplete work should remain after it unless the scheduling method and tool produce an explainable exception.
In Microsoft Project, check the project status date and the options that control the placement of completed and incomplete work. Microsoft documents how its status-date functions move completed or incomplete portions of tasks. Apply those functions carefully because an automated move cannot replace valid task-level status.
3. Remove invalid dates and status contradictions
Search for actual starts or finishes after the status date. Also identify incomplete work scheduled in the historical period, completed tasks without actual finishes and future activities marked complete. Review each exception against source status rather than applying a blanket correction.
Next, inspect in-progress tasks. Confirm that the actual start is accurate, the remaining duration is realistic and the forecast finish reflects current conditions. Avoid using percent complete alone when it produces progress that does not match physical accomplishment or the approved earned value technique.
4. Confirm that the IMS contains the required scope
A clean logic network cannot compensate for missing work. Reconcile the IMS to the work breakdown structure (WBS), statement of work, control accounts, work and planning packages, major subcontracts, government-furnished items, technical reviews and contractual milestones.
Every lowest-level activity should have enough coding to identify its scope and ownership. At minimum, inspect WBS, organizational responsibility, control account, work package, activity type and responsible organization fields where applicable. For a broader discussion of schedule organization, see how to structure an IMS using the WBS.
The NASA Schedule Management framework treats the baseline IMS as the foundation for coordinating program work and supporting management decisions. It also separates schedule development, assessment, maintenance, control and communication. That distinction is useful: preparation should verify both the schedule model and the processes used to maintain it.
5. Review missing and open-ended logic
Check incomplete activities for missing predecessors, missing successors and broken paths to program completion. Legitimate exceptions may include the authorized project-start milestone or a final completion milestone. However, the schedule should identify and explain those exceptions consistently.
Do not add arbitrary links simply to reduce the missing-logic percentage. Each relationship should describe a real technical, contractual, resource or execution dependency. Review the detailed method in the DCMA logic check for missing predecessors and successors.
Also inspect summary-task links, external dependencies and relationships to inactive tasks. Some tools can display a relationship that does not support a stable critical path calculation after export or file conversion.
6. Examine relationship types, leads and lags
Finish-to-start logic usually provides the clearest network sequence, but it is not the only valid relationship type. Start-to-start and finish-to-finish relationships may represent legitimate overlapping work when the planner can explain the dependency and maintain measurable completion criteria.
Review every lead because negative lag can obscure the work that must occur during an overlap. Replace a lead with discrete activities when those activities can be planned, statused and managed. In addition, inspect positive lags for hidden work, procurement wait time, review periods or curing time that would be clearer as an activity.
Document justified exceptions rather than forcing every relationship into one convention. The objective is credible logic, not cosmetic uniformity.
7. Validate constraints, deadlines and calendars
List every constrained incomplete activity and identify why the constraint exists. Hard constraints can override logic and prevent the schedule from responding dynamically. Soft constraints may also distort float or delay a task if the planner entered dates directly instead of building the correct network.
Microsoft Project uses several constraint types with different effects on early and late dates. Review Microsoft’s definitions of Project constraints before interpreting the results. Then use the DCMA hard constraints check to investigate activities that may restrict critical path calculations.
Meanwhile, verify the project, task and resource calendars. Confirm working hours, holidays, shifts and exception periods. A mismatched calendar can create unexplained duration, float and forecast-date differences even when the logic appears correct.
8. Investigate duration and float outliers
Run high-duration, high-float and negative-float checks. However, treat each result as a prompt for analysis rather than an automatic error.
Long activities may conceal intermediate handoffs, progress points or technical risk. Break them into smaller activities when the work has measurable internal steps. Do not split continuous work into artificial fragments solely to fall below a threshold. The DCMA high-duration activity review explains how to evaluate those cases.
For high float, trace the path and examine missing integration logic, distant constraints, calendar differences and disconnected completion criteria. For negative float, identify the controlling required date and the chain producing the variance. Negative float should lead to forecast analysis and management action, not an arbitrary duration reduction.
9. Prove the critical and near-critical paths
Do not rely only on a critical flag or a total-float filter. Trace the driving path from the program completion milestone or another required endpoint back through the network. Confirm that the path follows technically credible work and reacts logically when a driving activity slips.
Perform a critical path test by adding a controlled delay to a critical or driving activity in a copy of the schedule. The completion milestone should move by the expected amount unless available float, calendars or parallel logic absorb part of the delay. Restore the file after the test and record the result.
Also review near-critical paths because a low-float secondary path may become critical during the next update. If the schedule contains several completion milestones, test the driving path to each major contractual or technical endpoint.
10. Reconcile baseline, forecast and EVMS data
Confirm that baseline dates and durations exist where required and align with the approved baseline. Investigate activities with missing baseline data, actual dates before baseline authorization, unexplained baseline changes or forecast dates inconsistent with the current plan.
If the IMS supports an Earned Value Management System (EVMS), reconcile its coding and status with the cost system. Schedule progress, work package dates and earned value claims should tell a consistent performance story. The current DFARS 252.234-7002 EVMS clause, when included in a contract, requires management procedures that generate timely, reliable and verifiable information for required performance and IMS reporting. The contract still controls the specific deliverables and tailoring.
11. Prepare an exception log
Create a short disposition for each significant finding. Include the activity identifier, metric, cause, schedule effect, responsible owner and planned corrective action. Classify the finding as an error, accepted exception, pending status correction or program risk.
An exception log prevents the team from making unsupported changes during the review. It also helps distinguish a known program condition from a defective schedule model. For example, a customer-directed test date may create negative float. Removing the date would hide the issue, while documenting the forecast gap gives management useful information.
12. Run the assessment again and inspect the output
After corrections, recalculate the schedule and rerun the same health-check configuration. Compare the results with the preserved starting file. Large metric changes should trace to documented corrections.
Finally, open every deliverable file that the customer will receive. Check that custom fields, calendars, baselines, logic, activity identifiers and status values survived the export. Confirm that no filter or grouping hides activities and that the file opens without missing-link warnings.
Fictional example: preparing the Falcon Ridge IMS
The fictional Falcon Ridge sensor-upgrade program maintains a 2,800-activity IMS. Two days before a customer review, the first assessment reports missing successor logic, future actual dates, high-duration integration tasks and negative float to a test-readiness milestone.
The scheduler does not immediately add links or shorten tasks. First, the team confirms that the native schedule uses the correct month-end status date. It then discovers that a subcontractor import placed six actual finishes one reporting period ahead. Correcting the import removes the invalid dates.
Next, the integrated product team reviews 18 open-ended activities. Twelve lack valid successors, while six are authorized terminal milestones for separate deliverables. The scheduler adds technically supported logic to the 12 activities and records the six valid exceptions.
The team then decomposes a 90-day integration activity into configuration, installation, checkout and defect-resolution tasks because those steps have distinct owners and measurable completion criteria. However, it retains a 60-day environmental exposure activity because the work is continuous and cannot be meaningfully divided.
Finally, the negative float remains. The driving-path review shows that delayed hardware delivery now threatens the contractual test-readiness date. That result is not a schedule defect. It is a valid forecast condition that the program manager needs to address.
Common preparation failures
- Gaming the thresholds: adding arbitrary logic, shortening durations or deleting constraints without understanding the execution plan.
- Running against an unfinished update: assessing the IMS before actuals, remaining durations and forecasts are complete.
- Ignoring scope: focusing on metric percentages while major subcontractor, government or integration work remains outside the network.
- Changing the approved baseline: correcting current-schedule quality by overwriting baseline dates without authorization.
- Using different calculation settings: allowing the customer and contractor to assess different activity populations or threshold definitions.
- Submitting only a scorecard: providing percentages without the activity-level findings and explanations needed for corrective action.
Final readiness test
The IMS is ready for a schedule health assessment when the status cycle is complete, the data date is correct, scope and coding reconcile, the logic network produces credible driving paths and the file configuration is controlled. The team should understand every material exception before delivery.
A good result is not simply a row of green metrics. It is an IMS that responds predictably to change, exposes schedule risk and supports decisions about remaining work. Use the automated checks to locate potential weaknesses, then apply planner judgment, technical input and contract-specific criteria to determine what requires correction.
Frequently asked questions
Should every DCMA metric pass before the IMS is delivered?
Not necessarily. The thresholds identify areas for investigation. A contract or customer direction may establish specific acceptance criteria, but the standard metric goals alone do not prove contractual compliance. Document valid exceptions and correct actual schedule defects.
Should the scheduler remove all constraints and lags?
No. Remove or replace constraints and lags that hide work or override valid logic without justification. Retain legitimate uses when they represent the execution plan, and document their purpose.
Can a schedule pass the health check and still be unreliable?
Yes. Automated metrics may not detect missing scope, unrealistic resource assumptions, weak status evidence or an implausible critical path. A complete review combines quantitative checks with traceability, path analysis and program-team validation.