Si nadie en su organización puede responder con certeza quién es el dueño del resultado de su proyecto, probablemente la pregunta no es cómo hacerle seguimiento, sino quién lo está gerenciando.

Casi todos los proyectos de tecnología arrancan con optimismo. Hay un presupuesto aprobado, un proveedor seleccionado, un cronograma que cabe en una diapositiva y un equipo con ganas de empezar.
Unos meses después, la conversación suele ser otra: el cronograma se movió, el presupuesto ya no alcanza, el proveedor dice que el retraso es del cliente y el cliente dice que es del proveedor. Y cuando alguien pregunta quién responde por el resultado, la respuesta no es clara.
En mi experiencia, esa pregunta es la que define si un proyecto necesita una gerencia de proyectos distinta a la que tiene. No se trata de cuántas herramientas de seguimiento se usen, sino de quién tiene la responsabilidad real de que el proyecto cumpla lo que prometió.
La gerencia de proyectos es la planeación, dirección, control y ejecución de una iniciativa para que cumpla con el tiempo, el costo, el alcance y la calidad acordados. Es una disciplina con marcos reconocidos, como la guía del PMBOK, y con un objetivo muy concreto: convertir una decisión del negocio en un resultado entregado.
Con frecuencia se habla indistintamente de gerencia de proyectos y de gestión de proyectos. En la práctica son sinónimos. Si hay un matiz, es que la palabra gerencia pone el acento en la dirección y en la responsabilidad sobre el resultado, no solo en la administración de tareas.
Esa diferencia importa. Un proyecto puede tener un cronograma impecable, reuniones semanales y reportes bien diseñados, y aun así no tener a nadie que tome las decisiones difíciles cuando algo se desvía.
No todos los proyectos necesitan una PMO externa. Pero hay señales que se repiten en los que sí la necesitan.
La primera: nadie responde por el resultado completo. El proveedor responde por su parte, cada área responde por la suya y el proyecto, como un todo, no tiene dueño.
La segunda: los reportes dicen que todo va bien hasta que, de repente, todo va mal. Cuando el semáforo pasa de verde a rojo sin haber pasado por amarillo, el problema no es el proyecto, es la forma en que se está midiendo.
La tercera: el proveedor se está gerenciando a sí mismo. Es natural que un implementador defienda su alcance, sus tiempos y sus costos. Lo que no es sano es que sea también quien decide si lo está haciendo bien.
La cuarta: el equipo interno tiene doble función. Las personas clave del proyecto siguen respondiendo por la operación diaria, y el proyecto termina recibiendo el tiempo que sobra.
La quinta: es la primera vez que la organización ejecuta un proyecto de este tamaño. Una implementación de ERP, una migración a la nube o una iniciativa de inteligencia artificial no se parecen a los proyectos que la empresa hace todos los años, y los errores de un primer proyecto suelen ser los más costosos.
Asumimos el gobierno del proyecto con responsabilidad real sobre el resultado, desde el kickoff hasta la estabilización después del go-live.

Una PMO, u oficina de gestión de proyectos, es la estructura que define cómo se gobiernan los proyectos de una organización: metodología, roles, comités, indicadores y herramientas.
Una PMO interna tiene sentido cuando la empresa ejecuta proyectos de forma permanente y tiene el volumen para sostener un equipo dedicado. Construirla toma tiempo, y mantenerla tiene un costo fijo.
Una PMO externa, o PMO as a Service, es un equipo que asume el gobierno de un proyecto puntual con responsabilidad sobre el resultado, y se desmonta cuando el proyecto termina. Es la opción más frecuente para iniciativas grandes que no se repiten cada año, como la implementación de un ERP.
La pregunta no es si su empresa necesita una PMO. Es quién va a responder por el resultado de este proyecto en particular.
Un plan integral antes de empezar: alcance, cronograma, recursos, roles, costos, riesgos y plan de calidad, aprobados por un comité de dirección que entienda lo que está aprobando.
Un gobierno claro: quién decide qué, en qué instancia y con qué información. Un proyecto sin reglas de decisión termina resolviendo sus problemas por desgaste.
Un seguimiento continuo del riesgo, no solo un reporte al cierre de cada fase. Hoy es posible monitorear el riesgo del proyecto de forma permanente, incluso con agentes de inteligencia artificial que anticipan desviaciones antes de que se conviertan en crisis.
Un control del alcance que proteja el presupuesto. En un proyecto que gerenciamos bajo los lineamientos del PMBOK, el cierre llegó con una diferencia de solo 3% frente al costo estimado y con apenas dos personalizaciones al código del ERP. No es casualidad: es el resultado de decir que no a tiempo.
Un cierre formal y documentado, que deje a la organización con el modelo de implementación para sus próximos proyectos.
Integramos la gestión del cambio a la ejecución para que el proyecto se mida por la adopción, no solo por el go-live.

Un proyecto puede terminar a tiempo, dentro del presupuesto y con todo el alcance entregado, y aun así fracasar. Ocurre cuando el sistema queda instalado pero la organización sigue trabajando como antes.
Por eso creo que una gerencia de proyectos que no incluye la gestión del cambio está midiendo el éxito equivocado. Los servicios de gestión del cambio tienen que empezar el mismo día que el proyecto, no aparecer como una actividad de cierre.
Escribí sobre esto en detalle en por qué fracasan los proyectos de transformación digital: la mayoría no falla por la tecnología, sino por la forma en que las personas la reciben.
Hay proyectos que ninguna gerencia puede salvar, porque el problema no está en la ejecución sino en la decisión que les dio origen: un objetivo difuso, un caso de negocio que nadie construyó o una tecnología elegida antes de entender el problema.
Por eso, en los proyectos de mayor impacto, vale la pena empezar con una consultoría estratégica que defina qué hay que resolver, en qué orden y con qué indicadores. La gerencia de proyectos ejecuta mejor cuando sabe exactamente qué está ejecutando.
Pregunte quién va a responder por el resultado, no solo quién va a hacer el seguimiento.
Pregunte cómo se va a medir el riesgo y con qué frecuencia. Si la respuesta es un informe mensual, el riesgo se va a detectar tarde.
Pregunte qué relación comercial tiene con el proveedor de la tecnología. Una gerencia que depende del implementador difícilmente va a poder exigirle.
Pregunte cómo va a trabajar la adopción, no solo la instalación.
Y pregunte por proyectos anteriores con resultados verificables: tiempo, costo, alcance y, sobre todo, qué pasó después del go-live.
Una buena gerencia de proyectos no se nota por la cantidad de reportes que produce, sino por la cantidad de problemas que evita. Si su próximo proyecto es grande, nuevo para la organización o crítico para el negocio, vale la pena preguntarse quién va a responder por él.
En Cyrrus prestamos servicios de gerencia de proyectos como PMO externa, con responsabilidad sobre el resultado y con la gestión del cambio integrada desde el inicio.

Cuéntenos el reto de su organización. Coordinamos una conversación con el equipo indicado y le decimos con franqueza si podemos ayudar.