Cuando un proyecto acumula retrasos, sobrecostes o una resistencia creciente al cambio, casi siempre buscamos la explicación en un alcance mal definido, una planificación deficiente o unos plazos demasiado optimistas.

Es una reacción lógica. Yo mismo también pensaba así hace años. Sin embargo, después de participar en numerosos proyectos y de debatir este tema con alumnos y profesionales de distintos sectores, he terminado llegando siempre a la misma conclusión: el verdadero problema no suele estar en el cronograma, sino en las personas que nunca llegamos a comprender.

Y no me refiero únicamente a enviar más comunicaciones, convocar más reuniones o mantener actualizado un registro de interesados. Hablo de comprender quién puede influir realmente en el éxito de una iniciativa, quién se verá afectado por ella, quién puede convertirse en un aliado y quién, sin necesidad de oponerse abiertamente, tiene capacidad para ralentizar o incluso bloquear el cambio.

Lo curioso es que hablamos constantemente de gestión de stakeholders. Aparece en cualquier guía, metodología, certificación o curso sobre gestión de proyectos y, sin embargo, creo que sigue siendo una de las disciplinas peor entendidas y peor aplicadas en muchas organizaciones.

Más allá del triangulo de hierro

Durante años asociamos el éxito de un proyecto al conocido triángulo de hierro: cumplir los plazos previstos, mantenernos dentro de un presupuesto y entregar el alcance comprometido.

Esta perspectiva, que comenzó a transformarse con la adopción de los enfoques ágiles, hoy resulta insuficiente como visión única de éxito. Organizaciones referentes como el PMI y el IIBA insisten en que un proyecto no es exitoso solo por cumplir con sus restricciones técnicas, sino cuando genera el valor esperado, es adoptado eficazmente por la organización y demuestra ser sostenible en el tiempo.

Y aquí aparece una reflexión que, con el tiempo, he ido compartiendo cada vez más en clase. Un proyecto puede finalizar en la fecha prevista, sin desviaciones presupuestarias y con todos los requisitos implementados correctamente y, pese a ello, fracasar.

Es suficiente con que quienes deben utilizar el resultado no lo comprendan, no lo acepten o simplemente no encuentren motivos para abandonar la forma en la que llevan años trabajando.

Por ello, cada vez resulta más necesario diferenciar entre entregar una solución y conseguir que esa solución genere valor. La primera depende de una correcta dirección y ejecución técnica del proyecto: un enfoque puramente táctico. La segunda exige que la organización adopte el cambio, incorpore nuevas metodologías de trabajo y las mantenga en el tiempo, consolidando una visión profundamente estratégica

En este contexto, la gestión de stakeholders y la gestión del cambio convergen en una misma conversación. Al fin y al cabo, uno de los pilares fundamentales de la transición organizativa es articular un esfuerzo estructurado para asegurar que los involucrados comprendan, acepten y adopten una nueva realidad.

El stakeholder más importante

En clase suelo plantear una pregunta que parece sencilla, pero que casi siempre genera debate: ¿quién es el stakeholder más importante de un proyecto? Las respuestas suelen repetirse: el sponsor, el cliente, el comité de dirección, los usuarios o el Product Owner.

Todas son respuestas razonables, pero incompletas, porque parten de una premisa discutible: que la importancia de un stakeholder depende más de la posición que ocupa en la organización que de su capacidad real para impulsar o bloquear el éxito del cambio, con independencia del cargo que desempeñe o de si aparece o no en el organigrama.

A veces será el sponsor. Otras, un usuario senior que conoce la operativa mejor que nadie. En otros casos será un mando intermedio con una enorme capacidad de influencia informal o, incluso, alguien cuyo nombre ni aparecerá en ninguna estructura formal, pero a quien todos recurren cuando surge un problema.

El organigrama explica muy bien quién depende de quién. Lo que no explica es quién influye realmente en quién. La confianza, la credibilidad, las alianzas o el liderazgo informal no aparecen dibujados en ninguna “caja”, aunque muchas veces resulten mucho más determinantes que la propia jerarquía. Y es precisamente ahí donde suelen encontrarse los stakeholders que nadie identificó al inicio del proyecto.

Recuerdo un proyecto de desarrollo de software cuando trabajaba en consultoría en el que el mapa de interesados estaba impecable: sponsor, comité de seguimiento, responsables de negocio, usuarios clave… todos identificados desde el kick-off.

El proyecto, sin embargo, empezó a fallar en un punto que nadie había anticipado: un desarrollador junior del equipo, sin ningún peso formal en el organigrama ni presencia en los comités, era la persona a la que todos acudían cuando había dudas sobre cómo afectaban los requisitos del negocio al sistema.

Nadie lo había involucrado en las reuniones de seguimiento. Cuando por fin se le dio voz, muchas de las resistencias que llevábamos semanas intentando gestionar con comunicación resultaron ser, en realidad, limitaciones técnicas y decisiones de diseño que él llevaba tiempo advirtiendo y que nunca habían llegado a quien tomaba decisiones.

Aquel proyecto también reforzó una idea que he ido confirmando con los años: el éxito de una iniciativa depende tanto de entender cómo los stakeholders afectan al proyecto como de comprender cómo el propio proyecto afectará a esos stakeholders. Es, en el fondo también, la diferencia que veo de perspectiva que suelen aportar el Project Manager y el Business Analyst cuando trabajan de forma complementaria.

La diferencia no está tanto en las herramientas que utilizan, sino en las preguntas que cada uno intenta responder, ya que, aunque ambos profesionales comparten la visión global de la iniciativa, sus puntos de partida son distintos. 

El Director de Proyecto orienta su atención principal hacia cómo los stakeholders pueden afectar o ser afectados por la ejecución del proyecto, priorizando la mitigación de riesgos y el cumplimiento de plazos.

El Analista de Negocio, en cambio, amplía esa perspectiva y prioriza cómo el proyecto afectará a los stakeholders y de qué manera transformará sus formas de trabajar.

No creo que sean posturas excluyentes, sino focos complementarios: el primero busca más, blindar la viabilidad de la ejecución y el segundo asegurar la sostenibilidad del valor en el tiempo.

Gestión de stakeholders y gestión del cambio

En ocasiones tratamos la gestión de stakeholders y la gestión del cambio como si fueran ámbitos separados. Por un lado, identificamos interesados, analizamos aspectos tales como su poder e interés y definimos estrategias de involucramiento. Por otro, diseñamos planes de comunicación, formación, adopción o transición organizativa.

Sin embargo, en la práctica ambas disciplinas están profundamente conectadas, y los principales modelos de gestión del cambio nos proporcionan precisamente, estructuras sumamente útiles para segmentar a los stakeholders y entender con precisión qué necesita cada perfil en cada momento de un proceso de cambio.

Un modelo como ADKAR, por ejemplo, plantea que el cambio individual ocurre al avanzar a través de cinco etapas consecutivas.

Desde la perspectiva de la gestión de stakeholders, este modelo nos aporta un diagnóstico excepcional. En lugar de tratar a todos los interesados por igual, nos obliga a formularnos preguntas diferenciadas para cada perfil de la organización: 

• ¿Comprenden las personas por qué es necesario cambiar?
• ¿Ven algún beneficio en la iniciativa o solo perciben pérdidas?
• ¿Saben exactamente qué tendrán que hacer de manera diferente?
• ¿Disponen de tiempo, herramientas y apoyo operativo para ejecutarlo?
• ¿Existen mecanismos que eviten regresar a prácticas anteriores?

Esto demuestra que las resistencias que encontramos en los proyectos pueden tener diferentes causas, por lo que no debemos resolverlas con una única estrategia.

Con este enfoque, lanzar una comunicación igual para todos los interesados suele tener poco efecto. ADKAR nos da la posibilidad de adaptar el plan de involucramiento a las necesidades específicas de cada persona.

A otra escala, el modelo de 8 pasos de Kotter nos demuestra que los cambios no se consolidan únicamente por la calidad técnica de la solución, sino por la capacidad de movilizar a la organización: creando un sentido de urgencia, comunicando una visión atractiva y generando los “famosos” quick wins.

El aporte diferencial de Kotter en la gestión de interesados es que el éxito depende de identificar y alinear a un equipo impulsor que no siempre coincide con la estructura jerárquica del proyecto. Esta coalición debe integrar estratégicamente a: 

• El sponsor ejecutivo, que asegure respaldo y recursos.
• Líderes informales que permitan ganar credibilidad en las bases.
• Responsables intermedios y usuarios de referencia que rompan silos operativos.

Dicho de otro modo, según Kotter, gestionar el cambio implica entender que cada stakeholder clave juega un rol político y estratégico diferente para legitimar y empujar la transformación.

Incluso el modelo clásico de Kurt Lewin, con sus etapas de descongelar, cambiar y volver a estabilizar, aporta una reflexión indispensable sobre la dinámica de fuerzas entre stakeholders: todo estado organizacional es un equilibrio entre fuerzas que impulsan el cambio y fuerzas que lo reprimen. 

• Descongelar: Desestabilizar los patrones de comportamiento actuales, promoviendo una reflexión crítica sobre el statu quo.
• Cambiar: Guiar a las personas a través de la incertidumbre con orientación y soporte continuo.
• Recongelar: Asegurar que la nueva realidad se incorpore definitivamente en los procesos, roles, indicadores y sistemas. 

Si la gestión de interesados olvida la etapa de “recongelamiento”, el esfuerzo habrá sido en vano: las personas regresarán progresivamente a la situación anterior por la fuerza de la inercia cultural.

Cierra el recorrido el modelo de William Bridges aporta la dimensión humana y emocional más profunda al análisis de los stakeholders, diferenciando «cambio» de «transición». 

• El cambio es externo y técnico: Una nueva herramienta, una reorganización o una modificación de responsabilidades. Es el territorio del cronograma del proyecto. 
• La transición es interna y psicológica: la persona abandona una situación conocida, atraviesa una zona de incertidumbre y termina adaptándose a la nueva realidad. ¿Os suena lo de salir de la zona de confort?… pues exactamente eso.

Esta distinción es crítica para los directores de proyectos. Una organización puede implantar una nueva plataforma en una fecha concreta de salida a producción (Go-Live), pero eso no significa que los stakeholders hayan completado su transición ese mismo día. El proyecto puede celebrar un despliegue con éxito, mientras los usuarios todavía están intentando asimilar qué han perdido o cómo encajan en el nuevo contexto.

El valor definitivo de Bridges es recordarnos que gestionar interesados no consiste únicamente en explicar de forma unidireccional lo que va a cambiar. Implica, fundamentalmente, entender qué está dejando atrás cada persona y gestionar con empatía el duelo operativo de la organización.

Las herramientas no sustituyen el criterio

Llegados a este punto suele aparecer una conversación recurrente: la de las herramientas.

Me gustan. Las utilizo habitualmente, forman parte de mis clases y creo sinceramente que aportan muchísimo valor. El problema aparece cuando olvidamos que una herramienta nunca puede sustituir al criterio.

En mi opinión, la construcción de una matriz Poder-Interés carece de sentido si no se ha identificado con precisión a todos los actores relevantes. Asimismo, la elaboración de un mapa de empatía resulta ineficaz si no se ha dedicado tiempo a una escucha activa y profunda de las personas. De igual manera, el diseño de una estrategia de involucramiento se vuelve complejo cuando se desconoce la verdadera naturaleza de las preocupaciones de cada grupo de interés.

No todas las herramientas sirven para lo mismo y precisamente ahí reside su valor. Cada una ayuda a responder una pregunta distinta y, por eso, no compiten entre sí, sino que se complementan.

Primero necesitamos descubrir quién forma parte del ecosistema del proyecto. Después debemos comprender quién tiene mayor capacidad de influencia o quién se verá más afectado por el cambio. Más tarde llega el momento de entender expectativas, necesidades, motivaciones y posibles resistencias. Solo entonces tiene sentido definir estrategias de comunicación, involucramiento y gestión del cambio. Y todo ello debe revisarse de forma continua, porque los stakeholders evolucionan igual que evolucionan los proyectos.

Una persona que inicialmente apoyaba la iniciativa puede convertirse en detractora si considera que no se están cumpliendo las expectativas. Y alguien que mostraba resistencia puede transformarse en uno de nuestros principales aliados cuando comprende el cambio, participa en su diseño y comprueba que sus preocupaciones han sido escuchadas.

SIPOC como herramienta para identificar stakeholders

Probablemente tenga algo que ver con mi deformación profesional por trabajar desde hace años en procesos, pero cada vez utilizo más el SIPOC para identificar inicialmente stakeholders y no solo para analizar procesos.

Casi todo el mundo lo relaciona con el análisis de procesos, y con razón. Sin embargo, cuando analizamos quién suministra información, quién recibe las salidas de un proceso o qué áreas participan indirectamente, empiezan a aparecer actores que nadie había considerado. Y, curiosamente, muchas veces son precisamente ellos quienes terminan condicionando el éxito de una implantación.

SIPOC nos obliga a ampliar la mirada más allá de los usuarios visibles de una solución.

Permite descubrir proveedores internos, áreas de soporte, equipos que gestionan excepciones, responsables de controles, receptores de información o unidades que, sin participar directamente en la ejecución, dependen de sus resultados.

Nos ayuda, en el fondo, a comprender que un cambio rara vez afecta únicamente al área que aparece en el alcance inicial del proyecto.

Resistencia

Una vez vistos algunos modelos de gestión de cambios, y entendidas las herramientas que tenemos a nuestro alcance, para entender y conocer mejor a nuestros interesados, podemos decir que la resistencia al cambio casi nunca desaparece aumentando la presión. Disminuye cuando entendemos qué siente que está perdiendo cada persona.

En demasiadas ocasiones etiquetamos a alguien como “resistente” cuando, en realidad, simplemente está preocupado. Quizá teme perder autonomía, capacidad de decisión, conocimiento, reconocimiento, relaciones, estabilidad o incluso la seguridad de dominar perfectamente su trabajo.

También puede ocurrir que la resistencia no sea un bloqueo emocional, sino una postura completamente racional. En muchos casos, el interlocutor ha detectado un riesgo que el equipo del proyecto pasó por alto, conoce una limitación operativa no analizada o recuerda iniciativas previas que prometieron grandes resultados pero solo generaron más carga de trabajo. A pesar del valor de este diagnóstico, es común que la organización tache a estos perfiles de manera arbitraria como stoppers, perdiendo una oportunidad de oro para mitigar riesgos reales

Por eso no toda resistencia debe combatirse: en ocasiones debe escucharse. En ocasiones debe escucharse. Los modelos de cambio nos ayudan a estructurar la intervención, pero ninguno sustituye la necesidad de comprender el contexto.

Así, mientras ADKAR identifica la barrera individual y Kotter orienta la movilización organizativa mediante coaliciones, Lewin recuerda la necesidad de consolidar y Bridges profundiza en la dimensión psicológica de la transición. Ninguno, sin embargo, tendrá valor si se aplica de forma mecánica, ignorando la escucha activa y la adaptación del enfoque a la realidad de la organización.

Lo que queda claro, es que si no comprendemos cuál es la preocupación concreta de cada stakeholder, cualquier estrategia terminará pareciendo propaganda corporativa.

Los proyectos por sí solos no transforman las organizaciones, y por eso, gestionar stakeholders nunca ha sido solo rellenar matrices, sino comprender a las personas.

Las herramientas, a su vez, nos ayudan a ordenar el pensamiento, pero no sustituyen conversaciones, entrevistas, escucha activa ni la capacidad de observar cómo funciona realmente la organización.

Si tuviera que resumir en una sola frase el mayor error que sigo viendo en muchos proyectos, probablemente sería esta: Dedicamos mucho más tiempo a diseñar soluciones que a comprender a las personas que tendrán que convivir con ellas.

Y esto resulta especialmente curioso porque, como hemos visto, los proyectos no cambian organizaciones. Quienes realmente las cambian son las personas.

Por eso una de las frases que más me preocupa escuchar al terminar cualquier iniciativa no es “hemos tenido un retraso de dos semanas” o “hemos consumido más presupuesto del previsto”, sino una mucho más sencilla: “A mí nadie me ha preguntado nada.”

Cuando esa frase aparece, normalmente el problema no está en la planificación, ni en la metodología, ni siquiera en la tecnología como tal. El problema empezó mucho antes: el día en que confundimos gestionar stakeholders con mantener un listado de nombres en un documento creado durante el kick-off del proyecto.

Gestionar stakeholders significa comprender cómo se distribuye realmente su influencia, cómo perciben las personas un cambio, qué esperan ganar, qué temen perder y qué necesitan para avanzar.

Y probablemente ahí, mucho más que en cualquier cronograma, es donde se decide el verdadero éxito o fracaso de un proyecto.