← Todos los artículos

Por qué los beneficios desaparecen tras la puesta en marcha — y cómo conservarlos

By XNM Technologies · September 6, 2021 · 4 min read
Por qué los beneficios desaparecen tras la puesta en marcha — y cómo conservarlos

Lo más difícil de un proyecto no es el lanzamiento. Es todo lo que viene después. Un sistema nuevo entra en funcionamiento, se corta la cinta, el equipo de proyecto se disuelve — y un año más tarde nadie puede decir si la cosa realmente valió la pena. Se cumplió el cronograma, se mantuvo el presupuesto, y sin embargo los ahorros prometidos, el servicio más rápido o los registros más limpios nunca llegaron a materializarse. Este es el modo de fracaso silencioso de la entrega de proyectos, y no tiene nada que ver con lo bien que salió la construcción.

La realización de beneficios es la disciplina de asegurar que el valor previsto de un proyecto se logre y se mantenga realmente después de su puesta en marcha. Se volvió más difícil durante la recuperación de la pandemia: los equipos estaban sobrecargados, el trabajo híbrido dispersaba a las personas que debían adoptar el cambio, y las interrupciones de suministro seguían desviando la atención hacia apagar incendios. En ese entorno era fácil celebrar la puesta en marcha y seguir adelante. Los equipos que salieron adelante fueron los que trataron la puesta en marcha como un punto intermedio, no como la línea de meta.

Los errores que destruyen el valor en silencio

  1. Tratar la puesta en marcha como el final. El caso de beneficios se decide en los meses posteriores al lanzamiento, cuando las personas cambian su forma de trabajar. Si el proyecto se cierra y el equipo se dispersa el día en que el sistema arranca, nadie es dueño del resultado que el proyecto debía entregar.

  2. No medir nunca el punto de partida. Si no mediste el tiempo de ciclo, la tasa de error o el costo por transacción antes del cambio, no puedes demostrar la mejora después. Afirmaciones vagas como «parece más rápido» no sobreviven a una revisión presupuestaria.

  3. Confundir productos con resultados. Entregar el sistema es un producto. Menos aprobaciones tardías, menos retrabajos, informes más rápidos — esos son resultados. Los patrocinadores financian resultados, pero los equipos reportan productos, y en esa brecha mueren los beneficios.

  4. Ningún responsable nombrado por cada beneficio. Un beneficio sin responsable es un beneficio que nadie persigue. Cada meta necesita un responsable de negocio — no el jefe de proyecto — rendidor de cuentas de lograrla mucho después del cierre del proyecto.

  5. Ignorar la adopción. Una herramienta que la gente evita silenciosamente no aporta ningún valor, por muy limpio que haya sido el despliegue. Si la mitad del personal conserva su antigua hoja de cálculo, el beneficio está medio perdido — y a los equipos híbridos es especialmente fácil perderles la pista.

  6. Contar el beneficio una vez y marcharse. El valor se erosiona. Los atajos vuelven, el personal cambia y la configuración se desvía. Un beneficio medido al tercer mes puede haber desaparecido al duodécimo si nadie vigila.

Cómo conservar realmente el valor

Nada de esto requiere una nueva metodología pesada. Requiere decidir, antes de construir nada, cómo sabrás que el proyecto funcionó — y asignar a alguien que se ocupe de ello una vez que el equipo se haya ido.

  • Redacta un mapa de beneficios de una página antes de la aprobación: cada beneficio, su medida, su punto de partida, su fecha objetivo y su responsable nombrado.

  • Captura el punto de partida mientras aún puedes — normalmente durante el descubrimiento, antes de que la antigua forma de trabajar desaparezca.

  • Programa una revisión de beneficios a los 3, 6 y 12 meses tras la puesta en marcha, con el patrocinador en la sala, no solo el equipo de proyecto.

  • Sigue la adopción como indicador adelantado: uso, tasas de excepción y cuántas personas siguen haciéndolo a la antigua.

  • Reserva un pequeño presupuesto y un responsable nombrado para los ajustes posteriores a la puesta en marcha — el valor se realiza con el uso, no con el despliegue.

El cambio de mentalidad es simple, pero poco común. Un proyecto no está terminado cuando el sistema funciona. Está terminado cuando la organización está demostrablemente mejor y puede probarlo. Esa prueba es lo que te permite defender la próxima inversión — y lo que distingue un proyecto que se entregó de un proyecto que importó.

Si tu organización lanza proyectos una y otra vez sin confirmar nunca si valieron la pena, la asesoría de entrega de programas y proyectos de XNM puede ayudarte a integrar la realización de beneficios en la entrega desde el principio.