Using Lags
Like constraints, lags have a specific use in scheduling but may be abused. Because lags denote the passage of time, they are often misused to force successor activities to begin on specific dates. For example, if the general contractor has directed that the installation of roof trusses must start on November 6, yet its predecessor activity finishes on November 3, a 2-working-day lag would force the installation activity to occur later than necessary (figure 19).
Figure 19: Using a Lag to Force an Activity’s Start Date
The lag in figure 19 lessens the ability of the project schedule to dynamically respond to changes in the status of predecessor activities. A lag is static; that is, the lag will always be 2 days long unless the scheduler manually changes it. As shown in figure 20, if the predecessor activity is extended 1 day, the 2-day lag forces the mandated event to occur 1 working day later than November 6. For the event to occur on November 6, the lag must be changed to 1 day.
Figure 20: The Effect of a Lag on Successor Activities
Constantly updating manually defeats the purpose of a dynamic schedule and can make a schedule particularly prone to error when it contains many lags. If for some compelling reason outside the schedule, the installation of roof trusses cannot start before November 6, the better approach would be to put a SNET constraint there. Hence, that date will be maintained unless its predecessor is delayed beyond November 5, and then the activity will be pushed to a later date by logic.
Lags, like date constraints, must be used judiciously. They represent a real need to delay time between two activities. They must be justified by compelling reasons outside the schedule in the schedule documentation. In particular, F-S relationships with lags are generally not necessary. In these cases, every effort should be made to break activities into smaller tasks and to identify realistic predecessors and successors so that logic interface points are clearly available for needed dependency assignments. If used improperly, lags can distort float calculations in a schedule and can corrupt the calculation of the critical path. Lags are useful in summary and intermediate schedules because portions of long-term effort are likely to be unknown, or one may wish to reduce the number of activities displayed in high-level reports. Lags are usually used in places where detail is not sufficient to identify the needed interface points for making proper relationships, as in early summary-level schedules.
But lags must not be used in the place of effort in detailed schedules because lags use no resources. Likewise, lags should not represent procurement activities or other types of work performed by parties external to the schedule. Because lags are static and simply denote the passage of time, they cannot be updated with progress, are not easily monitored, and do not respond to the availability of resources. Reference or schedule visibility activities are more appropriate to represent effort that is not part of the scope yet has the potential to affect program activities.
Lags are also often used as buffers or margin between two activities for risk. However, this practice should be discouraged because the lags persist even as the actual intended margin is used up.