Los siete pecados de las programaciones de proyectos
Este artículo forma parte de nuestra colección "From the Trenches".
En este artículo se describen los errores comunes que se cometen en las programaciones de proyectos y se ofrecen consejos prácticos. Proporciona consejos prácticos y recomendaciones que son relevantes para cualquier versión de Microsoft Project.
Para ver más artículos, consulte las notas del producto "Desde las trincheras".
Los siete pecados de las programaciones de proyectos
La programación nunca es un componente simple de un proyecto; sin embargo, en los últimos 20 años, he tenido repetidamente los mismos problemas básicos en cada organización para la que he trabajado o consultado con respecto a sus horarios. Aquí descarto los siete pecados mortales de las programaciones del proyecto y les proporciono algunos antídotos. Espero que use este consejo para sentar las bases adecuadas para una administración correcta de proyectos cuando use programaciones.
Sin #1: ¡La programación es demasiado compleja!
Cuando tiene una programación que tiene más líneas que van de norte a sur que de izquierda a derecha, tiene un problema. Si las partes interesadas tardan semanas o días en comprender su programación, el modelo es demasiado complejo. Si es demasiado difícil explicar a los ejecutivos o incluso a su equipo, ¿cómo puede esperar que alguien se beneficie de él?
¿Cómo sabe si el proyecto es demasiado complejo? Pregúntese lo fácil que es encontrar la ruta crítica en su programación.
Sin #2: Su programación tiene demasiadas tareas
Esto, más que nada, contribuirá a por qué las programaciones se reducen por el camino. De algún modo, los administradores de proyectos tienen la impresión de que una programación debe ser una lista de comprobación de todo lo que se debe hacer. Los elementos pendientes y los recordatorios a sí mismo no pertenecen a una estructura de desglose del trabajo. Este enfoque elimina completamente el propósito completo de una programación que representa un modelo del proyecto.
Para ilustrar el punto, permítanme compartir un ejemplo. Supongamos que usted es la persona de suministro de madera o el armazón que va a construir una casa. Debe saber cuándo entregar el paquete de madera o cuándo presentarse con su equipo para empezar a trabajar. Esto suele ocurrir cuando se completa la base.
Puede crear una programación como esta:
O una como esta:
Si fuera el generador y el programador, ¿qué enfoque prefiere tener que actualizar y mantener los datos reales?
Ahora imagine que tiene 30 casas en construcción al mismo tiempo. ¿Cuál prefieres?
Esto no quiere decir que todas las demás tareas enumeradas no sean importantes o que no sea necesario realizar otras tareas. La verdadera pregunta aquí es cómo realizar un seguimiento y mantenerlo. También puede enumerar las tareas de detalle como una nota a la tarea de una línea mostrada anteriormente.
Esta es mi regla general, que tomo del libro de Eric Uyttewaal, Previsión de programación con Microsoft Project 2010: La duración mínima es el uno por ciento de la duración del proyecto; el máximo es el 10 por ciento de la duración.
Sin #3: La lógica de red está incompleta o no es dinámica
La lógica de red incompleta es la razón número uno por la que las programaciones no se pueden predecir correctamente o evolucionan dinámicamente. Muy pocas dependencias lo representan. El uso de demasiadas restricciones también afectará en gran medida a la naturaleza dinámica de una red adecuadamente establecida. Si ve principalmente restricciones en la columna del indicador, esto indica que es posible que no sepa realmente lo que está haciendo. Los administradores de proyectos suelen hacer que sea un punto para ocultar esta columna con el fin de ocultar que tienen muchas restricciones en su programación.
Esta es una prueba fácil para ti. Busque la ruta crítica en la programación (si no puede, ya tiene un problema importante) y, a continuación, realice una de las tareas incompletas más largas al principio de la programación y duplique la duración. ¿Cambia la fecha de finalización del proyecto? Si no es así, no tiene una programación de trabajo. No podrá beneficiarse de los inquilinos básicos de tener una programación dinámica que pueda usar para predecir tareas y períodos de tiempo y para que usted como administrador de proyectos controle mejor los resultados.
Sin n.º 4: Su programación no está prevista
No basar una programación dificultará, si no imposible, medir la varianza. La base ayuda a capturar la programación antes de empezar a trabajar y le permite aprender de las variaciones cuando se establece la realidad. Si no puede medirlo, no puede controlarlo.
Sin #5: Su programación no se actualiza
La gran mayoría de los horarios que he visto están obsoletos. Los administradores de proyectos a menudo abandonarán la programación una vez que el proyecto esté en curso y se encuentren luchando contra incendios mientras están en ejecución. La probabilidad de que esto ocurra aumenta significativamente si la programación es demasiado detallada y requiere demasiado trabajo para mantenerla actualizada. Conclusión: si no actualiza la programación, ha perdido la capacidad de predecir fechas futuras.
Sin #6: La programación no tiene asignaciones de recursos o están sobreasignadas
A menudo, las programaciones se crean sin ninguna asignación de recursos. Esto podría dar una imagen agradable, pero también podría dar la falsa impresión de que la escala de tiempo es alcanzable. Si se agregan recursos y, a continuación, se redistribuye, puede surgir una escala de tiempo completamente diferente.
Cuando se asignan recursos, más a menudo que cuando se miran "bajo el capó" (mediante la vista de uso de recursos), se asignan en exceso. Si empiezas con unidades fijas integradas, comenzarás con el pie equivocado. Tómese el tiempo necesario para evaluar si ha realizado asignaciones realistas en términos de tiempo y trabajo asignados dentro de la capacidad de una persona.
Además, muestre extrema precaución al usar la característica de nivelación automática de recursos. Se usa mejor en modo manual. Y el uso de una solución empresarial que le proporcione visibilidad sobre otras cargas de trabajo de proyecto debería aumentar la confianza de que las tareas se pueden realizar.
Sin #7: No sabe qué tipos de tareas son
Si no entiende cómo funciona el motor de programación de proyectos y cómo funcionan los tipos de tareas en la ecuación
Duración * Unidades = Trabajo
te quedarás para siempre tirando de tu cabello y frustrado con la herramienta.
Si no recibe el mensaje, le recomiendo que obtenga un buen recurso y lo estudie. La programación de previsión con Microsoft Project 2010 es un buen punto de partida.
Autor
Con más de 25 años de experiencia en la administración de proyectos, Kevin Watson, PMP, MCT, MCTS, es un cinturón negro en Microsoft Project y Microsoft Project Server. Kevin aporta una combinación única de administración de proyectos y servidor de proyectos al campo, donde es consultor sénior de Microsoft. Póngase en contacto con él en kevinw@microsoft.com.