7/9/2018 Pecados capitales de los cronogramas del proyecto | Gustavo Cañas Mejia | Pulse | LinkedIn

Regístrate Únete ahora

Diagrama Gantt elaborado en Excel. Gustavo Cañas Mejía.

Pecados capitales de los cronogramas

del proyecto
Publicado el 14 de agosto de 2018

Gustavo Cañas Mejia Seguir

Gerente en Impulso Vertical

La programación del proyecto es de vital importancia para lograr el éxito en los

resultados. El cronograma del proyecto es en su naturaleza el documento de planeación
y seguimiento del proyecto de mayor uso y utilidad. Si bien en la gestión ágil de
proyectos no es posible desarrollar un cronograma detallado hasta el final, su desarrollo
se hace por olas “Rolling Wave” definiendo con mayor precisión las semanas cercanas a
la fecha de cada seguimiento y de manera más esquemática las semanas posteriores.
Este proceso se repite periódicamente según la duración del proyecto.

No obstante, la importancia de esta herramienta, algunos de nosotros cometemos

errores, por falta de tiempo o de cuidado durante la actualización o por otras razones.
Acá repaso algunos de los principales Pecados y sus posibles soluciones.

Pecado 1: El cronograma es demasiado complejo

https://es.linkedin.com/pulse/pecados-capitales-de-los-cronogramas-del-proyecto-gustavo-ca%C3%B1as-mejia 1/6
7/9/2018 Pecados capitales de los cronogramas del proyecto | Gustavo Cañas Mejia | Pulse | LinkedIn

Cuando tienes un cronograma que es más extenso de arriba a abajo que de izquierda a Regístrate Únete ahora
derecha, tienes un problema. Si los interesados toman mucho tiempo en comprender el
cronograma, entonces el modelo es demasiado complejo. Si es demasiado difícil de
explicar a los ejecutivos o incluso a su equipo, ¿Cómo esperas que alguien se beneficie
y lo pueda usar como herramienta de gestión?

¿Cómo saber si tu cronograma

es demasiado complejo?

Una de las maneras de saberlo es

analizando la ruta crítica. Si es
demasiado difícil localizarla,
entonces el cronograma en
general es complejo.

Una manera de resolver este

problema es utilizar “la regla de
los tercios”: 1. La duración de la
actividad más corta no debe ser
menor a 1/3 de la duración
promedio de las actividades.
Tener un cronograma que
incumpla esta condición, puede
conducir a la micro-gestión
“Micro-Management”.
Igualmente existe la regla para el
caso opuesto: 2. La duración de la actividad más larga no debe exceder 3 veces el
promedio de las duraciones. En este caso, el cronograma es demasiado simple y le
podría conducir a descuidar detalles que pueden ser importantes en el proyecto.

Tener en cuenta la regla de los tercios, le ayudará a tener un cronograma balanceado de

arriba hacia abajo y de izquierda a derecha.

Otra forma de hacerlo la presenta, Eric Uyttewaal, en su libro Forecast Scheduling con
Microsoft Project: la duración mínima es del uno por ciento de la duración del proyecto
y la máxima es 10 por ciento de la duración. Personalmente me ha dado mejores
resultados la regla de los tercios.

Pecado 2: Su cronograma tiene demasiadas tareas

Esto es muy similar al punto anterior y puede conducir a que el cronograma se

abandone en el camino. Algunos gerentes de proyecto tienden a pensar que el
cronograma debe ser una lista de verificación “Checklist” de todo lo que debe hacerse.

https://es.linkedin.com/pulse/pecados-capitales-de-los-cronogramas-del-proyecto-gustavo-ca%C3%B1as-mejia 2/6
7/9/2018 Pecados capitales de los cronogramas del proyecto | Gustavo Cañas Mejia | Pulse | LinkedIn

Esto podría conducir a desconectar las actividades del cronograma de los paquetes de Regístrate Únete ahora
trabajo “Work packages”.

Las listas de verificación “Checklist” y las listas de pendientes, no necesariamente

deben estar integradas al cronograma, pueden referirse a un detalle todavía menor que al
de las actividades o tareas del cronograma. Se podrían manejar como archivos
independientes o como notas dentro de la tarea del cronograma.

Pecado 3: La lógica del diagrama de red del cronograma está

incompleta o no es dinámica.

Otra de las principales razones por las que las programaciones no pueden pronosticarse
correctamente o evolucionar de manera dinámica: El cronograma tiene demasiadas
dependencias.

Las dependencias del proyecto son la secuencia en que deben ejecutarse las actividades.
En algunos casos son dependencias discrecionales, dependen de la decisión del gerente
o del equipo del proyecto, en otros casos son de carácter obligatorio, técnico o legal.

Si tenemos demasiadas dependencias discrecionales, se restringe la dinámica del

cronograma. Si hay demasiadas dependencias en la columna “predecesoras” significa
que el seguimiento, la actualización del cronograma y el pronóstico de la fecha final son
difíciles de obtener.

Una manera de determinar si esto está pasando con su cronograma es examinar la ruta
crítica en el diagrama de Gantt. Si es demasiado difícil de seguir, su cronograma tiene
una lógica compleja. Otra prueba que puede hacer es tomar algunas de las actividades
de mayor duración y duplicar su duración, si la fecha final del cronograma no varía, es
probable que estemos ante el mismo problema, la dinámica del cronograma no
funciona.

Una manera de evitar esto es determinar cuales son las dependencias discrecionales y
analizar y eliminar los bucles “loops” o desvíos (“by pass”). Por ejemplo: si la actividad
A precede a la B y esta a la C, en la programación inicial no es necesario que C dependa
de A. Otra manera es crear “Hitos de control” como la llegada de varias tareas y punto
de partida de otras. También tener en cuenta que todas las rutas del cronograma, parten
de un punto inicial y confluyen en un punto final.
https://es.linkedin.com/pulse/pecados-capitales-de-los-cronogramas-del-proyecto-gustavo-ca%C3%B1as-mejia 3/6
7/9/2018 Pecados capitales de los cronogramas del proyecto | Gustavo Cañas Mejia | Pulse | LinkedIn

Pecado 4: El cronograma no tiene línea de base Regístrate Únete ahora

La línea de base del cronograma es aquel que queda fijo, formalmente aprobado y que
se usará como punto de comparación. Este se obtiene, una vez se ha adelantado el
proceso de análisis-programación-revisión del cronograma. En cada reunión de
seguimiento, el cronograma “real” del proyecto se comparará con el de base para
determinar su desviación. Si no se establece una línea de base, será difícil, si no
imposible, conocer la desviación. Si no se puede medir el cronograma, entonces no se
puede controlar.

La manera de resolver este pecado es simple: Una vez haya realizado todos los ciclos de
análisis-programación-revisión del cronograma y esté satisfecho con el producto final o
considere que es razonable, haga que sea aprobado formalmente por el patrocinador del
proyecto y grabe esta primera versión como la línea de base número 1. En el software
de programación esto se logra usualmente con un “click”.

Aunque el cronograma de línea de base queda fijo, el proceso de “Control de Cambios”

podría generar una nueva línea de base del proyecto. Si el cambio, materialización de un
riesgo, o decisión de la directiva del proyecto, se produce y es aprobado, debe generarse
una nueva línea de base de cronograma contra la cual Usted deberá comparar el
cronograma de ahora en adelante.

Pecado 5: El cronograma no se actualiza

Aunque a algunos esto les parecerá extraño, no es inusual encontrarme con un

cronograma impreso o gráfico que se elaboró al inicio y que se abandonó o que no se
actualiza en cada reunión de seguimiento.

Algunos gerentes o equipos de proyecto a menudo abandonan el cronograma una vez

que el proyecto esté en marcha y se encuentren combatiendo incendios mientras están
en la ejecución. La probabilidad de que esto suceda aumenta significativamente si el
cronograma tiene pecados como el excesivo detalle y requiere demasiado trabajo para
mantenerlo actualizado. Si no actualiza su cronograma, ha perdido su capacidad de
utilizarlo como herramienta de seguimiento y de estimación para las fechas futuras.

Este pecado se resuelve inicialmente con disciplina, que se convertirá en costumbre y

posteriormente en la necesidad de utilizar el cronograma como mapa de navegación
para las actividades del proyecto. Esto siempre y cuando, podamos entender fácilmente
nuestro mapa.

Pecado 6: El cronograma no considera la disponibilidad de

recursos.

A menudo, los cronogramas se crean sin ninguna asignación de recursos o se crean

considerando que los recursos tienen capacidad elástica o no tienen horario de trabajo.

https://es.linkedin.com/pulse/pecados-capitales-de-los-cronogramas-del-proyecto-gustavo-ca%C3%B1as-mejia 4/6
7/9/2018 Pecados capitales de los cronogramas del proyecto | Gustavo Cañas Mejia | Pulse | LinkedIn

Definitivamente un cronograma elaborado bajo estas condiciones, además de Regístrate Únete ahora
“planificar” el abuso de los recursos, es inalcanzable.

Si los recursos se agregan y luego se nivelan, (tener en cuenta que un recurso

usualmente no tiene un rendimiento del 100%) surgirá un cronograma completamente
diferente. Utilice el tiempo necesario para evaluar si las estimaciones del cronograma
son realistas, si considera horarios de tiempo razonables, si considera las vacaciones o
descansos del equipo o de sus proveedores o contratistas, si considera eventos
regionales especiales y, por último, si considera las capacidades reales de sus recursos.
Si no es así prepárese para su frustración, el disgusto de su equipo y las discusiones con
sus proveedores o contratistas.

Recomendación, tenga mucho

cuidado al usar la función de
nivelación automática de recursos en
el software de programación. Hágalo
preferiblemente de forma manual,
obtendrá un cronograma realista en
el cual puede confiar.

Pecado 7: No se sabe qué

tipos de tareas son

El cálculo de la duración de un actividad o tarea depende de que “tipo” es. Hay tareas
cuya duración es fija, por ejemplo, un plazo legal, o tareas que dependen del recurso,
por ejemplo, actividades de construcción o desarrollo que utilizan personal o equipos.
En este caso la duración depende del número de unidades de recurso que disponga.

Duración = Trabajo / Unidades

Pecado 8: El cronograma de seguimiento tiene paradojas de

tiempo

Esta es una de las razones más comunes que encuentro en los diferentes proyectos con
los que tengo contacto. Por ejemplo:

1. Una actividad que tiene avance 0% no puede tener una fecha estimada de inicio
anterior a la fecha de corte. Dicho de forma paradójica: No es posible iniciar la tarea
futura la semana anterior.

2. Si la actividad está en curso no puede tener una fecha final anterior a la fecha de
corte, en otras palabras: No es posible terminar la actividad futura la semana
anterior.

https://es.linkedin.com/pulse/pecados-capitales-de-los-cronogramas-del-proyecto-gustavo-ca%C3%B1as-mejia 5/6
7/9/2018 Pecados capitales de los cronogramas del proyecto | Gustavo Cañas Mejia | Pulse | LinkedIn

Regístrate Únete ahora

3. Y por último si la actividad está completa, avance 100%, su fecha final no puede ser
posterior a la fecha de corte, en otras palabras: No es posible haber terminado la
actividad en el futuro.

Si tienen en cuenta todas estas recomendaciones en sus cronogramas, con seguridad, se

convertirán en herramientas de programación, seguimiento y control muy eficientes.

Elaborado por Gustavo Cañas Mejía. Consultor de Gestión de Proyectos.

Derechos reservados.

Gustavo Cañas Mejia

Gerente en Impulso Vertical Seguir
10 artículos

¿Estás buscando más titulares recientes en LinkedIn?

Descubre más historias

Centro de ayuda Acerca de Trabajar en LinkedIn Publicidad Talent Solutions Sales Solutions Pequeñas empresas (en inglés) Móvil Idioma Aprendizaje en línea ProFinde

Buscar empleos Directorios Miembros Pulse Empresas Universidades

© 2018 Condiciones de uso Política de privacidad Directrices comunitarias Política de cookies Política de copyright Date de baja

https://es.linkedin.com/pulse/pecados-capitales-de-los-cronogramas-del-proyecto-gustavo-ca%C3%B1as-mejia 6/6