No es lo mismo ENTREGAR un proyecto que ADOPTAR un proyecto
Actualizado: 4 nov
«El éxito no se mide por lo que construyes, sino por lo que realmente funciona.»
Resulta muy común ver cómo se hacen proyectos que se desarrollan, pero luego nadie los usa. Esto es especialmente común en proyectos digitales, formas de trabajo o cambios culturales. Ahora se ve con IA.
El problema es simple de identificar: se generan entregables (como software, un tablero Kanban o un listado de valores) pero no se generan los nuevos comportamientos donde se usan esos entregables.
¿Te ha pasado?
La ilusión del proyecto exitoso
Durante años creí que un buen project manager se medía por entregar proyectos a tiempo y dentro del presupuesto.
Incluso muchos cursos y métodos son gestión de proyectos son diseñados así: cronogramas perfectos, riesgos controlados, stakeholders firmando actas de cierre. Y por allí, en algún lugar rezagado, se menciona que más allá de los outputs, hay unos outcomes, un «value delivery» y un impacto en el negocio. Se menciona la gestión del cambio como si de algo ligero se tratara, (junto a los power skills… lo que da para otro artículo).
Pero es que entregar un proyecto no significa que funcione.
Puedes tener el mejor sistema del mundo, el desarrollo más ágil, la capacitación más completa… y aún así fracasar si las personas no abrazan el cambio. Y es que los proyectos son los vehículos del cambio: y si los proyectos no están generando esos cambios deseables pues… ¿para qué se han hecho entonces?
A veces sospecho de managers que tienen objetivos donde se les mide el «presupuesto gastado en proyectos e iniciativas», un hambre de «hacer cosas» o simplemente desconocimiento de la conexión que debe haber entre un proyecto y el cambio que busca generar. O puede ser la comodidad de medir solo lo fácil.
¿Cuál es la diferencia real?
ENTREGAR es cumplir con el plan. Es medible, predecible.
ADOPTAR es cambiar comportamientos humanos. Es emocional, complejo, impredecible. Podemos saber cuánto tiempo tardamos en desarrollar una nueva herramienta, pero no cuánto tiempo tardará la gente en aprender a usarla y realmente integrarla en su business as usual.
ENTREGAR pregunta: «¿Terminamos lo que prometimos?»
ADOPTAR pregunta: «¿La gente realmente cambió su forma de trabajar?». Adoptar requiere quitarnos nuestros sesgos y dejar a un lado nuestro ego para de verdad escuchar y observar el impacto. Un ejercicio emocional más difícil que evaluar si la entrega cumplió o no.
ENTREGAR mide outputs: funcionalidades desarrolladas, usuarios entrenados, sistemas en producción…
ADOPTAR mide outcomes: procesos más eficientes, decisiones más rápidas, clientes más satisfechos. Se enfoca más en la eficacia y en resolver los problemas.
La diferencia no es sutil. Es abismal.
Por qué fallamos tanto en adopción
Creemos que la resistencia al cambio es el problema. Pero no lo es.
El problema es que tratamos a las personas como si fueran parte del sistema técnico. «Si les explico los beneficios, van a adoptar.» «Si los capacito bien, van a usar la herramienta.» «Si les doy incentivos, van a cambiar.»
Pero las personas no funcionamos así.
Las personas adoptamos los cambios cuando:
Entendemos el para qué personal, no solo el corporativo
Sentimos que el cambio realmente mejora lo anterior
Experimentamos mejoras desde el primer día
Nos sentimos parte de la solución, no víctimas del cambio.
Confiamos en el liderazgo
Y nada de esto aparece en los planes de proyecto tradicionales.
Entregar sin adoptar es costoso
Los números son brutales:
70% de las transformaciones digitales fallan
60% de los sistemas implementados tienen menos del 50% de adopción real
Pero el costo emocional es peor:
Empleados escépticos que ya no creen en los «próximos proyectos»
Líderes que pierden credibilidad
Organizaciones que se vuelven alérgicas al cambio
Costes de oportunidad gigantes, al haber podido destinar los recursos a otra cosa.
Priorizar la adopción
En mi experiencia, los proyectos que realmente transforman organizaciones hacen estas cosas diferente:
Empiezan con el final en mente: No «¿qué vamos a construir?» sino «¿cómo va a ser un día típico cuando esto funcione realmente?»
Involucran a usuarios y stakeholders desde el día cero: no como consultados sino como co-diseñadores de su propia transformación. Esto el enfoque ágil lo aborda muy bien.
Miden valor, no cumplimiento: KPIs de negocio, no KPIs de proyecto.
Celebran cambios de comportamiento: celebrando casos de éxito genuinos.
La adopción no es un «nice to have» que agregas al final del proyecto. ¡Es el proyecto! ¿Y sabes cuál es la disciplina que te aporta estructura y guía para esto? ¡El Change Management!
Antes de tu próximo proyecto, hazte esta pregunta: ¿estoy diseñando para entregar o para adoptar?
Claudia Salas Bozich
Comentarios