Publicado por: Rob Stauffer
Cuando asesoro a clientes o imparto cursos de gestión de proyectos, lo primero que pregunto es qué tipo de problemas experimentan al gestionar proyectos. Una respuesta típica es:
-
Completado después de la fecha límite
-
Por encima del presupuesto
-
horario poco realista
-
Insatisfacción de los miembros del equipo
-
Papel poco claro
-
limitaciones de recursos
-
falta de responsabilidad
Estos problemas generalmente se reconocen como problemas porque causan “dolor” en el tejido cuando ocurren. Como ocurre con la mayoría de los problemas, el primer paso es asumir que probablemente sean síntomas con alguna causa subyacente. Si usted o su organización no siguen una metodología de gestión de proyectos (es decir, cada uno gestiona los proyectos a su manera), puede esperar ver este tipo de problemas sistémicos. Un proceso variable siempre producirá resultados variables sin importar cuánto lo intentes.
Usar estructuras de desglose del trabajo
He descubierto que para aquellos que tienen una metodología de gestión de proyectos (o reconocen la necesidad de una), a menudo falta una herramienta en el conjunto de herramientas. Las organizaciones que tienen un plan estratégico pero no logran sus objetivos organizacionales a menudo carecen de esta misma herramienta. Esta herramienta se llama estructura de desglose del trabajo (EDT). Una EDT no es complicada, pero lleva tiempo planificar adecuadamente un proyecto o iniciativa estratégica.
Utilice el siguiente ejemplo para explicar qué es una EDT y por qué la necesita.
situación: ACME, Inc. fabrica máquinas de banco de pruebas que requieren software. Cada máquina que producen es diferente y requiere su propio software. Aunque el cronograma muestra tiempo para cargar el software, el proyecto se retrasa en lugar de completarse. Esto a menudo provoca retrasos en la finalización y sobrecostos.
fondo: ACME tiene una lista que describe los entregables de cada máquina que fabrica. Se crea un cronograma aproximado del proyecto (ver más abajo) y siempre se asigna tiempo al software.
Ejemplo de plan de proyecto ACME
En este ejemplo, ACME pasó 70 días diseñando, construyendo y ejecutando una máquina de banco de pruebas completa. Como puede ver, se asignan 45 días para el desarrollo de software, desde el 14 de febrero hasta el 31 de marzo.
El plan de proyecto anterior es inherentemente defectuoso porque se gestiona a nivel de entregables. Esto significa que cada gran tarea debe entregarse en una fecha determinada. Cuando el trabajo se programa en unidades tan grandes, a veces se lo denomina horario de shish kebab. Si para usted es importante completar su software a tiempo y rara vez lo completa, probablemente necesite información más detallada para realizar un seguimiento de su progreso.
El otro defecto de este cronograma es que no está exactamente claro (por nombre) quién hace qué. Tampoco está claro si existen dependencias dentro de cada sección o si existe la posibilidad de realizar tareas en paralelo (o al mismo tiempo).
Una WBS adecuada para 45 días de desarrollo de software podría verse así:
Desglosar 45 días de desarrollo de software en estas ocho líneas de detalle lleva un poco más de tiempo, pero la gestión a nivel de tarea (en lugar de entregable) tiene algunos beneficios.
Ventajas de la estructura de descomposición del trabajo
La WBS anterior tiene varias ventajas. Muestra que el desarrollo del software está programado para completarse en la fecha programada para la puesta en servicio de la máquina (31 de marzo). Esto puede resultar peligroso porque la programación del software no tiene tiempo adicional para situaciones desconocidas. Esta situación debe ser discutida antes de iniciar el proyecto. También nombra quién está haciendo qué, garantizando la rendición de cuentas y destacando qué recursos pueden estar sobrecargados.
La EDT también establece que los productos y los insumos deben definirse simultáneamente durante los primeros siete días. Esto se llama ejecución paralela (normalmente para ahorrar tiempo). Para que el proyecto comience a tiempo, dos personas diferentes deberán comenzar el 14 de febrero. De no hacerlo, se podrá retrasar el inicio de todo el proyecto. Estas dos tareas deben recordarse y controlarse cuidadosamente.
Además, la WBS documenta un desglose de seis pasos con dependencias de principio a fin. Es decir, no puede pasar al siguiente paso hasta que se complete la tarea anterior.
-
escribe el código
-
compila el codigo
-
ejecución en seco
-
Depuración de software
-
Recompilar el software
-
examen final
Finalmente, la WBS proporciona una imagen más clara de dónde se encuentra este proyecto en un momento dado. Esta es la principal responsabilidad del director del proyecto. Ejemplo utilizando la WBS anterior:
-
Si hoy es 15 de febrero, el director del proyecto debe confirmar que Todd y Sara comenzaron el paquete de trabajo.
-
Si alguien enferma repentinamente, está claro qué tareas habrá que reasignar.
-
Debido a que todos los paquetes de trabajo, excepto los dos primeros, tienen dependencias, es una buena idea asegurarse de que se cumplan todos los plazos de las tareas a medida que avanza el proyecto.
-
Si tenemos que entregar este proyecto a otro director de proyecto, está claro cuál es el plan y dónde debemos estar a partir de hoy.
Como se mencionó anteriormente, una WBS no es complicada, pero lleva un poco más de tiempo desarrollarla que una gran porción o un programa de shish kebab. Además de los beneficios mencionados anteriormente, el tiempo dedicado a desarrollar una EDT suele recuperarse reutilizándola en proyectos futuros. En este ejemplo, si la empresa continúa desarrollando software para equipos de prueba, los pasos pueden ser los mismos o similares para todos los proyectos futuros. Lo único que necesita actualización es el nuevo elenco de personajes y las fechas/plazos de inicio del paquete de trabajo.
Gestión de proyectos en el centro.
Rob Stauffer ha sido el director del programa Lean Business Solutions del Centro durante 15 años. Ha capacitado y asesorado a empresas de Michigan a través de una cartera de estrategias y metodologías Lean Sigma, especializándose en análisis financiero, contabilidad de costos, planificación estratégica y gestión de proyectos. También trabajamos con clientes en desarrollo de productos, lanzamientos de productos, procesos administrativos y ventas de programas técnicos.categoría: Crecimiento, Liderazgo/Cultura, Principios Lean, Fabricación, Centro