One quality of good schedules is that they are clear and understandable. This is at the heart of the Defense Contract Management Agency’s (DCMA) assessment guidelines concerning the use of schedule lags. Let’s take a look at this in more detail.
The DCMA 14-point assessment helps evaluate schedule quality. Schedules that meet or exceed the assessment criteria have a significantly greater opportunity for success. The 14-point assessment seal of approval certifies a well-constructed, and therefore practical schedule.
The third criteria in the 14-point assessment inspects lag in the schedule. Lag modifies the relationship between two activities by inserting waiting time or delays. Lag helps to better describe the true relationship or narrative between activities. The DCMA lag assessment looks at the possible unfavorable impact lag may have on the clarity, accuracy, and dynamic nature of a schedule, and provides guidelines to ensure a quality schedule.
This article looks at the DCMA (positive) ‘lag’ assessment as a gage of the quality of a schedule. This blog does not address negative lag (or lead), which is addressed in the DCMA ‘lead’ assessment guideline.
The precedence diagram, Figure 1, describes the cause-and-effect dependencies between two tasks.
A dependency is the relationship between the (start or) finish of one task and the start (or finish) of another task. In this diagram, Figure 1, task A is the independent cause or driver and task B is the dependent effect or driven. Relationship types between two tasks include: Start-to-Start (SS), Finish-to-Start (FS), Start-to-Finish (SF), and Finish-to-Finish (FF). Refer to our blog The Cause and Effect Task Dependency Paradigm for a more comprehensive discussion on the four types of task dependencies.
The precedence diagram method supports modifying the dependency or relationship between two activities by inserting waiting time or delays. This waiting time modifier is referred to as lag. Figure 2 displays the precedence diagram of a FS relationship, the most common relationship type, including a lag modifier.
The lag modifier in this FS relationship means that not only must predecessor activity A be complete before you can commence successor activity B, but you must also wait for a specific period of time after A finishes before you can actually begin the following activity B. In Figure 2 the relationship is ‘FS + 5’, which means you must wait 5 days after activity A finishes before you can commence activity B.
This lag modifier tool helps to better describe the true narrative of the connected activities. The classic example of lag is the lag (waiting time) needed to allow for the curing of concrete. After concrete is poured, the concrete must cure before proceeding with a successor task, perhaps, construct wall framing on a concrete floor. This curing of concrete time is conveniently modeled using lag. More details on modeling concrete cure in Primavera P6 Professional can be found in this article Primavera P6: A Simplified Procedure For Scheduling Cure Time.
The question at hand now is what do the DCMA ‘lag’ assessment guidelines have to say? The DCMA 14-point schedule assessment guidelines specifies that to avoid adverse effects on the schedule, and, possibly, the critical path no more than 5% of relationships in the respective schedule should have lag. So a limited use of lag is acceptable.
A setback in using lag to model schedules is the increased risk due to its lack of visibility. Lag on the Gantt chart is just a line connecting two tasks, and difficult to spot. Lag on both the Gantt chart and activities table lacks visibility and explanation (definition); it is hard to document lag.
A non-apparent or obscure definition of lag in your schedule may have a negative effect, particularly, if it is along the critical path. You want the critical path to be clearly defined. But lag is vague and not well-defined or documented, which becomes a problem when trying to detail the true schedule narrative. Lag is therefore not easy to monitor.
Another problem with lag is that it is static and simply denotes the passage of time. Lag cannot be updated with progress. Like constraints, lag will not change when predecessor activities are updated with progress, including delays. The unchanging lag may no longer represent the true story of the schedule. An example is when the general contractor specifies an August 8th start date for the install drywall activity and the schedule logic has the predecessor activity, install framing, finishing on August 3rd.
To target your drywall installation on the August 8th specified start date you may be tempted to insert a 3-day lag between install drywall and its predecessor install framing. However, if you do this and your install framing activity is delayed 2-days the 3-day lag time will cause your schedule to overshoot the desired August 8th install drywall start/target date. This is because like constraints lag does not change with schedule updates (as per our example the lag time remains 3-days).
Improper use of lag therefore may inhibit the dynamic quality of your schedule; target date lag must be manually changed as predecessor activity implementation changes. This is one reason that you are recommended to use lag judiciously. Again, limited use of lag ≤ 5% is acceptable. But lag in general is discouraged partly because of its static nature, i.e. its duration remains constant through predecessor activity updates.
So how do you improve your schedule to limit or avoid the use of lag? Well, if the lag represents some outside effort or activity, consider representing it as an explicit task. Indeed the PMI’s Practice Standards for Scheduling second edition suggests this is a good alternative to using lag.
Yes, the lag may represent static waiting time for your project team, but, perhaps, your customer might be performing an explicit task. In Figure 3, an original schedule models with an 8-day lag.
You write and submit a report for review, wait 8-days, and then you incorporate customer comments. During your lag time the customer is actually performing the explicit task of reviewing the report. An improved schedule would model the lag as an explicit ‘customer review’ task with an 8-day original duration, and no resource assignments. (Because this effort is beyond your project team no resources and cost loading are associated with this task.) This provides a better understanding to stakeholders on what is actually happening during this 8-day period of time connecting the two tasks. You also can monitor and adjust the customer review activity according to your customer’s progress.
This is the approach taken in the aforementioned concrete cure time blog. Here no one is performing an explicit task, but a chemical reaction is taking place (the curing of concrete). The curing of the concrete is modeled as a task having an estimated original duration, according to the estimated time the poured concrete takes to cure.
Just as the quality of a programmer’s software code is measured by its documentation and clarity to support other team member programmers, the schedules’ true picture needs to be understood by others beyond the actual scheduler. Limit lag in your schedules to no more than 5% of activity relationships to maintain a well-documented schedule, and reduce risk.
Again, unclear lags inhibit the schedule clarity and may adversely affect the critical path definition. Lag also is static, and, therefore, is not well suited to targeting successor start dates. Consider explicit tasks instead of lag for outside efforts and/or processes, such as the curing of concrete. The lag time may be static nonworking time for your project team, but still represent an explicit dynamic effort or process for others.