DCMA Lags Check Explained

The DCMA lags check measures how often positive lag appears in the logic relationships of an Integrated Master Schedule (IMS). The familiar screening target is approximately 5 percent or less. A result above that level signals that lag may be obscuring work, delaying successors artificially, or weakening critical path and float analysis.

A failed check does not prove that every lag is wrong. Instead, it identifies relationships that require review. Some lags represent valid elapsed time, such as a short curing period. However, schedulers should usually model significant waiting periods as named activities that can be assigned ownership, statused, analyzed, and explained.

What the DCMA lags check measures

A lag creates a time offset between two logically related activities. For example, a finish-to-start relationship with five days of lag prevents the successor from starting until five working days after its predecessor finishes.

The current Defense Acquisition University Program Management Fundamentals Handbook describes the metric as incomplete-task relationships that contain positive lag. It states that relationships with lag should not exceed 5 percent of all incomplete-task relationships.

Some references and software dashboards describe the numerator as tasks containing lag rather than individual relationships containing lag. Therefore, always confirm the calculation method before comparing results from different tools. One successor activity can have several predecessors and more than one lagged relationship.

DCMA lags check formula

The relationship-based formula is:

Lag percentage = Lagged incomplete relationships ÷ Total incomplete relationships × 100

For example, assume a schedule contains 800 relationships associated with incomplete activities. If 36 of those relationships contain positive lag, the result is:

36 ÷ 800 × 100 = 4.5 percent

That result falls within the commonly used 5 percent screening level. If the schedule contained 48 lagged relationships, the result would rise to 6 percent and warrant further analysis.

Published scorecards sometimes display the goal as less than 5 percent, while current DAU explanatory text uses language equivalent to no more than 5 percent. Consequently, an organization should define how it treats a result of exactly 5 percent. More importantly, analysts should review the underlying relationships instead of focusing only on a rounding boundary.

Why excessive lag weakens an IMS

Lag inserts time into the network without creating a visible activity. As a result, the schedule does not show what occurs during that period, who owns it, or whether the waiting condition has been satisfied.

This lack of visibility creates several problems:

  • Critical path analysis becomes less transparent. Lag can consume time on a driving path without appearing as a task that managers can monitor.
  • Float calculations become harder to explain. The offset affects scheduled dates and available float, but a reviewer may not understand the operational reason from the activity list.
  • Status cannot be recorded directly. A scheduler cannot assign an actual start, remaining duration, or forecast completion to the lag itself.
  • Risk may be hidden. A fixed lag assumes that the waiting period will occur exactly as entered. It cannot express duration uncertainty for schedule risk analysis.
  • Calendar behavior may be misunderstood. A five-day lag may represent working time rather than five consecutive calendar days, depending on the scheduling application and relationship settings.

The GAO Schedule Assessment Guide recommends minimizing and justifying lags. It also warns against representing schedule contingency as lag because lag has no descriptive name and can become lost within the logic network.

Therefore, the check supports more than scorecard compliance. It helps determine whether the schedule remains a usable model of program execution. For broader context, see the complete guide to the DCMA 14-point schedule assessment.

Positive lag versus negative lag

The lags check addresses positive offsets. Negative lag allows a successor to start or finish before the normal dependency point and is commonly called a lead.

In Microsoft Project, positive and negative values appear in the same Lag field. For example:

  • 24FS+5d means the successor waits five days after activity 24 finishes.
  • 24FS-5d means the successor can start five days before activity 24 finishes.

Microsoft guidance for adding lead or lag time confirms that positive values delay the successor, while negative values create overlap. Negative values should be evaluated under the separate DCMA leads check.

When a lag may be reasonable

A lag can be reasonable when it represents a short, passive, predictable passage of time rather than executable work. A common example is a defined material-curing period between completing an installation and beginning a test.

Before retaining a lag, ask the following questions:

  • Does the interval represent time rather than labor, approval, delivery, or another identifiable event?
  • Is the duration supported by an engineering standard, procedure, vendor instruction, or documented planning assumption?
  • Will the interval remain stable if the predecessor or successor changes?
  • Does the lag use the intended working or elapsed-time calendar?
  • Can a reviewer understand the reason without reverse-engineering the relationship?
  • Would converting the lag to an activity improve ownership, status, or risk analysis?

If the answers support retention, document the rationale in the schedule basis, activity notes, relationship log, or other controlled planning record. The guide to appropriate schedule lag use provides a more detailed decision framework.

Lag uses that should draw immediate attention

Several patterns usually indicate weak planning rather than legitimate elapsed time.

Using lag to force a preferred date

A scheduler may add 20 days of lag because a successor needs to begin on a date supplied by a manager. That approach makes the date appear logic-driven even though the relationship does not explain the delay.

Instead, identify the real driver. It may be facility availability, funding authorization, staffing, material delivery, or an external decision. Model that driver directly where practical.

Hiding approvals or customer reviews

Government review periods, engineering approvals, and configuration decisions are not empty time. They have entry criteria, responsible organizations, expected outputs, and completion events. Therefore, they usually belong in the schedule as activities or milestones.

Representing schedule contingency

Lag should not serve as an unnamed risk buffer. If the program uses schedule margin or another time-contingency method, the approach should be visible, controlled, and consistent with the contract and program scheduling procedures.

Replacing missing logic

Lag does not cure an incomplete network. If a successor waits because another activity must occur, add the missing activity and connect it with valid logic. Also review the schedule for the issues covered in the DCMA missing predecessor and successor check.

How to review lagged relationships

First, run the metric against the same statused schedule submitted for analysis. Confirm the status date, activity population, relationship population, calendars, and exclusions used by the assessment tool.

Next, produce a relationship-level list rather than reviewing only the percentage. At a minimum, capture:

  • Predecessor and successor identifiers
  • Activity names
  • Relationship type
  • Lag value and unit
  • Predecessor and successor calendars
  • Total float
  • Critical or driving-path status
  • Work Breakdown Structure and control account
  • Documented reason for the lag

Then prioritize the review. Start with lag on the program critical path, near-critical paths, contractual milestones, major handoffs, and activities with negative float. These relationships present the greatest potential management impact.

Finally, discuss questionable lag with the responsible planner, Control Account Manager (CAM), technical lead, or risk owner. The scheduler should not replace lag mechanically without understanding the intended sequence.

Reviewing lag in Microsoft Project

In Microsoft Project, add the Predecessors field to a task view and look for positive offsets such as FS+3d, SS+5d, or FF+2d. Microsoft explains the field notation in its Predecessors field reference.

For an individual task, open Task Information and select the Predecessors tab. The Lag column displays the offset for each incoming relationship. On a large IMS, however, a relationship export or dedicated schedule-analysis tool will provide a more reliable review population than visual inspection alone.

Practical example: replacing hidden wait time

Consider the fictional Falcon Ridge Sensor Upgrade program. Its IMS contains this relationship:

Complete Environmental Test FS+15d Release Test Report

The planner explains that the 15-day lag covers laboratory data processing, engineering review, discrepancy resolution, and report approval. Those steps involve real work and several responsible organizations. The lag hides that work and prevents management from seeing which step drives report release.

The team replaces the lag with four activities:

  1. Process Environmental Test Data — 4 days
  2. Complete Engineering Review — 5 days
  3. Resolve Test Report Comments — 3 days
  4. Approve Environmental Test Report — 3 days

The revised sequence does not shorten the plan automatically. However, it now shows ownership, progress, handoffs, and potential delay. It also allows the program to apply uncertainty to the appropriate activities during schedule risk analysis.

During the next status cycle, engineering finishes its review two days late. The schedule now identifies the affected path and forecasts the report milestone correctly. The original 15-day lag could not provide that level of execution insight.

Is the 5 percent threshold a contractual requirement?

Not by itself. The 5 percent screening level is a schedule-health metric used to identify potential problem areas. The DoD Risk, Issue, and Opportunity Management Guide describes the 14-point metrics as a framework for asking informed questions and conducting follow-up research.

The DFARS 252.234-7002 Earned Value Management System clause requires applicable contractors to generate timely, reliable, and verifiable IMS information. It does not establish a universal 5 percent lag limit.

A contract, data item, statement of work, scheduling guide, or approved system procedure may impose more specific expectations. Requirements also vary by agency, contract type, program, and tailoring decision. Therefore, review the governing contract before describing a lags-check result as a compliance violation.

What a scheduler should do after a failed check

  1. Validate the calculation. Confirm whether the tool counts lagged tasks or lagged relationships and whether it evaluates only incomplete work.
  2. Rank the relationships by impact. Review critical, near-critical, high-value, and milestone-driving paths first.
  3. Identify the reason for each lag. Separate legitimate passive waiting from hidden scope or date manipulation.
  4. Replace executable work with activities. Add clear names, durations, owners, calendars, and logic.
  5. Document retained lag. Record the technical basis and verify the time unit and calendar.
  6. Recalculate the schedule. Review changes to the critical path, driving predecessors, total float, and key milestone forecasts.
  7. Rerun the health assessment. Confirm the correction did not create missing logic, long durations, or unintended constraints.

A green score is not the final objective. The schedule must still explain how the program will execute. Conversely, a result slightly above the threshold may be manageable when every lag has a sound basis. The analyst should use the metric to focus professional judgment, not replace it.

Frequently asked questions

Does every lag need to be removed?

No. Retain a lag when it represents a justified and predictable passage of time and when a separate activity would add little management value. Document the reason and verify its calendar behavior.

Do completed relationships count?

The current DAU description evaluates relationships associated with incomplete tasks. However, assessment tools may use different configurations. Define the population before comparing results.

Can lag appear on relationship types other than finish-to-start?

Yes. Positive lag can appear on finish-to-start, start-to-start, finish-to-finish, and start-to-finish relationships. Review the lag separately from whether the relationship type accurately represents the work sequence.

Can a schedule pass the check and still misuse lag?

Yes. A schedule may remain below the percentage threshold while using a small number of high-impact lags on critical or milestone-driving paths. Always inspect the underlying relationships.