Errores en la planificación y cómo evitarlos

Por qué fallan las planificaciones

La mayoría de los errores de planificación no nacen de la herramienta, sino de la falta de estándares, de evidencia y de disciplina en torno a ella. Un cronograma en Primavera P6 puede ser técnicamente correcto y, aun así, resultar inútil si cada planificador lo construye distinto, si nadie actualiza el avance o si no hay forma de demostrar qué se calculó.

Este artículo recorre los errores más frecuentes de tres perfiles: contratistas con varios proyectos, consultores forenses y PMO corporativas. Después reúne las trampas comunes, los principios para evitarlos y el papel real del software. Algunos detalles de funciones varían según la versión de P6, así que conviene confirmar en tu release los que dependan de ella.

Los errores comparten un patrón: casi siempre son decisiones que se postergan, como definir un estándar, registrar una configuración o medir la calidad de los datos. Su costo aparece tarde, cuando corregirlos ya es caro.

Contratistas con varios proyectos

Quien lleva varios proyectos a la vez pierde el control sobre todo cuando cada cronograma vive aislado y sin reglas comunes.

1. Un archivo por proyecto, sin base compartida. Si cada proyecto vive en su propio archivo XER o en una base local, nadie ve la carga de un mismo recurso entre proyectos. Con dos o tres proyectos puede bastar un catálogo único de recursos y una hoja de control; con más, conviene una base compartida y evaluar EPPM.
2. Importaciones de XER sin control. Cada importación puede duplicar calendarios, recursos y códigos, hasta tener decenas de variantes de «Calendario 5x8». Define antes de importar qué datos se mapean a los existentes y cuáles se crean, y nombra a un responsable de limpiar duplicados.
3. Estructura y codificación sin estandarizar. Si cada planificador arma su propia WBS y sus propios códigos, consolidar es imposible. Una plantilla única de proyecto, con calendarios, códigos de actividad y niveles de WBS, resuelve la mayor parte.
4. Ciclo de actualización descuidado. Fechas de corte distintas, líneas base sobrescritas y cronogramas sin revisión de calidad hacen que el avance deje de ser comparable. Fija un calendario de actualización, una regla para conservar líneas base y una lista de verificación (lazos abiertos, restricciones excesivas, relaciones con retraso) antes de cada reporte.
5. Edición concurrente sin disciplina. Dos personas modificando el mismo proyecto, o un planificador que reimporta un archivo encima de cambios ajenos, provocan pérdidas de trabajo. Asigna un dueño por proyecto y un procedimiento de check-out y check-in, o de intercambio de archivos con versión y fecha.
6. Esperar portafolio de Professional. P6 Professional programa con mucha profundidad, pero la consolidación y los tableros entre proyectos son limitados. Si la dirección los pide, acuerda qué indicadores necesita de verdad o evalúa EPPM, en lugar de depender de un Excel manual.
7. Saltar a EPPM demasiado pronto. Con pocos proyectos y un solo planificador, montar servidores y administración puede costar más que el beneficio. Define disparadores concretos (más proyectos, recursos compartidos, más usuarios) que justifiquen migrar, y considera una opción alojada.

Consultores forenses

En el análisis forense, el error más caro es el que impide demostrar qué se calculó y sobre qué datos.

1. Modificar el cronograma original. Abrir, recalcular (F9) o guardar un archivo recibido puede cambiar fechas y holguras. Guarda los nativos en modo solo lectura, calcula una huella (hash) al recibirlos, trabaja siempre sobre copias identificadas y lleva una bitácora de cambios.
2. Opciones de cálculo no registradas. Retained logic o progress override, la definición de ruta crítica y el calendario de holgura cambian los resultados. Registra con qué opciones se calculó cada actualización, reproduce primero las fechas originales con la configuración original y mide por separado el efecto de cualquier cambio.
3. Mezclar versiones y herramientas. Un XER de otra versión de P6, o convertido desde otro software, puede dar fechas y holguras distintas. Compara una muestra de actividades contra el archivo original antes de analizar y documenta la versión y el software de origen de cada archivo.
4. Confiar solo en la herramienta. El resultado depende del método. Define y cita la metodología (por ejemplo, la práctica recomendada AACE 29R-03 o el protocolo de la SCL para retrasos y disrupciones) y contrasta cada hallazgo con registros contemporáneos: informes diarios, correspondencia, fotografías.
5. Datos incompletos o fuera de secuencia. Faltan actualizaciones intermedias, hay avances sin respaldo o líneas base modificadas sin aviso. Haz un inventario de las versiones recibidas, solicita formalmente lo que falta y señala los vacíos antes de concluir.
6. Trabajar sobre una base viva. En una base compartida, otros usuarios pueden modificar datos mientras analizas. Extrae una copia aislada, restringe los permisos y registra la fecha y la hora de la extracción.
7. Usar la web para el análisis fino. Las herramientas avanzadas de comparación y control del cronograma suelen ser más completas en Professional; confirma qué incluye tu versión. Reserva la interfaz web para consulta y presentación.

PMO corporativas

Para una PMO, el error de fondo es implantar la plataforma antes de definir el estándar que debe imponer.

1. Plataforma antes que estándar. Sin EPS, OBS, codificación, calendarios, roles de recurso y plantillas definidos, la plataforma solo centraliza el desorden. Pausa las nuevas cargas hasta fijar un estándar mínimo y migra los proyectos existentes por etapas.
2. Privilegios de más. Si muchos planificadores pueden editar datos globales (calendarios, códigos, recursos), un cambio accidental afecta a todos los proyectos. Define perfiles de seguridad por rol y limita la edición global a pocos administradores.
3. Administración subestimada. EPPM exige servidores, base de datos, respaldos, actualizaciones y monitoreo del rendimiento. Asigna responsables y presupuesto, prueba las restauraciones y evalúa una opción alojada si no hay capacidad interna.
4. Versiones desalineadas. Los clientes de Professional y la base de datos deben ser compatibles entre sí. Mantén un inventario de versiones, planifica las actualizaciones por etapas y valida la compatibilidad con la documentación vigente de Oracle.
5. Adopción sin capacitación. Los miembros de equipo no actualizan el avance si la interfaz les resulta confusa o si no está claro quién actualiza y cuándo. Define responsables, frecuencia y criterios, capacita por rol y mide el cumplimiento.
6. Tableros con datos pobres. Los indicadores de portafolio son tan buenos como las actualizaciones que los alimentan. Mide primero la calidad de los datos y marca en el tablero los proyectos desactualizados.
7. Integración prematura con el ERP. Conectar costos, compras y finanzas desde el primer día multiplica el alcance y propaga los problemas de datos. Empieza con cronogramas y recursos, y deja la integración para una segunda fase.
8. Personalización excesiva. Cientos de códigos, vistas y reportes a medida son difíciles de mantener y de enseñar. Depura lo que no se usa y exige justificar cada nuevo código o reporte.
9. Ciclo de vida sin gobierno. Sin reglas para crear, cerrar y archivar proyectos, la base crece, se vuelve lenta y se llena de proyectos obsoletos. Define criterios de cierre y archivo y asigna un responsable.

Trampas comunes a todos los perfiles

Tres errores atraviesan a cualquier organización que use Primavera, sin importar su tamaño.

• Elegir por prestigio y no por necesidad. Se paga y se administra una capacidad que quizá no se aprovecha. Documenta las necesidades reales antes de comprar y revisa la elección cuando cambie la escala.
• Confundir tener Primavera con tener control. La calidad de la programación depende del planificador y de las reglas, no de la herramienta. Define reglas de calidad, aplica revisiones independientes y audita una muestra de cronogramas cada trimestre.
• Licenciamiento y oferta sin verificar. Oracle ha cambiado con el tiempo cómo agrupa y licencia estos componentes, y ofrece además Primavera Cloud como alternativa en la nube. Confirma por escrito la oferta vigente con Oracle o un partner antes de comprometer presupuesto.

Principios para evitarlos

Cuatro principios evitan la mayoría de los errores anteriores: estándar primero, evidencia, calidad de datos y despliegue por fases.

1. Estándar primero. Define estructura, códigos, calendarios, plantilla y reglas de calidad antes de cargar proyectos o ampliar usuarios. Un estándar corto y aplicado vale más que uno exhaustivo e ignorado.
2. Evidencia y trazabilidad. Conserva los originales, registra las configuraciones y guarda el historial de líneas base. Lo que no se puede demostrar no se puede defender, ni ante un cliente ni ante un tribunal.
3. Calidad de datos antes que tableros. Mide el cumplimiento de la fecha de corte y la calidad del cronograma antes de usar indicadores para decidir. Un tablero con datos inconsistentes engaña con apariencia de precisión.
4. Implementación por fases. Empieza con un piloto de uno o dos proyectos, estabiliza cronogramas y recursos, y deja las integraciones y las personalizaciones para después. Revisa la decisión cuando cambie la escala.

El papel del software y sus límites

El software no corrige un mal hábito: convierte las buenas prácticas en reglas y deja evidencia de lo que se hizo.

Seis mecanismos concentran el beneficio: dato único y compartido, acceso por rol, historial y líneas base, cálculo reproducible, verificación de calidad, y consolidación e integración. Bien configurados, impiden por diseño errores como sobrescribir líneas base, editar datos globales sin permiso o consolidar proyectos a mano en Excel. Primavera no es la única opción: según la necesidad también ayudan otros programadores de cronogramas, analizadores de calidad y riesgo, y herramientas de análisis de retrasos, cuyo estado conviene verificar.

Hay límites claros. Ninguna herramienta arregla una lógica pobre de origen, la falta de estándares, los datos que nadie actualiza o una metodología forense débil. Tampoco evita la sobreconfianza: tener la herramienta puede dar una falsa sensación de control.

Lista de verificación y conclusión

Una revisión trimestral con esta lista detecta la mayoría de los errores antes de que cuesten.

• Existe una plantilla de proyecto única y se usa en todos los proyectos nuevos.
• Hay un catálogo único de calendarios, recursos y códigos, sin duplicados.
• La fecha de corte es la misma entre proyectos y entre periodos.
• Se conservan las líneas base y el historial de actualizaciones.
• Cada cronograma pasa una revisión de calidad antes de reportarse.
• Cada proyecto tiene un dueño y un procedimiento de edición o de intercambio.
• Los permisos sobre datos globales están limitados por rol.
• Los originales recibidos se conservan intactos y el análisis corre sobre copias.
• Las opciones de cálculo de cada actualización están registradas.
• Hay responsables de administrar la plataforma, con respaldos probados.
• Los usuarios saben quién actualiza el avance, cuándo y con qué criterios.
• La elección de la herramienta y el licenciamiento están documentados y vigentes.

Evitar estos errores rara vez exige más herramientas. Exige decidir pronto el estándar, conservar la evidencia y medir la calidad de los datos. Cuando esas tres decisiones están tomadas, el software refuerza la disciplina en lugar de sustituirla.