En mi empresa, donde nos enorgullecemos de fomentar una Cultura de Innovación, es el pan nuestro de cada día. Todos somos inconformistas, todos buscamos las mejores soluciones y todos opinamos sobre cualquier cosa.
No me malinterpretéis. La duda, el inconformismo, la inquietud son palancas imprescindibles para promover la innovación y con ella la mejora. Debemos admitirlas y promoverlas pero, sobretodo, debemos poder controlarlas y saber cómo sacar partido de ellas.
¿QUÉ PODEMOS HACER?
Nos encontramos ante es un incumplimiento fragante del Sistema de Gestión establecido. Corregir la situación de forma inmediata es sencillo: basta con llevar al Jefe de Proyecto de nuevo al redil. No podemos, ni debemos, obligarle a cambiar el pasado (esta estrategia sólo sirve de cara a la galería) pero sí le podemos instar a descartar las herramientas desarrolladas y a verificar que los procesos que se ha saltado no han afectado a la líneas base del proyecto (tiempo, calidad, coste).Toca ahora analizar las causas que han provocado estas desviaciones. Podemos pensar que el Responsable del Proyecto es un irresponsable, que no está suficientemente concienciado o que no ha recibido la formación suficiente. Y un problema menos.
Pero no siempre es, ni debe ser, así. Con demasiada frecuencia las causas de la rebeldía del Jefe de Proyecto estarán enraizadas mucho más profundamente (ver "Análisis de las causas que nos impiden detectar las verdaderas causas de los problemas").
En un ejercicio de honestidad quizás decidamos ubicar el problema en el diseño del Proceso de Gestión de Proyectos en lugar de enfocar nuestra ira contra el Responsable del Proyecto quién, podemos pensar, se ha limitado a luchar por hacer lo mejor posible su trabajo.
De nuevo, no me malinterpretéis. Hay personas que, sistemáticamente, se oponen a cualquier intento de sistematización, evitan seguir los procesos de la empresa o utilizar las herramientas disponibles, siempre inadecuadas, siempre peores que las de su antigua empresa. Otras, desembarcan en la organización atropelladamente para cubrir alguna urgencia y no reciben la formación adecuada; no tienen más opción que recurrir a lo que mejor conocen. Hay, como siempre, un poco de todo.La cuestión es: ¿debemos trabajar para que todos los proyectos sigan al pie de la letra las metodologías establecidas o es mejor ser flexibles aún sabiendo que podríamos estar abriendo las puertas al caos?. Si admitimos una sola metodología de gestión y desarrollo, nuestro sistema siempre será eficaz y predecible pero quizás no todo lo eficiente que debiera. Si dejamos completa libertad (y confiamos en la capacidad de los Jefes de Proyecto) quizás seamos más eficientes pero perderemos fiabilidad y predictibilidad.
Pero, ¿cómo convences a un Jefe de Proyecto para que siga una determinada metodología cuando sospecha -incluso aunque esté equivocado- que le va suponer un coste adicional, una pérdida de productividad y una bajada del margen operativo?. Por mucho que lo intentes, él siempre hará lo necesario para salir bien en la foto pero también aligerará todo aquéllo que suponga puede hacerle perder rentabilidad. Es su trabajo. Es lo que le exige una organización en la que el margen de los proyectos es un factor crítico (¿todas?)
GUÍAS DE ADAPTACIÓN
Desde mi punto de vista, una de las grandes aportaciones de CMMI en el mundo de la gestión son las Guías de Adaptación. Aparecen en el nivel 3 de madurez y, básicamente, obligan a cada proyecto a declarar explicítamente los procesos y herramientas estándar de la organización que van a utilizar, los qué serán adaptados o creados para cubrir las necesidades específicas del proyecto. En esta declaración es incluso posible elegir el ciclo de vida que mejor se ajuste a la idiosincrasia del proyecto o la metodología de gestión empleada.Este proceso de adaptación debe realizarse en la fase de establecimiento del proyecto y, por supuesto, todas las decisiones y cambios propuestos deben estar justificados (es necesario documentar esta toma de decisiones). Así las guías no se limitan a ofrecer alternativas, fomentan la adaptación de los procesos y modelos establecidos para asegurar una perfecta cobertura de las necesidades del proyecto.
Desde un punto de vista formal, las guías propuestas por CMMI se asemejan a un menú de opciones en el que se seleccionan los mecanismos (procesos, herramientas) que se van a emplear para gestionar, ejecutar, controlar y cerrar un proyecto. Algunos mecanismos serán de uso obligado; en otros casos encontraremos alternativas (un ciclo de vida en cascada o uno iterativo, por ejemplo). Pero también tendremos cierta libertad para proponer el uso de mecanismos o herramientas diferentes de los estándar (los propuestos por la organización). En este caso, será necesario indicar los motivos que justifiquen tal decisión. Y digo "cierta libertad" porque las Guías de Adaptación deben ser aprobadas antes de su aplicación por el propietario del proceso de gestión y desarrollo de proyectos o la PMO (Program Management Office).El resultado de este proceso de análisis y selección (y el de aprobación) deberá quedar registrado en el sistema. El Plan de Gestión del Proyecto es una buena alternativa, aunque no la única.
EN LA PRÁCTICA...
En algunos casos, la guía sólo ofrece una opción no siendo posible alternativa alguna. Por ejemplo, el Jefe de Proyecto no podrá descartar el proceso de Gestión de Requisitos, aunque sí podrá obviar el uso de Proceso de Control de Equipos de Medición o el de Compras.
En otros, podrá optar por una de las opciones disponibles o, incluso, elegir otras nuevas. Por ejemplo, podríamos preguntarle "¿Qué metodología de gestión de proyectos emplearás en tu proyecto?" y darle tres opciones "PMI / PRINCE2 / OTRAS". Las dos primeras han sido validadas por la organización previamente, pero reconocemos la posibilidad de que otras puedan resultar útiles. Por ejemplo, el Jefe de Proyecto podría considerar más interesante para su proyecto aplicar una metodología ágil tipo SCRUM. En este caso, elegiría la opción OTRAS, debería documentar y justificar los motivos de tal elección y solicitar la aprobación u homologación de la nueva metodología.
Una situación similar podría darse con las herramientas de planificación (MS Project, Open Project, un simple Excel) o las de gestión documental (Sharepoint, Google Apps for Windows, un servidor de ficheros, una herramientas proporcionada por el cliente)
VALOR AÑADIDO
Su uso extensivo en la organización tiene otro valor añadido. Una Guía de Adaptación es, en realidad, una propuesta de mejora consecuencia de Lecciones Aprendidas en el pasado y, susceptible, por tanto de convertirse en una "best practice" que acabe instaurándose en la organización (ver Aprender las las Lecciones Aprendidas)Un Responsable de Gestión inquieto recibirá con agrado las propuestas de cambio metodológico o el uso de herramientas alternativas y se preocupará por su correcta aplicación con el fin último de determinar su posible utilidad para el resto de la organización.
También puede interesarte:
- Aprender las las Lecciones Aprendidas
- Análisis de las causas que nos impiden detectar las verdaderas causas de los problemas
- Las 7 cosas que aprendía de PMP
- 17 herramientas de Software Libre (totalmente gratuitas) para Gestionar Proyectos
- Identificación y Gestión eficaz de los riesgos en los proyectos
No hay comentarios:
Publicar un comentario