Un Viaje por los Ciclos de Vida de los Proyectos: desde lo Predictivo hasta lo Híbrido

 Hablar de ciclo de vida de los proyectos es hablar de una metáfora poderosa: al igual que los seres vivos, todo proyecto tiene un inicio, una madurez y un cierre. Parte de una idea, se alimenta de planificación y ejecución, y llega a su fin cuando los entregables que lo motivaron se hacen realidad.

El concepto de ciclo de vida aplicado a los proyectos hace alusión a los momentos de su progreso. Estas etapas van desde una idea o requerimiento inicial, pasando por la planificación y ejecución del trabajo, hasta la materialización del entregable que motivó el despliegue del proyecto. En este orden de ideas, el ciclo de vida son etapas que se conectan y se transforman en función de las circunstancias. Por eso, conocer los distintos enfoques de ciclo de vida no es un lujo académico: es una necesidad práctica para cualquier gestor que deba equilibrar tiempos, costos, calidad y, sobre todo, expectativas de los interesados.

De acuerdo con la Guía del PMBOK (7a. Ed.), El Dominio del Enfoque de Desarrollo y del Desempeño del Ciclo de Vida aborda las actividades y funciones asociadas con el enfoque de desarrollo*, la cadencia** y las fases del ciclo de vida. La ejecución efectiva de este dominio se enfoca en los siguientes resultados:

• Enfoques de desarrollo que son consistentes con los entregables del proyecto.
• Un ciclo de vida del proyecto que consiste en fases que conectan la entrega del valor del negocio y el valor para los interesados, desde el comienzo hasta el final del proyecto.
• Un ciclo de vida del proyecto que consta de fases que facilitan la cadencia de entrega y el enfoque de desarrollo necesarios para elaborar los entregables del proyecto. (PMI, 2021).

(*) Enfoque de Desarrollo: Método utilizado para crear y desarrollar el producto, servicio o resultado durante el ciclo de vida del proyecto, tal como un método predictivo, iterativo, incremental, adaptativo o híbrido.

(**) Cadencia: Ritmo de las actividades realizadas a lo largo del proyecto.

El Ciclo de Vida Predictivo (Clásico): la Certeza del Plan

Durante mucho tiempo, el ciclo de vida predictivo, también conocido como “en cascada”, fue el enfoque predominante en la gestión de proyectos. En éste, el alcance, el tiempo y el costo se determinan desde las fases iniciales y cada etapa sigue una secuencia lógica: primero se define, luego se diseña, después se ejecuta y finalmente se valida.

Figura 1. Ejemplo de Ciclo de Vida Clásico (Predictivo)Fuente: (PMI, 2017)

Su gran virtud está en la claridad: cuando los objetivos están bien definidos y el entorno no cambia demasiado, este modelo aporta orden y seguridad. Sin embargo, también presenta una limitación evidente: su rigidez. En contextos donde el cambio es la única constante, resulta difícil volver atrás y ajustar lo ya planificado sin generar sobrecostos o retrasos.

Desde el punto de vista de la planificación, la información de alto nivel se va desplegando en planes específicos que tienden a incrementar su nivel de detalle en la medida en que el ciclo de vida avanza.

Tradicionalmente, el Ciclo de Vida Clásico del Proyecto ha sido concebido contemplando las fases de: a) Inicio del proyecto, b) Organización y preparación, c) Ejecución del trabajo, y d) Cierre del proyecto.

Figura 2. Estructura del Ciclo de Vida ClásicoFuente: (PMI, 2017)

Generalmente se opta por ciclos de vida predictivos cuando:

• El producto a entregar se comprende bien.
• Existe una base práctica significativa en la industria.
• El producto debe ser entregado en su totalidad para que tenga valor para los grupos de interesados.

Las metodologías en cascada son consideradas rígidas, poco flexibles y con muchas restricciones. Una vez terminada cada etapa, se realiza una serie de validaciones que permiten determinar si los entregables cumplen con los requisitos que les habilitan para pasar a la siguiente etapa.

Con todo, no conviene subestimar este enfoque. Proyectos de infraestructura, construcción de plantas industriales o implementación de normas regulatorias siguen encontrando en el ciclo de vida clásico una herramienta confiable.

Ciclo de Vida Iterativo (Incremental): Aprender en el Camino

La práctica demostró que no siempre es posible anticiparlo todo. Así nacieron los enfoques iterativos e incrementales. La diferencia puede sonar sutil, pero es significativa:

• En lo iterativo, se repiten fases de manera intencional, permitiendo ajustar lo aprendido y afinar el producto con cada vuelta del ciclo.
• Se van sumando funcionalidades o entregables de forma sucesiva, de modo que el producto final se construye poco a poco. Esto permite que se vaya incrementando el nivel de entendimiento del resultado final por parte del equipo del proyecto.
• Los incrementos van agregando de forma sucesiva, funcionalidades y características al entregable.

En otras palabras, se trata de una lógica que facilita la incorporación de retroalimentación y la reducción de riesgos. Resulta especialmente valiosa en proyectos complejos, donde el resultado final no puede definirse con claridad desde el inicio. Así, en el desarrollo de un software empresarial, cada iteración puede incluir pruebas piloto con usuarios reales, mientras que cada incremento añade módulos específicos como facturación, nómina o gestión de inventarios.

Figura 3. Estructura del Ciclo de Vida Iterativo/ Incremental

Los proyectos de gran envergadura suelen ejecutarse de manera iterativa precisamente para disminuir la incertidumbre. Este enfoque permite al equipo integrar de forma continua las lecciones aprendidas y ajustar el rumbo entre ciclos. En términos generales, se recurre a este tipo de ciclo de vida cuando:

• La organización necesita gestionar objetivos y alcances cambiantes.
• Para reducir la complejidad de un proyecto.
• Las liberaciones parciales benefician y generan valor para los interesados sin afectar el entregable o conjunto de entregables finales.

La gran ventaja aquí es el aprendizaje continuo: se avanza, se evalúa, se corrige y se vuelve a avanzar. Este modelo potencia la resiliencia del equipo y mejora la alineación con las expectativas reales de los clientes.

Ciclo de Vida Ágil (Adaptativo): Iteraciones Estandarizadas 

En un mundo marcado por la volatilidad, la incertidumbre y la necesidad de innovación constante, los ciclos de vida ágiles han ganado protagonismo.

En esencia, un ciclo ágil es iterativo e incremental, la diferencia estructural radica en que las iteraciones son rápidas, generalmente con unas duraciones y costos fijos. No se exige un catálogo completo de requisitos al inicio, sino que se priorizan funcionalidades y se ajusta el rumbo con cada entrega. La participación activa de los interesados es fundamental: no basta con recibir un producto terminado, se trata de co-construirlo durante el camino.

Son también conocidos como ciclos adaptativos o ciclos orientados al cambio, que buscan responder a niveles altos de cambio y procuran la participación activa y permanente de los interesados. Generalmente, en cada iteración se pueden ejecutar varios procesos de diversa naturaleza.

El resultado es un producto que evoluciona de la mano de quienes lo usarán, reduciendo el riesgo de entregar algo que no responde a las necesidades reales. Además, los métodos ágiles fomentan la motivación del equipo, al permitirle visualizar avances tangibles en lapsos cortos.

Algunas de las razones para utilizar ciclos ágiles son:

• Generar entregables intermedios.
• Validarlos con el cliente.
• Recibir su retroalimentación.
• Utilizarlos los resultados como insumos de partida en las siguientes iteraciones.

Al comienzo de cada iteración el equipo debe establecer las funcionalidades hacía donde se orientarán los esfuerzos, no obstante, es importante aclarar que para iniciar no se requiere obligatoriamente una matriz detallada de requisitos ni que todos los requisitos estén detallados al mismo nivel. Se va avanzando a través de los ciclos, y en cada iteración se aborda un número específico de características. En la siguiente iteración se irán identificando nuevas características, hasta completar el alcance total.

Figura 4. Estructura del Ciclo de Vida Ágil

Al final de cada iteración el producto debe estar listo para su revisión por el cliente. Esto no significa que se requiera que el cliente acepte la entrega, sino que el producto no debe presentar características sin terminar, incompletas o inutilizables. Los patrocinadores y el cliente deben estar continuamente involucrados en el proyecto para proporcionar retroalimentación a medida que se hacen entregas y para garantizar que el trabajo pendiente asociado al producto refleja sus necesidades actuales.

Generalmente se opta por métodos ágiles:

• En entornos que cambian rápidamente.
• Cuando los requisitos y el alcance son difíciles de definir con antelación.
• Cuando es posible definir pequeñas mejoras graduales que aportarán valor a los interesados.

Existen dos modelos básicos para este tipo de ciclos de vida:

• Enfocados en las iteraciones: Se basan en ciclos muy rápidos, con una duración de 1 a 4 semanas, en las que se debe realizar el trabajo. En la metodología Scrum, por ejemplo, a cada iteración se le denomina Sprint.
• Centrados en el flujo del trabajo: Por ejemplo, Kanban en el que se establecen claramente las delimitaciones sobre la secuencia de actividades, utiliza tableros visuales para gestionar el flujo de trabajo y detectar cuellos de botella.

Los ciclos ágiles también han transformado la relación entre cliente y proveedor: ahora los clientes esperan participar activamente, revisar entregas tempranas y priorizar funcionalidades en tiempo real. El alcance global del proyecto se va cumpliendo incrementalmente, en la medida en que se van desarrollando componentes o satisfaciendo requisitos.

Figura 5. Marco de Trabajo de SCRUMFuente: Scrum.org 

Ciclo de Vida Híbrido: lo Mejor de dos Enfoques

¿Qué ocurre cuando ni lo predictivo ni lo ágil, por sí solos, son suficientes? Allí entra en juego el ciclo de vida híbrido, una alternativa cada vez más popular en organizaciones que necesitan combinar certeza y flexibilidad.

• Un ciclo híbrido toma elementos de los modelos clásicos y de los ágiles, buscando adaptarse al contexto del proyecto:
• Puede que la planificación inicial (tiempo, presupuesto, objetivos generales) se haga de forma predictiva, para dar seguridad a los patrocinadores.
• Mientras que la construcción del producto o servicio se aborde con metodologías ágiles, permitiendo ajustes y entregas incrementales.

Por ejemplo, en la construcción de un hospital, la obra civil puede seguir un enfoque en cascada por sus exigencias técnicas y legales, mientras que el desarrollo del software de historias clínicas electrónicas se maneja con Scrum.

Lo híbrido no implica indefinición, sino la capacidad de usar el enfoque correcto en la fase correcta. Para el gestor, implica un reto adicional: liderar equipos que pueden estar trabajando bajo lógicas distintas y asegurar la coherencia global del proyecto.

Este enfoque refleja una madurez creciente en la gestión: reconocer que no existe un modelo universal y que la verdadera habilidad está en saber combinar herramientas para alcanzar los objetivos.

Elegir el Ciclo con Criterio

Frente a la diversidad de opciones, surge una pregunta clave: ¿Cómo elegir el ciclo de vida adecuado? No se trata de modas ni de dogmas, sino de analizar el nivel de incertidumbre, la naturaleza del entregable, la cultura organizacional y, sobre todo, las expectativas de los interesados.

• Si el proyecto es de bajo riesgo, con entregables claramente definidos, lo predictivo sigue siendo válido.
• Si la complejidad es alta y la innovación es central, lo ágil será más pertinente.
• Si se necesita estructura en unas fases y flexibilidad en otras, el híbrido es la mejor respuesta.

El arte de la gestión está en esa capacidad de discernimiento. Como responsables de la gestión, debemos recordar que el ciclo de vida es un marco, no una camisa de fuerza. La clave está en que nos permita alcanzar los objetivos con eficiencia, adaptándonos cuando sea necesario y garantizando valor para los interesados.

Conclusiones

En La Esquina de la Gestión entendemos que cada proyecto tiene su propia narrativa. Algunos se asemejan a novelas clásicas, lineales y bien estructuradas; otros recuerdan a colecciones de cuentos, donde cada capítulo aporta un valor particular; y muchos hoy se parecen a series abiertas, cuyo guion se escribe de la mano de los interesados.

El ciclo de vida no es simplemente un conjunto de fases técnicas, sino la arquitectura que conecta la visión con el resultado. Elegir entre lo predictivo, lo iterativo, lo ágil o lo híbrido implica decidir cómo gestionar la incertidumbre, aprender en el proceso y generar valor sostenible.

Nuestra responsabilidad como gestores es dar sentido a esa arquitectura: capitalizar sus fortalezas, mitigar sus limitaciones y, sobre todo, convertir cada proyecto en una historia de transformación. La verdadera madurez no consiste en aferrarse a un único modelo, sino en cultivar la sensibilidad y la pericia necesarias para combinar enfoques con criterio. Solo así los proyectos se convierten en auténticos espacios de innovación, aprendizaje e impacto organizacional, aun en medio de contextos marcados por la incertidumbre y la complejidad.

Referencias

• Project Management Institute. (2021). Guía de los fundamentos para la dirección de proyectos (7ª ed). Pennsylvania: PMI Publications.
• Project Management Institute. (2017). Guía de los fundamentos para la dirección de proyectos (6ª ed). Pennsylvania: PMI Publications.
• Scrum.org. (2024). What is Scrum?. https://www.scrum.org/resources/what-scrum-module

La PMO en la Guía del PMBOK (7a. Ed.): del proceso a la creación de valor

De acuerdo con el abordaje de la Séptima Edición de la Guía del PMBOK®, la Oficina de Dirección de Proyectos (PMO) deja de parecer una ventanilla de trámites para convertirse en la dirección de la orquesta del valor. La arquitectura del Estándar —ahora basada en principios y dominios de desempeño— desplaza el protagonismo desde la adhesión a procesos hacia la creación de valor verificable. La PMO que encaja en este marco ya no vive de listas de chequeo interminables ni de reportes exuberantes; vive de conversaciones con evidencia, de decisiones oportunas y de resultados que los usuarios pueden reconocer. Es un cambio de enfoque, que pasa de custodiar documentos a orquestar capacidades. Y cuando esa orquesta suena, la estrategia deja de ser discurso para convertirse en ejecución.

El contexto explica la mutación. Los proyectos ya no se despliegan en mesas estables: conviven con disrupciones tecnológicas, marcos regulatorios cambiantes y expectativas sociales volátiles. La PMO tradicional, pensada para garantizar conformidad, se queda corta si no es capaz de leer la incertidumbre, negociar prioridades y habilitar aprendizaje rápido. La séptima edición, al ordenar la conversación en dominios de desempeño, nos recuerda que el rigor no desaparece: se reubica. En vez de pedir el mismo ritual a todos, invita a modular la gobernanza según criticidad, exposición al riesgo y madurez del equipo, con una pregunta como brújula: ¿qué mínima estructura necesitamos para que el valor ocurra antes, con menos ruido y con menos retrabajo?

Figura 1. La PMO como habilitador: del proceso al valor

La primera señal del cambio es el lenguaje. La Guía insiste en resultados y beneficios antes que en el culto al proceso. Una PMO útil pone orden, sí, pero sobre todo habilita: comparte prácticas, presta recursos, acompaña a los equipos para que se muevan con soltura entre enfoques predictivos, adaptativos e híbridos. No impone una partitura única; alinea compases. Eso se traduce en mecanismos ligeros que acerquen datos a las decisiones. Para la alta dirección, una página clara con tres focos (beneficios esperados vs. realizados, riesgo agregado del portafolio y capacidad disponible) vale más que un océano de láminas. Para los equipos, menos casillas que llenar y más definición de preparado y terminado, demos que muestran aprendizaje y retrospectivas que producen mejoras concretas.

¿Y la disciplina? Permanece, pero ejercida con criterio. Donde antes se exigía la misma lista de cotejo a cualquier iniciativa, ahora se calibran niveles de control. Un proyecto con impacto en seguridad o cumplimiento normativo exige trazabilidad estricta y puntos de control formales; un experimento exploratorio necesita aire para equivocarse barato. Esta diferenciación no relativiza la calidad: la acerca a su razón de ser. La gobernanza será tanta como el valor la requiera. Y cuando el estándar habla de dominios, legitima esa flexibilidad responsable: la PMO diseña controles que sirven al resultado, no al ritual.

El catálogo de servicios ilustra el viraje. Siguen existiendo estándares y plantillas, pero ya no alcanzan para justificar la existencia de la PMO. Se suman piezas con impacto tangible: priorización por valor y beneficios, acompañamiento en casos de negocio (business cases) con escenarios y sensibilidades, gestión de dependencias entre equipos, apoyo en análisis de capacidad, coaching a sponsors y Product Owners para decidir mejor, y un núcleo de datos que permite comparar iniciativas heterogéneas con un lenguaje común. En organizaciones con fuerte componente ágil, la PMO se transforma en centro de excelencia o en oficina de entrega de valor: difunde prácticas como criterios de aceptación y Definition of Done (DoD)/ Definition of Ready (DoR), promueve tableros Kanban con límites WIP (Work in progress) y ayuda a sincronizar financiación con la cadencia real de las entregas.

El portafolio es el escenario donde la PMO revela su utilidad. El hábito de “coleccionar proyectos” se combate con una disciplina sencilla: revisar la lista con cadencia, decidir qué detener, qué acelerar y qué redefinir. Esa capacidad de decir “no” a tiempo ahorra dinero y libera foco. No se trata de caprichos: una PMO madura justifica las decisiones con señales —adopción de usuarios, reducción del tiempo de ciclo, mitigación de un riesgo sistémico o creación de una capacidad habilitante— y con umbrales acordados por la organización. Cuando una iniciativa avanza, lo hace por evidencia; cuando se cancela, se explica con honestidad y se documentan aprendizajes para no tropezar dos veces con la misma piedra.

Gestionar la incertidumbre es otra frontera. En versiones anteriores, la gestión de riesgos solía vivir como lista aparte. El enfoque de la séptima edición la integra en el dominio de la incertidumbre y mueve la conversación al centro del tablero: ya no basta con enumerar amenazas; importa comprender la exposición total del proyecto y del portafolio, el apetito y los umbrales de riesgo, las reservas disponibles y los disparadores que activan respuestas. La PMO sirve de curador: evita el maquillaje de la complejidad, fomenta hipótesis y experimentos que convierten dudas en datos, y ayuda a ajustar el sistema de trabajo para que el costo del cambio no se dispare. Es menos auditoría y más navegación.

La cadencia importa. No solo la cadencia de entrega —una entrega única, hitos múltiples o ciclos periódicos—, también la cadencia de dirección: los momentos en que la organización guía, financia y reasigna recursos. En entornos adaptativos e híbridos, la dirección sucede a intervalos fijos (al cierre de cada sprint, por ejemplo); en contextos predictivos, se establecen puntos de control formales para revisar avance y recibir retroalimentación. El tipo de entregable y el enfoque de desarrollo influyen en la frecuencia de esas citas, y esas citas marcan el pulso del riesgo. La PMO que diseña bien la cadencia encaja decisiones, métricas y reservas con el ritmo del valor, sin forzar a todos a bailar la misma música.

Figura 2. Cadencia de Entrega y Enfoque de Desarrollo

Fuente: Guía del PMBOK (PMI, 2021, p.46)

El cambio de rol se percibe en lo cotidiano. Una PMO obsesionada con el papeleo tiende a multiplicar formularios y crear embudos de aprobación; una PMO orientada a valor observa dónde se atasca el flujo y actúa con detalles prácticos que no ganan premios, pero sí confianza. Con esa confianza, la oficina puede pedir más: pedir datos mejor curados, comprometer tiempos de respuesta, o frenar iniciativas que diluyen el portafolio. De ese intercambio nace la legitimidad.

De acuerdo con la séptima edición de la Guía del PMBOK (PMI, 2021). las organizaciones con estructuras más planas, iniciativas centradas en el cliente y enfoques de entrega más adaptables pueden adoptar una estructura de Centro de Excelencia Ágil (ACoE) u Oficina de Entrega de Valor (VDO), es este sentido, un ACoE/VDO, pone el acento en habilitar capacidades más que en mandar. Acerca coaching a equipos y líderes, estandariza artefactos mínimos para comparar progreso sin homogenizar metodologías, y ayuda a sincronizar dependencias entre productos. Un hilo frecuente es la financiación por producto: presupuestos que se mueven con el valor, no con la duración del proyecto. La oficina también facilita prácticas de descubrimiento —prototipos, pruebas con usuarios, hipótesis medibles— para validar antes de escalar. Todo para que el gasto más caro, el del retrabajo tardío, sea la excepción y no la costumbre.

Las métricas merecen un aparte. Medir por medir hace daño. La tentación de instrumentarlo todo produce ruido y desata conductas defensivas. La PMO debería pactar con la alta dirección un conjunto compacto, comprensible y estable: beneficios esperados contra realizados, salud del flujo (lead time, throughput, tasa de retrabajo), calidad (densidad de defectos, satisfacción de usuario), y riesgo agregado. En contextos predictivos, valor ganado y variaciones siguen siendo útiles; en entornos ágiles, las métricas de flujo cuentan mejor la historia. Lo esencial es que los números permitan decidir: ¿seguimos, paramos o cambiamos algo ya?

Para que ese sistema eche raíces, hay dos palancas invisibles: talento y cultura. Ningún marco compensa un equipo agotado o una dirección que rehúye la realidad. La PMO de alto impacto cuida perfiles especializados (T‑shaped), promueve rotaciones sanas, crea comunidades de práctica y ofrece rutas de carrera dual (experta y de liderazgo). Y cultiva una cultura de transparencia: reconocimiento al que simplifica, espacios seguros donde un miembro del equipo pueda decir “no llegamos” sin miedo. La oficina deja de ser policía y se vuelve un socio que facilita que la verdad llegue antes a la mesa.

Figura 3. Enfoque Tradicional de los Marcos de Trabajo de las PMO

Fuente: Basado en PMI, 2013

También ayuda una estratificación inteligente. En muchas organizaciones conviene combinar PMO de línea (cerca del negocio), servicios compartidos transversales y una Oficina Corporativa de Dirección de Proyectos (EPMO) que converse con estrategia y finanzas. La EPMO evita el “mosaico inconexo de proyectos” —cada uno con su sistema de métricas atomizado— y ofrece comparabilidad; las PMO de dominio preservan contexto para moverse rápido. No es un organigrama rígido, sino un diseño que permite coordinar sin asfixiar, con reglas claras de escalamiento cuando un problema rebasa el alcance de un equipo.

No faltan riesgos: burocratización, desalineación estratégica, indicadores sin criterio o pérdida de legitimidad. Se mitigan con principios sencillos: mínimo suficiente (poda trimestral de artefactos), reglas de terminación anticipada para proyectos zombis, conjunto de KPI pequeño y útil, y patrocinadores visibles que den la cara. Cuando la oficina cae en alguno de esos vicios, la cura es volver al propósito: estamos aquí para acelerar decisiones que crean valor sostenible. Todo lo demás debería ser accesorio.

Una escena final para medir el avance. El equipo presenta un incremento de producto o un entregable clave. La PMO no está al fondo tomando lista: está facilitando la conversación. Se muestran beneficios y riesgos con honestidad, se presentan alternativas con el lenguaje que la dirección entiende, y se decide sin dilaciones. La reunión termina unos minutos antes y el tablero del portafolio refleja de inmediato el cambio. Nadie celebra por la plantilla perfecta; se celebra por el impulso renovado. Si esa escena todavía suena lejana, quizá sea hora de releer la Séptima Edición con ojos de valor y rediseñar la oficina como lo que siempre debió ser: el orquestador que hace que la estrategia suceda.

Referencias

• Project Management Institute. (2021). Guía de los fundamentos para la dirección de proyectos (7ª ed). Pennsylvania: PMI Publications.
• Project Management Institute. (2013). Pulso de la Profesión de PMI: Marcos de trabajo de la PMO. http://www.pmi.org/~/media/PDF/Knowledge%20Center/Spanish/pmo-frameworks-report.ashx
• Redondo. A. (2016). Oficina de Gestión de Proyectos (Project Management Office - PMO). https://alredsa.blogspot.com/2016/02/oficina-de-gestion-de-proyectos-project.html

De la Gestión de los Riesgos al Dominio de la Incertidumbre en La Guía del PMBOK (7a. Edición)

La séptima edición de la Guía del PMBOK® representa un giro radical en la forma de concebir la dirección de proyectos. Tras muchos años de estructurar la gestión como una secuencia de procesos y áreas de conocimiento, el estándar adopta doce principios y ocho dominios de desempeño que responden mejor a los entornos VICA/VUCA (volatilidad, incertidumbre, complejidad y ambigüedad) dominante. Esta evolución es especialmente evidente en la manera como se aborda el riesgo: se pasa de la subdisciplina acotada de la Gestión de los Riesgos, a un Dominio de Desempeño de la Incertidumbre donde el riesgo es solo una de múltiples facetas. El propósito de este post, es sintetizar y analizar esa transición, ilustrando cómo el nuevo enfoque amplía la mirada, refuerza la creación de valor y se integra con los demás dominios.

 

De la gestión de los riesgos al gobierno de la incertidumbre 

En las ediciones anteriores de la Guía del PMBOK® el riesgo se gestionaba mediante un flujo lineal: planificar cómo gestionar, identificar, analizar cualitativa y cuantitativamente, planificar respuestas, implementar y controlar. El resultado era un registro de riesgos, matrices de probabilidad–impacto y, con suerte, un conjunto de planes de contingencia. Ese modelo funcionaba cuando los proyectos se desplegaban en entornos relativamente estables, pero muchas iniciativas actuales enfrentan disrupciones constantes: tecnologías emergentes, ciclos regulatorios acelerados, nuevos competidores digitales, pandemias y eventos climáticos extremos. Bajo estas condiciones, el riesgo no se limita a una lista de “cosas que podrían salir mal”, y se asume como la manifestación de un espectro más amplio de incertidumbre. 

El Estándar reconoce esta realidad y crea el Dominio de Desempeño de la Incertidumbre, cuyo objetivo es asegurar que el equipo de proyecto identifique, valore y navegue todas las formas de lo desconocido.  

Este dominio se apoya en la idea de que la incertidumbre no siempre es negativa: también es fuente de oportunidades. Por tanto, gestionar incertidumbre implica generar iniciativas para maximizar el riesgo positivo y minimizar el negativo, equilibrando la exposición global dentro del apetito aceptable para los interesados.

 Figura 1. Esquema del Dominio de Desempeño de la Incertidumbre

Fuente: Basado en (PMI, 2021)

El principio “Optimizar las respuestas a los riesgos” 

El Estándar enumera doce principios; el décimo, Optimizar las respuestas a los riesgos, condensa la filosofía moderna: “los equipos buscan maximizar oportunidades y reducir amenazas, de forma costo‑efectiva y acordada con los interesados”. Este principio introduce cuatro ideas clave:  

1. Dualidad del riesgo: Amenazas y oportunidades coexisten; ignorar las segundas es desperdiciar potencial de valor.
2. Alineación con el apetito: La organización define cuánto riesgo está dispuesta a asumir; el equipo calibra sus estrategias para no exceder ese umbral. 
3. Asignación de propiedad: Cada riesgo relevante debe tener un responsable que disponga de autoridad y presupuesto para ejecutar la respuesta. 
4. Iteración continua: El riesgo es dinámico, por consiguiente, su gestión requiere revisiones recurrentes, no hitos esporádicos.  En consecuencia, el plan de riesgos ya no es un documento estático sino un “backlog vivo” sincronizado con la revisión de alcance, cronograma, presupuesto y calidad.

 Figura 2. Principio: Optimizar la Respuesta a los Riesgos

Fuente: (PMI, 2021)

Anatomía de la incertidumbre: riesgo, ambigüedad, complejidad y volatilidad 

De forma general, la Guía del PMBOK (7ª Ed.) asume la incertidumbre como la falta de comprensión y conciencia de los incidentes, eventos, caminos a seguir o soluciones a buscar. La incertidumbre se refiere a las probabilidades de acciones, reacciones y resultados alternativos.

Para desenvolverse en este dominio hay que distinguir varios matices:

• Riesgo: Evento o condición incierta con efecto positivo o negativo en los objetivos.
• Ambigüedad: Falta de claridad sobre significados, causas o soluciones. La ambigüedad puede surgir de tener muchas opciones o de una falta de claridad sobre la elección óptima.
• Complejidad; Conjuntos de elementos interconectados cuyo comportamiento agregado es impredecible, y que puede ser difícil de gestionar debido al comportamiento humano, el comportamiento del sistema y la ambigüedad.
• Volatilidad: Cambios rápidos e inesperados.  

En este sentido, cada matiz demandará tácticas específicas. La ambigüedad se reduce con elaboración progresiva, experimentos y prototipos. La complejidad se aborda con desacople, simulación y diversidad de perspectivas. La volatilidad se mitiga con reservas de cronograma y costo, y análisis de alternativas. El riesgo se gestiona con las estrategias clásicas, ahora integradas en un mosaico más amplio que considera patrones emergentes y aprendizaje adaptativo.

  

Apetito, umbral y riesgo general del proyecto 

El apetito al riesgo refleja el nivel de incertidumbre que los interesados están dispuestos a aceptar en busca de recompensa; el umbral de riesgo cuantifica la variación permitida sobre un objetivo (p. ej., ± 5 % en costo). La séptima edición de la Guía del PMBOK® enfatiza que estos parámetros deben establecerse al inicio y revisarse cuando el contexto cambie.

Un concepto que se fortaleció es el riesgo general del proyecto: la exposición agregada proveniente de todas las fuentes de incertidumbre. No basta con vigilar los riesgos individuales; hay que monitorear si la suma de amenazas y oportunidades mantiene la iniciativa dentro de un rango aceptable. Si el riesgo global excede el apetito, se activan estrategias a nivel portafolio: posponer, redefinir alcance o incluso cancelar.

El riesgo general a menudo depende de la complejidad, la ambigüedad y la volatilidad. Las respuestas al riesgo general del proyecto son las mismas que para las amenazas y oportunidades individuales, aunque las respuestas se aplican al proyecto en general en lugar de a un evento específico. Si el riesgo general en el proyecto es demasiado alto, la organización puede optar por cancelar el mismo. (PMI, 2021).

Estrategias revisadas para amenazas y oportunidades 

El equipo del proyecto debe buscar de forma anticipada los riesgos durante todo el ciclo de vida, con el fin de prevenir o reducir el impacto negativo y las consecuencias de las amenazas y, a la vez, aprovechar o potenciar el impacto positivo o efectos de las oportunidades. Para ambos tipos de riesgo existen diversas estrategias de respuesta que pueden prepararse con antelación y aplicarse cuando la situación lo requiera. El catálogo de cinco tipos de estrategias para hacer frente al desafío derivado para cada uno de los riesgos se mantiene, pero se contextualiza: 

Oportunidades:

• Explotar: el equipo interviene directamente para asegurar que la oportunidad se concrete.
• Escalar: se traslada al patrocinador u otra instancia porque la oportunidad rebasa el alcance o la autoridad del proyecto.
• Compartir: se asigna la responsabilidad a un tercero capaz de aprovechar mejor el beneficio.
• Mejorar: se incrementan proactivamente la probabilidad o el impacto positivo, idealmente desde fases tempranas.
• Aceptar: se reconoce la oportunidad sin planificar acciones adicionales, observándola hasta que surja la ocasión de actuar.

 Figura 2. Estrategias para hacer frente a las Oportunidades

 Amenazas:

• Evitar: eliminar por completo la amenaza o aislar el proyecto de sus efectos.
• Escalar: remitir la amenaza a los patrocinadores u otro nivel, cuando excede el alcance o la autoridad del director del proyecto.
• Transferir: ceder la responsabilidad a un tercero que asuma y gestione el riesgo y sus posibles consecuencias.
• Mitigar: reducir de forma proactiva la probabilidad o el impacto de la amenaza, preferiblemente desde etapas tempranas.
• Aceptar: reconocer el riesgo sin acciones proactivas; puede ser aceptación pasiva (sin reacción) o activa (preparar un plan de contingencia para ejecutarlo si se materializa la amenaza).

 Figura 2. Estrategias para hacer frente a las Amenazas

La diferencia entre los tipos de estrategias está en la velocidad y en la experimentación: el estándar alienta acciones tempranas y prototipos para convertir hipótesis en datos. Además, subraya la importancia de documentar riesgo residual (lo que queda tras la respuesta) y riesgos secundarios (los creados por la misma respuesta).

 

Herramientas para navegar la incertidumbre 

Gestionar la incertidumbre demanda una cultura de transparencia: se recompensa la detección temprana y no se penaliza al mensajero. Las revisiones semanales de estatus, las retrospectivas (Scrum) y las sesiones de lecciones aprendidas son vehículos para actualizar el registro de incertidumbre, reasignar reservas y ajustar prioridades. Las métricas evolucionan de contar riesgos a medir tendencias: densidad de defectos, tiempo de ciclo (lead time) hasta cerrar un riesgo, tasa de oportunidades capitalizadas, variación del riesgo general en el tiempo, entre otras.

Entre de las técnicas y herramientas que pueden ser de gran utilidad para afrontar los desafíos de la incertidumbre, se encuentran:

1. Matrices de probabilidad–impacto renovadas con factores de ambigüedad y volatilidad.  
2. Histogramas y simulaciones Monte Carlo para riesgo agregado.  
3. Modelos EMV / ROI Ajustado al riesgo que sitúan decisiones en clave financiera.  
4. Tableros Kanban orientados a riesgo, donde cada impedimento visible se trata como señal de incertidumbre emergente.  
5. Reservas para contingencias y de gestión,
6. recalibradas conforme cambian los supuestos.  
7. Revisiones de cadencia corta (stand‑ups, demos, retrospectivas) para detectar y responder de forma temprana.

Nota: La séptima edición introduce el concepto de cadencia como el ritmo que marca el momento y la frecuencia con que se liberan los entregables—ya sea una única entrega, hitos múltiples o lanzamientos periódicos—y, al mismo tiempo, regula cómo se ejerce la dirección del proyecto: en enfoques adaptativos e híbridos esa guía y el intercambio de conocimiento siguen intervalos fijos (p. ej., al cierre de cada sprint), mientras que en modelos predictivos se concretan en puntos de control formales para revisar el progreso y recibir retroalimentación.

 

Conclusiones  

La Guía del PMBOK® Séptima Edición no rechaza la gestión de riesgos tradicional: la trasciende al ubicarla dentro de un espectro más amplio. Al concentrarse en el Dominio de Desempeño de la Incertidumbre, los equipos ganan una brújula que señala no sólo dónde están las amenazas, sino también dónde habita la innovación.

El director de proyecto del siglo XXI necesita combinar pensamiento sistémico, disciplina financiera y mentalidad experimental para transformar incertidumbre en ventajas competitivas que fortalezcan el despliegue estratégico de la organización. Quien domine este arte entregará proyectos más resilientes, generará confianza en los interesados y abrirá espacios para oportunidades que, bajo una óptica puramente defensiva, habrían pasado desapercibidas.

Referencias

• Project Management Institute. (2021). Guía de los fundamentos para la dirección de proyectos (7ª ed). Pennsylvania: PMI Publications.
• Redondo, A. (2016). Áreas de Conocimiento de la Dirección (Gestión) de Proyectos.  http://alredsa.blogspot.com.co/2016/02/areas-de-conocimiento-de-la-direccion.html

Del cilindro musical a los bits: el viaje rebelde de los telares que encendieron la chispa de la computación

Cuando pensamos en los orígenes de la informática, es fácil saltar directamente a Charles Babbage o a los tabuladores de Herman Hollerith. Sin embargo, medio siglo antes de Babbage, cuatro inventores franceses, Basile Bouchon, Jean-Baptiste Falcon, Jacques de Vaucanson y Joseph Marie Jacquard, desarrollaron sistemas textiles que introdujeron tres ideas clave de la computación: programabilidad, almacenamiento externo de instrucciones y automatización repetible. Su innovación fue tan profunda que las tarjetas perforadas que gobernaban sus telares siguieron vigentes en los mainframes de IBM hasta los años 1970.

El cilindro musical: la primera memoria programable

Mucho antes de que un telar levantara su primer hilo automático, la música mecánica ya había descubierto el poder de codificar acciones en un soporte externo. Desde los órganos de manivela medievales hasta los rollos de pianola (piano-rolls) del siglo XIX, los cilindros con pines (o las cintas perforadas) traducían una partitura en golpes exactos para controlar las notas y los pedales. Cada vuelta del cilindro era un ciclo de instrucción: leer la “bitácora” de pines, activar la nota correspondiente y avanzar al siguiente latido. Esa secuencia discreta de órdenes, almacenada fuera del mecanismo que las ejecutaba, es el rasgo que conecta directamente aquellos autómatas musicales con los computadores modernos.

 

Figura 1. Ilustración de un órgano de barril

 

Basile Bouchon (1725): la cinta perforada como “memoria”

Bouchon, hijo de un constructor de órganos de Lyon, adaptó la lógica de los cilindros musicales al telar: sustituyó al ayudante que tiraba de los hilos por una tira continua de papel perforado. Cada columna de perforaciones indicaba qué hilos elevar, convirtiendo la cinta en un “programa” mecánico y reutilizable. Fue la primera aplicación industrial de una máquina semi-automática.

El truco de Bouchon fue trasplantar la lógica de los autómatas musicales —cilindros con clavijas que activaban martillos para tocar notas— al mundo textil. En vez de golpear cuerdas de órgano, las clavijas virtuales eran agujeros; y las “notas” eran los hilos de urdimbre que se alzaban o quedaban quietos. Con esa metáfora sonora, el tejido se convirtió en una partitura visual que la máquina podía “interpretar” sin fatiga.

En los órganos de barril, los pines funcionan como ceros y unos: “pin fuera” (1) golpea la nota; “sin pin” (0) la silencia. Bouchon cambió las notas por hilos y los pines por agujeros, pero mantuvo intacta la idea de que un soporte perforado puede almacenar instrucciones binarias ejecutables en bucle. Si los cilindros musicales fueron el primer disco duro, su telar fue el primer procesador que los leía.

Paralelo informático: la cinta de papel es un antecesor directo de la cinta perforada usada para cargar software en los primeros computadores y, conceptualmente, de la memoria externa secuencial.

 

Jean-Baptiste Falcon (1728): de cinta a tarjetas enlazadas

Falcon amplió la idea de su mentor con tarjetas rectangulares unidas por cordel: cada tarjeta controlaba una pasada de la lanzadera. El formato modular facilitaba editar o reordenar patrones —un “código fuente” intercambiable— y permitía diseños más anchos al duplicar la cantidad de agujeros por fila.

Paralelo informático: las tarjetas individuales anticipan la noción de registros discretos de información y la posibilidad de debugging físico (reemplazar una tarjeta defectuosa).

Jacques de Vaucanson (1745): el primer telar completamente automático

Famoso por sus autómatas, Vaucanson integró cilindros con levas y tarjetas para eliminar la intervención humana durante el tejido. Su telar —aunque poco exitoso comercialmente— demostró que la lógica perforada podía accionar todos los movimientos del telar, no solo la selección de hilos.

Paralelo informático: Vaucanson introdujo la idea de que un único medio perforado podía orquestar múltiples ejes de movimiento, anticipando el control multi-eje de los robots industriales y de las máquinas de Control Numérico Computarizado (CNC).

Joseph Marie Jacquard (1801-1804): el sistema programable que conquistó la industria

Jacquard combinó las mejores ideas previas y añadió un prisma cuadrado que rotaba las tarjetas perforadas, multiplicando la complejidad de patrones sin incrementar el tamaño del telar. Su máquina contaba con ocho filas de agujas y ganchos capaces de levantar diferentes hilos de urdimbre, de forma independiente; ello permitía “dibujar” brocados, damascos o arabescos con un detalle sin precedentes y, además, sobre cada disparo de la lanzadera, no cada cuatro como en máquinas anteriores. El diseño se almacenaba en un carrete infinito de cartones, que funcionaba como una memoria externa reescribible, por consiguiente, bastaba con “cargar” otro juego de tarjetas para cambiar de patrón en minutos, sin tocar el hardware.

Es importante acotar que en 1812 ya había más de 11000 telares Jacquard funcionando en Francia. 

Figura 2. Ilustración simulada de un telar de Jacquard  

Paralelo informático: 

Concepto en el telar Jacquard	Equivalente en un computador	Impacto
Cadena de tarjetas perforadas	Medio de entrada/programa	Separa hardware de software
Cada tarjeta = 1 fila de diseño	Instrucción secuencial	Imita ciclo de instrucción
Reemplazo de tarjetas	Reprogramación instantánea	Facilita iteración y depuración
Ganchos activados/no activados	Bits (1/0)	Primer uso masivo de codificación binaria

 

De Lyon a Silicon Valley: influencia directa en la historia de la computación 

• Charles Babbage visitó Lyon y conservó un retrato de Jacquard tejido por el propio telar; adoptó la tarjeta perforada como dispositivo de entrada/salida para su Máquina Analítica (1837).
• Herman Hollerith reutilizó el principio para tabular el censo estadounidense de 1890, fundando la empresa que luego sería IBM.
• Las tarjetas dominaron la programación hasta la llegada de los discos magnéticos, y la idea de datos codificados físicamente evolucionó hacia las memorias de núcleo y, más tarde, hacia los chips de silicio.

 

Conclusiones

Los inventores de los telares perforados no buscaban crear computadores, pero establecieron los cimientos conceptuales de:

1. Programabilidad: un medio externo que contiene instrucciones.
2. Almacenamiento reescribible: cambiar tarjetas = cambiar programa.
3. Automatización precisa y repetible: ejecución mecánica sin intervención humana.

De esta forma, los telares del siglo XVIII y XIX no solo revolucionaron la industria textil; también tejieron la primera trama de la era de la información, demostrando que la inteligencia de una máquina podía residir fuera de su mecanismo, lista para ser leída, interpretada y ejecutada, exactamente como ocurre hoy, cada vez que un procesador carga código desde memoria.

Fuentes principales: LiveScience, Computer History Museum, HistoryOfInformation.com, Science Museum Group y archivos de IBM.