Foto de Gabriel Sollmann en Unsplash

¿Consciente o inconscientemente?

En realidad, no hay nada peor para las partes interesadas, como los clientes o los consumidores, que no sepan qué está pasando en el proyecto, cuál es el estado actual y cómo van las cosas, o que se hable mucho de ellas y no haya posibilidad de verificar lo que se ha conseguido.

Sólo en contadas ocasiones veo proyectos que se mantienen deliberadamente en secreto durante un determinado periodo de tiempo. Puede elegirse en proyectos de reestructuración en los que se estudian diferentes escenarios y el secreto pretende evitar temporalmente confusiones y rumores innecesarios en la organización. Pero ten cuidado, no puedes no comunicarte. Incluso ahí, un mínimo de transparencia es útil. En muchos casos, surgen más rumores cuando algo es secreto.

Además, hay proyectos en los que la transparencia se mantiene deliberadamente baja para que no haya un supuesto control "externo" y una dirección externa. Personalmente, no creo que sea una buena idea. Porque los proyectos no son un fin en sí mismos, sino que están hechos para clientes y consumidores con los que hay que mantener una comunicación de confianza. Y la transparencia genera confianza. En la gran mayoría de los proyectos, la falta de transparencia no es un acto consciente, sino una consecuencia de la complejidad y el ritmo frenético del proyecto; en muchos casos es también un signo de cierta sobrecarga de tiempo o técnica. La transparencia no falta del todo, pero suele ser insuficiente.

¿Cómo puedo crear transparencia?

El problema de la falta o insuficiencia de transparencia es la complejidad en un proyecto. Todo está conectado de alguna manera. Por ejemplo, si una decisión necesaria en el comité de dirección del proyecto no se toma en un plazo determinado, se producen retrasos en el proyecto. Los retrasos repercuten en la disponibilidad del personal, y es posible que el personal nuevo tenga que sustituir al existente, lo que supone un trabajo adicional. Si no se dispone de un sustituto interno, hay que recurrir a especialistas externos, lo que supone costes adicionales de compra e integración, que a su vez conllevan costes adicionales en el proyecto. Las dependencias son muy grandes en un proyecto y pueden dar lugar a toda una serie de problemas.

La transparencia se crea principalmente con el uso de estructuras (también llamadas estructuras de proyecto o estructuras de desglose del trabajo EDT). Me parece que las estructuras han pasado a un segundo plano, especialmente en el mundo ágil, aunque Scrum, SAFe y compañía también utilizan estructuras claras. Las estructuras reducen la complejidad y se centran en un tema más pequeño. Por eso los libros de las bibliotecas, por ejemplo, no sólo están ordenados alfabéticamente, sino también por temas. Las estructuras pueden presentarse de forma jerárquica, así como en forma de matrices y redes, y completarse con agrupaciones y relaciones. En este contexto, las estructuras no son una división o escisión del proyecto, lo cual no es posible debido a la coherencia y las dependencias internas del proyecto mencionadas anteriormente. Las estructuras son formas de ver y asignar el proyecto.

Recomiendo no reinventar la rueda, sino utilizar referencias probadas para las estructuras. Distingo entre gestión de proyectos (PM) y desarrollo de productos. Si no se especifica nada más, yo personalmente utilizo la metodología PMI PMBOK Guide para lo primero. Durante muchos años he utilizado las diez llamadas Áreas de Conocimiento como estructura principal. Con la última, la séptima edición de la Guía del PMBOK, estas Áreas de Conocimiento, junto con las fases del proyecto en 2021, se han transformado en Dominios de Desempeño del Proyecto, que me gustan aún más. Estos son:

• Partes interesadas
• Equipo
• Enfoque de desarrollo y ciclo de vida
• Planificación
• Trabajo del proyecto
• Entrega
• Medición
• Incertidumbre

Pero las antiguas áreas de conocimiento también siguen teniendo su justificación. Por supuesto, también pueden utilizarse estructuras de otros métodos de PM. Además del valor probado de un método, me da la certeza de que conseguiré tanto el equilibrio temático como la exhaustividad del proyecto con esta estructura. Con un método generalmente conocido, puedo suponer que los interesados también entienden y aceptan las estructuras.

En el proceso de desarrollo de productos, siempre utilizo primero la estructura de resultados (estructura del producto) en el sentido de la EDT y luego integro los pasos/tareas del proceso. De esta manera consigo un enfoque orientado a los resultados, en el que primero se define lo que hay que conseguir y luego cómo se puede conseguir. Desgraciadamente, todavía hay proyectos que se estructuran al revés, según las fases de desarrollo del proyecto (por ejemplo, diseño, construcción, prueba), lo que siempre genera problemas.

Básicamente, la estructura aplicada no debe ser en sí misma demasiado complicada, en el espíritu de Albert Einstein: "Tan simple como sea posible, pero no más simple".

¿Cómo se aplican estas estructuras?

Una vez que se ha encontrado y aplicado una estructura adecuada para el proyecto, éste se controla a través de ella. Sólo el uso constante y recurrente de la estructura en el proyecto conduce a la transparencia y familiarización deseadas, y crea confianza. A menudo observo que, aunque se hayan implantado estructuras, éstas se diluyen en el transcurso del proyecto, se añaden otras nuevas y se omiten otras. Esto conduce a una mezcla de estructuras diferentes, y la transparencia se resiente como resultado. Utilizo la estructura elegida (principal) siempre que es posible a lo largo del proyecto. Cada elemento estructural contiene numerosas subestructuras, que pueden adaptarse a necesidades específicas. En consecuencia, planifico y gestiono el proyecto según esta estructura, y me comunico en ella. Un informe mensual sobre el estado del proyecto, por ejemplo, está diseñado exactamente según esta estructura. La cabina del proyecto también tiene exactamente esta estructura.

Es aconsejable comprobar las estructuras después de la implantación y, posteriormente, de vez en cuando, para ver si realmente se entienden y aceptan, y si siguen ajustándose al proyecto, que también puede cambiar. Si es así, deben adaptarse dentro de la metodología. Sin embargo, esto no debe ocurrir con demasiada frecuencia ni en exceso, ya que las estructuras son un elemento fundamental del proyecto en el que los cambios pueden tener un gran impacto y confusión.

Esto supone bastante trabajo y esfuerzo para el gestor del proyecto, que desgraciadamente no siempre se percibe como tal desde el exterior. No surge de forma natural, y debe aplicarse y mantenerse de forma activa. Pero es una inversión muy buena y que merece la pena.

Las estructuras de los proyectos siempre van de la mano de los datos de los mismos. Todos los datos del proyecto deben estar alineados con la estructura, es decir, asignados a los elementos estructurales. Una herramienta de gestión de proyectos con una base de datos central es muy útil en este caso. Esto permite tener diferentes vistas de todo el proyecto y de todos los datos del mismo en cualquier momento. Cuando se utilizan documentos individuales (por ejemplo, para los costes, la programación o los recursos), la generación de vistas generales requiere mucho más tiempo, es ineficiente y a veces ni siquiera es posible. Por el contrario, una herramienta de PM de este tipo es mucho menos útil si no se almacena una estructura adecuada en el proyecto.

Conclusión

A pesar de las estructuras, sigue habiendo problemas en el proyecto y siempre los habrá. Sin embargo, gracias a la transparencia creada por las estructuras, se pueden detectar los problemas en una fase temprana, identificar las causas y, por tanto, tratarlas y resolverlas de forma sostenible. Como ya se ha dicho, la transparencia en el proyecto genera confianza entre las partes interesadas, dentro y fuera del proyecto. La confianza garantiza una cooperación mucho mejor y más constructiva, que también es más divertida para todos los implicados y, en última instancia, conduce a mejores resultados.