In Primavera P6, it’s very important to track your project’s health throughout its lifecycle. As a project schedule develops, issues will inevitably arise. Identifying these issues early on is vital to the project’s success – and can help you save both time and money.

In the past, Primavera P6 offered the schedule Log File to assist with this. The Log File would identify issues such as Open Ends and Out of Sequence activities. However, it wouldn’t identify all potential issues – such as Negative Float or Late Activities. Even with the Log File, you would often need to also manually track the schedule.

With the release of Primavera P6 Professional 22, we now have a new tool to help track schedule health: Check Schedule Report. The Check Schedule Report will analyze the quality of your project against common schedule analysis metrics. Most of these metrics come from the DCMA 14-Point Assessment, which is generally seen as the standard for schedule health. Not only can this tool identify problem areas, but it can also help you with correcting them.

This article will cover how to use Primavera P6’s Check Schedule Report. Here, we will look at the tool’s default schedule metrics, and how to customize their thresholds. The following examples are from Primavera P6 Professional 23. However, this tool is available in any version of P6 from 22 on.

Running Check Schedule Report

To use Check Schedule Report, first open up a project. You can use this tool with multiple projects open, but it will only analyze one project at a time. Select Tools > Check Schedule.

If you have multiple projects open, select the desired project from the dropdown. Next, you can customize which metrics to assess the project with. You can turn metrics on or off using the checkboxes, or adjust their Target thresholds.

When you run this report, the tool will identify any activities that match the metric. These values will appear in either red or green. A green value indicates that the percentage of activities identified does not exceed the target threshold. On the other hand, a red value indicates that the percentage has exceeded the target threshold. For example, if there is more than 1% of activities in the schedule with negative lag, the Negative Lag field will display in red. Some metrics also allow you to customize individual values. Long Lags, Large Floats, and Large Durations allow you to enter in a duration value to not exceed.

If you decide to customize these parameters, they will revert back to default after you use the tool. To save your customized values, make sure to press the Save button to the right of the window. This will ensure that your custom values are always available whenever you use Check Schedule Report. However, these values only save for the open project. If you open another project, you will need to enter in these custom values once again.

If you save any parameter changes, you can get back to the default values by selecting the Default button.

With all your settings set, select Check Schedule to run the tool. The Check Schedule HTML report will automatically open. Here, you’ll see how your project is doing in regards to the selected metrics. Before we dive too far into this report, let’s take a look at the metrics it uses to analyze your project.

Check Schedule Report Metrics

Check Schedule Report will analyze your schedule against common analysis metrics. Most of these metrics match those found in the DCMA 14-Point Analysis. This is a formalized assessment used to track the quality of project schedules.

P6’s Schedule Report will analyze your project using the following metrics:

Logic

This metric will analyze the percentage of activities with no predecessor or successor. These activities are often referred to as Open Ends or Dangling Activities. This metric will not include any In Progress, Completed, Start Milestones, or WBS Summary Activities. As a best practice, every activity should have at least one predecessor and at least one successor. There’s only two exceptions to this: the first and the last activity in the schedule. The first activity is the only one that should not have a predecessor. In the same way, the last activity is the only one that should not have a successor. All other activities should have both predecessors and successors to drive the project’s logic.

By default, the target for this metric is <5.00% – meaning that less than 5% of activities should be missing logic. I recommend minimizing this percentage to <1.00%, especially for shorter projects.

Negative Lags

This metric will analyze the percentage of activity relationships that use negative lag. Negative lag, also known as leads, allow the successor activity to start before the predecessor finishes. Using negative lag can alter the logic and critical path of the schedule. Leads are generally seen as a bad scheduling practice, and are often prohibited by contracts. Ideally, you should have no negative lag within the project schedule. Completed activities are not included within this analysis.

By default, the target for this metric is <1.00%. I recommend setting this to <0% if negative lag is not allowed within your project schedules. 

Lags

This metric will analyze the percentage of activity relationships that use positive lag. Again, Completed activities are not included in this analysis. Lag is a waiting period between two activities within a relationship. For example, if you have two activities in a FS relationship with 3 days of lag, the successor would begin 3 days after the predecessor finishes. Unlike negative lag, positive lag is generally allowed. However, you should not overuse it – too much lag can obstruct and change the critical path. 

By default, the target for this metric is <5.00%. It is a scheduling best practice to have lag on no more than 5% of relationships, so I would recommend keeping this target as it is.

If you’re finding that you need to use lag too often, you can create an activity to represent the lag time instead. For example, if I had an activity of Pour Footings and an activity of Strip Footings, I may want to use lag to account for curing time. However, instead of using lag, I could add a new activity to represent the lag time. Between these two activities, I could add an activity called Footing Cure Time to represent the lag period.

Long Lags

This metric will analyze the percentage of activities with a positive lag value greater than a set threshold. By default, this threshold is set to 352 hours (approximately 44 working days). Again, Completed activities are not included here.

If you need to use positive lag, it’s generally ideal to keep it to shorter amounts of time, such as a day or two. If you have too long of a lag value, it may be confusing to schedule collaborators. They may be unsure about what is causing such a long break within the schedule’s logic.

As mentioned, this field is set to 352 hours by default – which is about 44 work days. I would recommend lowering this target to around 14 work days. If you need to include a longer lag period, it’s recommended to add an activity to represent the lag time instead. That way, everyone will know exactly what that waiting period is for.

Relationship Types

This metric will analyze the relationship types used with the project’s activities: FS, FF, SS, and SF. For each relationship type, the report will show the percentage of activity relationships using it. This only accounts for In Progress and Not Started activities – it doesn’t include Completed activities.

For the target percentage, you can specify the percentage of activities that should use the Finish to Start (FS) relationship type. Finish-to-Start means that when the predecessor activity finishes, the successor activity will start. This is the most common type of relationship and allows activities to perform in sequence. The majority of your activity relationships should be FS.

By default, this percentage will be set to >90.00%. This is generally considered the ideal percentage for FS relationships for baseline schedules. While working on your baseline, I recommend leaving this value as it is. Once the project actually begins, you may need to adjust relationship types to shorten the project’s duration. This is often needed if you run into delays, get off track, or incur negative float. At this time, you may want to decrease this percentage to be a little more lenient.

Hard Constraints

This metric identifies the percentage of activities that have a hard constraint assigned. Hard constraints include Mandatory Start and Mandatory Finish. These constraints will force an activity to start/finish on a specified date, regardless of the schedule’s logic. This metric does not include Completed, WBS Summary, or Level of Effort activities. It also doesn’t include any activities using a Start constraint that have already started.

Hard constraints overrule the logic of the project and can cause project issues, such as negative float. In general, it’s better to allow the logic of the project to drive activity dates – rather than constraints. It’s a good practice to only use hard constraints when absolutely necessary.

By default, this percentage is set to <1.00%. Many contracts and organizations forbid the use of hard constraints. If your contract forbids the use of hard constraints, I would recommend adjusting this percentage to <0.00%.

Soft Constraints

This metric identifies the percentage of activities that have a soft constraint assigned. Soft constraints are those that impose a date for the activity to start/finish, but they do not defy the schedule logic. Soft constraints include Start On or Before, Start On or After, Finish On or Before, Finish On or After, and As Late As Possible. Again, this metric does not include Completed, WBS Summary, or Level of Effort activities.

Unlike the hard constraints, these constraints leave the schedule logic intact. If the activity has enough float to start or finish on the constraint date, it will. However, if the activity can not logically move to the constrained date, it will gain negative float. This negative float will show how far behind the activity is from reaching the constrained date. Soft constraints are better to use than hard constraints as they keep the schedule logic intact. 

By default, this percentage is set to <5.00%. You should use all constraints sparingly, as they can add delays to activities. As a scheduling best practice, you should use soft constraints on less than 10% of project activities. I would recommend adjusting this value to <10% to match scheduling best practices.

Large Float

This metric identifies the percentage of activities with a total float value exceeding the set target duration. Total Float is the amount of time that you can delay an activity without delaying the project’s completion. Although float is generally a good thing, high float values indicate that the activity is missing relationships. This metric does not include Completed, WBS Summary, or Level of Effort activities.

By default, this metric considers 352 hours (or 44 working days) to be a high float value. As a scheduling best practice, most activities should have no more than 40 days of float. Therefore, I suggest adjusting this value down to 320 hours instead. The target percentage for this metric is set to < 5.00% – which is generally considered the scheduling standard. I would recommend keeping this value as it is. 

If you’re finding that many of your activities have high float values, you may want to check for missing logic.

Negative Float

This metric identifies the percentage of activities with a total float duration less than 0 – otherwise known as negative float. Negative Float indicates that the project is not likely to complete on time. This is often the result of using constraints. If you have a constrained activity that can’t meet the constraint date, it will gain negative float. This metric, like most other, will not include Completed, WBS Summary, or Level of Effort activities within the analysis

Negative float indicates a delay in the project’s completion, so it is important to track. If an activity has a negative float, you should try to remove it. You can do this with a schedule compression technique such as crashing or fast tracking

By default, this metric is set to <1.00%. Ideally, you would want no activities in the schedule to have negative float. I recommend adjusting this value to <0.00% to ensure that you’re always tracking for potential delays.

Large Durations

This metric identifies the percentage of activities with a remaining duration greater than the specified value. Completed, WBS Summary, and Level of Effort activities are not included in this analysis. 

Large durations are not always a cause for concern. For example, procurement activities generally have long durations. However, construction activities with longer durations are generally harder to manage and update. If you have a lot of activities with large durations, you might want to break them down into shorter tasks. This will help you as you update the project’s progress, and give more insight into cost breakdowns.

By default, the large duration value is set to 352 hours, or 44 working days. As a scheduling best practice, non-procurement activities should have no more than 40 days of duration. I recommend adjusting this value to 320 hours (or 40 working days) to match. The target percentage is set to <5.00% by default, which is generally considered ideal.

Invalid Progress Dates

This metric identifies the percentage of activities with invalid progress dates. Invalid progress shows differently, depending on the status of the activity. For Not Started activities, invalid dates occur when the start date is earlier than the data date. For In Progress activities, invalid dates include remaining early start dates earlier than the data date, or actual start dates later than the data date. Lastly, for Completed activities, invalid dates occur when the actual finish date is later than the data date. WBS Summary, Level of Effort, and Completed activities (without an invalid actual finish date) are not included in this analysis. 

Put simply, your planned dates should be ahead of the data date, and your actual dates should be behind it. This is a critical metric –activities with invalid project dates will negatively affect the accuracy of the project. Ideally, you would want to have no activities with invalid dates. By default, the target percentage for this field is set to <1.00%. I would recommend adjusting this to <0.00% to ensure there is no invalid progress.

Resource / Cost

This metric identifies the percentage of activities that do not have at least one resource, role, or expense assigned. Resources and Roles account for the people, equipment, and materials used on the project. Expenses are project-specific one-time costs – such as travel costs. Assigning resources or expenses to activities allows you to cost-load the project. Milestone, WBS Summary, and Level of Effort activities are not included in this metric. These types of activities are generally not cost-loaded.

Of all the values in this report, this metric is the most open-ended. Some projects do not have to be cost-loaded. If your contract does not require you to resource or cost load, you can ignore this metric.

By default, the target percentage for this metric is set to <1.00%. Again, if you are not required to cost load the project, you may want to deselect this for a better schedule health score.

Late Activities 

This metric identifies the percentage of activities that are late compared to the original baseline plan. If an activity’s current start/finish date is later than the baseline start/finish date, it is late. If you haven’t created a baseline, an activity is late if its remaining early finish date is later than its planned finish date. Milestone, WBS Summary, and Level of Effort activities are not included in the analysis.

Late activities indicate that the project is falling behind. If 5% or more of the project’s activities are late, you may want to create a corrective plan to get the project back on track. Ideally, you will want to have as few late activities as possible. By default, the target percentage for this field is set to <5.00%. I would recommend leaving this target as it is.

BEI – Baseline Execution Index

This metric compares the number of completed activities with the number of baseline activities that should have finished before the current data date. Similarly to the last metric, this one is analyzing whether your project is running on track compared to your baseline. Not Started, In Progress, Milestone, WBS Summary, and Level of Effort activities are not included in this analysis.

Your actual project schedule should follow the baseline plan. Again, if you find that many activities are running late, you may need to make a corrective plan for the schedule. Depending on the extent of the issue, you may need to submit a delay claim, or re-baseline the schedule.

For this metric, you can choose an acceptable ratio of activities compared to the baseline with a percentage. By default, this value is set to > .95 – meaning that over 95% of your activities should be on track. I would recommend keeping this target as it is, as most of your activities should follow their baseline dates.

Viewing the Report

With your metrics and targets selected, press Check Schedule to run the report. The Check Schedule report, much like the Schedule Log, will save to your computer. However, it will also open as an HTML file within your computer’s internet browser.

The report will give you a percentage for each of the different metrics. If the percentage is beyond the target threshold, it will display in red. These are the values that most likely need correction.

As you scroll down, you’ll see a list of all activities identified by the metric. For example, I can see that I have several open ends. Scrolling down to the Logic section of the report, I’ll see a list of all identified activities. For each activity, I can see whether it is missing a predecessor or a successor activity.

If the value is tracking a specific value, such as Large Float, the identified activity’s value will display as well. With this information, you can immediately identify potential issues within your project. Now, you can go back into the project and correct these errors.

As you fix these issues, you should continue to use the Check Schedule report to monitor the schedule. Although it’s rare to have a perfect project, it’s a good idea to check this report for these metrics going forward. I recommend using the Check Schedule report after every status update to ensure your project continues to run smoothly.

Summary

Primavera P6’s Check Schedule Report tool lets you monitor the health of your project at all stages. When used regularly, this report can help you identify problem areas and mitigate any potential issues. Check Schedule Report monitors your schedule against a variety of common schedule analysis metrics. Most of these metrics are things you will want to track your project for – such as negative float or late activities. However, you can adjust the metrics and targets to customize the report if needed. In general, it’s a good idea to analyze the health of your schedule as the project progresses. With Check Schedule Report, you can now do this with ease.

If you have any comments, questions or suggestions, please use the comment section on the bottom of this page. Don’t forget to subscribe to our blog to get more Primavera P6 tips & tricks directly in your inbox!

Lauren Hecker is the instructor for the Primavera P6 Professionals training courses. To see her next open enrollment course, please visit our calendar. To schedule an onsite or custom course, please contact us!