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.
La puntuación es determinista: el mismo archivo evaluado con el mismo perfil obtiene el mismo número, siempre. La puntuación no depende de ninguna IA, y cada versión del motor debe superar una batería de pruebas de regresión que fija puntuaciones conocidas antes de desplegarse, de modo que tu puntuación no puede variar por accidente.
Las 17 verificaciones y cómo se ponderan las 14 puntuadas
Solo se puntúan las 14 verificaciones DCMA; cada una contribuye a la puntuación final en proporción a su peso, así que un fallo en una verificación de alto peso afecta más que uno en una de bajo peso. Las 3 verificaciones de valor (15–17) se reportan como información pero no tienen peso.
Only the 14 DCMA checks are scored; their weights total 104 points, and each percentage below is that check’s share of the 104. The 3 value checks (15–17) are reported but carry no score weight. Percentages assume every scored check is applicable; NA checks are excluded from the denominator at runtime, so the effective weight of the remaining scored checks scales up accordingly.
Tu Puntuación de Salud del Cronograma siempre es un número del 0 al 100. Así llegamos a ese número. Ejecutamos 17 verificaciones, pero solo se puntúan las 14 verificaciones DCMA; cada una tiene un peso según cuánto influye en que un cronograma se mantenga, 104 puntos de peso en total. Tu puntuación es la proporción de los puntos aplicables que tu cronograma obtiene: si pasa una verificación conserva sus puntos, si falla los pierde. Si una verificación no aplica a tu archivo, la dejamos fuera del total para que nunca cuente en tu contra. Las 3 verificaciones de valor (15–17) se reportan como información pero nunca afectan la puntuación. Los 104 puntos son solo la escala interna. El número que ves está normalizado de 0 a 100, para que puedas comparar dos cronogramas cualesquiera y seguir el mismo a lo largo del tiempo.
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: An injected delay on the critical path must flow day-for-day to the project finish
We inject a 600-day delay into an in-progress critical task and confirm the project finish moves with it. If the delay is absorbed (by missing links or hard constraints), the finish date is not actually driven by the network and cannot be trusted.
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.
Beyond the score: schedule risk & confidence
The score measures how well the schedule is built. A separate Monte Carlo analysis estimates how likely it is to finish on time: a P50/P80 confidence date and the tasks that drive the risk.
How schedule risk and confidence analysis works →