Scheduling guidelines like the Defense Contract Management Agency (DCMA)’s 14 point assessment will fail a schedule of any negative lags (or leads) are found: effectively banning their use entirely. In addition, to DCMA the Naval Facilities Engineering Command (NAVFAC) baseline checklist prohibits negative lags in schedules. This sentiment is also reflected in many other practice standards and contract language. So guidelines agree and are definitive: do not use negative lags in scheduling projects.
The remaining question then becomes: are positive lags acceptable? Guidelines are not as clear. NAVFAC says to assign Finish to Start (FS) relationships with 0 lag. Is this NAVFAC’s way of saying do not insert positive lags? The DCMA says a limited number of positive lags are acceptable: i.e. up to 5% of the activities can have lag on their relationships.
This article discusses why positive lags in the schedules should be limited.
We begin our discussion by reviewing the precedence diagram, Figure 1, which describes the relationships between tasks.
In the precedence diagram the predecessor is the cause and the successor is the effect. And the cause predecessor drives the effect successor. Acceptable relationships between tasks include: Finish to Start (FS), Start to Start (SS), and Finish to Finish (FF).
These relationships may be modified to include waiting time between the predecessor and successor. An FS relationship modified by positive lag, Figure 2, says that not only must predecessor activity A be complete before you begin successor activity B, but you must also wait a defined period of time after A finishes before you can actually begin the successor activity B.
An ‘SS’ modified by positive lags says wait a defined period of time after predecessor A begins before starting successor B.
The lag modifier is helpful because it better describes the true narrative of the connected activities. A popular example of lag modifies the FS relationship by inserting waiting time needed to allow concrete to cure.
After concrete pour (or lay foundation) construction crews must wait for the concrete to cure before starting (install walls) successor activities.
Positive lag is often used to modify SS relationships. A classic example is lag between dig trench and lay pipe, Figure 5.
After dig trench has begun you must wait a defined period of time, say 5-days, before there is enough room in the trench to begin laying pipe. In both these situations the lag becomes a helpful tool in modeling the interaction between activities: in this case staggering the start of each activity to allow for parallel work
Despite the utility of positive lag it does have some setbacks. Lag (negative or positive) is not very visible in the schedule. On the Gantt chart lag is displayed as a simple line connecting two tasks, which may be difficult to spot.
A lag in the schedule should really come with a note of explanation. Still, even with proper documentation, lag is difficult to define in the schedule. An obscure definition of lag (even positive) in your schedule can have a negative impact, particularly when occurring on the critical path.
Lag (negative or positive) is also static; it does not adjust based on updates to predecessor activities. Changes in predecessor activities may require manual adjustment to lag, which quickly becomes a tedious process when dealing with multiple lag definitions.
Target date lag, where lag is specifically employed to target a successor start date, will miss the critical start date when the predecessor task does not progress as planned. Excessive use of lag (even positive) therefore has an unfavorable effect on the dynamic quality of a schedule.
Instead of arbitrarily defining a lag waiting time, it may be preferableto specify a known scope of work to represent that period of time. Yes, the positive lag may truly represent static waiting time for your project team, but, other stakeholders, may, perhaps, be performing an explicit task. In our original lag demonstration, Figure 6, we write and submit a report for review, wait 8-days, and then incorporate customer comments.
During our lag waiting time the customer is performing the explicit task of reviewing the report. An improved schedule, Figure 6, models the lag instead as a ‘customer review’ task with an 8-day duration, and no resource assignments. (No resources or costs are associated with this task because it is not performed by your project team.) The improved schedule provides stakeholders more insight into what is actually taking place (customer review) during the 8-day period of waiting time.
Let’s take a look at another situation. In Figure 7, we have a tile manufacturing project.
This schedule reads 8-days after we start manufacturing we begin mobilization, and mobilization finishes when all tiles are received on sight. The problem inherent in this schedule is that the 8-day lag appears to be an arbitrary delay. The start of mobilization is not based upon the completion of a known scope of work.
What happens if not enough tiles are manufactured to warrant start of mobilization? Stakeholders are unaware of this potential problem, because the lag delay does not inform them of the reason for the delay.
A better solution, Figure 8, breaks up tile manufacturing into two known scopes of work: manufacturing sail tiles and manufacturing main hull tiles.
This (defined scope of work) schedule provides stakeholders a much clearer picture of the project. Taking a step back and inspecting the schedule, they are manufacturing tiles for a scale model submarine. This project has a smaller effort to manufacture and install sail tiles and a larger effort to manufacture and install main hull tiles.
The driver for the start of mobilization is the manufacture completion of submarine scale model sail tiles. So instead of the 8-day lag we have a manufacture sail tiles task with 8-day duration. If after 8-days the manufacture of sail tiles is not complete we know to delay mobilize sail crew until completion of this sail tile manufacturing effort. Thus, defining a known scope of work instead of lag wait time makes the schedule more transparent and dynamic.
Most scheduling guidelines discourage insertion of negative lags (leads) in project schedules. Positive lags are acceptable, but on a limited basis. In many situations the negative lag is replaced by a positive lag. But positive lags have many of the same disadvantages as negative lags that should discourage their wide adoption.
Positive lags are difficult to spot; they are not very visible in the schedule. They also do not provide the stakeholder with a very clear understanding of what is actually taking place at that moment in time. They also are static; they do not adjust to changes in progress. The better solution to positive lag is to define a known scope of work for that particular effort. This is a more apparent and responsive scheduling solution.