866-847-7515 info@taradigm.com

Understanding the Schedule Health Score in Oracle Primavera Cloud

by | May 16, 2023 | Oracle, Primavera, Primavera P6 | 0 comments

Risk analysis is a vital part of the project management workflow. As a project schedule develops, it’s important to identify all risks and issues as they arise. Identifying errors early on ensure their removal as soon as possible – saving both time and money for the project. Oracle Primavera Cloud allows users to track project health at any time using Schedule Health Score tool. The Schedule Health Score will test the quality of your project against common schedule analysis metrics – such as those from the DCMA 14-Point Assessment. Through this analysis, users can identify and mitigate errors throughout the project lifecycle.
 
This article will show how to use Oracle Primavera Cloud’s Schedule Health Score tool. Here, we will look at the default schedule metrics within the tool. We will also look at customizing the analysis metrics and thresholds. Organizations can customize these metrics for their individual project planning needs.


Accessing the Schedule Health Score

The Schedule Health Score is available within the project’s Activities page. To start, open up a project by selecting the Object Selector and choosing Projects from the list. Select a project from the list of recent projects, or use the Search field to filter down the results. Selecting a project’s name will open up that associated project.

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

Within the upper right hand corner of the screen, select the heart icon. This will open the Schedule Health Score panel. To be able to view this panel, you will need to have set permissions to view projects and schedule health data.
The Schedule Health Check tool will evaluate the current project data using calculated metrics. Every time you schedule the project, the tool will analyze activities and produce scores based on the set metrics. 
At the top of the panel, the overall schedule health score will display as a percentage out of 100. The higher the schedule health score, the healthier the project is. The goal for schedulers would be to try and get this score as close to 100 as possible

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.

Selecting a check will show a description of what the check is and a list of identified activities. Project managers should focus on analyzing the checks that are in red and have a higher number of identified activities.
 
Within each check, select Description to see exactly what the check is looking for. All activities identified from the check will be listed below. The listed activities are all hyperlinked; if you select an activity from the list, the Activities table will jump to that activity. This makes it very easy for users to fix any potential errors identified by the check.

Schedule Health Score Metrics

The Schedule Health Score panel will analyze your project against common schedule analysis metrics. Many of these metrics are from the DCMA 14-Point Assessment, which is a standardized guideline for reviewing project schedules. The Schedule Health Score will use the following metrics to track your schedule’s health:

Open Ends

This check will show all activities without a predecessor or successor relationship. You will sometimes hear these activities referred to as ‘dangling activities’. As a best practice, every activity should have at least one predecessor and at least one successor – with the only exceptions being the first activity and the last activity in the schedule. This is a very important metric to track to ensure that your project has a tight logical path.

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.
 
Depending on your contract, you may not need to ensure that every one of these checks is at zero. However, these metrics can provide a lot of insight on the project’s health. Continuing to analyze this data regularly can help you avoid major project delays.

Adjusting the Schedule Health Score Metrics & Thresholds

 Within any project, users with set permissions can adjust the Schedule Health Score metrics as needed. Users can adjust the descriptions, target threshold values, weight values, and even turn checks on or off. Any changes made to the Schedule Health Score panel will only affect the current project. These settings will not affect the Schedule Health Score panel for any other project.
 
To adjust these settings, select the Summary & Settings app within the open project.
Select the Settings tab from the left of this window. Then, select the Schedule Health Check tab at the top.
The table will display the metrics, along with their descriptions, targets, and weighting. There is also an Active checkbox – any metric that is checked will display within the Schedule Health Score panel. All unchecked options will be hidden fron the panel. You can customize exactly which metrics display by selecting and deselecting these options. For example, if you do not resource load your projects, you may want to turn off the No Resource option by deselecting the associated checkbox.
The descriptions within the table can also be customized. To adjust a description, simply double click on the description cell. You can add additional text or remove text as needed to give your team a better understanding of the check.
Under the Target column, you can adjust the target threshold percentage for the metric. Any check that exceeds that threshold will be seen in red within the Schedule Health Score panel. For example, the target threshold for Large Duration is <=5.00%. This means that the Large Duration metric will show in red if 5% or more of the activities have a duration above 40 days. You can adjust these targets by double clicking within the cell and entering in a new one.

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.

In the Details section, you’ll be able to adjust the same options seen in the table above. There is also a Criteria section here, which allows you to adjust the criteria for some of the checks. For example, you can adjust the criteria for both the Large Float and Large Duration metrics. By default, these criteria fields are set to 40 days – meaning that a float value or duration value is large if it equals or exceeds 40 days. This can be adjusted if needed. According to the DMCA 14-Point Assessment, large float and large duration values are any that exceed 44 days. I’ll adjust this criteria to match that assessment.
After making any changes, make sure to select the Save button in the upper right hand corner of the screen. Once saved, these changes will take effect within the Schedule Health Score panel.

Summary

Oracle Primavera Cloud’s Schedule Health Score is a valuable tool to track project health. When used regularly, the tool will help users identify and mitigate any potential issues or risks. It’s a good idea to analyze the health of the project schedule throughout the project’s lifecycle. In general, you should check the current Schedule Health Score after scheduling each status update. With this tool, you can quickly identify problem areas and efficiently mitigate them before they impact the project.
If you have any comments, questions or suggestions, please use the comment section on the bottom of this page, and don’t forget to subscribe to our blog to get more Oracle Primavera Cloud tips & tricks directly in your inbox!

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

Submit a Comment

Your email address will not be published. Required fields are marked *