PMI - Redefiniendo el éxito de un proyecto con M.O.R.E.

PMI, Project Management

PMI - Redefiniendo el éxito de un proyecto con M.O.R.E.

¿Cómo miden el valor en tu proyecto?, hoy conversaremos cómo la perspectiva ha evolucionado del éxito medido en la triple restricción de un proyecto (costo, tiempo y alcance), al éxito medido en valor. Durante muchos años, el éxito de un proyecto se evaluaba bajo la llamada "triple restricción", conformada por: **1. Costo:** El presupuesto necesario para realizar un proyecto. **2. Tiempo:** El cronograma del proyecto, cuánto tiempo tarda en completarse cada fase/etapa, así como la duración total. **3. Alcance:** Lo que va a entregar el proyecto una vez se haya concluido. Adicionalmente a estas tres restricciones, se consideraba embebida la “Calidad” como un elemento a considerar. Si hablamos de restricciones de un proyecto en 2026, creo que sería algo como: 1. Costo 2. Tiempo 3. Alcance 4. Tokens (“Créditos” para usar la IA) (image: inteligencia-artificial-ia-ai-tokens-guadalajara-mexico-01.webp) Aclaro que el punto anterior referente a los Tokens ha sido una broma (o tal vez no 😉), pero lo que sí es cierto es que por mucho tiempo, el cumplir con esos tres parámetros era sinónimo de éxito. Las cosas han cambiado, ya que, en los últimos años, el (link: https://www.pmi.org/ text: Project Management Institute) o (link: https://www.pmi.org/ text: PMI), después de un estudio muy exhaustivo, publicado en 2024, ha impulsado una visión más amplia de lo que llama: La definición de éxito de un proyecto. (image: pmi-project-management-institute-logo.webp) Como menciona (link: https://www.linkedin.com/in/pierre-le-manh-3a4158/ text: Pierre Le Manh, CEO del PMI): “La forma en que hemos estado midiendo el éxito ya no funciona.” Por lo cual, de acuerdo con el PMI y esta nueva definición de éxito: **"Un proyecto exitoso es aquel que entrega valor que justifica el esfuerzo y gasto realizado"** (image: pmi-ceo-project-management-institute-pierre-le-manh-more.webp) Aquí me gustaría abrir un paréntesis, como dicen mis amigos chilenos: ¡Ojo al piojo!", ya que esto no quiere decir que las restricciones no sean necesarias ni importantes (vivimos en un mundo de restricciones), solo que, bajo esta nueva perspectiva, un proyecto no se mide solo por entregar a tiempo, los requerimientos definidos y dentro del presupuesto, sino por el impacto real que genera en la organización, en los clientes y en la sociedad. **Estamos pasando de solo gestionar un proyecto a gestionar el éxito del proyecto**. Desde la época de (link: https://leonelzapien.com/blog/que-es-agile text: Agile), basado en los principios del (link: https://leonelzapien.com/blog/esto-es-lean text: Pensamiento Lean), se ha buscado este valor, pero la verdad es que muchos equipos fallaban en definirlo, o bien, esta definición de valor estaba acotada o incompleta. No es algo nuevo el buscar el valor, lo nuevo son los lentes con los que estamos viendo este valor, un enfoque más amplio. En este nuevo paradigma, el éxito se traduce en beneficios claros y tangibles, resultados que justifican la inversión. # ¿Qué es M.O.R.E.? Pues bien, derivado del estudio realizado por el PMI publicado en 2024, se identificaron algunos elementos comunes de los proyectos que son percibidos como exitosos y que tienen un mayor impacto positivo, a partir de esto, define un marco llamado M.O.R.E., un cambio de mentalidad, que nos puede ayudar a avanzar hacia esta mencionada entrega de valor, ahora desde una perspectiva mucho más amplia. M.O.R.E. es un acrónimo que significa: · Manage Perceptions (Gestionar percepciones) · Own Success (Hacer propio el éxito) · Relentlessly Reassess Project Parameters (Reevaluar Implacablemente los parámetros de un proyecto) · Expand Perspective (Expandir perspectivas) (image: pmi-more-acronimo.webp) Con M.O.R.E. podemos generar valor desde una perspectiva más amplia y considerando el largo plazo, partiendo de que nuestros proyectos siempre tienen un impacto en las organizaciones, y estas organizaciones forman parte de un ecosistema (industria, sociedad, y hasta el propio planeta), por lo cual también es necesario considerar el impacto que estamos generando a este nivel. Veamos cada una de las 4 letras que conforman M.O.R.E. un poco M.Á.S. a detalle: # Manage Perceptions ### Gestionar percepciones (image: manage-perceptions.webp) Hemos hablado de valor, pero lo que es valioso para una persona puede no serlo para otra, por esto, el éxito de un proyecto para un stakeholder puede ser distinto para otro stakeholder. Primero que todo, es necesario tener presente esto a fin de poder gestionar las percepciones, por lo que debemos: - Analizar las expectativas y percepciones de valor de las partes interesadas. - Diseñar e implementar estrategias de influencia. - Ejecutar la comunicación estratégica en un entorno de incertidumbre. Par esto, es importante que contemos, además con habilidades en Gestión de Proyectos, con una base de habilidades de negocio (Business Acumen), hablar idioma de negocio. Por lo tanto, debemos de establecer criterios de éxito, identificar cómo definen el éxito del proyecto nuestros stakeholders o partes interesadas. Lo anterior, nos ayuda a orientar la toma de decisiones mediante sistemas de medición y realizar el seguimiento de las métricas necesarias en base al éxito y como ha sido definido Debemos de apoyarnos del storytelling para crear una narrativa que explique lo que las métricas realmente implican. # Own Success ### Hacer propio el éxito (image: own-success.webp) El verdadero sentido de propiedad va más allá de la responsabilidad. Se trata de pensar y actuar cómo el éxito del proyecto tiene repercusión directamente en toda la organización. El sentido de propiedad no es una política que se pueda imponer, es una algo que se cultiva. El PMI menciona que, todo proyecto tiene un impacto en el negocio, y debemos evaluar este impacto más allá de solo métricas del desempeño de un proyecto, sino desde tres lentes: - Conocimiento financiero. - Contexto de mercado. - Impacto organizacional. # Relentlessly Reassess Project Parameters ### Reevaluar implacablemente los parámetros de un proyecto (image: relentlessly-reassess.webp) La reevaluación constante no consiste en cambiar de rumbo continuamente. Se trata de percibir, evaluar y adaptarse de manera sistemática para avanzar siempre hacia la generación de valor. Estamos hablando de Agilidad Organizacional (no de Scrum, Kanban o Agile, no hablamos de marcos de trabajo o métodos, sino de un nivel de agilidad o de adaptación como habilidad de toda la organización). En este punto, el PMI hace un gran énfasis en (link: https://www.pmi.org/learning/agile/manifesto-for-enterprise-agility text: Agilidad Organizacional), maneras flexibles de trabajar (Ways of Woring), así como de utilizar un enfoque en Pensamiento Sistémico, una perspectiva más aplica para ver la organización como un sistema, formado por varios sistemas). El PMI menciona que los tres elementos de organizaciones con alto nivel de agilidad organizacional son: - Apoyo y visión del liderazgo. - Cultura organizacional y entorno. - Maneras de trabajar (WoW o Ways of Working). # Expand Perspective ### Expandir perspectivas (image: expand-perspective.webp) Todo proyecto forma parte de un ecosistema más amplio de sistemas: Ambientales, sociales y organizacionales, por lo tanto, el éxito de un proyecto no se debe solo a cumplir con la triple restricción. El valor debe de incluir una visión de conjunto: - Cómo las decisiones tomadas repercutirán en las comunidades, en la sociedad y en el mundo - Cómo el trabajo se alinea con los valores de la organización y cómo sus resultados generan un cambio duradero más allá de logros inmediatos. En este punto entra en juego lo que se conoce como (link: https://www.pactomundial.org/noticia/la-sostenibilidad-empresarial-desde-las-siglas-asg-o-esg/ text: ESG (Environmental, Social, and Governance)) se refiere a los criterios ambientales, sociales y de gobernanza corporativa, se usan para medir la sostenibilidad y la ética de las organizaciones más allá de las ganancias económicas. Por lo tanto, debemos evaluar el impacto ambiental, social y ético de nuestros proyectos, los factores ESG ya no son algo opcional, la sostenibilidad es un factor crítico. # Conclusiones M.O.R.E. nos invita a tomar una perspectiva sistémica, por lo tanto, nuestros stakeholders o partes interesadas abarca ahora a “nuevos” actores, pues ahora la #sostenibilidad deja de ser algo opcional para pasar a tomar un enfoque clave, y considera a lo que se conoce como ESG (Environmental, Social and Governance), traducido al español quiere decir los factores Ambiental, Social y Gobernanza. Si bien mucho de lo que se menciona con M.O.R.E. ya se lleva a cabo por diversos profesionales y organizaciones, esta perspectiva llega a mencionar explícitamente y como una guía que nos ayude a enfocarnos y generar alineación. Estamos en un momento de transición de solo gestionar un proyecto a gestionar el éxito de los proyectos. ¿Conocías M.O.R.E.?, ¿Cómo mides el valor generado por tus proyectos?

31 de julio de 2026

Agile, PMI

PMI - Manifiesto para la Agilidad Empresarial

Recién salido del horno este mes, la (link: https://agilealliance.org/ text: Agile Alliance) del (link: https://www.pmi.org/ text: Project Management Institute o PMI) , acaba de publicar el Manifiesto para la Agilidad Empresarial (Manifiesto for Enterprise Agility), ¿Pero no es lo mismo que el (link: https://leonelzapien.com/blog/25-aniversario-del-manifiesto-agile text: Manifiesto Ágil de hace 25 años)?, la respuesta sería algo como: "Sí pero no": Este Manifiesto habla de Agilidad a nivel Empresarial, es decir, más allá de a nivel equipo, y es justo en este punto donde complementa al clásico (link: https://agilemanifesto.org/ text: Manifiesto Agile), busca ir más allá de equipos Scrum o equipos Kanban (esto lo menciono solo como ejemplo, y también es cierto que existen marcos y métodos de escalado que buscan abordar esta situación, como Scrum@Scale, LeSS o Large Scale Scrum, Nexus, Enterprise Kanban, Spotify Model, Scaled Agile o SAFE, y varios más que bien solo este punto es bastante amplio y puede ser tema para un próximo artículo, si te interesa compárteme un mensaje o correo, y con gusto lo podemos abordar), pues bien, con la perspectiva del PMI de Agilidad Empresarial se busca hablar de una alineación a lo largo y ancho de toda la organización, desde los valores y principios, sin acotarlo a un marco de trabajo o método en particular. (image: pmi-agile-alliance-leonel-zapien-lopez-guadalajara-mexico.webp) ## Agilidad Empresarial En base a este enfoque más allá de equipos, el PMI define **Agilidad Empresarial **como la capacidad de adaptarse a escala sin perder coherencia: decidir con rapidez, redirigir recursos deliberadamente y mantener la estrategia viable bajo la presión del mundo real, y algo clave es que la identifica como una **habilidad** esencial para la supervivencia en un entorno marcado por la incertidumbre, la IA y los cambios constantes del mercado. Este Manifiesto tiene un enfoque amplio al enfatizar la alineación entre la estrategia, objetivos a largo plazo, ventajas competitivas y sostenibilidad alineados a lo largo y ancho de toda la organización, con una organización capaz de a ver ajustes o pivotes más rápidos que el mercado, mientras se mantiene un crecimiento sostenible. (image: pmi-agile-alliance-manifiesto-agilidad-empresarial-leonel-zapien-lopez-guadalajara-mexico-pmp-pmi-acp.webp) ## Empieza con el “Porqué” (así pegado y con acento) Como menciona (link: https://simonsinek.com/ text: Simon Sinek) en su increíble libro **Empieza con el Porqué** (siempre menciono que la palabra “porqué”, así pegado y con acento, significa causa, motivo o razón), debemos de partir siempre desde el propósito, esa poderosa razón por la cual hacemos lo que hacemos. (image: simon-sinek-empieza-con-el-porque-circulo-dorado-golden-circle-leonel-zapien-lopez-guadalajara-mexico.webp) **Imagen:** Simon Sinek, creador del “Cículo Dorado” y autor del libro “Empieza con el Porqué”. En este mismo orden de ideas, personalmente algo que me ha encantado y me parece súper poderoso es que el Manifiesto menciona la importancia de partir primeramente desde el Propósito, al mencionar: “Propósito claro realizado a través de planes adaptativos”, y pone, así mismo, un especial foco en las personas: “Centrarse en el ser humano en medio del cambio”. Agile Alliance menciona que cuando la Agilidad Empresarial funciona, la estrategia se convierte en acción sin fricciones, los equipos actúan con autonomía y alineación, y la organización evoluciona más rápido que el mercado, manteniendo al mismo tiempo su crecimiento. ## Principios y valores Este Manifiesto cuenta con 9 principios, y prioriza algunos valores: 1. Guiar con propósito y ajustar en el camino en lugar de mantener una ilusión de control. 2. Priorizar objetivos a largo plazo y la colaboración a lo largo de toda la organización sobre objetivos a corto plazo (Objetivos Clave de Desempeño o KPIs a nivel local o departamental). 3. Desafiar activamente los modelos operativos establecidos e innovación sobre la inercia estructural y preservación del Status Quo. 4. Aprendizaje continuo, desarrollar resiliencia, habilitar la autonomía, y liderar con empatía la confianza, sobre liderar el cambio solo basado en procesos. P.D. La lista completa de valores no la transcrito aquí para no extender demasiado el artículo, pero si es de tu interés conocerla, la puedes consultar en la sección de "Anexos", al final del artículo. ## El Liderazgo es clave El Manifiesto de Agilidad Empresarial menciona y reconoce como elemento clave de apalancamiento el **nuevo rol del liderazgo**, menciona que los líderes deben de ser los primeros en adaptar sus enfoques, así mismo, deben de fomentar un entorno donde el aprendizaje a partir del error sea posible a través de entornos de seguridad psicológica, es acerca de reemplazar el miedo a fallar con un apetito por experimentar y progresar. ## Conclusiones Este Manifiesto cambia radicalmente le enfoque de la Agilidad, reconoce la Agilidad como una habilidad, y busca permear un impacto a lo largo y ancho de toda la organización, el foco no es tener equipos súper ágiles que trabajen de manera aislada, sino desarrollar la capacidad de adaptación a lo largo de múltiples equipos, a lo largo de la organización (por cierto, si te interesa profundizar un poco más en este tema de pasar más allá de equipos aislados, te invito a ver el** video** de una charla referente a este tema que tuve el enorme gusto de impartir titulada: “**Alineándonos alrededor de Flujos de Valor o Value Streams**”, puedes ver el video haciendo (link: https://www.youtube.com/watch?v=eVbt1R2HZ6o text: clic aquí)). Y en esencia, hablamos de valores y principios, nada de marcos de trabajo o frameworks, ni métodos o herramientas. Con este enfoque el PMI integra la Agilidad de manera natural, ahora con una perspectiva amplia, con vistas a los objetivos a largo plazo. ¿Qué opinas de este Manifiesto y su enfoque? **P.D.** Te comparto que **soy miembro activo del PMI desde 2013** (PMP, PMI-ACP), y a lo largo de los años algo que he visto es la evolución, tanto del enfoque del PMI como del movimiento Agile, así que este Manifiesto me parece un gran acierto en este sentido. Sabemos que la constante es el cambio, por lo tanto, debemos de mantenernos en constante evolución. ## Anexos Puedes descargar el Manifiesto para la Agilidad Organizacional directo de la página del PMI, haciendo (link: https://www.pmi.org/learning/agile/manifesto-for-enterprise-agility text: clic aquí.)

31 de marzo de 2026

Project Management, Agile, Scrum, PMI

¿Gestión de Riesgos en Agile?

En agile no se gestionan riesgos, eso es muy de “waterfall”… ¿Te suena? Se dice mucho que el Scrum Master se enfoca en remover impedimentos o bloqueos del equipo Scrum, esto es cierto, pero esto en un es sentido reaccionar a algo que ya sucedió, muchísimo aporta que se puedan gestionar estos impedimentos antes de que sucedan. Por cierto, (link: https://scrumguides.org/ text: La Guía Scrum ) en este sentido menciona que el Scrum Master debe: “Procurar la eliminación de impedimentos para el progreso del Scrum Team.” En una reunión que tuve hace unas semanas con un equipo surgió el tema de los riesgos (como comentario, fue en mi segunda reunión del día, a las 6:30 a.m.), y es por esto que pensé en traer el tema a la mesa. (image: precaucion.webp) # Primero lo primero, ¿Qué es un Impedimento, un Bloqueo y un Riesgo? Si nos vamos a la definición de diccionario, de acuerdo con la Real Academia de la Lengua Española o RAE, un (link: https://www.rae.es/diccionario-estudiante/impedimento text: impedimento) es: “Cosa o persona que impiden algo” Un (link: https://dle.rae.es/bloqueo text: bloqueo), también, de acuerdo con la RAE, lo define como un sinónimo de “obstrucción o atasco”. Para definir un riesgo, lo veremos de dos maneras, desde una definición genérica que nos brinda la RAE y de la que nos brinda una fuente específica como el (link: https://www.pmi.org/ text: Project Management Institute o PMI). • (link: https://www.rae.es/diccionario-estudiante/riesgo text: Riesgo) (de acuerdo con la RAE): “Posibilidad de que ocurra algo malo”. • (link: https://www.pmi.org/learning/library/es-desmitificando-el-enfoque-practico-de-la-planificacion-de-riesgos-7331 text: Riesgo) (de acuerdo con el PMI): “Un riesgo en proyectos es un evento o condición incierta que, en caso de que ocurra, tiene un efecto positivo o negativo sobre al menos un objetivo del proyecto, que puede ser tiempo, costo, alcance o calidad.” Si un equipo está trabajando y de pronto se topa con que están detenidos porque se ha terminado un determinado número de parte (materia prima), porque no cuentan con un requerimiento que aún no ha sido confirmado por el cliente, o porque ha fallado un servidor en producción, entonces el equipo está bloqueado, tiene un impedimento que no le permite continuar. En este sentido, una forma de ver un impedimento es como un riesgo que ya ha ocurrido. Por eso la importancia de actuar con un enfoque preventivo por medio de la Gestión de Riesgos. # No nos casemos con una metodología Como siempre lo he dicho: No nos casemos con una metodología, marco de trabajo o método. Todas son simplemente herramientas y, como todo en la vida, debemos de utilizar la herramienta adecuada para cada situación. Claro que, si tengo que clavar un clavo y solo tengo a la mano unas pinzas, seguro que puedo darle de golpes para clavarlo, tal vez le voy a batallar un poco más, pero no hay como utilizar un martillo. En “la vida real” enriquece mucho utilizar distintas herramientas, y como fui primero Project Maganer ((link: https://www.pmi.org/certifications/project-management-pmp text: PMP)) que Scrum Master y Agile-Lean Coach (si te interesa leer más sobre el Agile Coach, puedes leer un artículo que escribí sobre el tema haciendo clic (link: https://leonelzapien.com/blog/scrum-master-o-agile-coach text: aquí)), confieso que desde el inicio he utilizado Gestión de Riesgos (con un enfoque ágil), y funciona de maravilla 😀 # Gestión de Riesgos (Risk Management) Un riesgo puede ser positivo o negativo (esto, cuando lo leí por primera vez hace como 12 años, me voló la cabeza), ya que solo concebía el concepto de un riesgo como algo negativo que puede suceder. Un **riesgo positivo* *es una oportunidad y solo en caso de ocurrir generaría un impacto positivo al equipo. Un **riesgo negativo** es del tipo que comúnmente conocemos, una amenaza que, en caso de ocurrir, tendría consecuencias negativas. **Los riesgos se evalúan por su probabilidad de ocurrencia y su impacto.** (image: riesgo-probabilidad-impacto-explicado-risk-management-leonel-zapien-lopez-guadalajara-mexico-pmi-pmp-2.webp) Crédito de imagen: BrainUp Co. . ### Un ejemplo: Si voy a hacer un viaje por carretera de 4 horas a la playa, el impacto de que se ponche una llanta o neumático del coche es alto, ya que no podría continuar el viaje con solo 3 llantas. Pero, ¿Qué tan probable es que suceda? Digamos que en condiciones “normales” (neumáticos en buenas condiciones, camino en buenas condiciones) la probabilidad de que suceda es baja (tan baja que, con 1 sola llanta o neumático de refacción hacemos el viaje, sin necesidad de llevar 4 llantas de refacción en la cajuela del coche). Este podría ser un riesgo de impacto alto con probabilidad de ocurrencia baja. En este ejemplo, quizá quiera mitigar aún más este riesgo y decido llevarme en la cajuela una segunda llanta o neumático de refacción. Ese es mi plan para mitigar este riesgo. ¿Es demasiado?, tal vez sí o tal vez no, dependerá del contexto, ¿Qué tal si ese viaje a la playa es para casarme allá y el llevar dos neumáticos de refacción me da paz mental, porque no quiero ninguna sorpresa en el trayecto? Ahora, voy a exagerar con el ejemplo, pero qué tal si considero que el viaje a la playa se puede poner en riesgo por un meteorito que caiga en la carretera. El impacto sería claramente alto (demasiado alto), pero y ¿la probabilidad de que esto ocurra?, ¿Valdrá la pena o es siquiera posible hacer un plan para mitigar este riesgo? Con este último ejemplo quiero enfatizar el hecho de que no podemos centrarnos en todo, por esto debemos de **enfocarnos en los riesgos con la adecuada combinación de impacto y probabilidad de ocurrencia.** (image: gestion-de-riesgos-risk-management-dragon-leonel-zapien-lopez-guadalajara-mexico-pmi-pmp.webp) Crédito de imagen: Esta imagen la tomé de un post que me encantó de mi amiga de Ciudad de México (link: https://www.linkedin.com/in/carolina-loperena/ text: Carolina Loperena), quien es toda una Jedi como Project Manager (en el link en su nombre puedes encontrar su perfil en LinkedIn). . Se deben de tener las conversaciones adecuadas con las personas adecuadas para **cocrear** una identificación de riesgos, después hacer un análisis de cada riesgo identificado, definir un plan de respuesta (y aquí no solo es mitigar o evitar, ahorita lo vemos más a detalle), para después llevar a cabo las acciones identificadas, y de manera continua permanecer evaluando si alguno de los riesgos ha cambiado su probabilidad de ocurrencia o su impacto, o si surgen nuevos riesgos. Es un proceso continuo, y si se aborda con** Transparencia, Inspección y Adaptación**, ¡Es una combinación poderosa! Al definir un posible plan para cada riesgo, es importante saber que un riesgo se puede: ### 1.Mitigar: Disminuir la probabilidad de que se presente y/o el impacto en caso de que suceda. ### 2.Evitar: Eliminar la causa raíz para que no ocurra el riesgo (“cortar de tajo”, como decimos acá en México). ### 3.Transferir: Una tercera parte es responsable del riesgo, tal vez no se puede evitar, pero la otra parte absorbe el impacto (en parte o en su totalidad), por ejemplo, el contratar un seguro contra accidentes automovilísticos no evita la probabilidad de chocar, pero si ocurre, se transfiere el impacto del riesgo a alguien más (en este caso a la aseguradora, claro que a cambio de un correspondiente pago). ### 4.Aceptar: Dependiendo la situación, lo más adecuado (o posible) sería dejar que ocurra. Como decimos acá en México: “No hay de otra y bebemos de apechugar”. (image: riesgo-estrategias-risk-management-leonel-zapien-lopez-guadalajar-mexico-pmi-pmp.webp) Como punto final sobre la gestión de riesgos, me gustaría agregar algo que me ha compartido un muy buen amigo, (link: https://www.linkedin.com/in/jorgesanchezlopez/ text: Jorge Sánchez López), de Valencia, España (en el link en su nombre puedes encontrar su perfil en LinkedIn), a manera de cultura general, y es que la gestión de riesgos viene de la **ISO 31000**. # El ingrediente final: Transparencia Con todo lo que hemos conversado el día de hoy, para cerrar la idea, y ya que hemos visto que los riesgos se clasifican en cuanto a su probabilidad de ocurrencia y a su impacto, para asegurar que esta información esté disponible para todas las partes interesadas y surjan las conversaciones adecuadas, los riesgos se visualizan en una **Matriz de Riesgos** como la de la imagen, la cual ayuda a esta Transparencia que he mencionado 3 veces hasta el momento en este artículo. (image: matriz-de-riesgos-risk-management-gestion-leonel-zapien-lopez-guadalajara-mexico-pmi-pmp.webp) Como dicen mis amigos chilenos: ¡Ojo al piojo! Ten en cuenta que esta matriz sirve de poco si no se revisa y actualiza de manera regular. Y me gustaría cerrar un mensaje final: **Lo poderoso no es esta Matriz, sino las conversaciones que surgen.** ¿Qué opinas de este tema?

30 de abril de 2025

Scrum, Agile, Project Management

Scrum NO es una metodología… 30 años después

Scrum cumple 30 años este 2025, y aún es común encontrar montones de post y artículos que lo llaman metodología. Scrum **NO es una metodología**, es un marco de trabajo o framework, la Guía Scrum lo llama un “marco liviano”. ¿Cuál es la diferencia con una metodología y por qué no lo es? ### Metodología La definición “by the book” de metodología nos dice que es un conjunto estructurado de principios, procesos y prácticas que deben seguirse para lograr un objetivo. Una metodología brinda** pasos claros y detallados **para llevar a cabo algo en específico, y esto se resume en que es necesario seguir estos pasos detallados, lo cual deja poco margen para adaptaciones. ### Marco de Trabajo Por otro lado, un marco de trabajo es mucho más flexible, proporciona una serie de **guías generales** y, como no dicta a detalle cómo deben realizarse los puntos que abarca, fomenta la colaboración y la creatividad dentro de sus límites. ### Y eso en Scrum, ¿Qué quiere decir? Es por esto que (link: https://scrumguides.org/ text: La Guía Scrum), que es la fuente oficial de Scrum, **consta de solo 16 páginas** (incluyendo la portada, el índice y los agradecimientos 😂), y por esto la propia Guía menciona que “El marco de trabajo Scrum es incompleto de manera intencional"… por lo tanto, si quieres implementar Scrum con tus equipos te vas a dar cuenta de que La Guía menciona muchos puntos que deben de cumplirse, pero no te dice cómo hacerlo, por lo que es necesario complementarlo con otras técnicas, herramientas, métodos, y etcétera y etcétera. Por ejemplo, La Guía Scrum menciona que se deben de ordenar los elementos del **Product Backlog**, pero no dice cómo o con cuáles técnicas de priorización. Menciona que se inculca la calidad al adherirse a una **Definición de Terminado o DoD** (si te interesa profundizar en este concepto, puedes leer el artículo que escribí sobre la Definición de Terminado (link: https://leonelzapien.com/blog/scrum-calidad-5-1-tips-para-una-poderosa-definicion-de-terminado text: aquí)), más no te dice cómo hacerla. Menciona también que en las **Retrospectivas** el Equipo Scrum identifica formas de aumentar la calidad y la efectividad, pero de igual manera no habla de técnicas de facilitación ni de herramientas para identificar causa raíz. ### La Complejidad está en el aire ¿Y por qué Scrum no brinda un paso-a-paso detallado? La respuesta es por la complejidad, la volatilidad y la incertidumbre (entre otros elementos) que hacen prácticamente imposible que se pueda definir un procedimiento a detalle para cada posible situación Si hablamos de complejidad (si te interesa profundizar un poco sobre complejidad y Sistemas Adaptativos Complejos o CAS, puedes leer un artículo que escribí sobre este tema es (link: https://leonelzapien.com/blog/organizacion-sistema-adaptativo-complejo text: aquí)), tiene que ver con múltiples variables que pueden influir en una situación, de las cuales a veces ni siquiera somos conscientes de que existen o de sus relaciones, así que no se pueden modelar ni predecir. Por esto **Scrum funciona muy pero muy bien para entorno complejos** (por cierto, si te interesa leer un poco más sobre qué es Scrum, puedes leer un artículo que escribí sobre el tema(link: https://leonelzapien.com/blog/que-es-scrum text: aquí), y puedes ver un video que hice sobre Agile (link: https://www.youtube.com/watch?v=X7S4aR2gDFc&t=4s text: aquí)). ### Conclusiones En resumen, una metodología es como un manual detallado, mientras que un marco de trabajo podría ser más como una** caja de herramientas** que puedes usar según el contexto. ¿Qué opinas de este tema?

4 de abril de 2025

Agile, Project Management, PMI

La Amalgama del PMI + Agile Alliance

El pasado 3 de enero de manera oficial se confirmó una gran noticia: El Project Management Institute (PMI) ha firmado un acuerdo para integrar a Agile Alliance. El comunicado oficial puedes leerlo (link: https://www.agilealliance.org/agile-alliance-joins-project-management-institute-pmi/ text: aquí), entre otras cosas menciona: “El futuro de la gestión de proyectos, centrado en el éxito del proyecto impulsado por el valor entregado, no puede depender de distinciones rígidas entre los enfoques de entrega. La integración de Agile Alliance dentro de PMI solidifica aún más el liderazgo de PMI en la transformación de la profesión de proyectos. PMI Agile Alliance se beneficiará del alcance y los recursos globales de PMI, mientras que los miembros de PMI obtendrán un mayor acceso al liderazgo intelectual, las herramientas y los recursos de Agile, mejorando su desarrollo profesional y permitiendo un mayor éxito de los proyectos.” Para encuadrar un poco más de qué va todo esto: # El origen del PMI El PMI, fundado hace más de 50 años, el 3 de octubre de 1969 para ser exactos, ha sido la autoridad y referente a nivel mundial en gestión de proyectos. Durante décadas, la forma (ahora llamada “tradicional”) de gestionar proyectos de manera metodológica ha sido dictada por el PMI. (image: pmi-logo-1998-2024.webp) Es la casa de la prestigiosa certificación (link: https://www.pmi.org/certifications/project-management-pmp text: PMP o Project Management Professional), y un montón de certificaciones más… en gestión de riesgos, del cronograma o de tiempo, gestión de programas, de portafolios, etcétera. Además de incluir en años más recientes, certificaciones en Agilidad. **Nota #01:** El enfoque tradicional o **enfoque predictivo**, se refiere a la manera secuencial y por etapas de gestionar un proyecto, lo que se conoce de manera no oficial pero ampliamente difundida como** “Waterfall” o “Cascada”** (si te interesa conocer un poco más a profundidad sobre Gestión de Proyectos en Cascada, puedes leer el artículo que escribí al respecto (link: https://leonelzapien.com/blog/gestion-de-proyectos-en-cascada-waterfall text: aquí)). # El origen de Agile Alliance (link: https://www.agilealliance.org/ text: Agile Alliance), por otro lado, organización sin fines de lucro, fue fundada en 2001 después de la creación del (link: https://agilemanifesto.org/ text: Manifiesto Ágil ) por algunos de los firmantes del propio manifiesto (si te interesa conocer un poco más a profundidad sobre el Manifiesto Ágil, puedes leer el artículo que escribí al respecto (link: https://leonelzapien.com/blog/23-aniversario-n-manifiesto-agil text: aquí)), y fue creada “para personas que desarrollan software y ayudan a otros a desarrollar software para explorar, compartir ideas y experiencias”, con el propósito de propagar la adopción del mindset o mentalidad ágil, es decir, de un **enfoque adaptativo**. (image: agile-alliance-logo.webp) Al contrario del (link: https://www.pmi.org/ text: PMI), o de otras instituciones como (link: https://www.scrumalliance.org/ text: Scrum Alliance), (link: https://www.scrum.org/ text: Scrum.org), (link: https://www.scruminc.com/es/ text: Scrum Inc.), y una larga lista de etcéteras… **Agile Alliance no ofrece ninguna certificación**, y, de hecho, en un sentido promueve la experiencia en Agile sin necesidad de obtener una certificación necesariamente. (Si te interesa conocer un poco más a profundidad sobre Agile, puedes leer el artículo que escribí al respecto (link: https://leonelzapien.com/blog/que-es-agile text: aquí)), # La evolución del PMI y de Agile Por un lado, la gestión de proyectos tradicional evangelizada por el PMI no funciona muy bien que digamos en cierto tipo de proyectos (en entornos volátiles, inciertos, complejos, ambiguos, frágiles, que generan ansiedad, no lineales e incomprensibles… sí, todo eso). Por el otro lado, un hecho innegable es ante el crecimiento del movimiento Agile, el PMI se vio en la necesidad de incorporar también la perspectiva ágil a su catálogo. En su momento agregó la certificación (link: https://www.pmi.org/certifications/agile-acp text: PMI-ACP (Agile Certified Practitioner)), y en 2019 adquirió (link: https://www.pmi.org/disciplined-agile/ text: Disciplined Agile), con lo cual amplió su portafolio y profundizó en el enfoque ágil con certificaciones como Scrum Master, Agile Coach y Value Stream. **Nota #02:** Por cierto, como parte de la reestructuración y evolución que el PMI está haciendo, para este primer y segundo cuarto del 2025, estará liberando el **nuevo path de certificaciones de Disciplined Agile**, entre los cambios es reajustar la certificación de Scrum Master… pero una cosa a la vez, en cuanto haya novedades sobre este tema, pasaré por aquí con un artículo al respecto. El caso es que el entorno llevó al PMI a evolucionar, lo cual está en realidad bien. Por el otro lado, un movimiento que está tomando fuerza es el que plantea **“Agile is dead” o “Agile ha muerto”**. Muy personalmente no considera que sea así ni que no lo sea, sino todo lo contrario, simplemente que es necesaria una evolución para Agile también. Agile debe de evolucionar, al igual que el PMI, y también está tremendamente bien. Por un lado, **se tergiversó el tema con certificaciones para todo, al “por mayor”**, y por el otro lado, se ha logrado desviar un poco del enfoque en el mindset, en aportar valor, Agilidad no solo es mover post-its por un tablero y hacer retrospectivas temáticas de Harry Potter o los Avengers. Entonces, la evolución es más que necesaria. Es bonito y está bien. # La verdad es que no todo es Agile Pero siendo muy abiertos y evitando ser puristas, tampoco todo funciona con Agile o enfoque predictivo, es decir, con entregas incrementales y de manera iterativa… aquí me encanta poner un ejemplo que mi buen amigo (link: https://www.linkedin.com/in/sebastian-lopreto/ text: Sebastián Lopreto), desde Bariloche, Argentina, siempre menciona: “Cuando vos vas al dentista porque te van a extraer una muela (presuponiendo que el diagnóstico está hecho y no ha de otra opción), ¿le dices que te la quite de un tirón, o que te la quite de a poco, de manera incremental y cada dos semanas, hasta que tengas toda la muela fuera de tu boca?” Así que, aunque muchos “agilistas extremistas o puristas” pudieran decir que algo es agile o no lo es, muy personalmente soy un apasionado Agilista y practicante Lean, pero también soy PMP (de hecho, primero fui PMP antes que Scrum Master. De verdad. Hace casi 12 años que obtuve la certificación de PMP, y unos meses después la de Scrum Master de Scrum Alliance), así que siento que puede aportar bastante el conocer a profundidad ambas perspectivas, y, por lo mismo, siempre he dicho que debemos de utilizar la herramienta más adecuada a cada contexto. Volviendo al punto de si algo es agile (adaptativo) o es cascada (predictivo), el PMI pone sobre la mesa además el **“enfoque híbrido”**, en el cual conviven el enfoque predictivo con elementos del enfoque adaptativo, combina trabajo predictivo o en cascada con ágil.… Pero ¿No va esto contra toda la naturaleza del Manifiesto Ágil?… De nuevo: tal vez sí, tal vez no, tal vez todo lo contrario. (image: hibrido-01.webp) La verdad es que, como siempre digo, todo depende del contexto: Ser Agile no significa utilizar (link: https://leonelzapien.com/blog/que-es-scrum text: Scrum) o Extreme Programming, en esencia es un conjunto de valores y principios que, si se viven y se aplican, no importa que sea con un marco de trabajo, método o cualquier otra herramienta. He visto de primera mano los enfoques híbridos, y la verdad es que aportan muchos beneficios. Considero que se puede abordar conociendo ampliamente ambos enfoques, contextualizando con respeto cada herramienta, y de nuevo: Funcionan muy bien. # Ok, lo inimaginable ha ocurrido y se han unido el PMI y Agile Alliance… entonces, ¿ahora qué sigue? He escuchado opiniones muy encontradas. He escuchado a algunos puristas del PMI decir que están sumando a unos “hippies” al instituto. He escuchado a algunos puristas Agile darse de topes en la cabeza y decir que va contra la esencia Agile. Muy personalmente, veo mucho potencial en esta unión. En la “vida real”, siendo un apasionado Agilista y practicante Lean, aplicaba varias herramientas del mundo del PMI en mi día a día. Respetando sus formas, claro. Y funciona de las mil maravillas. (image: pmi-agile-alliance-01.webp) Así que, aunque solo el tiempo dirá si este movimiento ha sido acertado… algunos posibles “pros” y “contras” (dependiendo de cómo lo veas) pudieran ser: ### Posibles Pros: **1. Expansión a otros sectores.** El PMI tiene amplia presencia en industrias donde Agile no ha llegado (o no ha sobrevivido). Este apalancamiento podría ayudar a llevar Agile a esos recónditos lugares. (**Por ejemplo, el PMI acaba recientemente de sacar una certificación específica para la industria de la Construcción,** ¿sabías de esto?, ahora tomemos este ejemplo y consideremos las posibilidades en industrias que requieren cierta especialización). **2. Flexibilidad para la ocasión (¿Certificaciones híbridas?):** Como ya hemos mencionado, no todo es predictivo, no todo es adaptativo. También está lo “híbrido” justo a la mitad. Tal vez pueda ayudar esta amalgama. **3. Impulso (a través de recursos):** El PMI tiene una estructura sólida, esto quizá pudiera brindar de cierta formalidad a la Agilidad. **4. Mayor catálogo (¿En toda la industria?):** En última instancia, si hay oferta hay demanda. El catálogo de productos y servicios del PMI se va a reestructurar (vienen cambios en Disciplined Agile, como ya he mencionado), y esto posiblemente lleve a un cambio completo en la industria entera, recordemos en gran poder de apalancamiento del PMI, y tal vez acaben sumándose otras casas certificadoras a la ola. La clave no es un mayor catálogo, sino un catálogo más adecuado al contexto, y reitero que una certificación no garantiza la habilidad, solo tómalo en cuenta. **5. Poder con Infinity (La IA del PMI):** El poder de la IA es innegable, pues bien, **el PMI tiene una IA particular llamada Infinity** (no es genérica como ChatGPT, Gemini, Claude, etc.), esto pudiera ser una catapulta si se hace específica incorporando Agile y enfoques híbridos. ### Posibles Contras: **1. Burocratización:** El 3er Pro, la estructura sólida del PMI, bien podría ser un elemento en contra pues es una posibilidad que se vuelva rígida, lenta e inflexible a la agilidad. **2. Pérdida de la esencia:** El tan mencionado y ambicionado mindset ágil ¿Podrá sobrevivir dentro de la esencia del PMI sin perder a su vez su esencia?, ¿Podrá emerger algo como una esencia combinada, y es esto posible? **3. Disolución:** Una posible línea de certificaciones nuevas del PMI, pudiera diluir el enfoque, como he mencionado anteriormente, vienen cambios este 2025 en Disciplined Agile. # Otros dicen que ambos ya han muerto Una postura satírica y que la verdad me ha dado mucha risa, es la de (link: https://www.comicagile.net/ text: Comic Agile) (famosa empresa conocida a nivel mundial por hacer tiras cómicas que satirizan todo… (link: https://leonelzapien.com/blog/que-es-agile text: Agile), (link: https://leonelzapien.com/blog/que-es-scrum text: Scrum), (link: https://scaledagile.com/ text: SAFe), (link: https://less.works/ text: LeSS), al propio (link: https://www.pmi.org/ text: PMI), etc.), que ha hecho un post (puedes leerlo (link: https://www.linkedin.com/posts/comicagile_agile-projectmanagement-pmi-activity-7281237516727275520-dizk?utm_source=share&utm_medium=member_android text: aquí)), donde menciona que no solo Agile ha muerto, sino que también el PMI. Aquí te comparto su tira cómica al respecto, la cual dice: - Agile Alliance y el PMI uniendo fuerzas es un trato (o un partido) hecho en el cielo - ¿Por qué? - Porque ambos están muertos. (image: comic-agile-pmi-agile-alliance.webp) **Aclaración: Esta es una sátira de Comic Agile y no refleja para nada mi punto de vista**, solo estoy compartiendo la información desde la perspectiva de distintas fuentes de la manera más objetiva posible. Finalmente, Pierre Le Manh, actual presidente y CEO del PMI hace el anuncio oficial sobre esta unión, si te interesa, puedes leerlo (link: https://www.linkedin.com/posts/pierre-le-manh-3a4158_agile-projectmanagement-leadership-activity-7280964881137242112-Dt0c/?utm_source=share&utm_medium=member_android text: aquí). # Conclusiones Pues bien… el hecho es que la unión entre el PMI y Agile Alliance ha ocurrido. Hay muchísimas preguntas sobre lo que podría venir, nuevas… ¿perspectivas, certificaciones, puntos de dolor?, aún estamos en una etapa muy inicial como para saberlo. Personalmente veo esta unión como algo positivo, considero que nunca se ha tratado de **“PMI vs Agile”**, sino de centrarnos en las personas, aportar valor, adaptarnos y utilizar las herramientas adecuadas a cada contexto. **Las expectativas son muy altas y las posibilidades infinitas.** Ahora, veamos lo que está por venir. ### ¿Qué opinas sobre esta unión?

6 de enero de 2025

Project Management

Gestión de Proyectos en cascada (waterfall)

De acuerdo con el Instituto de Gestión de Proyectos o PMI por sus siglas en inglés (Project Management Institute, el cual es una organización estadounidense sin fines de lucro que asocia a profesionales relacionados con la Gestión de Proyectos), un proyecto es un esfuerzo temporal, con una fecha de inicio y fin determinadas, y que tiene como finalidad crear un producto, servicio o resultado único. La Gestión de Proyectos se define como un conjunto de conocimientos, habilidades, herramientas y técnicas para describir, organizar y monitorear el avance de las actividades de un proyecto para lograr los objetivos del mismo. Todo proyecto tiene un ciclo de vida que se refiere a la serie de fases por las que éste atraviesa desde su inicio hasta su conclusión, y proporciona el marco de referencia requerido para dirigir el proyecto en cuestión. La mayoría de los proyectos están divididos en estas fases, y sin importar si son pequeños o grandes, todos tienen un ciclo de vida y estructura similar. Las fases de un proyecto consisten de segmentos de trabajo que permiten una fácil gestión del mismo, algunos proyectos pueden tener una sola fase en tanto que otros pueden contener múltiples. Este número de fases puede variar dependiendo de la complejidad del proyecto, así como de la industria en la que se crea el mismo. Los ciclos de vida pueden ser predictivos, iterativos, incrementales, adaptativos o híbridos. Si bien hablaré de diversos ciclos de vida en otras entradas de mi blog, para el tema en cuestión, nos centraremos en este momento en los ciclos de vida predictivos: · **Ciclo de vida predictivo**: El alcance, tiempo y costo del proyecto son determinados en las fases iniciales del mismo, por lo que también se les denomina ciclos de vida en cascada (del inglés “waterfall”). La metodología en cascada es la metodología de Gestión de Proyectos de mayor difusión y uso durante los pasados 40 años, y hasta bien entrada la década de 1990, la mayoría de los proyectos se ejecutaban utilizando esta metodología, donde un proyecto se completaba en etapas separadas y avanzaba paso a paso hacia el lanzamiento último a los clientes finales. El nombre de “cascada” proviene de la similitud en que las fases son representadas, una después de la otra, como se muestra en la siguiente figura: En el método de cascada, cada paso o etapa debe de ser completado al 100% antes de moverse al siguiente, y todas estas etapas deben de ser completadas antes de entregar valor al cliente. Este método es conocido como “conducido por el plan” (del inglés plan-driven) debido al nivel de diseño y conceptualización que se realiza al inicio del proyecto, y se pasa por todas los grupos de proceso de gestión que indica el PMI: Inicio, planeación, ejecución, monitoreo y control, y finalmente el cierre. Este proceso, de levantar todos los requerimientos en la etapa inicial, si bien era funcional hace unas décadas, hoy en día es complicado de mantener debido a la evolución del entorno: El dinamismo de los mercados actuales, proyectos más complejos y ciclos de vida de productos cada vez más cortos. La etapa de análisis era por lo general lenta y tenía un alto grado de imprevisibilidad, lo que resultaba, por un lado, a menudo en un producto final o entregable distinto de lo que el cliente esperaba, y por otro lado, en un retraso de meses o inclusive hasta años para que el cliente viera resultados tangibles. Es por esto que, la tradicional metodología de cascada para la gestión de proyectos ha necesitado evolucionar, a la par que los marcos de referencia ágiles han ido creciendo en popularidad desde la década de 1990, siendo actualmente bastante utilizados (punto que por cierto abordaré a detalle en otras entradas de este blog). ### **Conclusiones** La metodología de cascada ha liderado la gestión de proyectos durante los últimos 40 años, nos ha enseñado la gestión de la integración del proyecto, del alcance, del tiempo, de los costos, de la calidad, de los recursos humanos, de las comunicaciones, del riesgo, de las adquisiciones, y de los interesados o stakeholders. En esta metodología los requerimientos se definen al inicio y se realizan todos los planes subsidiarios para posteriormente comenzar con la ejecución del proyecto, pero las condiciones del entorno actual requieren mejor manejo de la incertidumbre, especialmente en entornos complejos en los cuales los marcos de trabajo ágiles han demostrado ser bastante eficientes, razón por la cual estos marcos de trabajo han ido aumentando en popularidad en los últimos años.

16 de junio de 2020

El bloc de notas de un Agilista Jedi