'Lags' quality metric
Use this metric to check the proportion of links that have no lag, which offsets tasks forwards.
Lag time is the gap or delay between one task ending and its successor starting. Imposing a fixed delay between two tasks is useful in certain situations. For example, you may need to introduce lag time after a task that involves painting in order to allow time for the paint to dry:
The lag time is illustrated by the blue arrow in the following example:
It is possible to have lead/lag at both ends of a link. If a link has lead/lag at both ends, the lead at one end of a link can affect, or even cancel out, the lag at the other end, and vice-versa. This quality metric checks the net lag time of each link, ie the lag time that results from combining the lead/lag at both ends of the link.
Lag represents non-working time between activities and can obscure detail in a schedule. A high proportion of links with lag - ie tasks that are offset forwards by lag - can indicate that a schedule contains insufficient detail and it may be a good idea to convert some or all of the lags into tasks so that they can be managed.
With the pass and fail boundaries set to 95.00%, this metric meets the requirements of DCMA test 3 (Lags).
Examples of links with lag
In the following illustration, the link between Task 1 and Task 2 has 3d lag at the start of the link. This link would fail this metric:
In the following illustration, the link between Task 1 and Task 2 has 3d lag at the start of the link and 1d lead at the end of the link. This link 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 links with no lag is greater than or equal to the pass boundary percentage.
For example, if the pass boundary was set to 75.00%, a project would pass this metric if 75.00% or more of links had no lag. |
| Fail |
A project fails this metric if the percentage of links with no lag is less than the fail boundary percentage.
For example, if the fail boundary was set to 75.00%, a project would fail this metric if less than 75.00% of had no lag. |
| Neither pass nor fail | If the percentage of links with no lag falls between the pass and fail boundary percentages, the result is neither a pass nor a fail, but somewhere in between. |
Default suggested settings
- Pass boundary: 75.00%. A project will pass this metric if 75.00% or more of links have no lag.
- Fail boundary: 75.00%. A project will fail this metric if less than 75.00% of links have no lag.
The following table shows whether some example projects would pass or fail this metric using these settings:
| Percentage of links with no lag | Pass or fail? |
|---|---|
| 0.00% | Fail |
| 25.00% | Fail |
| 74.99% | Fail |
| 75.00% | Pass |
| 80.00% | Pass |
| 100.00% | Pass |
Suggested settings to meet the requirements of DCMA test 3 (Lags)
- Pass boundary: 95.00%. A project will pass this metric if 95.00% or more of links have no lag.
- Fail boundary: 95.00%. A project will fail this metric if less than 95.00% of links have no lag.
The following table shows whether some example projects would pass or fail this metric using these settings:
| Percentage of links with no lag | Pass or fail? |
|---|---|
| 0.00% | Fail |
| 50.00% | Fail |
| 94.99% | Fail |
| 95.00% | Pass |
| 98.00% | Pass |
| 100.00% | Pass |
Does the metric force a project to be rescheduled?
Yes. If you include this metric in a quality check, the charts and summary groups that are included in the scope of the quality check are rescheduled automatically when you execute the quality check.
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 links that have failed the metric, together with the tasks at either end of the links.
You could take the following actions to remedy the failing links:
- Examine the links to determine whether it is appropriate for them to have lag. If a link has inappropriate lag, edit the link and remove the lag.
- If it is appropriate for a link to have lag, consider removing the lag from the link and creating an additional task that represents the lag time. For example, if a 'Pour concrete' task is linked to a 'Drainage works' successor task by a link with 2d lag, with the lag representing the time it takes for the concrete to cure, consider removing the lag from the link and adding a 2d long task called 'Cure concrete' between the 'Pour concrete' and 'Drainage works' tasks, as illustrated below.
The link with lag:
Can be replaced with a 2d long task:
