Las 14 verificaciones de cronograma de la DCMA, explicadas

Why it matters

Every task except the first and last must have at least one predecessor and one successor. When a task has no logic tie it floats free of the network. The schedule cannot tell you when that work needs to happen, and delays in it will not propagate forward.

How it is measured

The engine counts non-summary tasks with no predecessor and non-summary tasks with no successor. Count divided by total non-summary tasks. Above 5% is a FAIL.

How to fix it

In MS Project, open Task Information for each flagged task and add a predecessor and successor. For the project start milestone, a missing predecessor is expected and excluded.

Why it matters

A negative lag on a Finish-to-Start relationship means the successor can start before its predecessor finishes. This is physically impossible in most cases, hides real work, and creates phantom float. The engine applies zero tolerance.

How it is measured

Any relationship with lag < 0 fails. Count divided by total relationships. Any occurrence above 0% is a FAIL.

How to fix it

In MS Project, open Task Information > Predecessors tab for each flagged task and set the lag to 0 or positive. If genuine overlap exists, use a Start-to-Start relationship with a positive lag instead.

Why it matters

Lags represent waiting time. Excessive lags often mask missing activities (the wait is really undocumented work) and create unrealistic float in the network.

How it is measured

Relationships with lag > 0 are counted. Count divided by total relationships. Above 5% is a FAIL.

How to fix it

Review each lagged relationship. Where the lag represents real work (a procurement lead, a concrete cure time), add a dedicated activity for it. Where it is a shortcut, remove it.

Why it matters

Finish-to-Start is the only relationship type that maps cleanly to how work happens in the field: B cannot start until A finishes. SF and FF relationships are hard to manage, often misunderstood, and frequently indicate incorrect logic.

How it is measured

The engine counts FS relationships divided by total relationships. Below 90% FS is a FAIL.

How to fix it

Review each non-FS relationship in MS Project (Task Information > Predecessors tab). Replace SF and FF with FS plus appropriate lags where the logic genuinely requires overlap.

Why it matters

Hard constraints override logic. When a constrained task cannot move, its successors cannot move either, even when reality changes. High constraint counts produce schedules that do not respond to progress updates.

How it is measured

Non-summary tasks with constraint types SNET, SNLT, MSO, or MFO are counted. Count divided by total non-summary tasks. Above 5% is a FAIL.

How to fix it

In MS Project, open Task Information > Advanced tab for each flagged task. Replace hard constraints with logic ties where possible. Reserve hard constraints for genuine external handoffs.

Why it matters

Very high float almost always means a missing logic tie or artificially inflated duration. Tasks with more than 44 days of float are not contributing to schedule control and are likely disconnected from the network.

How it is measured

Incomplete non-milestone work tasks with total float > 44 working days. Count divided by eligible tasks. Above 5% is a FAIL. Returns NA if no float data is present in the file.

How to fix it

In MS Project, sort by Total Slack (descending). Review each flagged task for missing successors or predecessors. Add the missing logic tie. If the float is a genuine buffer, document it.

Why it matters

Negative total float means the schedule already predicts a late finish. This is almost always caused by a hard constraint that conflicts with the logic network, or a finish deadline imposed without adjusting scope.

How it is measured

Incomplete work tasks with total float < 0 are counted. Any occurrence is a FAIL. Returns NA if no float data is in the file.

How to fix it

In MS Project, sort by Total Slack (ascending). For each negative-float task, trace back to the constraining task or deadline and either remove the constraint, add resources, or adjust scope.

Why it matters

Tasks longer than two months are too coarse to measure or manage. Progress cannot be tracked accurately, and delays are detected too late to recover.

How it is measured

Incomplete non-milestone work tasks with duration > 44 working days. Count divided by eligible tasks. Above 5% is a FAIL. Summary tasks are excluded.

How to fix it

In MS Project, decompose each flagged task into smaller work packages. A common rule: no task should exceed one reporting period in length.

Why it matters

Dates that contradict the data date or each other break every calculation that depends on them. Invalid dates are often left from schedule rebaselining or manual overrides.

How it is measured

The engine flags: (1) incomplete tasks with early finish before the data date, (2) actual start after the data date, (3) actual finish after the data date. Any occurrence is a FAIL. Returns NA if no data date is set.

How to fix it

In MS Project, filter for tasks where Actual Start or Actual Finish is outside the expected range. Fix each date manually, then run Update Project to reschedule uncompleted work.

Why it matters

Unresourced tasks cannot be cost-loaded or used for earned-value analysis. Without resource assignments, workload planning and schedule risk analysis are not possible.

How it is measured

Work tasks with duration > 0 but no resource or cost assignment. Returns NA automatically if fewer than 50% of tasks are resource-loaded (the check is inapplicable to non-resource-loaded schedules).

How to fix it

In MS Project, open the Resource Sheet and define your resources. Assign them to flagged tasks using Task Information > Resources tab.

Why it matters

A task is "missed" when its baseline finish date has passed but it is not 100% complete. These tasks are causing live slippage right now. Returns NA without a baseline and data date.

How it is measured

Non-summary tasks whose baseline finish is on or before the data date, and who have no actual finish and are not 100% complete. Count divided by eligible tasks. Above 5% is a FAIL.

How to fix it

Update the actual progress on each flagged task in MS Project (Tracking Gantt view). Then use Tools > Track > Update Project to reschedule uncompleted work past the data date.

Why it matters

The critical path is the longest logical path from project start to finish. If no tasks are marked critical, the network is broken. Without a valid critical path, total float is unreliable and you cannot identify the real constraint on the finish date.

How it is measured

The engine checks whether any non-summary tasks are marked as critical. If none are critical, the check fails. A full delay-injection test is planned for a future release.

How to fix it

Fix open-ended tasks (no predecessor or no successor) in the critical-path chain. Use the Network Diagram view in MS Project to trace the break. Recalculate the schedule after each fix.

Why it matters

CPLI = (remaining float + critical path length) / critical path length. Below 0.95 is a reliable predictor of a late project finish. It accounts for both how far you have to go and how much margin remains. Returns NA without a baseline and data date.

How it is measured

Critical path length = days from data date to current project finish. Total float = days from current finish to baseline finish. CPLI = (CPL + total float) / CPL.

How to fix it

To improve CPLI you must either shorten the critical path (fast-track or crash activities) or increase float by removing unnecessary constraints. Updating actuals often reveals that the current finish is better than the schedule shows.

Why it matters

BEI = completed tasks / tasks that should be complete by the data date per baseline. Below 0.95 means more than 5% of tasks are running late against the original plan. Returns NA without a baseline and data date.

How it is measured

Tasks with an actual finish recorded, divided by tasks whose baseline finish is on or before the data date.

How to fix it

A low BEI usually means the baseline was set before scope was fully defined, or that actual progress is not being recorded in the schedule. Update actuals first, then assess whether the baseline dates are still realistic.

Why it matters

A well-connected schedule has each task linking to at least one predecessor and one successor, for an average of 2.0+ link endpoints per task. Below this floor signals widespread open ends beyond what the logic check alone catches.

How it is measured

Total predecessor + successor link endpoints across all non-milestone, non-summary tasks, divided by the count of those tasks. Below 2.0 is a FAIL.

How to fix it

Address the root-cause open ends identified by the Logic check. Each task that gains a missing predecessor or successor improves the density metric.

Why it matters

A task with many converging predecessors is a high-risk merge point. If any one predecessor is late, the merge task is late. Eight or more predecessors on a single task creates a bottleneck that is nearly impossible to manage and usually indicates missing intermediate milestones.

How it is measured

Any non-summary task with 8 or more predecessors. Even one such task is a FAIL.

How to fix it

In MS Project, review the flagged task in the Network Diagram. Insert intermediate milestones or handoff tasks to break the fan-in. Reduce the number of direct predecessors to a manageable set.

Why it matters

If a single task spans more than 10% of the project duration, it is probably a placeholder or a summary rolled into the wrong level. These tasks produce misleading progress reports and make the schedule unmanageable.

How it is measured

Project span = max finish date minus min start date, in days. Any incomplete non-milestone work task with duration > 10% of the span is flagged. Even one such task is a FAIL. Returns NA if project span cannot be determined.

How to fix it

In MS Project, decompose each flagged task into measurable work packages. Each package should represent one reporting period of effort with a clear deliverable.