Guía DCMA-14: los 14 chequeos de calidad de un cronograma P6

¿Qué mide?

Mide el porcentaje de actividades que no tienen predecesora, no tienen sucesora, o ambas. Estas se llaman "open ends" (extremos abiertos). Se excluyen actividades completadas y las de tipo LOE/WBS.

¿Por qué importa?

Un cronograma con muchos extremos abiertos no refleja la secuencia real del trabajo. Si una actividad no tiene sucesora, no afecta a nada cuando se atrasa — el cronograma no captura el impacto. Si no tiene predecesora, arrancará en la data date sin importar si sus requisitos están listos.

¿Qué pasa cuando falla?

Cuando más del 5% de tus actividades no están conectadas lógicamente, el cronograma pierde capacidad de predicción. Los atrasos no se propagan correctamente y el análisis de ruta crítica deja de ser confiable.

¿Cómo corregirlo en P6?

1. En P6, abre la vista Activity Table y añade las columnas "Predecessors" y "Successors".
2. Ordena por la columna de predecesoras vacías para encontrar actividades sin conexión.
3. Asigna relaciones FS (Finish-to-Start) a cada actividad que lo necesite.
4. Las actividades de inicio del proyecto pueden no tener predecesora — eso es válido. Lo mismo para los hitos de cierre sin sucesora.

¿Qué mide?

Busca relaciones entre actividades que tengan un lag negativo ("lead"). Un lead de -5 días significa que la sucesora puede empezar 5 días antes de que se cumpla la condición de la relación.

¿Por qué importa?

Los leads esconden lógica real. Cuando pones un lag de -3 días en una relación FS, estás diciendo que la sucesora puede empezar 3 días antes de que termine la predecesora. Eso debería ser una relación SS+lag, o dos actividades divididas con lógica explícita. El lead evita modelar la realidad.

¿Qué pasa cuando falla?

Cualquier relación con lag negativo hace fallar el chequeo. No hay margen de tolerancia.

¿Cómo corregirlo en P6?

1. En P6, abre la pestaña Relationships de cada actividad marcada.
2. Identifica la relación con lag negativo.
3. Reemplaza el lead por una relación Start-to-Start (SS) con un lag positivo equivalente, o divide la actividad predecesora en dos partes y conecta la sucesora al punto correcto.

¿Qué mide?

Mide el porcentaje de relaciones que tienen un lag positivo (tiempo de espera entre actividades). Un lag de 10 días en una relación FS significa que la sucesora no empieza hasta 10 días después de que termine la predecesora.

¿Por qué importa?

Los lags son tiempo "muerto" que el cronograma no puede gestionar. Si tienes un lag de 14 días para "curado del concreto", ese tiempo no aparece como actividad — no se le puede asignar recursos, no se puede rastrear su progreso, y no se puede acortar si hace falta. Es mejor modelarlo como una actividad real.

¿Qué pasa cuando falla?

Cuando más del 5% de tus relaciones usan lag positivo, el cronograma tiene demasiada lógica oculta en las relaciones en vez de en actividades explícitas.

¿Cómo corregirlo en P6?

1. Revisa cada relación con lag. Pregúntate: ¿este tiempo de espera debería ser una actividad?
2. Para tiempos de curado, esperas de aprobación, tiempos de entrega: crea una actividad explícita.
3. En P6, abre Relationships, encuentra las relaciones con lag > 0, y reemplázalas.

¿Qué mide?

Mide qué porcentaje de las relaciones en el cronograma son de tipo Finish-to-Start (FS). El tipo FS es la relación más directa: la sucesora empieza cuando la predecesora termina.

¿Por qué importa?

Las relaciones FS son las más fáciles de entender y las que mejor representan la lógica real de construcción. Las relaciones SS, FF y SF son válidas pero más difíciles de interpretar y pueden enmascarar lógica incorrecta. Un cronograma con demasiadas SS o FF suele estar "forzado" para que la barra del Gantt se vea de cierta forma.

¿Qué pasa cuando falla?

Si menos del 90% de tus relaciones son FS, el cronograma está usando demasiadas relaciones alternativas.

¿Cómo corregirlo en P6?

1. Revisa las relaciones SS y FF. Muchas veces se pueden descomponer en FS dividiendo actividades.
2. Ejemplo: si tienes Actividad A →SS+5d→ Actividad B, considera dividir A en A1 y A2, donde A1→FS→B y A1→FS→A2.
3. En P6, filtra TASKPRED por tipo de relación distinto a FS para encontrarlas.

¿Qué mide?

Cuenta las actividades que tienen constraints de tipo "duro": Must Start On (MSO), Must Finish On (MEO), Mandatory Start, y Mandatory Finish. Estos constraints fuerzan la fecha de una actividad sin importar la lógica del cronograma.

¿Por qué importa?

Un constraint duro le dice a P6: "esta actividad empieza/termina en esta fecha, sin importar qué diga la lógica". Eso anula el propósito del cronograma. Si la predecesora se atrasa 2 semanas, la sucesora con MSO no se mueve — el cronograma miente sobre el impacto real.

¿Qué pasa cuando falla?

Cuando más del 5% de las actividades tienen estos constraints, el cronograma no puede calcular correctamente la propagación de atrasos.

¿Cómo corregirlo en P6?

1. En P6, abre la columna Constraint en la Activity Table.
2. Para cada constraint duro, pregúntate: ¿realmente esta fecha es inamovible?
3. Si la fecha depende de otra actividad, quita el constraint y usa lógica (relaciones).
4. Si la fecha es un requisito contractual externo genuino (ej: "la obra debe empezar el 15 de marzo por contrato"), un constraint duro puede ser válido — pero documéntalo.
5. Reemplaza MSO/MEO por "Start On or After" (SNET) o "Finish On or Before" (FNLT) cuando sea posible — estos son constraints "suaves" que permiten que la lógica funcione.

¿Qué mide?

Mide el porcentaje de actividades cuyo float total supera los 44 días hábiles. El float es cuánto puede atrasarse una actividad sin afectar la fecha de fin del proyecto.

¿Por qué importa?

Un float extremadamente alto indica que la actividad está "desconectada" del camino principal del proyecto. Puede ser que le falten relaciones, que tenga un constraint incorrecto, o que la lógica no refleje la realidad. Actividades con float de 200+ días básicamente no están participando en el cronograma.

¿Qué pasa cuando falla?

Cuando más del 5% de las actividades tienen float mayor a 44 días.

¿Cómo corregirlo en P6?

1. Revisa las actividades marcadas. ¿Tienen todas las relaciones que necesitan?
2. ¿Hay relaciones faltantes hacia actividades posteriores?
3. ¿Tienen constraints de tipo "As Late As Possible" (ALAP) que les están inflando el float artificialmente?
4. En P6, abre la columna Total Float y ordena de mayor a menor para encontrar las peores.

¿Qué mide?

Cuenta actividades cuyo float total es negativo. Float negativo significa que la actividad ya está atrasada respecto a la fecha de fin del proyecto — necesitaría "tiempo extra" que no existe para cumplir.

¿Por qué importa?

Float negativo es una señal de alarma seria: el cronograma dice que no es posible terminar a tiempo con la lógica actual. Si hay 50 actividades con float de -10 días, el proyecto necesita recuperar 10 días en algún punto de la ruta crítica — o aceptar que terminará tarde.

¿Qué pasa cuando falla?

Cualquier actividad con float negativo hace fallar el chequeo.

¿Cómo corregirlo en P6?

1. Float negativo generalmente viene de un constraint que fuerza una fecha que ya no es alcanzable.
2. Revisa si hay constraints duros que estén generando el float negativo.
3. Actualiza la lógica y los constraints para reflejar la realidad: si la fecha ya no es posible, no la fuerces.
4. En P6: Schedule → Options → verifica que no estés usando "Retained Logic" cuando deberías usar "Progress Override", o viceversa.

¿Qué mide?

Mide el porcentaje de actividades cuya duración planificada supera los 44 días hábiles (aproximadamente 2 meses). Se excluyen actividades tipo LOE (Level of Effort), WBS, milestones y actividades completadas.

¿Por qué importa?

Una actividad de 3 meses es imposible de gestionar bien. Si tiene 30% de avance, ¿cuánto falta realmente? ¿Qué parte se está haciendo ahora? Las actividades largas esconden atrasos: puedes llevar 2 semanas de atraso y no saberlo hasta que estás en el mes 3.

¿Qué pasa cuando falla?

Cuando más del 5% de las actividades exceden los 44 días de duración.

¿Cómo corregirlo en P6?

1. Divide las actividades largas en partes de máximo 2 semanas a 1 mes.
2. Ejemplo: "Montaje estructura" de 90 días → "Montaje estructura - Nivel 1" (15d) → "Montaje estructura - Nivel 2" (20d) → etc.
3. Conecta las sub-actividades con relaciones FS.
4. En P6, usa la función "Dissolve" o simplemente crea las nuevas actividades y reasigna las relaciones.

¿Qué mide?

Busca actividades cuyas fechas no son consistentes con la data date del proyecto. Por ejemplo: una actividad no empezada cuyo early start es anterior a la data date, o una actividad con actual start posterior a la data date.

¿Por qué importa?

Fechas inválidas significan que los datos del cronograma no reflejan la realidad. Si una actividad tiene "inicio real" el 15 de marzo pero la data date es 1 de marzo, ¿cómo puedes saber que empezó si aún no llegaste a esa fecha? Esto suele indicar errores al ingresar actuals o problemas con el scheduling.

¿Qué pasa cuando falla?

Cualquier actividad con fechas inconsistentes hace fallar el chequeo.

¿Cómo corregirlo en P6?

1. Revisa las actividades marcadas una por una.
2. Si el early start es anterior a la data date pero la actividad no ha empezado: corre el scheduler (F9/Schedule) — P6 debería recalcular.
3. Si hay actual dates posteriores a la data date: corrige el actual date o avanza la data date.
4. En P6: Tools → Schedule (F9) resuelve la mayoría de estos problemas.

¿Qué mide?

Mide el porcentaje de actividades activas (no completadas, no LOE/WBS) que tienen al menos un recurso asignado en P6.

¿Por qué importa?

Sin recursos asignados, el cronograma es solo una lista de tareas con fechas. No puedes analizar costos, cargas de trabajo, ni detectar sobre-asignaciones. Muchos owners y financiadores exigen que el cronograma esté "resource-loaded" para aprobar pagos.

¿Qué pasa cuando falla?

Cuando menos del 80% de las actividades tienen recursos. Si el archivo XER no incluye la tabla TASKRSRC, el chequeo se marca como N/A.

¿Cómo corregirlo en P6?

1. En P6, abre la pestaña Resources de cada actividad y asigna los recursos apropiados.
2. Usa el diccionario de recursos del proyecto para mantener consistencia.
3. No necesitas asignar recursos a milestones — solo a actividades con duración.

¿Qué mide?

Mide el porcentaje de actividades que, según el baseline, debían estar completadas para la data date pero no lo están — ya sea porque no se completaron o porque se completaron tarde.

¿Por qué importa?

Este chequeo mide qué tan bien se está ejecutando el proyecto respecto al plan original. Si muchas actividades que debían estar terminadas no lo están, el proyecto tiene un problema de ejecución que probablemente afectará la fecha de entrega.

¿Qué pasa cuando falla?

Cuando más del 5% de las tareas que debían completarse según el baseline están atrasadas o incompletas. Si no hay baseline asignado, el chequeo puede dar N/A.

¿Cómo corregirlo en P6?

1. Este chequeo no se "arregla" en el cronograma — se arregla en el campo. Las actividades atrasadas necesitan acción real.
2. Lo que sí puedes hacer en P6: verificar que el baseline esté correctamente asignado (Project → Assign Baselines).
3. Revisa si las fechas del baseline son razonables. A veces un baseline mal asignado infla artificialmente los atrasos.

¿Qué mide?

Verifica que exista una ruta crítica válida en el cronograma: que haya actividades con float total = 0 y que la cadena llegue hasta el milestone de fin del proyecto.

¿Por qué importa?

La ruta crítica es la cadena de actividades que determina la duración del proyecto. Si no existe, o está rota, no puedes saber qué actividades afectan directamente la fecha de entrega. Cualquier análisis de impacto de atrasos pierde sentido.

¿Qué pasa cuando falla?

Falla si no hay actividades con float cero, o si el milestone de fin del proyecto no es crítico (float ≠ 0).

¿Cómo corregirlo en P6?

1. Si no hay actividades críticas: probablemente hay un constraint que está "cortando" la ruta. Revisa constraints duros.
2. Si el milestone de fin no es crítico: verifica que esté conectado lógicamente a las actividades finales del proyecto.
3. Corre el scheduler (F9) y revisa el log para ver si hay warnings sobre la ruta crítica.
4. En P6: View → Show Critical Activities on Gantt para visualizar la ruta.

¿Qué mide?

Índice que mide la salud de la ruta crítica. Se calcula como: CPLI = (CPL + Float del proyecto) / CPL, donde CPL es la cantidad de días desde la data date hasta la fecha de fin programada.

¿Por qué importa?

Un CPLI de 1.0 significa que la ruta crítica llega exactamente a la fecha de fin. Un CPLI de 0.90 significa que hay un "déficit" de 10% — el proyecto necesita comprimir 10% del tiempo restante para cumplir. Es un indicador predictivo de si vas a terminar a tiempo.

¿Qué pasa cuando falla?

Cuando el CPLI es menor que 0.95, indicando que el proyecto está significativamente atrasado respecto a la meta de finalización.

¿Cómo corregirlo en P6?

1. El CPLI es un indicador calculado, no un parámetro que puedas cambiar directamente.
2. Para mejorar el CPLI: reduce la duración de actividades en la ruta crítica (fast-tracking, crashing).
3. Revisa si hay actividades críticas con duración inflada que podrían optimizarse.
4. Si el float del proyecto es muy negativo, los chequeos 5 y 7 (constraints duros y float negativo) probablemente también fallan — arregla esos primero.

¿Qué mide?

Índice que mide la ejecución real vs. el plan. Se calcula como: BEI = Tareas completadas / Tareas que debían estar completas según baseline. Las "tareas que debían estar completas" son aquellas cuya fecha de fin en el baseline es anterior o igual a la data date.

¿Por qué importa?

El BEI dice qué tan bien estás cumpliendo con el plan. Un BEI de 0.80 significa que solo completaste el 80% de lo que debías haber terminado para esta fecha — estás ejecutando más lento que el plan.

¿Qué pasa cuando falla?

Cuando el BEI es menor que 0.95. Si no hay baseline o no hay tareas vencidas en el baseline, el resultado es N/A.

¿Cómo corregirlo en P6?

1. Al igual que el CPLI, el BEI es un indicador — no se "arregla" en el software.
2. Un BEI bajo requiere acción en el proyecto: acelerar trabajo, agregar recursos, reducir alcance.
3. En el cronograma: verifica que el baseline esté correctamente asignado y que los actuals estén actualizados.
4. Si el baseline es irreal (fue creado sin análisis), considera solicitar un re-baseline con aprobación del owner.