Cada pocos años aparece un nuevo framework que promete resolver los problemas de gestión de proyectos que los anteriores no pudieron. Scrum reemplazó al waterfall. SAFe escaló Scrum. Ahora hay frameworks para escalar SAFe.
Y sin embargo, los proyectos siguen fallando a tasas parecidas.
Algo no está funcionando — y no es el framework.
El problema con los frameworks
Un framework es una estructura de referencia. Te dice cómo organizar el trabajo, qué roles crear, qué reuniones hacer, qué artefactos producir. Es útil como punto de partida y como lenguaje común.
Lo que un framework no puede hacer es pensar por vos.
No puede decirte cuándo el cliente está dando señales de que el alcance va a cambiar y conviene conversarlo antes de que explote. No puede decirte que el sponsor que dice que sí a todo en las reuniones está en realidad perdiendo la fe en el proyecto. No puede decirte que el equipo está quemado aunque los reportes de avance digan que todo está bien.
Esas lecturas requieren criterio. Y el criterio no se certifica ni se aprende en un manual.
Cómo los frameworks se convierten en el problema
El momento en que un framework deja de ser útil es cuando se convierte en un fin en sí mismo.
Lo veo en organizaciones que tienen ceremonias Scrum impecables — daily standups, sprint reviews, retrospectivas — pero donde las decisiones reales siguen tomándose en conversaciones informales entre los mismos tres directivos de siempre. El equipo hace las ceremonias. La organización funciona como siempre.
Lo veo en equipos que siguen el PMBOK al pie de la letra, producen documentación exhaustiva, tienen sus matrices de riesgos actualizadas — y aun así no logran alinear al sponsor con el equipo porque nadie está gestionando esa relación como la prioridad que es.
El framework está. El proyecto falla igual.
Lo que los frameworks no pueden reemplazar
Hay tres cosas que ningún framework puede darte:
Lectura del contexto organizacional. Cada organización tiene su historia, sus conflictos, sus jerarquías informales y sus agendas. Un PM que no entiende eso gestiona el proyecto en el vacío — y se sorprende cuando las cosas no avanzan aunque el proceso sea correcto.
Conversaciones difíciles. Los proyectos no fallan por falta de documentación. Fallan porque nadie tuvo la conversación incómoda a tiempo: que el alcance es irreal, que el plazo es imposible, que el equipo no tiene la capacidad que el plan asume. Un framework no te da el coraje para tener esa conversación. Ni el criterio para saber cuándo tenerla.
Adaptación en tiempo real. Los frameworks describen cómo debería funcionar un proyecto en condiciones normales. Los proyectos reales no funcionan en condiciones normales. La capacidad de adaptar el enfoque cuando el contexto cambia — sin perder el control ni tirar el plan — es una habilidad que no está en ningún manual.
Por qué seguimos adoptando frameworks
Si los frameworks no resuelven el problema, ¿por qué seguimos adoptándolos?
Porque dan una sensación de control. Cuando un proyecto falla, es más fácil decir “no implementamos bien el framework” que decir “no teníamos el criterio para gestionar esta complejidad”. El framework es un chivo expiatorio conveniente.
Y porque las organizaciones necesitan estructuras comunes para coordinar a escala. Un equipo de cinco personas puede funcionar con criterio y conversaciones. Un equipo de cincuenta necesita un lenguaje compartido. Ahí los frameworks tienen valor real.
Cómo usar un framework sin que el framework te use a vos
La diferencia entre un PM que domina un framework y uno que está dominado por él es simple: el primero sabe cuándo no seguirlo.
Eso requiere entender el propósito de cada práctica — por qué existe, qué problema resuelve — en lugar de seguirla porque “así dice el framework”. Cuando entendés el propósito, podés adaptar la práctica al contexto sin perder lo que la hace valiosa.
El PMBOK 8 lo dice explícitamente: los 40 procesos que documenta son no prescriptivos. No son una lista de cosas que hay que hacer — son un catálogo de prácticas que podés adaptar según lo que necesite el proyecto. Si querés entender cómo encaja esto con el nuevo examen PMP, tengo un artículo sobre qué cambió con el PMBOK 8.
La pregunta que vale la pena hacerse
Antes de adoptar un framework — o antes de defender el que ya usás — la pregunta correcta es:
¿Qué problema estamos tratando de resolver y esta práctica ayuda a resolverlo?
Si la respuesta es sí, usala. Si la respuesta es “no sé, pero así dice el proceso”, es momento de cuestionar.
Los mejores PMs que conozco no son los que más frameworks conocen. Son los que tienen el criterio para saber cuándo usar cada herramienta — y cuándo no. Si querés pensar en qué enfoque conviene para cada tipo de proyecto, tengo un artículo sobre cómo elegir entre predictivo, ágil e híbrido.
Valeria Yashan es PMP® #1613335, MBA e Ingeniera Industrial. Consultora, docente y autora de cuatro libros sobre gestión de proyectos e IA aplicada. Trabajó con equipos en Argentina, LATAM y España. Conocé más sobre Valeria.
Para ver qué sí funciona en la práctica, leé cómo implementar gestión de proyectos en tu empresa. Y para entender cuándo los enfoques ágiles ayudan y cuándo no, Predictivo, ágil o híbrido: cómo elegir el enfoque correcto.