A practical MS Project schedule health review should test whether the schedule calculates valid dates, reflects the current status and provides a credible forecast. At a minimum, review task modes, logic, constraints, durations, calendars, float, progress, the critical path and baseline variance.
The 15 checks below apply to Microsoft Project desktop schedules, including many integrated master schedules (IMSs), proposal schedules and program execution plans. They complement the broader practices described in the GAO Schedule Assessment Guide and can support the methods discussed in Microsoft Project for Integrated Master Scheduling.
However, this checklist is not a universal contractual scorecard. Contracts, data item descriptions, agency procedures and program scheduling plans may impose different or additional criteria. Therefore, apply contract-specific thresholds and tailoring before assigning a formal pass or fail.
Set Up an MS Project Schedule Health View
Start with a working copy of the schedule. Then add the fields needed to see calculation problems without opening every Task Information dialog box.
A useful review table includes Task Mode, Duration, Estimated, Start, Finish, Actual Start, Actual Finish, Remaining Duration, Predecessors, Successors, Constraint Type, Constraint Date, Deadline, Total Slack, Free Slack, Calendar, Baseline Start, Baseline Finish, Finish Variance and Overallocated. Also include ID and Unique ID when investigating logic references or comparing versions.
Use highlighting and filters rather than reviewing thousands of rows manually. The procedures in How to Build Custom Filters in Microsoft Project can help you create reusable tests for each reporting cycle.
15 MS Project Schedule Health Checks
1. Confirm the project settings and status date
Before testing individual tasks, verify the settings that control the entire calculation. Review the project start date, scheduling direction, default task mode, hours per day, hours per week and critical-task slack setting.
Next, confirm the status date. It should match the approved reporting cutoff rather than the date when the scheduler happens to open the file. Microsoft explains how to set and display this date in its guidance on setting the status date for project reporting.
A wrong status date can make valid progress appear late or place incomplete work in the historical period. As a result, every downstream status test becomes unreliable.
2. Find manually scheduled tasks
Filter Task Mode for manually scheduled detail tasks. Microsoft Project does not automatically move these tasks in response to normal network calculations. Microsoft describes this behavior in How Project Schedules Tasks: Behind the Scenes.
Manual scheduling can help during early planning when dates or durations remain uncertain. However, it usually weakens a controlled execution schedule because the task may not respond to predecessor movement, calendar changes or other scheduling factors.
Convert mature work to automatically scheduled tasks after confirming its logic and duration. Do not perform a mass conversion without reviewing the resulting dates.
3. Identify missing predecessors and successors
Every normal detail task should connect to the network through appropriate predecessor and successor logic. Exceptions may include the authorized start, final completion milestone, approved external interfaces and certain level-of-effort activities.
Create separate filters for detail tasks with blank Predecessors and blank Successors. Exclude summary tasks and review legitimate exceptions individually.
Missing logic often creates unrealistic float and allows work to move independently of the activities that should drive it. Therefore, a low count alone does not prove health. Each open end needs an explanation.
4. Review relationship types
Finish-to-start relationships provide the clearest sequence when one task must finish before another begins. Start-to-start and finish-to-finish relationships can also model valid work, but they should describe the actual dependency rather than force a preferred date.
Review all non-finish-to-start relationships. Confirm that each link has a defensible technical basis and that paired start-to-start and finish-to-finish links do not create unintended behavior.
Start-to-finish relationships are rare in most IMS networks. Do not ban them automatically, but examine each occurrence closely.
5. Inspect leads and lags
A lead is a negative lag that allows the successor to overlap its predecessor. Leads can hide the point at which enough predecessor work exists to support that overlap. Therefore, replace them with explicit activities or clearer logic when practical.
Positive lags can represent legitimate elapsed time. However, a lag cannot receive resources, progress or narrative status. If the period represents review, curing, transportation, approval or another monitorable event, model it as a task.
Use program-defined criteria for acceptable lags. No single numeric threshold applies to every contract or schedule.
6. Find unintended constraints
Filter Constraint Type for anything other than As Soon As Possible in a forward-scheduled project. Then determine whether the constraint represents an approved external condition or an attempt to hold a task on a desired date.
Must Start On and Must Finish On constraints can override normal schedule movement. Other constraint types can also distort float or prevent logic from producing the expected result. Microsoft defines the calculation behavior of each type in its Microsoft Project constraint reference.
Prefer network logic when work depends on another activity. Where management needs a target date without fixing the calculated date, consider a deadline. For more detail, see hard constraints versus soft constraints.
7. Challenge long and estimated durations
Filter the Estimated field for Yes and look for Duration values marked with a question mark. These flags often remain after the planning team has accepted the duration.
Next, review activities above the program’s long-duration threshold. Long tasks are difficult to measure, forecast and assign clear completion criteria. Break them into discrete, logically linked activities when the work contains identifiable handoffs or intermediate products.
Do not split a task only to satisfy an arbitrary limit. The resulting activities still need meaningful scope, ownership and completion evidence.
8. Validate milestones, summaries and task records
Confirm that true milestones have zero duration. They should represent an event, decision, delivery or interface rather than a period of work.
Also review links, resources and progress entered on summary tasks. Summary dates should normally roll up from their subtasks. Direct logic on summary tasks can create broad dependencies that become difficult to trace after activities move or the work breakdown structure changes.
Finally, filter for blank task names, placeholder text, inactive tasks and unexplained duplicate names. Duplicate names may be valid, but they make status discussions and logic reviews ambiguous unless the surrounding context distinguishes them.
9. Verify calendars and working time
Review the project calendar, task calendars, resource calendars, holidays and shift exceptions. A task on an unintended 24-hour calendar can finish much earlier than the same task on a standard workweek.
Check whether special calendars have a documented purpose. Then inspect tasks that ignore resource calendars or use unique task calendars. Microsoft Project combines project, task and resource calendar information when it calculates dates.
Also verify the organization’s duration-unit settings. For example, changing hours per day affects how Project displays entered duration units, although it does not by itself rewrite every underlying working-time period.
10. Trace the critical path to key milestones
Displaying red critical bars is only the beginning. Trace the driving path from the current status point through the remaining work to the contractual or management completion milestone.
The path should form a continuous and technically credible sequence. Investigate constraints, lags, missing links and unusual calendars that interrupt or redirect it. Also examine near-critical paths because a small amount of delay can make one of them the new critical path.
The process in How to Trace a Critical Path in Microsoft Project provides a more detailed review method.
11. Investigate negative and excessive float
Negative total slack indicates that the calculated network cannot meet a constrained date under the current plan. Identify the constraint or deadline driving the result, quantify the required recovery and confirm that the responsible manager understands the exposure.
Very high positive float may indicate missing logic, an open network end or a distant constraint. However, high float can also be valid. Review the path before changing it.
Use thresholds defined by the contract, customer, program or scheduling procedure. A convention used by one organization does not automatically become a requirement for another.
12. Check incomplete work before the status date
Filter incomplete tasks whose Start is earlier than the status date. Review whether the remaining work still sits in the past or whether the scheduler moved it to a valid forecast date.
Do not automatically mark work complete to clear the exception. Obtain actual progress and a forecast from the responsible control account manager (CAM), technical lead or work package owner.
Meanwhile, look for unstarted tasks scheduled entirely before the status date. These tasks often indicate missed status, missing logic or an unrealistic recovery assumption. A consistent process for statusing an integrated master schedule helps prevent these errors.
13. Review future actuals and out-of-sequence progress
Actual Start and Actual Finish dates should not fall after the approved status date unless the program uses a specifically authorized convention. Future actuals mix reported performance with forecast information.
Next, identify work that started or finished before its driving predecessor allowed it. Out-of-sequence progress may reflect valid execution, incorrect actual dates or obsolete logic.
Do not delete the relationship merely because field execution occurred differently. First determine what happened. Then revise future logic if the execution plan changed and document the reason according to program procedures.
14. Compare the forecast with the baseline
Confirm that the applicable baseline fields contain approved reference dates. Then review Start Variance, Finish Variance and changes to key milestone forecasts.
Microsoft describes a baseline as a reference snapshot used to compare the current plan with earlier planned dates, work and costs. Its instructions for creating or updating a baseline in Project desktop explain the available baseline sets.
On an Earned Value Management System (EVMS) program, do not overwrite baseline data merely to remove variance. Follow the approved change-control process, system description and contract requirements. For the software procedure, see How to Create a Baseline in Microsoft Project.
15. Test resource feasibility when resources drive the plan
If the schedule uses resource assignments to demonstrate execution feasibility, filter Overallocated for Yes and review the Resource Usage view. Focus first on critical and near-critical work.
Do not level the entire file automatically without understanding the settings. Leveling can split or delay tasks and may change the critical path. Instead, confirm availability, assignment units, work estimates and priorities before accepting the result.
Some IMSs do not use Microsoft Project resource loading as the authoritative staffing model. In that case, document how the program verifies resource feasibility elsewhere rather than presenting an unresourced schedule as proof that the plan is achievable.
Fictional Example: A Health Check That Changes the Forecast
The fictional Falcon Sensor Integration program reports progress through June 26. Its Microsoft Project file shows the qualification test completing on September 18, which supports the planned delivery milestone.
During the health review, the scheduler finds four problems. The test procedure has a Must Finish On constraint. A 20-day lag hides the customer review period. Two predecessor tasks are manually scheduled, and one incomplete design task retains remaining work before the status date.
After the team replaces the lag with a review activity, converts the mature tasks to automatic scheduling and updates the remaining design forecast, the qualification test moves 13 working days later. The original September date was not a reliable forecast. It was the product of a constrained and partially static network.
The revised schedule looks worse, but it is healthier. It now identifies the real driving path and gives management time to evaluate recovery options.
How to Use the Checklist During Each Update Cycle
- Preserve the submitted version. Run the checks on a controlled working copy.
- Set the approved status date. Confirm project options before evaluating task-level exceptions.
- Run structural checks first. Review task modes, missing logic, relationships, lags, constraints and calendars.
- Run status checks next. Examine incomplete past work, future actuals and out-of-sequence progress.
- Validate the forecast. Trace critical and near-critical paths, then investigate unusual float.
- Compare against the baseline. Explain milestone variance and confirm that approved changes remain traceable.
- Record dispositions. Mark each exception as corrected, accepted with rationale or assigned for follow-up.
A healthy schedule is not a file with zero exceptions. Complex programs will have approved constraints, long activities, special calendars and unusual relationships. The goal is to ensure that each exception has a valid purpose and that Microsoft Project calculates a credible, explainable forecast.