En la gestión de proyectos, las metodologías principales reinan absolutas, y las metodologías híbridas de gestión de proyectos suelen ser consideradas una herejía. Tu equipo debe ser predictivo o adaptativo (dependiendo de tu postura), y no hay espacio para mezclar las líneas, bajo riesgo de ser exiliado del reino de las metodologías puras de gestión de proyectos.
Los gestores de proyectos, y en particular los gestores de proyectos digitales, siempre han estado obsesionados con las metodologías. ¿Por qué basamos todo lo que hacemos en ellas y realmente importan tanto?
En este artículo voy a analizar qué son las metodologías híbridas de gestión de proyectos, los beneficios de usar una y por qué no son tan subversivas como pueden parecer.
¿Qué es una metodología híbrida de gestión de proyectos?
Una metodología híbrida de gestión de proyectos es una combinación de dos (o más) de los muchos enfoques diferentes que existen para ejecutar proyectos. Consiste en tomar elementos de algunas metodologías de proyecto (a menudo el método en cascada o alguna de las metodologías ágiles) y adaptarlas a tu manera para ajustarlas a las necesidades de tu proyecto.
Y esta idea de hibridar o adaptar el enfoque de tu proyecto no es tan inusual o tan criminal como algunos te han hecho creer. De hecho, un estudio reciente de ProjectManager.com reportó que el 60% de los profesionales encuestados estaban usando un enfoque híbrido o una mezcla personalizada de varios estilos.
Pero antes de adelantarnos, alineémonos en los conceptos básicos.
¿Qué son las metodologías de gestión de proyectos?
Las metodologías de proyectos son marcos o sistemas compuestos por prácticas, técnicas, reglas y procesos específicos que rigen tu proyecto y su gestión. Generalmente, involucran tareas principales, principios o estándares en las distintas fases del proyecto como la iniciación del proyecto, planificación del proyecto, ejecución, monitoreo y el cierre del proyecto.
Parece haber una cantidad interminable de opciones a la hora de elegir una metodología de gestión de proyectos, pero todas pueden clasificarse a grandes rasgos en dos categorías: métodos predictivos, como el cascada, y métodos adaptativos, entre los que se encuentra ágil, que a su vez tiene varias ramas y marcos como Scrum y Lean, por ejemplo.
Voy a centrarme en los dos enfoques más significativos que aparecen una y otra vez al hablar de gestión de proyectos digitales: el método en cascada, un enfoque tradicional basado en dependencias que funciona mejor cuando la predictibilidad es crucial, y Scrum ágil, el popular marco impulsado por sprints que es ideal para proyectos que requieren agilidad para desenvolverse rápidamente ante lo desconocido.
¿Por qué? Porque a pesar de que Scrum se considera la opción sensata para muchos equipos digitales y que el método cascada tiene mala fama por ser anticuado, rígido y poco realista, la realidad es que tanto las metodologías ágiles como en cascada tienen beneficios específicos y contextos de proyecto para los que son más adecuadas.
¿Cómo podría ser una metodología híbrida?
La realidad es que existen muchos equipos y organizaciones de proyectos digitales que creen haber adoptado una sola metodología, pero en realidad usan una combinación para ejecutar sus proyectos. Para nuestros propósitos, llamemos a esto "híbridos accidentales".
Por ejemplo, simplemente dividir el trabajo en sprints de desarrollo de dos semanas y hacer una reunión diaria no te convierte automáticamente en un equipo Scrum. De hecho, esto se parece más a tomar algunos elementos de Scrum para mejorar la comunicación, la urgencia y un espíritu de iteración.
De la misma manera, solo porque tengas fechas de hitos concretas con tareas dependientes no significa que el método cascada sea tu única opción. Muchos equipos Scrum preparan su backlog y hacen planificación de sprints para entregar resultados específicos en fechas de hitos determinadas.
En términos generales, habrá elementos de diferentes metodologías que pueden ser ventajosos para un proyecto o una organización específica. También habrá elementos de distintas metodologías que pueden limitar la capacidad del proyecto para alcanzar sus objetivos. Y ahí es donde tiene sentido diseñar una metodología híbrida o adaptada.
¿Pero cómo se ve eso realmente?
Para poner esto en un contexto concreto, supongamos que tu proyecto involucra organizaciones colaboradoras que necesitan tener los requisitos completamente definidos y acordados al inicio, antes de poder construir nada. Al mismo tiempo, tus partes interesadas están preocupadas por tener que esperar hasta el final del proyecto para ver por primera vez el resultado final.
Con un enfoque Scrum, podrías disipar las preocupaciones de tus partes interesadas acerca de la "caja negra" mediante revisiones de sprint y una cultura de equipo enfocada en construir un entregable potencialmente publicable en cada sprint. Pero Scrum generalmente no favorece la captura de requisitos desde el principio que necesitas de tus socios.
Con un enfoque en cascada (waterfall), podrías obtener y lograr la aprobación de todos los requisitos desde el principio, e incluso programar algunas demostraciones para los stakeholders durante el desarrollo. Pero no tendrías una manera clara de gestionar los nuevos requisitos que surjan a través de la retroalimentación de las partes interesadas.
Una opción podría ser dividir el proyecto en fases, donde cada fase del proyecto aborde un componente de la solución. Los requisitos completos de cada componente se recopilarían al inicio, aprobarían y luego construirían antes de pasar a la fase del siguiente componente.
Visualmente, podría verse así:

Pero también podrías querer diseñar un enfoque híbrido que tome lo "mejor de" cada metodología que estés considerando.
Por ejemplo, podrías tomar la captura de requisitos previa del enfoque en cascada y luego ejecutar el desarrollo usando sprints y ceremonias estilo Scrum que empoderen a los stakeholders para dar retroalimentación al backlog del producto, donde las organizaciones asociadas puedan revisar los nuevos requisitos como solicitudes de cambio.
Eso podría verse más así:

Metodologías Híbridas De Gestión De Proyectos Como Transición Hacia Agile
Las metodologías híbridas también pueden ser una excelente fase intermedia mientras tu organización o equipo avanza hacia una forma de trabajo ágil.
No siempre es fácil implementar los enfoques ágiles por completo o de inmediato en las organizaciones, mucho menos a gran escala. Implementar ágil requiere un cambio organizacional a nivel de operaciones y cultura, y hay muchos otros factores involucrados. Los enfoques ágiles no necesariamente se mezclan con clientes que quieren cosas como alcance del proyecto, presupuesto y cronograma definidos desde el inicio (aunque esto puede resolverse mediante un contrato ágil).
Con las dificultades de implementar métodos ágiles, hacer una transición sin problemas a la entrega ágil es muy difícil para muchas organizaciones. Existen muchos factores que complican la implementación:
- Un alto nivel de involucramiento del cliente puede ser perjudicial para el proceso ágil e interrumpir las fases de construcción cuidadosamente planificadas, o los sprints
- Una falta general de entendimiento sobre qué es ágil y cómo puede aplicarse a un tipo particular de proyecto
- Puede que tengas una historia de uso de un enfoque waterfall u otra metodología predictiva con el cliente, lo que podría generar dudas por miedo a tensar la relación
Es más fácil realizar una transición gradual para adoptar principios ágiles o el proceso Scrum. Esta situación requiere de un enfoque híbrido, el cual puede ser una solución más realista, al menos durante la transición.
Aquí tienes un ejemplo de cómo podrías ajustar tus prácticas de planificación de proyectos para que sean más ágiles usando un enfoque híbrido.
Supongamos que eres una agencia digital que ha atendido a sus clientes durante décadas usando un enfoque de precio fijo y de tipo cascada. Por lo general, los clientes siempre sabían qué iban a recibir, cuándo y cuánto costaría.
Un día, le comunicas a tus clientes que pasarás a formas de trabajo ágiles en agencia, lo que inmediatamente activa una alarma en sus cabezas sobre que podrían no recibir nada de lo que quieren después de 7 sprints, creando sobrecostos y retrasos en el cronograma.
Para hacer la transición más fluida, podrías decidir que tu siguiente proyecto utilice requisitos fijos entregados en sprints en días específicos. Quizá la recopilación de requisitos a alto nivel ocurra al principio, con una planificación más detallada antes de iniciar el siguiente sprint.
Luego, en el siguiente proyecto, podrías revisar el proceso de solicitud de cambios con ellos y convencerlos de la idea de que el cambio debe incorporarse en el proceso a través de las revisiones de sprint y la re-priorización del backlog en su lugar (esto es algo con lo que la inteligencia artificial en la gestión del backlog puede ayudar), reduciendo así el tiempo dedicado a recopilar todos los requisitos al principio.
Después de unos cuantos proyectos más, es posible que estés trabajando casi completamente de forma ágil, con tus clientes entendiendo el valor de comprar sprints como una forma de ser flexibles ahora que están más alejados de la mentalidad de desconfianza y de pensar que todo debe estar definido desde el inicio, y están más cerca de convertirse en promotores de valor y resultados junto a tu equipo.
Pero creo que el hilo conductor y la lección más importante de todos estos ejemplos es lo siguiente: crear un enfoque híbrido es mejor cuando se hace de manera deliberada. En lugar de empezar con un enfoque “puro” y luego hacer excepciones a lo largo del camino, comienza con la intención de crear un enfoque personalizado o híbrido que se adapte como un guante a tu proyecto.
Aprende a Combinar Metodologías de Proyecto Correctamente
Descubre nuestro mini curso sobre Personalización de tu Enfoque de Proyecto. Obtendrás:
- Una inmersión de 40 minutos en metodologías híbridas y el proceso de personalización
- Un kit de herramientas para personalizar la metodología de tu proyecto
- Una plantilla para documentar tu enfoque de proyecto personalizado
¿Qué proyectos son más adecuados para metodologías híbridas?
No se trata exactamente de tipos particulares de proyectos, sino más bien de ciertos escenarios o circunstancias que rodean a los proyectos que podrían hacer que tu proyecto sea adecuado para una metodología híbrida.
Aquí tienes algunas situaciones en las que podrías usar una metodología híbrida.
- Puede que tu equipo de desarrollo de software quiera usar sprints, pero tu cliente no tiene capacidad para tomar decisiones de inmediato en tus ceremonias de Scrum, lo que detiene vuestro avance por completo.
- Quizá tu equipo se siente cómodo con un enfoque tradicional de gestión de proyectos como el waterfall, pero tu producto tiene demasiadas incógnitas. Puedes intentar hacer un plan secuencial que prediga el futuro hasta la fecha exacta de entrega, pero si estás construyendo algo que tiene mucha ambigüedad, es posible que no sepas todos los pasos ni cuánto tiempo llevará cada uno.
- Puede que tu equipo quiera utilizar iteraciones incrementales, pero tu proyecto tenga algunos requisitos regulatorios que hacen que los incrementos rápidos del producto sean un poco más complicados debido a largos procesos de auditoría de proyectos, o incluso a menor escala.
- Tal vez tu equipo ágil sigue Scrum, pero tu proveedor funciona con Kanban (lee sobre Kanban vs Scrum aquí)
- Quizás tu equipo de ingeniería tiene sprints de desarrollo de tres semanas, pero tu equipo de diseño trabaja en sprints de dos semanas.
¿Cuáles son los beneficios de las metodologías de gestión de proyectos híbridas?
¿Por qué alguien invertiría tiempo en personalizar o hibridar el enfoque de su proyecto?
- Puedes aprovechar y combinar ventajas de dos metodologías diferentes, como por ejemplo, velocidad y previsibilidad. Supón que quieres combinar la mentalidad de crear productos potencialmente comercializables en sprint de dos semanas, pero tienes un patrocinador del proyecto que prefiere un enfoque más distante. Podrías agrupar varios sprints en algunos hitos formales de revisión a lo largo de tu ciclo de vida del proyecto.
- Puedes proporcionar una base familiar frente a restricciones especiales. Por ejemplo, si el equipo está acostumbrado a Kanban, pero tienes elementos específicos en tu proyecto que deben ser entregados en fechas concretas para que los revise un organismo regulatorio, podrías agregar hitos a tu flujo continuo habitual.
- Puedes usar esto para generar confianza donde hay incertidumbre. Por ejemplo, si tu cliente no confía en que un enfoque ágil garantice un alcance específico, puedes incluir una fase inicial de descubrimiento para definir la solución antes de entrar en iteraciones ágiles. Consejo profesional: utiliza estas preguntas de la sesión de descubrimiento para que sea un ejercicio útil.
- Es una excelente manera de empezar a explorar nuevas formas de trabajo como organización. Puedes decidir adoptar una metodología híbrida adaptada para categorías o niveles específicos de proyectos, o incluso una metodología personalizada de facto para todos los proyectos de tu organización.
- A medida que las personas participan en conversaciones sobre metodologías de proyectos, su comprensión sobre cómo se entregan los proyectos se profundizará. Incluso pueden valorar un poco más tu rol como gestor de proyectos.
- Una metodología a medida puede convertirse en un diferenciador competitivo para tu equipo u organización. Si consigues adaptar tu enfoque para una entrega en un nicho, como por ejemplo, herramientas digitales para empresas de exploración minera junior (y para lo cual puedes usar software de gestión de proyectos para minería), serás más atractivo que tus competidores. Simplemente evolucionar tu forma de trabajar ya puede diferenciarte de competidores con un enfoque más estático.
Desafíos de las Metodologías Híbridas
Al definir tu propio proceso híbrido, hay desafíos comunes a los que debes prestar atención.
Cultura de Equipo Inadecuada
Debes asegurar la adaptabilidad de tu equipo y las partes interesadas, así como contar con un equipo altamente capacitado y stakeholders hábiles. Son personas que pueden hacer bien su trabajo, incluso si los parámetros están cambiando.
Asimismo, necesitas tener un historial sólido de excelente comunicación con todas las partes involucradas. Los equipos van a trabajar de una manera nueva, y necesitarán colaborar y compartir información eficazmente para mantener el proyecto en marcha.
Cultura Organizacional Inadecuada
Una cultura organizacional flexible y preparada para el cambio también es clave. Todos deben estar dispuestos a aceptar cierto nivel de compromiso metodológico para que el proyecto tenga éxito. Los marcos y enfoques populares tienen beneficios e inercias intrínsecos.
Así que en cuanto empiezas a cambiar componentes, empiezas a comprometer ese diseño original. Es como modificar un iPhone para que tenga un cargador USBC.
Cuando los equipos trabajan en silos, están polarizados o carecen de experiencia para trabajar eficazmente fuera de su zona de confort, esas no son buenas bases para un enfoque de proyecto modificado. Además, si tu objetivo es simplemente complacer a un stakeholder, quizás valga la pena hacer una pausa. Tratar de satisfacer a quien más se queja sin una estrategia pondrá en peligro tu capacidad de lograr el éxito del proyecto.
Falta de Proceso o Estructura
Un enfoque híbrido de gestión de proyectos no significa 'hacerlo como nos apetezca'. Todavía necesitas establecer límites para tu equipo y ser estratégico sobre cómo y por qué adaptas la metodología.
En lugar de seguir un sistema, podrías pasar al extremo opuesto y no tener nada concreto definido. El proyecto se vuelve un caos porque no hay una forma de trabajo establecida en absoluto. Si los miembros del equipo no saben realmente cómo deben trabajar, pueden irse por las ramas y dejar de centrarse en lo que deberían estar haciendo.
Por otro lado, no pongas procesos por el simple hecho de tenerlos. No añadas documentación innecesaria porque sí. Mantén el proceso lo más ágil posible.
Recurrir A Un Enfoque "Talla Única"
Cuidado con el enfoque de talla única. Esta es la idea de que, porque algo resultó exitoso una vez, funcionará para todo. Asegúrate de considerar cada proyecto como una entidad propia. Aunque debe haber cohesión en los procesos de la organización, cada proyecto es diferente en sí y necesita ser tratado como tal.
Falta de Compromiso del Equipo
Tu equipo podría pensar que tu híbrido es solo una metodología disfrazada de otra. Como si fuera solo una etiqueta de marketing y no una descripción válida. Justifica bien tu decisión.
Por eso es importante documentar tu razonamiento. Además, reformula los beneficios de cada enfoque en el contexto específico de tu proyecto. Lo importante es hacer lo correcto para el equipo y el proyecto, así que haz que el equipo entienda cómo les beneficia.
Por ejemplo, si no puedes utilizar un enfoque de gestión ágil de proyectos, explica qué sucedería si el proyecto fuera ágil y qué tendría que cambiar para que el proyecto soporte metodologías ágiles.
Cómo combinar métodos de gestión de proyectos para crear un híbrido
A continuación, se detallan los pasos para crear o decidir una metodología de gestión de proyectos híbrida y cómo lograr que su uso sea exitoso.
1. Considera los objetivos y el contexto del proyecto
Para empezar, siéntate con tu equipo y los principales interesados para comprender, priorizar y clasificar lo que es importante para tu nuevo proyecto.
Aquí tienes algunos ejemplos (¡esta no es una lista exhaustiva!):
- Velocidad: ¿Este proyecto necesita hacerse rápido o de manera ágil? ¿Necesitamos ser capaces de pivotar?
- Costo: ¿Intentamos hacerlo lo más económico y agradable posible?
- Calidad: ¿Buscamos hacerlo perfecto a la primera?
- Conformidad: ¿Existen procesos de revisión externos que impactarán la forma en que trabajamos?
- Participación del cliente: ¿Qué tan importante es recibir retroalimentación de los usuarios finales a lo largo del proceso?
- Innovación: ¿El propósito de este proyecto es hacer algo diferente a lo habitual y abrir caminos? ¿O es más importante tener previsibilidad en términos de fechas fijas, requerimientos fijos y funcionalidad fija?
Luego merece la pena considerar el contexto de tu proyecto. Nuevamente, esto no pretende ser una lista exhaustiva:
- ¿Qué tan compleja es la composición del equipo? ¿Está este equipo preparado para trabajar fuera de su zona de confort?
- ¿Cuál es la cultura de los equipos y las organizaciones involucradas? ¿Es colaborativa? ¿Son compartimentados? ¿Son flexibles o rígidos?
- ¿Qué tan estables son los requisitos? ¿Van a permanecer igual o casi con certeza fluctuarán?
- ¿Tenemos requisitos regulatorios a considerar u otros socios que van a estar involucrados?
- ¿Lo que estamos construyendo puede iterarse de alguna forma?
- En términos de dependencias, ¿dependemos de otros proyectos o otros proyectos dependen de nosotros?
- ¿Tendremos acceso directo a las partes interesadas y a los usuarios?
- ¿Qué metodologías se han utilizado con éxito antes?
2. Elige una metodología como punto de partida
Tener un punto de partida le da a todos una base con la que identificarse. Pero no todas las metodologías son iguales.
Por ejemplo, Scrum es ideal para entregar en iteraciones, involucrar al cliente y fallar rápido y temprano. Si estuviera creando una aplicación pionera en una industria emergente, probablemente consideraría Scrum. Pero Scrum no siempre es adecuado para industrias muy reguladas, proyectos de alcance fijo o organizaciones burocráticas y lentas.
La gestión de proyectos en cascada es excelente para la previsibilidad y establecer expectativas en torno a fechas y entregables específicos. También es adecuada para trabajos con interdependencias y es buena para proyectos con presupuestos fijos y resultados específicos.
Pero la metodología en cascada no es buena para manejar cambios a mitad de proceso (lo que desajusta tu diagrama de Gantt), recibir retroalimentación temprana y continua, o ser eficiente en términos de elaboración de documentación. Así que si tu patrocinador no está muy seguro de lo que quiere, la metodología en cascada puede que no sea la mejor opción.
Ahora que has creado tu lista corta, ¿cómo la reduces a una o dos opciones? Hay muchas herramientas y métodos diferentes para esto. Lo importante es que uses los objetivos y el contexto del proyecto para fundamentar tu decisión.
3. Toma de decisiones en equipo
Una vez que hayas elegido un punto de partida, necesitas ponerte el sombrero de diseño operativo y empezar a tomar decisiones con tu equipo.
Evalúa cada componente de la metodología seleccionada:
- Qué componentes de tu metodología funcionarán y cuáles no para tu proyecto particular.
- ¿Qué necesita una sustitución de otra metodología o una modificación para adaptarse mejor a los parámetros de tu proyecto?
- ¿Qué falta; qué habría que añadir?
Supongamos que decides que el planning poker y los gráficos de burndown basados en velocidad no serán útiles para los clientes, así que los sustituyes por estimaciones más tradicionales de dólares y horas.
También puedes decidir que los standups imponen demasiada presión sobre los equipos que trabajan en proyectos concurrentes, así que los modificas para que sólo se realicen una vez por semana.
El proceso de modificar y sustituir puede volverse más complicado rápidamente, así que procede con intención y cuidado. Algunas de las preguntas que deberías hacerle a tu equipo, a tus partes interesadas y a ti mismo son:
- ¿Qué tiene que suceder y cuándo?
- ¿Cómo debe compartirse la información entre las partes interesadas y los miembros del equipo?
- ¿Cómo deben entregarse y revisarse las cosas?
- ¿Cómo necesitarán las personas involucrarse e interactuar?
- ¿Qué herramientas y plantillas son apropiadas y cuáles necesitan un ajuste?
A continuación, prueba esto en la práctica. Algunas ideas aquí:
- Realiza una sesión de pre-mortem para los líderes de equipo donde puedan cuestionar tu enfoque.
- Organiza una sesión de práctica con juego de roles. Repasen juntos un ciclo o incremento de proyecto para ver cómo va.
- Empieza en pequeño y pilótalo, y recoge feedback continuo en el proceso.
Mientras haces esto, asegúrate de definir cómo medirás el éxito o el fracaso.
Para proyectos de mayor complejidad, documenta tu razonamiento, mapea tu flujo de trabajo de reemplazo, evalúa el riesgo implicado en el cambio y construye el esquema de un playbook que puedas usar para ganar aceptación y para incorporar a las personas involucradas en tu proyecto.
4. Consigue la Aceptación del Equipo
Lo importante aquí es que las personas entiendan el concepto y la razón detrás de él, y que tengan un documento claro y útil al que puedan referirse.
Empieza creando el playbook e incluye un breve resumen fácil de digerir que comunique el enfoque a las personas. Luego, comparte el enfoque y la justificación con los líderes de equipo, preséntalo a tu patrocinador o cliente y logra la aceptación de las partes interesadas clave. Finalmente, usa este documento para incorporar tanto a tu equipo como a tus proveedores.
Trata el playbook como un documento vivo y registra los cambios que realices para que puedas tener una retrospectiva significativa del proyecto después de finalizar.
5. Mide y Refina
Acabas de crear algo nuevo. No está tan probado como las metodologías establecidas, y los parámetros de tu proyecto son lo suficientemente únicos como para que hayas decidido adaptar una metodología desde el inicio.
Entonces, ¿cómo sabes si tu método híbrido está funcionando?
- Hazlo un hábito: revisa regularmente con los miembros del equipo y partes interesadas, aunque sólo sea para obtener comentarios informales y anecdóticos. ¿Cómo sienten que está funcionando esto?
- Combina eso con algunos comentarios formales a través de encuestas a lo largo del proyecto
- Asegúrate de medir siempre tus KPI y tus criterios de éxito
- Haz una retrospectiva de proyecto y documenta las lecciones aprendidas
Ejemplos de Metodologías Híbridas de Gestión de Proyectos
A continuación, algunos ejemplos de híbridos que tienen relevancia en el mundo de la gestión de proyectos y con los cuales puede que ya estés familiarizado.
- Scrumban, que normalmente añade reuniones habituales y estructura a un flujo tipo Kanban continuo.
- Water-Scrum-Fall (o water-agile-fall), que suele ser un proceso iterativo con fases predictivas tipo waterfall al inicio y al final. En otras palabras, un sándwich de scrum.
- Wagile (o watergile), que típicamente tiene una fase inicial de descubrimiento y recopilación de requisitos, seguida por un diseño y desarrollo iterativo.
¿Qué Sigue?
¡Adelante, comienza a personalizar tus metodologías! Si quieres aprender más sobre este tema, tenemos un taller disponible a través de nuestro programa de membresía, o lee sobre otra metodología híbrida "sándwich" aquí.
