Un proyecto tecnológico puede estar perfectamente definido.
Puede tener alcance, presupuesto, hitos, responsables, arquitectura, integraciones y un calendario detallado.
Y aun así, una parte importante de la organización puede no entender realmente qué está ocurriendo.
No porque falte información.
Sino porque información y significado no son lo mismo.
En muchos procesos de transformación se comunica el proyecto desde dentro del propio proyecto.
Se habla de fases, entregables, funcionalidades, fechas, versiones, incidencias o dependencias.
Todo ello es necesario para gestionarlo.
Pero no siempre sirve para explicarlo.
La organización necesita algo diferente.
Necesita entender qué problema se está intentando resolver, por qué se ha elegido ese camino, qué va a cambiar y qué relación tiene todo ello con su realidad.
En otras palabras, necesita una historia que pueda comprender.
Un proyecto y una transformación no se cuentan de la misma manera
La gestión de proyectos necesita precisión.
Qué se entrega.
Cuándo.
Con qué recursos.
Qué riesgos existen.
Qué decisiones están pendientes.
Pero cuando esa misma estructura se utiliza para comunicar una transformación, pueden aparecer dificultades.
Una persona que no participa directamente en el proyecto probablemente no necesita conocer todas las tareas completadas durante el último sprint.
Necesita saber por qué ese proyecto existe.
Qué problema había antes.
Qué situación se quiere alcanzar.
Qué cambiará en su trabajo.
Y cómo sabrá la organización que realmente se ha mejorado algo.
Por eso, comunicar transformación no consiste en trasladar toda la información disponible.
Consiste en seleccionar aquella que permite construir sentido.
Toda transformación empieza con un problema, no con una herramienta
Una de las formas más habituales de explicar un proyecto tecnológico consiste en empezar por la solución.
Se implantará una nueva plataforma.
Se automatizará un proceso.
Se desarrollará un modelo de inteligencia artificial.
Se migrará un sistema.
Se construirá un nuevo entorno de datos.
Pero para quien recibe el mensaje desde fuera del proyecto, esa explicación puede resultar insuficiente.
La tecnología explica qué se está haciendo.
No necesariamente por qué merece la pena hacerlo.
El punto de partida debería estar antes.
¿Qué problema existe?
¿Qué limitación genera?
¿Qué consecuencias tiene actualmente?
¿Qué oportunidades no pueden aprovecharse?
Cuando el problema se entiende, la solución empieza a adquirir sentido.
Sin ese contexto, una iniciativa puede percibirse simplemente como otra herramienta más que llega a la organización.
Las personas recuerdan mejor una lógica que una lista de funcionalidades
Los proyectos tecnológicos suelen acumular funcionalidades.
Dashboards.
Integraciones.
Automatizaciones.
Nuevos flujos.
Alertas.
Permisos.
Modelos.
Interfaces.
Es habitual intentar explicar el valor del proyecto enumerando todo lo que será capaz de hacer.
Pero una larga lista de funcionalidades no siempre construye comprensión.
Puede incluso producir el efecto contrario.
Cuanto más detalle aparece, más difícil resulta identificar qué es realmente importante.
Una historia sencilla suele funcionar mejor:
Antes ocurría esto.
Eso generaba este problema.
Se ha decidido cambiar esta parte.
La nueva solución permitirá trabajar de esta otra manera.
Y el resultado esperado será este.
No se trata de convertir una transformación en una campaña publicitaria.
Se trata de darle una estructura comprensible.
Una buena historia no oculta la complejidad
Hablar de narrativa puede generar cierta desconfianza en entornos técnicos.
Puede interpretarse como una forma de simplificar excesivamente el proyecto o de presentar únicamente su parte positiva.
Pero una buena historia no debería maquillar la realidad.
Debería organizarla.
Puede explicar que existen dificultades.
Que habrá decisiones pendientes.
Que algunas partes cambiarán más adelante.
Que determinadas ventajas requerirán tiempo.
Que existirán nuevas responsabilidades.
Que la solución no resolverá todos los problemas.
De hecho, reconocer esos elementos puede hacer que el mensaje resulte mucho más creíble.
La narrativa no consiste en eliminar la complejidad.
Consiste en proporcionar una estructura que permita entenderla.
El mismo proyecto necesita historias diferentes
Una transformación no significa lo mismo para todas las personas.
Para dirección puede ser una inversión destinada a mejorar productividad o reducir riesgo.
Para operaciones puede cambiar la manera en que se planifica o ejecuta el trabajo.
Para tecnología puede significar reducir deuda técnica o mejorar una arquitectura.
Para finanzas puede modificar la trazabilidad de costes.
Para un usuario puede implicar aprender un nuevo sistema.
Por eso no existe una única forma correcta de contar un proyecto.
Existe un núcleo común.
El problema.
La decisión.
La dirección.
El resultado esperado.
Pero alrededor de ese núcleo, el mensaje necesita adaptarse.
No porque haya que contar historias diferentes sobre lo que está ocurriendo, sino porque cada audiencia necesita comprender una parte distinta de la misma realidad.
Comunicar avance no es comunicar actividad
Otro problema frecuente aparece durante la ejecución.
Los proyectos generan mucha actividad.
Reuniones.
Desarrollos.
Pruebas.
Configuraciones.
Incidencias.
Entregables.
Migraciones.
Todo ello puede comunicarse periódicamente.
Pero actividad y avance no son sinónimos.
Decir que se han completado treinta tareas puede aportar poco contexto sobre si el proyecto está realmente más cerca de generar valor.
Una comunicación más útil debería responder a preguntas diferentes:
¿Qué capacidad nueva existe ahora?
¿Qué problema se ha eliminado?
¿Qué decisión importante se ha tomado?
¿Qué riesgo ha aparecido?
¿Qué ha aprendido el proyecto?
¿Qué puede hacer hoy la organización que antes no podía hacer?
Ese cambio de enfoque modifica completamente la conversación.
El proyecto deja de presentarse como una sucesión de tareas y empieza a entenderse como una evolución.
También hay que explicar las decisiones que no se ven
Una parte importante del trabajo en transformación permanece invisible.
Alternativas descartadas.
Procesos que se han simplificado.
Decisiones arquitectónicas.
Cambios de alcance.
Pruebas que no funcionaron.
Hipótesis que tuvieron que revisarse.
Cuando sólo se comunica el resultado final, puede parecer que determinadas decisiones han sido arbitrarias.
Explicar parte del razonamiento ayuda a construir confianza.
No es necesario trasladar todas las discusiones internas.
Pero sí mostrar la lógica suficiente para que la organización entienda por qué se ha elegido un determinado camino.
Porque una decisión comprendida no siempre será una decisión compartida.
Pero probablemente será una decisión mucho más fácil de aceptar.
La historia también debe evolucionar
Los proyectos cambian.
Aparecen nuevas restricciones.
Se aprende.
Se modifican prioridades.
La organización también cambia mientras el proyecto avanza.
Por eso la historia inicial no puede convertirse en un relato rígido que se repite durante meses aunque la realidad ya sea diferente.
La comunicación necesita evolucionar con el proyecto.
Qué se pensaba al principio.
Qué se ha descubierto.
Qué ha cambiado.
Qué sigue siendo válido.
Qué decisiones nuevas aparecen.
Actualizar la narrativa no significa admitir que el proyecto estaba mal definido.
Significa reconocer que transformar también implica aprender.
Cuando la organización entiende el proyecto, puede participar en él
Existe una diferencia importante entre conocer una iniciativa y comprenderla.
Cuando sólo se conoce, el proyecto pertenece al equipo que lo ejecuta.
Cuando se comprende, empieza a formar parte de una conversación más amplia.
Las personas pueden identificar implicaciones.
Detectar riesgos.
Proponer mejoras.
Relacionarlo con otros procesos.
Entender decisiones.
Prepararse para el cambio.
Y esa participación resulta especialmente importante en transformación digital, porque la tecnología rara vez genera valor de manera aislada.
Necesita modificar procesos, comportamientos, decisiones y formas de trabajar.
Transformar también es saber contar qué está cambiando
Un proyecto tecnológico puede funcionar técnicamente y seguir siendo percibido como algo ajeno por buena parte de la organización.
Por eso la comunicación no debería aparecer al final, cuando llega el momento de anunciar el lanzamiento.
Debería formar parte del diseño de la transformación desde el principio.
No como una capa estética.
No como una presentación.
No como una campaña.
Sino como una forma de construir comprensión.
Porque una organización no necesita conocer cada detalle técnico para entender hacia dónde se dirige.
Pero sí necesita una explicación suficientemente clara para poder relacionar el proyecto con su propia realidad.
Y quizá ahí esté una de las diferencias entre implantar tecnología y transformar una organización:
un proyecto puede gestionarse con tareas, pero una transformación necesita además una historia que explique por qué todo aquello importa.
