Gestión de stakeholders

He visto proyectos técnicamente sencillos complicarse (y proyectos complejos salir bien) por una sola razón:

👉 cómo se gestionan expectativas, decisiones y validaciones entre personas.

Aquí van situaciones normales (de las que pasan en casi todos los proyectos) y qué hacer para que no te exploten al final.

1️⃣ “Todos mandan” → nadie decide

Cuando hay muchas voces pero no hay una persona con autoridad real, las decisiones se retrasan o se revierten.

Qué funciona:

👉 Nombrar un PO (Product Owner / Responsable del Producto) con capacidad de decisión y una regla simple: una persona decide, el resto influye.

2️⃣ Stakeholders “fantasma” que aparecen tarde

Legal, seguridad, IT, compliance… entran cuando ya está “casi hecho” y entonces llega el clásico: “esto no nos vale”

Qué funciona:

👉 Hacer un mapa de stakeholders desde el día 1

👉 Definir hitos de validación por colectivo

No hace falta que estén en todas las reuniones, pero sí que validen cuando toca.

3️⃣ No hay tiempo para validar… hasta que el final se vuelve infernal

Si el negocio no valida a tiempo, el feedback llega cuando es caro.

Y se convierte en urgencias, recortes y frustración.

Qué funciona: una cadencia fija:

• 🔹 Demo quincenal

• 🔹 Criterios de aceptación antes de desarrollar

• 🔹 Una persona responsable de aprobar cada entrega

4️⃣ Confundir sponsor con usuario (y matar la adopción)

El sponsor (quien paga) busca ROI.

El usuario (quien lo usa) busca menos fricción y menos pasos.

Si solo contentas a uno, el proyecto sufre.

Qué funciona: separar stakeholders por rol y darles espacio:

• Sponsor: objetivos y métricas (ROI)

• Usuarios: flujo real de trabajo

• IT: viabilidad, mantenimiento y seguridad

• Compliance: riesgo y auditoría

5️⃣ “Solo una cosita más” (scope creep)

(scope creep = crecimiento silencioso del alcance)

No suele ser maldad: es entusiasmo, urgencia o “ya que estamos…”.

Pero es la forma más común de romper plazos.

Qué funciona:

👉 Un mecanismo de cambios transparente

👉 Si entra algo, sale algo (o cambia fecha/coste)

Sin drama. Con realidad.

6️⃣ Guerra de prioridades entre áreas

Ventas quiere A.

Operaciones quiere B.

Finanzas quiere C.

Todo es “crítico”.

Resultado: roadmap errático y desgaste.

Qué funciona:

👉 Una única regla de priorización (por ejemplo, impacto vs esfuerzo)

👉 Un backlog visible para todos

Menos política. Más criterio.

🔧 Lo que yo aplico para que el proyecto termine (y termine bien)

1️⃣ Mapa de stakeholders + responsabilidades claras

2️⃣ RACI (Responsible, Accountable, Consulted, Informed) para no mezclar roles

3️⃣ Cadencia fija de comunicación y validación (no “cuando podamos”)

4️⃣ Definición compartida de “Done” (Hecho): incluye QA, despliegue y formación

5️⃣ Gestión de cambios con trade-offs explícitos

💡 Idea final

Un proyecto avanza a la velocidad de sus decisiones.

Y las decisiones avanzan cuando sabes:

• quién decide

• cuándo valida

• y con qué información

Si estás en un proyecto de software a medida y notas bloqueos, cambios al final o reuniones eternas, casi siempre hay una causa raíz:

👉 stakeholders sin un marco claro.