La Oficina de Gestión de Proyectos debe enfocarse en conseguir resultados, o será considerada un centro de coste. Las empresas suelen motivar la necesidad de implementar una PMO cuando el número de proyectos en ejecución es elevado, los directivos deben controlar que terminan a tiempo, en presupuesto, alcanzando los objetivos de negocio y entregando el valor, pero no disponen del tiempo material para gobernarlos de manera efectiva.
Los proyectos son cada día más complejos. La PMO no tiene recursos para dirigir con efectividad todos los proyectos, que pueden llegar a superar los 500 en ejecución.
La PMO debe gobernar los proyectos, no debería gestionarlos directamente. Debería delegar la gestión en profesionales responsables de que cada proyecto salga adelante, capaces de rendir cuentas, anticiparse a los problemas, proponer y ejecutar acciones correctoras antes de que sea demasiado tarde.
Un profesional de proyectos no se limita a redactar informes, asignar y controlar tareas. Debe dedicar tiempo a gestionar profesionalmente el proyecto, lo cual incluye, entre otras actividades:
- Controlar el cronograma, el presupuesto, la financiación y el alcance.
- Orientar los trabajos del equipo para que entreguen valor y consigan los objetivos de negocio asignados al proyecto.
- Gestionar los riesgos, los supuestos, los problemas y las dependencias (acrónimo RAID, en inglés).
- Comunicar frecuentemente informes de seguimiento evaluando el trabajo, señalando los puntos a mejorar y acciones propuestas.
- Medir desviaciones y calcular pronósticos.
- Controlar los gastos y las horas trabajadas por los miembros del equipo.
- Asignar tareas a los miembros del equipo (en proyectos predictivos).
- Gestionar entregables y cambios.
- Gestionar los requisitos y las expectativas de los interesados.
- Vigilar que se cumplen las cláusulas contractuales.
Para hacer frente al problema de gobernar 50-500 proyectos complejos concurrentes con muchos interesados, muchas organizaciones adoptan antipatrones, o estrategias contraproducentes que, después de implementarlas, no consiguen el objetivo de mejorar la madurez organizacional en gestión de proyectos, terminan de convencer a los directivos de que las PMO son centros de coste que no aportan valor, las personas involucradas en los proyectos no se implican, y nos cierran las puertas a los profesionales de proyectos.
«Los antipatrones aparecen cuando la PMO no es diseñada por un Project Manager»
Muchas organizaciones acaban sufriendo las consecuencias negativas de una PMO creada sobre uno o varios antipatrones de implementación de PMOs:
1) El Informático
El antipatrón tecnológico para implementar PMOs consiste en encargar a un informático que solucione el problema de controlar 50-500 proyectos concurrentes:- Modelará los proyectos como agregación de tareas, y construirá una solución basada en herramientas de control de tareas. El resultado será un sistema de gestión de proyectos para digitalizar tareas, documentos y formularios sobre Jira, Azure DevOps, Notion, Coda, Monday, ClickUp, Smartsheet o Asana. Peor aún, podrían llegar a inventar herramientas a medida para controlar tareas, con el consiguiente coste recurrente de mantenimiento.
- Después de una fase de depuración de las herramientas a partir de las sugerencias técnicas de los equipos de proyectos, tratará de imponer la obligación de que las personas usen las herramientas tal y como se ha definido, así como la prohibición para no usar cualquier otra herramienta no permitida. En la práctica, gestionar proyectos consiste principalmente en reaccionar a los problemas cuando surgen. La técnica más efectiva de gestión de proyectos son las reuniones, ya sean presenciales o en remoto, que desgastan enormemente a las personas involucradas, que tampoco tienen visibilidad del contexto. «Los árboles no les dejan ver el bosque». Los proyectos no se priorizan, ni se estructuran en áreas de negocio, portafolios o programas.
- ¿Qué ocurre cuando los miembros de los equipos de proyectos no entran los datos en estas herramientas? ¿A quién deben preguntar los jefes, por ejemplo, la fecha estimada de finalización de un proyecto? ¿Quién rinde cuentas cuando el proyecto termina mal, tarde y con sobrecoste? Si las herramientas calculan una cosa y los project managers dicen otra, ¿quién tiene la versión correcta de la realidad?
2) El Consultor
El antipatrón de Consultoría para implementar PMOs consiste en encargar el diseño de la PMO un consultor en gestión de proyectos:- Dedicará mucho esfuerzo al análisis de situación actual, escenario futuro, identificación de gaps, plan de acción estratégico, etc. Convencerá a los directivos de que, para gestionar proyectos, primero hay que cambiar los procedimientos. Lo que se clasifique como «operación» quedará fuera del alcance. Modelará los distintos tipos de proyectos según las fases del ciclo de vida. Propondrá plantillas documentales y planes de formación en proyectos, programas, portafolios, etc.
- Para controlar el número creciente de proyectos cada vez más complejos, será necesario implementar herramientas PPM, con altos costes por licenciamiento o por integración con los sistemas de información corporativos, a los que seguirá el coste de un equipo permanente de consultores, que dedicarán la mayor parte del tiempo a administrar la herramienta y preparar informes.
- ¿Qué ocurre cuando la alta dirección decide que no es momento de asumir estos cambios estratégicos? ¿Quién perderá su tiempo en escribir documentos que nadie lee?
3) El Experto en Procesos
El antipatrón de Rediseño de Procesos para implementar PMOs consiste en pedirle a un experto en procesos que intente industrializar los proyectos de forma análoga a las operaciones, como si fueran cadenas de montaje de una fábrica:- Modelará los procesos correspondientes a los diferentes tipos de proyectos, definiendo flujos de trabajo y aprobación, pasos automáticos, métricas e indicadores clave de desempeño, identificarán cuellos de botella, objetivos de mejora, etc. Pasarán varios meses de definición y formación antes de que algún proyecto comience a gestionarse bajo los nuevos procesos.
- Los proyectos no son repetitivos, ni estables. Consisten en transformar las ideas en realidad. Dependen enormemente del factor humano. Son sistemas naturales, no artificiales, siguen la ley de la cosecha. No es trabajo industrial operativo, sino trabajo del conocimiento. Las personas involucradas en proyectos no deberían sentirse como engranajes de una máquina. Es muy efectivo que tengan visibilidad, contexto y, por encima de todo, darles voz.
- ¿Qué ocurre cuando la gente descubre que pueden saltarse algunos pasos de los procesos y consiguen mejores resultados, antes y más valiosos para el negocio?
4) El Científico de Datos
El antipatrón de Ciencia de Datos para implementar PMOs consiste en que un científico de datos trata de resolver el problema de gobernar 50-500 proyectos automatizando algunos informes numéricos:- Identificará las fuentes de datos, diseñará procesos de extracción, transformación y carga, data marts, visualizaciones gráficas de series históricas, estados, tendencias, indicadores, KPIs, etc. El resultado suelen ser sistemas de gestión de proyectos basados en la generación más o menos automatizada de informes en Excel o Powerpoint. Las PMO más sofisticadas usan PowerBI o Tableau.
- La dirección verá una serie de cuadros de mando que transmitirán una sensación de control engañosa. En el mejor de los casos, si las tablas de hechos representan fielmente el estado de los proyectos, solo se tendrá medición retrospectiva de lo que ha pasado y ya no tiene remedio.
- ¿Llegarán a tiempo las respuestas para mejorar el desempeño de los proyectos en rojo? ¿Qué ocurre cuando los indicadores semafóricos están en verde, pero sabemos que los proyectos no van bien?
Implementar PMOs con PMPeople
PMPeople es la herramienta para la Economía de Proyectos. En todas las organizaciones, de cualquier tipo, se gestionan proyectos, programas y portafolios con el objetivo de transformar las ideas en realidad. Las organizaciones están experimentando una «proyectización» creciente y necesitan profesionales de proyectos capaces de rendir cuentas, ser predecibles y, en última instancia, responsabilizarse de alcanzar el éxito en cada proyecto. En PMPeople, utilizamos el término «XPMO» para referirnos a la PMO sin procesos, que puede implementarse con efectividad gracias a la colaboración entre las personas que adoptan diferentes roles. El concepto XPMO está basado en el marco ágil XP (eXtreme Programming). En 1996, Ken Beck inventó un marco de desarrollo software a partir de las sugerencias de sus equipos de programadores, que propusieron un enfoque de desarrollo software extremo, evitando de manera drástica cualquier actividad que originase desperdicio y conservando las que se orientan al valor. Así, crearon un marco basado en 12 prácticas de ingeniería y 5 roles.
«eXtreme PMO (XPMO) suprime la burocracia mediante roles y prácticas de valor»Los individuos interaccionan en la gestión de los proyectos en que están implicados, usando roles colaborativos:
- Estructura: Organizar los proyectos en áreas de negocio, portafolios y programas.
- Paquetes: Gestionar los proyectos gestionando los paquetes de trabajo.
- IPECA: Estandarizar el ciclo de vida de proyectos (Inicio, Planificación, Ejecución, Cierre, Archivo).
- Seguimientos: Publicar seguimientos ligeros y frecuentes.
