The DCMA leads check identifies predecessor relationships that contain negative lag. A lead allows a successor activity to start or finish before the relationship would otherwise permit. For example, an FS-5d relationship directs the successor to start five working days before its predecessor finishes.
Under the traditional Defense Contract Management Agency 14-point schedule assessment, the goal is zero leads. The check does not prove that every flagged relationship is technically impossible. Instead, it highlights logic that may hide the actual handoff, distort float, or make the schedule harder to status and defend.
For a broader explanation of the complete assessment, see the DCMA 14-point schedule assessment guide.
What the DCMA leads check measures
A lead is a negative time value assigned to a dependency. Microsoft Project and other scheduling tools often label the relationship field as lag, even when the entered value is negative. Therefore, schedulers may also describe a lead as negative lag.
Consider these Microsoft Project relationships:
- 25FS-5d: The successor may start five working days before Task 25 finishes.
- 40SS-20%: The successor may start after 20 percent of the predecessor’s duration has elapsed. Because the value is positive, this example is a lag rather than a lead.
- 55FF-2d: The successor may finish two working days before Task 55 finishes.
Microsoft’s guidance on adding lead or lag time confirms that Project represents lead time with a negative number or percentage. The software allows the entry, but software capability does not establish good scheduling practice.
The classic DCMA target is no incomplete tasks with lead values in their predecessor relationships. However, assessment tools do not always display the result in the same way. Some report the number of affected tasks. Others calculate:
Lead percentage = relationships containing leads ÷ total relationships × 100
These methods can produce different counts because one successor may contain several predecessor relationships, including more than one lead. Therefore, review the calculation rules in the customer’s assessment tool, schedule management plan, or delivery instructions before reconciling results.
Why the target is zero leads
A lead describes overlap by counting backward from a predecessor event that has not yet occurred. That approach can obscure the condition that actually authorizes the successor to proceed.
For example, “Start qualification review five days before design completion” does not explain what must be ready five days early. Does the review need a complete draft, approved drawings, released interfaces, or only selected sections? The relationship creates a date, but it does not define the technical handoff.
The GAO Schedule Assessment Guide defines a negative lag as a lead used to accelerate a successor activity. GAO also emphasizes that a reliable schedule should use logical and dynamic relationships so that changes flow through the network correctly.
Leads can weaken that behavior in several ways:
- They hide scope. The schedule omits the interim product, approval, or maturity point that enables overlap.
- They complicate status. A scheduler cannot status the lead itself or determine whether its assumed condition occurred.
- They can misstate float. The negative offset changes calculated dates without explaining the underlying work sequence.
- They reduce traceability. Control account managers and reviewers may struggle to understand why downstream work can begin.
- They weaken schedule risk analysis. A lead has no discrete duration or uncertainty distribution that analysts can assess independently.
NASA’s Schedule Management Handbook similarly recommends avoiding leads and lags unless they represent a real acceleration or delay. It notes that they often mask lower-level activities that should appear explicitly in the schedule.
A lead is not automatically a contractual violation
The DCMA leads check is a schedule-quality diagnostic. It is not, by itself, a Federal Acquisition Regulation or Defense Federal Acquisition Regulation Supplement clause. A lead becomes a compliance concern when applicable contract language, a Contract Data Requirements List, a data item description, an approved schedule management plan, or customer direction establishes the relevant scheduling criteria.
Therefore, do not label every lead a contractual noncompliance solely because it fails a health metric. First, review the contract and governing program documents. Then determine whether the relationship also prevents the Integrated Master Schedule (IMS) from meeting required network, status, traceability, or critical-path expectations.
Likewise, passing the check does not prove that the schedule has sound logic. A schedule can contain zero leads yet still have missing relationships, excessive constraints, or invalid sequencing. The related DCMA missing predecessor and successor check addresses another major part of network integrity.
How leads affect schedule execution
Leads often look harmless during baseline development because the dates appear reasonable. Problems emerge when actual performance differs from the original plan.
Suppose a 20-day design activity drives a review through an FS-5d relationship. The review starts on day 16. If the design later grows to 30 days, the review moves to five days before the new finish. However, the schedule still does not identify whether a reviewable product will exist on that date.
Meanwhile, the control account manager may report that the design is 70 percent complete while the review team has already started. The scheduler must then decide whether the work occurred out of sequence or whether the original logic failed to represent the true handoff. See out-of-sequence progress explained for the status implications.
Leads can also affect management analysis. Because relationship offsets influence early and late dates, they may alter the calculated critical or driving path. They can also make float difficult to interpret. As a result, reviewers should examine any lead found on a path to a contractual event, major delivery, technical review, or significant earned value milestone.
How to correct a DCMA leads check failure
Do not remove a lead only to make the metric turn green. First, determine why the overlap exists. Then model that condition explicitly.
1. Identify the real entry condition
Ask what allows the successor to begin before the predecessor finishes. Common answers include a draft release, partial material availability, completion of one geographic area, interface approval, or availability of preliminary test data.
If the team cannot name a measurable condition, the overlap may be unsupported. In that case, a standard finish-to-start relationship may better represent the work.
2. Split the predecessor at the handoff point
Replace the broad predecessor with activities that show the deliverable’s development and release. For example, replace “Complete design” with “Prepare review draft,” “Release review draft,” and “Incorporate final comments.”
The review can then start after the draft-release milestone. Meanwhile, final design work may continue in parallel where technically valid. This structure preserves the intended overlap without counting backward from an uncertain future finish.
3. Use relationship types that represent the work
A start-to-start or finish-to-finish relationship may describe legitimate concurrency better than a negative offset. However, changing FS-5d to SS solely to avoid the leads check does not improve the schedule. The new relationship must reflect an actual dependency.
Also, avoid replacing every lead with a positive lag. That approach merely trades one diagnostic issue for another. For more guidance, see when schedule lags are appropriate.
4. Recalculate and review the affected paths
After revising the logic, recalculate the schedule. Then review total float, free float, milestone forecasts, resource loading, and the critical or driving path.
A logic correction may expose schedule pressure that the lead previously concealed. If a key delivery moves, confirm that the revised forecast reflects executable work rather than restoring the old date with a constraint. The article on tracing a critical path in Microsoft Project explains how to follow the resulting network.
Fictional program example
The Falcon Ridge avionics program includes a 25-day activity named “Complete flight computer design.” The scheduler links “Conduct independent design review” with FS-5d because the review team plans to start before the design team finishes.
The DCMA leads check flags the relationship. During the review, the scheduler learns that the review team does not need the final released design. It needs a complete review draft and an approved interface data package.
The program replaces the original logic with these activities:
- Develop flight computer review draft.
- Approve interface data package.
- Release review package milestone.
- Conduct independent design review.
- Resolve review comments and release final design.
The release milestone requires both the draft and interface package. The independent review starts after that milestone. Therefore, the final design work can continue without a lead, while the IMS shows the specific maturity point that enables the review.
This model also improves status discussions. If interface approval slips, the schedule identifies the actual blocker. The program manager no longer sees only a moving five-day overlap.
Reviewing negative lag in Microsoft Project
In Microsoft Project, open the successor task and review the Predecessors tab in the Task Information dialog. A negative value in the Lag column represents lead time. You may also see the value in the Predecessors field, such as 125FS-5d.
For a small schedule, review the relationships manually. For a large IMS, use an approved schedule-analysis tool or a controlled export that evaluates individual relationship records. Searching only the displayed Predecessors text may miss complex links or create false matches.
For every lead, record at least:
- the predecessor and successor identifiers;
- the relationship type and negative offset;
- the affected control account and work breakdown structure element;
- the reason for the overlap;
- the path or milestone affected;
- the proposed logic correction; and
- the responsible control account manager or schedule owner.
Finally, compare the corrected schedule with the prior version. Confirm that the change did not accidentally delete valid logic, create open ends, or move baseline dates without authorization.
Common mistakes when resolving leads
- Deleting the relationship: Removing the lead and its entire dependency can create missing logic.
- Changing the link to SS without analysis: A different relationship type does not automatically represent the technical sequence.
- Adding a date constraint: A constraint may restore the desired date while making the schedule less dynamic.
- Replacing the lead with positive lag: This may conceal the same missing handoff behind another offset.
- Ignoring completed work: Historical leads still help explain prior sequencing and should be addressed according to the program’s schedule-change procedures.
- Treating the metric as the final answer: A zero-lead schedule can still contain weak or incomplete logic.
DCMA leads check FAQ
What is the acceptable threshold for leads?
The traditional DCMA 14-point target is zero leads. Some tools also show the percentage of relationships containing negative lag. Verify the tool’s scope and denominator before comparing results.
Are leads prohibited in Microsoft Project?
No. Microsoft Project allows negative lag. However, an allowed software feature may still conflict with program scheduling procedures or customer expectations.
Can a lead represent valid overlap?
Yes, the underlying overlap may be valid. Even so, the IMS should usually identify the measurable handoff that permits downstream work to begin.
Should every lead be replaced with a start-to-start relationship?
No. Use start-to-start logic only when the successor truly depends on the predecessor’s start. Otherwise, split the work at the real handoff or use another technically accurate relationship.
Does passing the leads check prove the IMS is healthy?
No. The result addresses one aspect of schedule logic. Review it with missing logic, lags, constraints, relationship types, float, critical-path integrity, and status quality.
Practical conclusion
The DCMA leads check asks a focused question: does any incomplete work rely on a negative relationship offset? The preferred answer is zero because leads often replace a missing activity, milestone, or technical handoff.
However, the scheduler’s job is not merely to eliminate negative values. The goal is to preserve valid concurrency while making the IMS transparent, statusable, and logic-driven. When a lead appears, identify the real entry condition, model it explicitly, recalculate the network, and confirm the resulting path with the responsible program team.