Sin embargo, antes de la siguiente reunión de seguimiento, el planificador sigue comprobando qué versión del cronograma es la actual. El responsable de costes compara el último forecast con los datos de avance. Los jefes de proyecto recurren a hojas de cálculo para determinar si los hitos importantes siguen siendo alcanzables.
Cuando todos consiguen ponerse de acuerdo sobre la situación actual, buena parte de la reunión ya se ha dedicado a discutir los datos en lugar de decidir qué hacer con ellos.
Mientras tanto, los riesgos relacionados con la planificación se hacen visibles cuando la holgura ya está desapareciendo. Los hitos empiezan a desplazarse. Los forecasts empeoran. Problemas que deberían haber provocado una actuación antes acaban llegando a escalación.
El software funciona. Entonces, ¿por qué la empresa sigue reaccionando tarde?
La distancia entre disponer de software de gestión de proyectos y conseguir realmente un mayor control es más habitual de lo que parece. Y rara vez empieza por una funcionalidad que falta en el software.
Objetivo: reforzar la tensión principal del artículo:
Software operativo ≠ Project Controls eficaz
El visual debe resumir el problema que el lector acaba de reconocer antes de explicar por qué ocurre.
Las expectativas que acompañan a una inversión en software de gestión de proyectos suelen estar claras.
Mayor visibilidad. Informes más consistentes. Alertas más tempranas. Una mejor coordinación entre planificación, riesgos y costes. En definitiva, mayor confianza sobre la dirección que siguen los proyectos y tiempo suficiente para intervenir cuando algo empieza a desviarse del plan.
Una implementación técnica satisfactoria crea las condiciones necesarias. Pero no genera automáticamente la forma de trabajar que debe acompañarla.
El sistema puede estar correctamente configurado. Los usuarios pueden haber recibido formación. Los datos pueden introducirse y los dashboards pueden generarse. Pero si los proyectos siguen gobernándose, analizándose y debatiéndose prácticamente igual que antes, es posible que la empresa simplemente haya trasladado su antigua forma de trabajar a una plataforma más avanzada.
Ahí puede aparecer una ilusión de control.
Tienes más información que antes, pero no necesariamente mejores criterios para decidir. Tienes dashboards, pero las decisiones siguen llegando tarde. Tienes datos de proyecto, pero los equipos continúan dedicando tiempo a determinar qué información pueden considerar fiable.
Un Project Controls eficaz empieza cuando esa información cambia lo que las personas hacen a continuación.
El software de gestión de proyectos puede proporcionar una gran cantidad de información. Puede dar soporte a la planificación, los riesgos, los costes, los recursos, los cambios y los informes.
Pero el software no puede decidir cómo debe responder tu empresa cuando algo cambia.
Imagina que un dashboard muestra que un hito importante se está desplazando. ¿Qué ocurre a continuación?
¿Alguien entiende qué está provocando ese cambio? ¿Se conoce su posible impacto sobre los costes o los riesgos? ¿Hay una persona responsable de investigarlo? ¿Existe un punto acordado a partir del cual el problema debe escalarse? ¿Y confía el equipo lo suficiente en la información como para actuar?
Si resulta difícil responder a estas preguntas, el problema ya no consiste simplemente en determinar si el software funciona.
La cuestión es cómo funcionan a su alrededor los procesos, las responsabilidades, la información y la toma de decisiones.
Esta diferencia es importante porque Project Controls no es simplemente un conjunto de sistemas e informes. Es la forma en que una empresa utiliza la información para comprender el rendimiento de sus proyectos, identificar desviaciones y tomar decisiones con suficiente antelación para poder influir en el resultado.
Las señales de que Project Controls todavía no forma parte de la manera en que la empresa dirige sus proyectos suelen aparecer en el trabajo diario.
No es necesario que se produzcan todos los problemas a la vez. Unos pocos síntomas recurrentes ya pueden indicar que la causa va más allá de la configuración del software.
Los cronogramas se actualizan, los riesgos se registran y los dashboards se generan. Sin embargo, los equipos siguen dedicando mucho tiempo a interpretar qué significa realmente la información antes de poder decidir qué hacer.
Una señal de alerta puede ser visible en los datos. Pero si las responsabilidades, los umbrales o las acciones posteriores no están claramente definidos, esa alerta no se traduce automáticamente en una intervención.
La empresa informa sobre el rendimiento, pero eso no significa necesariamente que lo utilice para dirigir el proyecto.
Cuando aumenta la presión, suelen reaparecer soluciones conocidas.
Un planificador mantiene una hoja de cálculo adicional. Un jefe de proyecto crea su propio resumen. Diferentes proyectos utilizan estructuras, definiciones o ciclos de reporting ligeramente distintos.
Cada solución puede resolver una necesidad inmediata. En conjunto, sin embargo, dificultan la comparación entre proyectos, reducen la confianza en la información consolidada y complican la comprensión del rendimiento de todo el porfolio.
La planificación, los riesgos, los costes, los recursos y los cambios pueden gestionarse profesionalmente dentro de sus respectivas disciplinas. El problema aparece cuando esas disciplinas no están suficientemente conectadas.
Un cronograma puede mostrar presión sobre un hito mientras el riesgo relacionado se gestiona en otro lugar. Un cambio en el forecast puede debatirse sin establecer una relación clara con el avance o el rendimiento del cronograma.
Cada equipo ve una parte del proyecto. La empresa todavía tiene que unir esas perspectivas antes de poder comprender el impacto completo.
Estas situaciones no significan necesariamente que el software esté fallando. Indican que el siguiente reto está en cómo se integra Project Controls alrededor de la tecnología.
Cuando las empresas reconocen estos síntomas, la reacción natural suele ser volver a mirar la tecnología.
¿Necesitamos otro dashboard? ¿Más formación? ¿Otra integración? ¿Deberíamos utilizar más funcionalidades de las que ya tenemos disponibles?
Todas ellas pueden ser acciones útiles, pero deberían llegar después de una conversación más fundamental.
Empieza planteando tres preguntas:
Estas preguntas trasladan la conversación desde el simple uso del software hacia la forma en que Project Controls funciona en toda la empresa.
Es también donde se hace más evidente la diferencia entre una implementación técnicamente satisfactoria y un Project Controls sostenible.
La puesta en marcha sigue siendo un hito importante. Pero no es el momento en el que termina el trabajo.
El verdadero valor del software de gestión de proyectos aparece cuando las personas pueden confiar en la información que tienen delante, comprender lo que significa y responder antes de que una desviación se convierta en una escalación.
Eso requiere tecnología, pero también alineación alrededor de esa tecnología.
Cuando esa alineación no existe, las empresas pueden invertir mucho tiempo en mejorar informes, configuraciones o procesos individuales sin abordar la causa fundamental por la que Project Controls sigue siendo reactivo.
Y eso plantea una pregunta importante:
Si el problema no es el software, ¿dónde deberías centrarte ahora?
Reconocer el problema es una cosa. Entender dónde se origina dentro de tu empresa, qué camino seguir y qué mejorar primero es bastante más difícil.
Ahí es donde continúa nuestro white paper Tienes el software, pero no los resultados.
Analiza las causas organizativas recurrentes por las que Project Controls se estanca después de la implementación, las diferentes respuestas que adoptan las empresas cuando los resultados esperados no llegan y un camino práctico hacia un Project Controls más maduro y proactivo.
Si tu software ya está operativo, pero los equipos siguen conciliando información, creando soluciones alternativas o reaccionando más tarde de lo necesario, este es el siguiente paso.