¿Cuántas veces te has preguntado qué hacer para evitar o disminuir las desviaciones en tus proyectos?
La verdad es que la respuesta no es una sola y no es fácil, pueden ser muchas las razones que están provocando esa situación, algunas razones son evidentes otras no tanto.
No siempre tenemos la capacidad de ver las causas de nuestros propios problemas (o los de nuestros proyectos) y esto puede ser parte del problema mismo.
Inclusive las causas pueden variar de una organización a otra radicalmente, de un tipo de proyecto a otro, de un entorno a otro pueden haber grandes variaciones en las causas. No hay una regla mágica o atajo para esto.
Empezar por entender las causas es una buena idea, es una forma de anticiparte, es aprender de lo ocurrido para establecer medidas profilácticas, es pasar de ser reactivo a ser preventivo.
Las siete razones mas comunes que hemos encontrado en muchos de nuestros clientes son las siguientes:
1. Gestión del alcance, problemas en la definición y manejo de los cambios
2. Estimaciones «ingenuas», solo con «visión comercial» o poco realistas.
3. Falta de cultura de gestión de proyectos en todos los miembros de la organización y Madurez en el conocimiento de las prácticas de dirección de proyectos por parte de los ejecutores y líderes de los proyectos y la organización.
4. Mala definición del tipo de proyecto o selección del ciclo de vida y el esquema de ejecución
5. Herramientas para la gestión de los proyectos no integradas o integradas incorrectamente
6. Fallas en la comunicación y alineación entre todos los actores, los protagonistas y los de reparto.
7. Gestión de los riesgos inexistente o incompleta.
Ahora analicemos la primera de estas razones “Gestión del alcance, problemas en la definición y manejo de los cambios”
En primera instancia es importante haber creado dos elementos: primero: el plan para manejar todo el tema el alcance a lo largo del proyecto y en segundo término: el alcance mismo, considerando algunas variables, tales como: quien o quienes participan en su definición, cual es el nivel de definición que se puede realmente tener la iniciar el proyecto, cuanto de lo definido es firme y cuanto puede cambiar.
Teniendo todo lo anterior presente podemos entonces pasar al siguiente paso, la definición del alcance del proyecto.
Existen muchas dinámicas para acometer esta importante tarea, una opción que nos gusta y utilizamos con frecuencia, son las dinámicas de Design Thinking.
Lo importante no es la dinámica, lo importante es no perder el foco, contar con información de calidad, tener a todos los interesados representados, dedicar el tiempo adecuado y especialmente lograr el consenso con el alcance que finalmente obtengamos.
Dicho lo anterior, consideremos entonces como puede ser representado el alcance, como puede ser validado y preservado.
En muchos casos el problema se origina cuando definimos un alcance y no nos ocupamos de preservarlo, esto no quiere decir que no pueda cambiar, lo que quiere decir es que si va a cambiar debe ser de manera controlada, aplicando control de la configuración y una adecuada gestión de cambios.
La Estructura Desagregada de Trabajo o WBS por su nombre en inglés es una excelente herramienta para su representación, es sencilla, es gráfica y puede ser fácilmente validada.
Con la WBS, su diccionario y una definición del alcance entonces creamos la línea base del Alcance, contra la cual obtendremos las líneas bases de Cronograma y de Costos, en un próximo artículo hablaremos de estas líneas bases, su interrelación y como preservarlas. Volviendo al alcance, y para cerrar lo de su definición, es importante obtener una aprobación, aquí mas es mejor, es decir; mientras más interesados, especialmente los críticos, aprueben la línea base es mejor, ojo: la aprobación implica revisión.
Ahora que ya la tenemos (la línea base de alcance), debemos con mucha disciplina gestionar sus cambios.
Es responsabilidad del patrocinador evitar cambios innecesarios, el debe resguardar el alcance original de cambios innecesarios.
Es responsabilidad de los interesados solicitar cambios que solamente, y que efectivamente, generen valor adicional, que sean realmente necesarios.
Es responsabilidad del Gerente de Proyectos evaluar, con su equipo e interesados afectados, de manera acuciosa cada solicitud de cambio hecha y una vez que haya sido dimensionado el cambio y analizado el impacto, entonces decidir aceptarlo, rechazarlo, escalarlo o modificarlo para luego poder aceptarlo.
Cualquiera que sea la decisión, debe ser documentada, difundida formalmente y asumida por el equipo.
En caso de ser aprobada entonces todos deben realizar los cambios que en consecuencias implica la solicitud que ha sido aprobada. Aquí el punto es Integración.
Que síntomas se pueden notar en un proyecto que la gestión de cambios es inadecuada:
En otros instrumentos para la gestión, como cronograma y presupuesto, se consiguen diferencias con respecto a la realidad del proyecto.
La comunicación de los cambios es informal y muchas veces inoportuna, solo se realiza cuando es urgente informar que algo ha cambiado y ahora hay que realizar actividades diferentes.
Reclamos por parte del cliente, de los proveedores o de ambos, por diferencias entre el trabajo ejecutado, las expectativas y el trabajo planificado.
Equipo de trabajo sin una visión clara, desorientados o apagando fuego en distintos frentes del proyecto.
Improvisación en la ejecución de actividades, en las adquisiciones, desviaciones en las fechas y en los costos.
Las causas subyacentes en esta razón de falla de los proyectos es básicamente falta de conocimientos sólidos en la gestión de Alcance, de Interesados y Riesgos. La solución no es tener un mejor planificador o mejores controles de tareas y costos. La solución pasa por mejorar las competencias en definición del alcance, en las relaciones personales, en las habilidades blandas y en la gestión de los riesgos en cuanto a alcance se refiere.
Acerca del autor:
Ned Rodríguez: Ingeniero de Sistemas, estudios de postgrado en Gerencia de Proyectos, facilitador, conferencista e investigador en Gerencia de Proyectos. Especialista en Gestión de Proyectos, Gestión de Cronograma y Gestión de Riesgos. Posee las certificaciones del PMI como: Project Management Professional (PMP ID 20.966, 1.999), Risk Management Professional (PMI-RMP ID 1.550.638, 2012), and Scheduling Management Professional (PMI-SP ID 1.587.543, 2012), Agile Certified Practitioner (PMI-ACP ID 3.209.403, 2022), Agile Metrics y Agile Hibryd Project Pro.
También está certificado como: PRINCE2 Project Manager Foundation (# GR633090694NR), Scrum Master, Scrum Product Owner, Scrum Developer Team, Scrum Advance, User Stories, Design Thinking, Agile Business Owner, Team Kanban Practitioner, OKR, DevOps, Agile Coach y Lean SixSigma.
Facilitador de los programas de preparación para las certificaciones PMP, PMI-RMP, PMI-ACP y PMI-SP, coordinador y miembro del equipo de facilitadores del diplomado en Gerencia de Proyectos de la Universidad Gran Mariscal de Ayacucho, Venezuela. Facilitador del Programa de Gerencia de Proyectos Aplicada y de los talleres de Planificación y Control de Proyectos, Gestión de Riesgos y Gestión Integral de Proyectos para PITS Soluciones.
