¿Cómo debe afrontar la dirección la nueva gestión de proyectos?

Los proyectos importan más que nunca. Aparte de los megaproyectos públicos y privados de infraestructuras e instalaciones, la mayoría de las empresas eligen el “modo proyecto” para llevar a cabo sus iniciativas de cambio. Antonio Nieto, que fue presidente del Project Management Institute, habla de una “economía de los proyectos”, que ya representa más del 45% del PIB en los grandes países occidentales y crece a un ritmo del 5% anual.

La otra cara de la moneda son los ejemplos icónicos y las cifras del fracaso: apenas un 29% de los proyectos alcanzan los resultados esperados, según los Informes del caos del Standish Group, aunque parece que hemos ido mejorando. En realidad, no tenemos que mirar muy lejos: todos estamos en algún proyecto en nuestras organizaciones, muchos fracasan y la mayoría nos parecen una pérdida de tiempo.

Hace 25 años, Tom Peters escribió un librito inspirador, hoy casi romántico, en el que proclamaba el valor de los proyectos para innovar, cambiar las empresas, romper los silos e inercias organizativas, crear nuevos productos y negocios y descubrir talentos. Para las personas, el proyecto es una manera de afrontar nuevos retos y aventuras, así como encontrar y desarrollar carreras. “Haz de cualquier actividad una aventura, un proyecto que importe”, recomendaba. Los llamaba proyectos WOW.

Sin embargo, en los currículums de la mayoría de las escuelas de negocios, la formación en gestión de proyectos no existe o es superficial, y este espacio se ha dejado en manos de “expertos”. Y, a medida que se hacen más proyectos, de diferente tamaño, riesgo y nivel de complejidad, ha aumentado también el número de escuelas, métodos, certificaciones y tribus, y las disputas escolásticas entre ellos.

Denominamos “proyecto” a todo lo que no son las “operaciones”. Estas son los procesos que seguimos en el día a día para cumplir la misión y servir a los clientes. Las operaciones son estables y permanentes y nos aseguran los beneficios de cada día. Los proyectos son iniciativas únicas, con principio y final, formados por un equipo ad hoc y que producen un resultado diferente cada vez. Los proyectos son inversiones para realizar la visión, la estrategia, que nos deberían proporcionar riqueza en un futuro no lejano y, en muchos casos, mejorar nuestras operaciones. Un proyecto es una manera controlada de ejecutar una inversión.

La gestión de proyectos es la práctica empresarial para manejar proyectos. Se trata de una colección de principios, actividades, procesos, métodos y herramientas que se necesitan para llevar un proyecto a los resultados deseados.

 

Solo proyectos imprescindibles

Para Peter Drucker, la estrategia es el arte de decir que no, dejar de hacer, abandonar todo aquello que no aporta valor. Se hacen demasiados proyectos, cuando solo se deberían llevar a cabo los imprescindibles: los que tienen un claro retorno y nos colocan en mejor posición para competir, los que permiten aumentar los ingresos, reducir los costes, mejorar el servicio y la experiencia de cliente o cumplir los Objetivos de Desarrollo Sostenible.

Todo eso se puede medir, hay colecciones de indicadores. Esta declaración (la definición del proyecto) es el acuerdo que vincula a todos los directivos, empleados y proveedores que participan en un proyecto antes, durante y después de su ejecución.

Antes de empezar un proyecto, los que lo proponen y la dirección que lo aprueba tendrían que ser capaces de contestar un conjunto de preguntas y compartir las respuestas:

• ¿Qué problema u oportunidad de negocio necesitamos resolver?

• ¿Qué vamos a hacer para resolverlo? ¿Necesitamos un proyecto?

• ¿Qué vamos a hacer en el proyecto? ¿Cuál será el resultado?

• ¿Cómo lo vamos a hacer? ¿En qué consiste el proyecto?

• ¿Cuáles son los riesgos de hacerlo y de no hacerlo? ¿Cómo los vamos a manejar?

• ¿Con qué otras iniciativas compite? ¿Qué vamos a dejar de hacer?

• ¿Quién está a cargo? ¿Cómo se toman las decisiones?

• ¿Cómo sabremos que hemos conseguido el resultado? ¿Cómo lo medimos?

El profesor Joe Peppard dice que la dirección estratégica de sistemas de información consiste en decidir cuánto dinero gastamos y en qué lo gastamos. Cada propuesta de inversión se compara con otras. Cada decisión de hacer supone tomar otra decisión de no hacer o de recortar. Los criterios de decisión deben ser transparentes y las conversaciones deben ser claras. El proceso (la conversación entre directivos) es tan importante como el resultado, que será un portafolio de programas y proyectos. Frecuentemente, las dimensiones “programa” y “portafolio” son más próximas, naturales y comprensibles para la dirección, más “estratégicas” que la dimensión “proyecto”, quizá demasiado granular y de detalle. La alta dirección es la responsable de la gestión integral del portafolio de proyectos (ver el cuadro 1).

 

 

Gestión imprescindible, la gestión ágil

En el complejo contexto empresarial actual, pedimos a los proyectos resultados más rápidos, más flexibles para atender a los cambios y más económicos, pero seguimos pidiendo al mismo tiempo previsibilidad, control y auditoría. La dirección reclama certezas, que frecuentemente no tiene para sí misma: qué tendremos, cuándo lo tendremos, cuánto nos costará.

Los métodos de gestión tradicionales, llamados predictivos, aspiran a proporcionar un plan detallado y preciso donde el alcance (lo que vamos a hacer y sus requisitos), el tiempo de realización (el calendario) y el coste (la dedicación de los equipos y las compras de productos y recursos externos) estén bien definidos desde el inicio y sean controlables y auditables. Esto no ocurre casi nunca, pero es más fácil en proyectos de infraestructura e instalaciones, en el mundo del hardware y las comunicaciones y en entornos muy regulados o de financiación pública, donde se requiere un aparato exhaustivo de documentación para la rendición de cuentas. Fuera de estos contextos, en los espacios de innovación, investigación y desarrollo de producto, en el marketing y en la construcción de software, la vida no es así.

A este alineamiento entre alcance, tiempo y coste se le ha llamado el “triángulo de hierro”. Advierte el profesor Aaron Shenhar que esta obsesión de la disciplina con el triángulo perfecto no ha ayudado a las empresas: “Enfocados en el tiempo, el presupuesto y el alcance como los rígidos indicadores del éxito, se ha perdido el foco principal: que los proyectos se ponen en marcha por razones de negocio”. En la actualidad, hay que entender el triángulo de hierro como un sistema en un equilibrio inestable y complejo, que coloca el valor en el centro (ver el cuadro 2).

 

 

Y aquí aparece la agilidad. Los llamados “métodos adaptativos” ya son la corriente general. La gestión de proyectos adaptativa acepta y convive con la incertidumbre, el cambio y el error; planifica y entrega en fases y partes más pequeñas, mediante ciclos cortos e iteraciones; mantiene una comunicación continua con usuarios muy activos; los procesos de decisión son más participativos, y los criterios de éxito se fundan en el valor creado. Importa lo que la empresa y el usuario podrán hacer o harán mejor con el producto, más que el cumplimiento en tiempo y coste de una determinada funcionalidad y su documentación exhaustiva. Un proyecto imprescindible se organiza solo mediante las actividades imprescindibles para proporcionar ese valor. Lo demás es caro y es desperdicio. Se podría llamar a este enfoque la “gestión imprescindible de proyectos imprescindibles”.

Según el State of Agile Report, más de la mitad de las empresas utilizan alguna forma de agilidad en sus proyectos de desarrollo de software, siendo scrum el método más extendido. Según el Chaos Report de 2020, los proyectos ágiles son hasta cinco veces más exitosos que los proyectos tradicionales, ya que terminan antes (o, al menos, las reglas son claras y se sabe mejor cómo terminan), son más baratos, producen más y mejores resultados con relación a la inversión, se ganan la confianza de los clientes y la satisfacción de los desarrolladores. Además, van mejor con equipos y proyectos no muy grandes y que no requieran un gran número de interdependencias o integración con otros proyectos o con aplicaciones heredadas.

Por eso los métodos adaptativos son el entorno ideal para proyectos que, en realidad, son mejoras y evoluciones de un producto existente. Sin embargo, pueden generar dudas en proyectos muy grandes y complejos (excepto en las empresas que ya nacieron ágiles y digitales), aunque casi siempre se pueden trocear. Tampoco es fácil disponer de los nuevos roles y los equipos formados y dedicados que pide este modelo, ni cambiar la cultura y la forma de trabajar propia y de los proveedores.

 

Proyectos híbridos

Es responsabilidad de la dirección entender el tipo de problema de negocio y decidir o ayudar a decidir qué clase de enfoque es el más adecuado. Las tendencias actuales se inclinan hacia métodos híbridos y contingentes, adaptados a cada problema y contexto organizativo.

En los últimos años, varios autores y practicantes han propuesto enfoques de contingencia para la gestión de proyectos. Robert Wysocki es el autor que mejor ha establecido un modelo para entender y ayudar a decidir sobre el modo de gestión de un proyecto y una metodología híbrida para manejar proyectos complejos. En su enfoque (ver el cuadro 3), los dos factores que mejor predicen el tipo de proyecto son el nivel de claridad y certidumbre que tenemos tanto sobre el problema como sobre la solución (la tecnología disponible). A este análisis inicial, para refinar la decisión, se suman otros factores de contexto organizativo y el nivel de madurez de la cultura de proyectos en la empresa.

 

 

Cuanto más claro es el objetivo, más poderoso y activo es el sponsor, más conocidos los productos y las herramientas, más pasivos son los usuarios y más estables son el mercado y la cultura de la empresa, más sentido tienen los métodos directivos, predictivos o estructurados. En esta clase de enfoque, la preparación, la planificación, la documentación y el control son claves para reducir los cambios y evitar (o manejar con mano de hierro) las desviaciones de alcance, tiempo y coste. Por ejemplo, los sistemas de telecomunicaciones o los paquetes de gestión integrados (ERP, CRM) suelen ser proyectos bastante predictivos.

Cuanto más ocurra lo contrario, al menos en su primera versión, o más dudosas y abiertas sean las definiciones de todo lo anterior y mayor el riesgo, más aconsejables serán las aproximaciones adaptativas:

• En un proyecto ágil, el problema está bien definido, aunque los requisitos pueden cambiar y la solución no es conocida.

• En los proyectos extremos, propios de la investigación y desarrollo, problema y solución no están definidos con claridad y el riesgo es alto. No hay triángulo de hierro, todo está abierto. Para conseguir el resultado y limitar el riesgo, los equipos trabajan en modo exploratorio en ciclos cortos. Después de cada ciclo se decide si seguir o abandonar.

• En los proyectos que yo traduzco como proyectos invertidos (Wysocki los llama “emertxe”, invirtiendo las letras de “extreme”) tenemos la “solución” (la tecnología a nuestra disposición), pero no sabemos cómo usarla, como nos sucede en la actualidad con la inteligencia artificial. Estos proyectos son también exploratorios, pero el producto son casos de uso elaborados por un equipo capaz de diseñar de forma creativa y pruebas de concepto para hacer experimentos.

En ingeniería del software, los métodos predictivos se relacionan con el desarrollo en cascada, lineal o secuencial, a partir de una definición inicial de los requisitos muy detallada. Por su parte, los métodos adaptativos se relacionan con modelos de desarrollo basados en ciclos e iteraciones más o menos largos (el estándar es de dos a tres semanas).

En la práctica, los modelos suelen moverse en un continuo: en un proyecto tradicional, por ejemplo, puedes producir prototipos y soluciones parciales sobre las que el cliente se pronuncia con cierta frecuencia; en un proyecto adaptativo, puedes establecer ciclos largos de versiones que se parecen a un proyecto tradicional.

Por eso, en las metodologías híbridas, el marco general de gestión no es muy distinto del que usamos en los proyectos tradicionales y que
está bien codificado por el Project Management Institute, PRINCE2 o PM2. Existen unas fases o procesos de gestión definidos: el ciclo de aprobación-iniciación-planificación-ejecución-cierre. Y unas áreas de conocimiento experto o dimensiones del proyecto: los riesgos, la calidad, la comunicación, la relación con los interesados, la gestión económica o de personas, los contratos, etc.

La mayor diferencia se produce, como es lógico, en el nivel de detalle de la definición de requisitos y en la planificación y ejecución del proyecto. La planificación es un marco general que determina el número y duración de las versiones y ciclos, lo que podríamos llamar una hoja de ruta. En cada ciclo, los equipos establecen su planificación detallada y los resultados a obtener. La fase de ejecución tiene su propia colección de artefactos y ceremonias de gestión (el backlog, las reuniones cortas diarias, las retrospectivas o los papelitos pegados en una pizarra). Una vez completado el ciclo, se revisa la planificación general, si procede, y se planifican los ciclos siguientes. La ejecución, que siempre fue el agujero negro de los métodos predictivos, ahora manda.

Esta clase de enfoque híbrido permite a la empresa disponer de un lenguaje compartido a alto nivel, que es común para cualquier proyecto, y una caja de herramientas operativas que se pueden escoger y aplicar a diferentes tipos de proyectos. Es un instrumento de gobierno.

Para manejar programas y portafolios medianos y grandes de proyectos complejos, en los últimos años han surgido métodos que permiten escalar la agilidad, es decir, coordinar las interdependencias y sincronizar los entregables. Uno de los más conocidos es SAFe (Scaled Agile Framework), que incluye mecanismos económicos de priorización continuada, un aparato de gobierno y toma de decisiones y una caja de herramientas ágiles y lean, como scrum y kanban.

SAFe y similares facilitan la gestión de cualquier tipo de demanda (lo nuevo, lo evolutivo o lo incidental) contra cualquier tipo de oferta (lo que se hace ágil, en cascada o la gestión de servicios bajo diferentes métodos) y tienen presente la limitación de capacidad (uno de los problemas habituales de aceptar demasiados proyectos).

 

Reinventando la gestión de proyectos

A continuación, propongo una agenda directiva para reinventar la gestión de proyectos, ya que las empresas necesitan hacer cambios en sus métodos, organización y mecanismos de selección y asignación de recursos y líderes.

1. Gobierno directivo. El comité de dirección, una parte de ese comité o un órgano delegado tienen que decidir de forma transparente qué proyectos se hacen y por qué, qué resultados se obtendrán y cómo se medirá el éxito. Y deben decidir periódicamente qué proyectos deben continuar y cuáles no. Algunas empresas que trabajan por proyectos tienen un primer directivo (Chief Project Officer) para preparar estas decisiones, asegurar la ejecución, coordinar la asignación de recursos de diferentes áreas y proporcionar método y soporte a los equipos. Pero el rol verdaderamente crítico es el sponsor, o patrocinador, del proyecto, quien comprende y defiende cada proyecto, asigna los recursos adecuados, supervisa a los líderes funcionales y técnicos y tiene que explicar a la alta dirección el éxito y el fracaso. Normalmente, el sponsor es un miembro del comité de dirección de la compañía.

2. Cultura de proyecto, agilidad por defecto. Solemos entender la cultura como un conjunto de convenciones suaves que representan los valores y la forma de ser de la empresa. Eso está bien. Pero para que esto ocurra se requiere un conjunto de estructuras, procesos e incentivos que facilitan que los directivos y empleados actúen de una manera y no de otra. Una cultura de proyecto establece roles y responsabilidades claras sobre el gobierno y la gestión de los proyectos, dispone de métodos y procesos de gestión conocidos y encuentra y premia a los líderes y los equipos capaces de diseñar y ejecutar proyectos de éxito. Además, los métodos ágiles de gestión de proyectos fomentan el trabajo en equipo y la colaboración entre negocio e informática sobre unos valores compartidos: orientación al valor, responsabilidad, transparencia, calidad, colaboración y foco en la ejecución. Se trata de cocrear, codirigir y coproducir.

3. Nuevos roles y responsabilidades. Por debajo del sponsor, los roles más importantes son el responsable de producto (product owner), el responsable funcional (el que sabe qué se necesita hacer) y el responsable del proceso (el que sabe cómo hay que hacerlo, un facilitador o un scrum master). Los jefes de proyecto siguen siendo importantes, pero en las organizaciones ágiles cualquier mánager puede serlo ocasionalmente. Estos roles dirigen los equipos responsables de producir colaborativamente el proyecto (idealmente en el mismo espacio físico) y de incorporar recursos expertos adicionales (técnicos o funcionales) cuando se necesitan. Lo mejor que puede hacer la dirección es retirarse lo máximo posible, fuera de los puntos de control de ciclo y producto. Hay que reducir reuniones, comités de dirección y documentación.

4. “Nuestro” método. Aunque se decida que el modo de trabajo por defecto para los equipos sea ágil, seguirá habiendo proyectos tradicionales y otros más complejos. Cada empresa necesita construir una metodología propia y práctica para las características de cada proyecto y su cultura y estilo de gestión, su propio manual. He sugerido un enfoque híbrido, con un marco de trabajo a alto nivel, que sea común para cualquier proyecto, y una caja de herramientas operativas que se pueden escoger y aplicar a diferentes tipos de proyectos. La oficina de proyectos es la responsable de los métodos y el soporte a los proyectos. Normalmente, son oficinas hands-off, sin responsabilidad ejecutiva. A veces, pueden incorporar un grupo de jefes de proyecto profesionales que se asignan a proyectos más complejos (hands-on, con responsabilidad sobre los resultados). La dirección, con el apoyo de la oficina de proyectos, necesita decidir cuál es el método de gestión más apropiado para cada proyecto o sus partes.

5. Espacio para aprender. La gestión de proyectos es un formidable espacio de aprendizaje organizativo, que normalmente desaprovechamos. Al final de cada proyecto, los participantes deberían conversar para extraer las lecciones aprendidas y crear un repositorio de experiencias de las cuales se pueden beneficiar los proyectos futuros. A veces, empresas externas pueden proveer formación, entrenamiento y soporte temporal cuando faltan capacidades internas. Algunas organizaciones profesionales (Project Management Institute, PRINCE2, Internacional Scrum Institute o SAFe) proporcionan marcos de trabajo y certificaciones de práctica. Hasta hace poco, estos certificados eran una condición para hacer una carrera como jefe de proyecto; ahora son una capacidad adicional para muchos directivos de cualquier función.

6. Agilidad empresarial. El uso cada vez mayor de la agilidad en la informática y otras funciones de la empresa, como marketing o desarrollo de producto, y sus experiencias de éxito están impulsando un movimiento para extender la cultura y la organización ágil en toda la empresa y convertir los métodos ágiles en la manera natural de trabajar. Excepto las empresas nacidas digitales, las organizaciones que emprenden ese camino lo hacen con cautela y reduciendo el riesgo: identifican oportunidades, equipos maduros y proyectos de transformación sobre los cuales crecer paso a paso. Otros eligen organizaciones duales (la empresa tradicional y la ágil) o financian iniciativas fuera de la empresa matriz, como si fueran una apuesta de capital riesgo. La ambición es grande, el camino es prudente. El aprendizaje obtenido en proyectos de TI puede ser extendido y aprovechado en toda la empresa.