Cómo funciona la puntuación de salud del cronograma
La puntuación de salud del cronograma es un número de 0 a 100 que calculamos a partir de tu archivo. Es nuestro índice compuesto, no un resultado oficial de la DCMA. La DCMA solo da aprobado/fallido por verificación. Nosotros ponderamos esos resultados y producimos una puntuación única para que puedas medir la mejora.
La DCMA (Agencia de Gestión de Contratos de Defensa) desarrolló la evaluación de 14 puntos como una forma estándar de evaluar si un cronograma de proyecto es suficientemente confiable. Las agencias federales la usan para revisar cronogramas de contratistas. Construimos nuestro motor sobre las mismas 14 verificaciones, más 3 verificaciones de valor adicionales.
Las 17 verificaciones y sus pesos
Cada verificación contribuye a la puntuación final en proporción a su peso. Un fallo en una verificación de alto peso afecta más.
Percentages assume all 17 checks are applicable (total raw points: 119). NA checks are excluded from the denominator at runtime, so the effective weight of remaining checks scales up accordingly.
Threshold: At most 5% of tasks missing a predecessor or successor
Every task except the first and last must have at least one predecessor and one successor. Gaps in the logic network make the schedule uncontrollable: delays cannot propagate, float is unreliable, and the finish date is a guess.
Threshold: A valid critical path must exist and be continuous
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 across the project is meaningless.
Threshold: At most 5% of tasks with hard constraints (SNET, SNLT, MSO, MFO)
Hard constraints override logic. When a constrained task cannot move, its successors cannot move either, even when reality changes. High hard-constraint counts produce schedules that do not respond to progress updates.
Threshold: 0% — no tasks with negative total float allowed
Negative total float means the schedule mathematically predicts a late finish before work begins. It is almost always caused by a hard constraint that conflicts with the logic network, or a deadline imposed without adjusting scope.
Threshold: 0% — no negative lags allowed
A negative lag on a Finish-to-Start relationship means a successor starts before its predecessor finishes. This is physically impossible in most cases and hides real work. The engine allows zero tolerance; any occurrence is a FAIL.
Threshold: At most 5% of baseline-eligible tasks missed
Applies to in-progress schedules with a baseline and data date. A task is "missed" when its baseline finish has passed but it is not 100% complete. These are the tasks causing live slippage right now.
Threshold: BEI ≥ 0.95
Ratio of tasks completed to 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. Chronic BEI below 0.95 indicates systemic slippage.
Threshold: CPLI ≥ 0.95
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 you have left.
Threshold: 0% — no invalid dates allowed
Incomplete tasks with early finish dates before the data date, actual dates after the data date, or finish dates before start dates. These break every downstream calculation that depends on those dates.
Threshold: At most 5% of tasks with total float above 44 working days
Very high float almost always means a missing logic tie or artificially inflated duration. Tasks with 44+ days of float are not contributing to schedule control and are likely disconnected from the network.
Threshold: At most 5% of tasks with duration above 44 working days
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. Summary tasks are excluded.
Threshold: At least 90% of relationships must be Finish-to-Start
Finish-to-Start is the only relationship type that maps cleanly to how work happens in the field. SF and FF relationships are hard to manage and often indicate incorrect logic. The engine requires at least 90% FS.
Threshold: At most 5% of relationships with positive lag
Lags represent waiting time. Excessive lags often mask missing activities (the wait is really undocumented work) and create unrealistic float in the network.
Threshold: All work tasks must have a resource or cost assignment
Unresourced tasks cannot be cost-loaded or used for earned-value analysis. If the schedule is not resource-loaded at all, this check returns NA rather than FAIL, since the check is inapplicable to that type of schedule.
Threshold: Average of at least 2.0 logic links per task
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.
Threshold: No task with 8 or more predecessors
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 almost impossible to manage.
Threshold: No task longer than 10% of the total project span
If a single task spans more than 10% of the project duration, it is probably a placeholder or a roll-up that should be decomposed. These tasks produce misleading progress reports and make the schedule unmanageable at the working level.
Honestidad sobre los límites: la puntuación es tan buena como lo que hay en el archivo. Un cronograma con datos precisos obtiene una puntuación precisa.