-

Oracle Primavera Cloud Basics Training | Thursday, October 8th, 2026
$699.00 -



Oracle Primavera Cloud Advanced Training | Thursday, October 22nd, 2026
$699.00 -



Oracle Primavera Cloud Basics Training | Thursday, November 5th, 2026
$699.00 -



Oracle Primavera Cloud Basics Training | Thursday, December 3rd, 2026
$699.00
Accessing the Schedule Health Score


With a project open, hover your cursor over the Schedule app and select Activities.




Underneath, there is a list of the metrics, or checks, that the project is a run against. Each metric has an individual check score, indicating how well the activities are meeting the defined threshold. If the metric is listed in red, it means that the project did not meet the target threshold.
The number next to the check will state the number of activities that did not meet the defined threshold. You should analyze all red checks to determine ifthe project needs adjustments.
Each check will also feature a percentage. This will show the percentage of activities in the project were identified by the check.




Schedule Health Score Metrics
Open Ends
No Predecessors
This check is related to Open Ends, but only shows activities that do not have a predecessor activity. Predecessor activities are activities that are performed before the selected one. As a best practice, the only the first activity in the schedule should have no predecessors. For the rest of the activities, you will want to assign a predecessor to create a tight logical path.
No Successors
Similarly, this metric identies activities without a successor activity. Successor activities are activities that will be performed after the selected one. Like predecessors, every activity should have atleast one successor activity. The only activity that should not have a predecessor is the last activity within the project.
Dangling Start
This check will identify all activities that have successors, but do not have predecessors. The activity could have successor relationships such as SS or SF, but the start of the activity is not led by any predecessor. Dangling activities will not be driven by the logic of the project. Again, it is ideal that all activities to have at least one predecessor and successor relationship. You should only have one activity with a dangling start – the first activity within the schedule.
Dangling Finish
This metric will identify activities that have predecessors, but do not successors. The finish end of the activity is dangling and does not push the schedule logic forward. These activities could have SF or FF predecessors, but they do not push logic forward with their completion. Like Dangling Starts, it’s ideal for all activities to have at least one predecessor and successor relationship. You should only have one activity with a dangling finish – the last activity within the schedule.
Predecessor Negative Lag
This check will identify all activities with negative lag (also known as leads). Negative lag is used to overlap two activities within the project schedule – allowing the successor to start before the predecesssor finishes. Using negative lag will alter the critical path and logic of the schedule. In general, negative lag should be used as little as possible due to the effects that it can have on the schedule’s logic. Ideally, you should have no negative lag within the project schedule.
Predecessor Lag
This metric identifies all activities with lag values. Lag allow you to place a delay or a waiting period between two activities within a relationship. For example, if two activities were in a FS relationship with two days of lag, the successor would start 2 days after the predecessor finishes. Lag isn’t considered as prohibitive to use as leads are. However, using them excessively can obstruct critical path analysis. In general, you should have lag on less than 5% of activity relationships. If you find that your activities have a lot of lag, consider creating another activity instead to represent the lag time.
FS Predecessor
This check will identify activities that are assigned as a predecessor with an FS relationship. FS stands for Finish-to-Start, meaning that when the predecessor activity finishes, the successor activity will start. This is the most common and easily trackable type of relationship. The majority of your activity relationships should be FS. It is recommended to have 90% of schedule activities use the FS relationship type.
SS Predecessor
This metric will identify activities that have been assigned as a predecessor with an SS relationship type. SS stands for Start-to-Start, meaning that when the predecessor activity starts, the successor activity will also start. SS relationships allow activities to be worked on simultaneously. SS relationships are acceptable to use but should be assigned in moderation. Again, the majority of the relationships should be FS. In general, you would want assign less than 10% of activities with SS relationships.
FF Predecessor
This metric identifies activities that have been assigned as a predecessor with an FF relationship type. FF stands for Finish-to-Finish, meaning that when the predecessor activity finishes, the successor activity will also finish. FF relationships allow activities to be worked on simultaneously. Just like with SS relationships, FF relationships are fine to use in moderation. In general, you would want to assign less than 10% of activities with FF relationships.
SF Predecessor
This metric identifies all activities that have been assigned as a predecessor with an SF relationship type. SF stands for Start-to-Finish, meaning that when the predecessor activity starts, the successor activity will finish. SF relationships are rarely used and are often seen as a poor practice. You can use SF relationships if needed, but it should be done extremely rarely and with caution.
Hard Constraint
This metric identifies all activities that have been assigned a hard constraint – such as Mandatory Start or Mandatory Finish. These constraints will cause an activity to start/finish on a specified date, regardless of the schedule logic. Hard constraints overrule the logic of the project and can cause project issues. In general, it’s good to allow the logic of the project to flow naturally. Therefore, hard constraints should be used with caution. It’s a good practice to only use hard constraints as little as possible and only when necessary.
Soft Constraint
This check identifies activities with soft constraints – such as Start On or Finish On. These constraints will create parameters for an activity to start/finish on a specified date. Unlike hard constraints, however, they won’t adjust the schedule logic. Instead, they will cause negative float if the activity does not meet the constraint date. Soft constraints are better to use than hard constraints as they keep the original schedule logic intact. All constraints should be used sparingly as they can add delays to activities. In general, you should use soft constraints on less than 10% of project activities. If you do need to use constraints, soft constraints are preferable.
Invalid Progress Date
This metric identifies activities that have invalid progress. Invalid progress occurs when a planned start/finish date is in the past or an actual start/finish date is in the future. You will want to have all planned dates be ahead of the project’s data date. All actual dates, on the other hand, should be behind the project’s data date. This is a critical metric – any activities with invalid project dates will affect the accuracy of the project. Ideally, you would want to have no activities with invalid dates.
Late Activity
This metric identifies activities that are late compared to their original baseline dates. An activity is late if it starts or finishes past their original planned start/finish dates. The presence of late activities show that the project is falling behind. If 5% or more of the project’s activities are late, you will 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.
Large Float
This metric identifies activities that have a float value exceeding 40 working days. Float represents the amount of time that an activity can be delayed without impacting the project’s completion. Although float is generally a good thing, too high of a float value may show that the activity is missing relationships and. As a scheduling best practice, it’s recommended that no more than 5% of activities have float values that exceed 40 working days. If you’re finding that many of your activities have high float values, you may want to analyze the relationships to ensure nothing is missing.
Negative Float
This check identifies any activities that have negative float. Negative float indicates that the activity will not finish when it needs to. This is often is the result of using constraints. If an activity is assigned a constraint and won’t meet the assigned constraint date, negative float will be incurred. Because a negative float indicates a delay in the project’s completion, it is important to track and mitigate it as needed. Ideally, you would want no activities in the schedule to have negative float. If they do, corrective action should be taken – such as performing crashing or fast tracking on the project.
Large Duration
This metric identifies any activities with a planned duration above 40 working days. This is not always a point for concern – for example, Level of Effort activities will generally have long durations. However, Task Dependent activities with long durations are often harder to manage. If you’re finding that you have many activities with large durations, you may want to break them down into smaller, more defined tasks. This will provide more insight into the project schedule and cost breakdowns. It’s recommended to have no more than 5% of activities with durations higher than 40 days.
No Roles or Resources
This metric identifies activities that have not been assigned resources or roles. Resources and roles account forthe people, equipment, and materials used on the project. Assigning them to activities allows you to cost-load the project. This is the most open-ended metric from the list, as many projects do not have to be resource loaded. If your contract does not require you to resource-load, this metric can be ignored.
Adjusting the Schedule Health Score Metrics & Thresholds










The table will also feature a column for Weighting. The Weighting determines the weight of each individual check. These weights will determine the overall schedule health score for the project. By default, all metrics will have a weight of 10. This means that every metric that’s turned on will contribute evenly to the schedule health score. If I wanted to indicate some of these metrics as being more important to the overall schedule health, I could increase the weightings as needed.






Summary
Lauren Hecker is an Oracle Primavera Cloud Instructor and teaches onsite and virtual Oracle Primavera Cloudcourses. To see her next open enrollment course, please visit our OPC page. To schedule an onsite or custom course, please contact us!










0 Comments