'Merge hotspot' quality metric
Use this metric to check the proportion of tasks that have fewer predecessors than a given number. Tasks with a large number of predecessors - known as "merge hotspots" - are prone to delay due to the cumulative effect of the incoming links. A high proportion of merge hotspots can indicate that a schedule may be prone to delay.
If a bar contains more than one task, a task is considered to be linked to its immediate predecessor and/or successor tasks on the bar by "implied links", even if no actual links exist between the tasks, unless the bar is configured to allow tasks to overlap. This metric treats implied links in the same way as normal links.
Examples of merge hotspots
In the following illustration, Task 3 has three predecessor tasks - it has three incoming links. If 3 was the given number in the settings of this quality metric, Task 3 would be considered to be a "merge hotspot" and would fail this metric:
In the following illustration, the second task on bar 3 has three predecessor tasks - it has two actual incoming links and one "implied link" between it and the earlier task on the same bar. If 3 was the given number in the settings of this quality metric, the second task on bar 3 would be considered to be a "merge hotspot" and would fail this metric:
You can change the impact that this metric has on the weighted total result of a quality check by entering a factor by which the quality metric should be multiplied in the Weighting field. For the weighting to have any effect, a quality check must have more than one quality metric.
Pass and fail criteria
| Pass or fail? | Criteria |
|---|---|
| Pass |
A project passes this metric if the percentage of tasks that have fewer than the given number of predecessors is greater than or equal to the pass boundary percentage.
For example, if the count was set to 3 and the pass boundary was set to 90.00%, a project would pass this metric if 90.00% or more of tasks had fewer than 3 predecessors. |
| Fail |
A project fails this metric if the percentage of tasks that have fewer than the given number of predecessors is less than the fail boundary percentage.
For example, if the count was set to 3 and the fail boundary was set to 75.00%, a project would pass this metric if less than 75.00% of tasks had fewer than 3 predecessors. |
| Neither pass nor fail | If the percentage of tasks that have fewer than the given number of predecessors falls between the pass and fail boundary percentages, the result is neither a pass nor a fail, but somewhere in between. |
Suggested settings
- Count: 3.
- Pass boundary: 90.00%. A project will pass this metric if 90.00% or more of tasks have fewer than 3 predecessors.
- Fail boundary: 75.00%. A project will fail this metric if less than 75.00% of tasks have fewer than 3 predecessors.
The following table shows whether some example projects would pass or fail this metric using these settings:
| Percentage of tasks with fewer than 3 predecessors | Pass or fail? |
|---|---|
| 0.00% | Fail |
| 50.00% | Fail |
| 74.99% | Fail |
| 75.00% | Neither pass nor fail |
| 80.00% | Neither pass nor fail |
| 89.99% | Neither pass nor fail |
| 90.00% | Pass |
| 100.00% | Pass |
Does the metric force a project to be rescheduled?
No.
Suggested actions if a project fails this metric
If a project fails this metric, select the metric in the Quality Check Results dialog and click Show Failing Tasks to view the tasks that have failed the metric.
Examine the tasks to determine whether it is appropriate for them to have so many predecessors. If a task has any incoming links that can be deleted, delete them.