Un Gran Pecado de las PMO y VMO

Imagen generada con DALL-E

En el mundo de las Oficinas de Gestión de Proyectos (PMO) y las Oficinas de Valor (VMO), se tiende a pensar que la gestión es clave. Sin embargo, algo que he observado en mi experiencia evaluando estas áreas y conversando con quienes las lideran es que, aunque no tienen que ser perfectas, cometen un pecado recurrente: la falta de validación del valor prometido en las iniciativas que gestionan.

Falta de Casos de Negocio Claros

Uno de los primeros problemas que encuentro es que muchas veces las PMO o VMO no cuentan con casos de negocio sólidos para las iniciativas que gestionan. Aún peor, cuando existen, esos casos suelen carecer de una promesa de valor específica. No basta con decir que una iniciativa mejorará los ingresos, la satisfacción del cliente, reducirá problemas o incrementará la eficiencia. Es necesario detallar cuánto se espera mejorar, ser específicos con el impacto esperado.

El Problema de No Medir el Valor Generado

El pecado más grande es que, incluso cuando se establece una promesa de valor, muchas veces no se mide si ese valor fue realmente generado. Las PMO y VMO tienden a centrarse en si los casos de negocio cumplen con el formato o si los proyectos avanzan según el cronograma, pero una vez completados, rara vez se verifica si realmente lograron el impacto prometido. Este enfoque limitado impide que las organizaciones identifiquen si las iniciativas fueron un éxito, si generaron desperdicio, o si podrían mejorarse para tener un mayor impacto en el futuro.

¿Por Qué la Validación del Valor es Crucial?

La validación del valor es, curiosamente, una de las actividades que menos se realiza en las PMO o VMO. Si tú lo haces en tu organización, estás entre los pocos que realmente aseguran que el valor prometido sea tangible. Entiendo que en muchos casos, los gerentes de proyectos no tienen la responsabilidad directa de validar el éxito post-implementación. Su rol suele centrarse en la ejecución del proyecto, no en evaluar si la solución funciona en el mundo real. Pero la organización como un todo no debería olvidar esta evaluación.

¿Cómo Corregir Este Pecado?

Reconozcamos que el impacto o valor generado por un proyecto no siempre es inmediato, pero puede y debe medirse en un tiempo razonable. Validar ese impacto permite:

• Identificar si el valor prometido fue logrado.
• Ampliar las buenas prácticas hacia otras áreas de la organización si el proyecto es exitoso.
• Asesorar al área solicitante para que mejores futuros casos de negocio si el resultado no fue el esperado.

Reflexión Final: ¿Qué Obstaculiza la Validación del Valor?

Muchas organizaciones no hacen esta validación porque no tienen un proceso claro para ello. Si tu organización no valida el valor de sus iniciativas, es hora de preguntarse: ¿qué lo está obstruyendo? Los pasos para mejorar esta práctica incluyen establecer métricas claras, fijar plazos de medición y crear un proceso formal para revisar el éxito o fracaso de los proyectos. Esto no solo mejora la efectividad de las iniciativas, sino que también asegura un aprendizaje continuo y una mejora en los procesos de negocio.

La validación del valor generado debe ser una prioridad, no solo para PMO o VMO, sino para cualquier organización que quiera optimizar sus inversiones en proyectos, productos y servicios.

Saludos ágiles,

Jorge Abad

Video: Antipatrones (malas prácticas) en priorización de Product Owners, PMO y VMO

---- Enlace al Póster ----

___

10 Anti-patterns (bad practices) in prioritization of Product Owners, PMO and VMO

Hello everyone

One of the factors that most destroys agility is the lack of adequate prioritization patterns according to the context in which it is located, that is, both upstream (1) and downstream (2) practices are used (which even from the good intention) destroy value for the organization. In general, we can incur:

• Building unnecessary things
• Building things that are necessary but worthless
• You don't build what's important
• We let ourselves be carried away by intuition
• We let ourselves be carried away by authority
• We let ourselves be carried away by feelings of friendship or enmity
• etc.

We destroy value and generate waste by dedicating time, effort and money from business areas, execution areas and suppliers in things that should not have been developed and relegating others, which would allow better financial performance or customer satisfaction.

---

---

---

(and one of mine)

"Building something that was not correctly prioritized is destroying value for the organization"

---

Below, I share some of the anti-patterns that I have observed when prioritizing both PMO - Project Management Office -, VMO -Value Management Office- and Product owners, and that I promote to be removed in processes of agile transformation or team agile coaching.  

I hope they will help you advance in the knowledge of better ways to prioritize the work to be done.

Expect more articles on this topic.

Agile greetings,

Jorge Abad.

 

References, notes, or comments

1. Upstream: where the project, product or initiative is prioritized by the PMO, VMO or those who are responsible for prioritizing the portfolio.
2. Downstream: where the product is being developed, and the solution team builds the different functionalities.

De Colección: 10 Antipatrones (malas prácticas) en priorización de Product Owners, PMO y VMO

Hola a todos,

Uno de los factores que más destruye la agilidad es la carencia de patrones adecuados de priorización de acuerdo con el contexto en el que se encuentre, es decir, tanto aguas arriba (upstream) (1) como aguas abajo (downstream) (2) se emplean prácticas (que aun desde la buena intención) destruyen valor para la organización. En general podemos incurrir en:

• construir cosas innecesarias
• construir cosas necesarias pero carentes de valor
• no se construye lo realmente importante
• nos dejamos llevar por la intuición
• nos dejamos llevar por la autoridad
• nos dejamos llevar por los sentimientos de amistad o enemistad
• etc.

En últimas, destruimos valor y hacemos que se genere desperdicio por dedicar tiempo, esfuerzo y dinero de áreas de negocio, áreas de ejecución y proveedores en cosas que no debían haber sido elaboradas y relegando otras, que permitirían un mejor desempeño financiero o de satisfacción del cliente.

---

---

(y una mía)

"Construir algo que no fue correctamente priorizado es destruir valor para la organización"

---

A continuación, te comparto algunos de los antipatrones que he observado al momento de priorizar tanto por PMO - Project Management Office -, VMO -Value Management Office- y Product owners, y que promuevo sean removidos en procesos de transformación ágil organizacional o de acompañamiento de equipos.

Espero te sirvan para avanzar en el conocimiento de mejores formas de priorizar el trabajo a realizar.

Espera más artículos sobre este tema.

Saludos ágiles,

Jorge Abad.

--- Ver video explicativo aquí ---

Referencias, notas o comentarios

1. Upstream: donde se prioriza el proyecto, producto o iniciativa por parte de la PMO, VMO o quienes se encargan de priorizar el portafolio.
2. Downstream: donde se está desarrollando el producto, y los equipos de solucionadores a construyen las diferentes funcionalidades.

RespuestasAgiles: ¿Qué es la LEY DE LITTLE y por qué es importante para las GERENCIAS DE TI y PMOs?

Varios proyectos a la vez generará más retraso en la generación de valor. Limita el WIP.

Hola a todos

Muchas veces tenemos la sensación de que debemos satisfacer las necesidades de todas las áreas o personas que nos piden tareas, requerimientos o proyectos, esto sucede a nivel:

• individual
• de equipo
• de áreas de construcción o ejecución de proyectos y productos de software,

con la sensación de que debemos atenderlos a todos, ya sea para no generar quejas, o por evitar problemas políticos, pero esto en vez de ayudarnos generará:

• pérdida de foco
• grandes esfuerzos de gestión y pérdida de energía, pues debes estar pendiente de varias cosas a la vez
• retrasos en la entrega, que a su vez generará:
• más inconformidad en las áreas que esperan resultados
• pérdida de valor de las funcionalidades construidas y la necesidad de introducir cambios
• sobrecostos por los cambios introducidos
• pérdida de dinero debido a la no generación oportuna de valor
• poca flexibilidad para reaccionar a los cambios, debido a que debes resolver muchas cosas a la vez y habrá demoras resolviendo un problema puntual.

Por eso, si lideras un equipo, un área de ejecución o aún de forma individual, te sugiero que:

• tengas foco
• hagas una o pocas cosas a la vez
• Limita el Work In Progres (WIP) o trabajo en progreso
• Aprende a decir ¡No!

Sino, tu propias ganas de satisfacer a todos, distruirá tu propósito de generar valor, cayendo en el adagio popular 

"El que mucho abarca, poco aprieta"

Saludos ágiles

Jorge Abad

Un Ejemplo Práctico de Gestión Lean-Agile de Portafolio

Ejemplo Técnico de Gestión Lean-Agile del Portafolio de Proyectos o Productos

(No incluye conversaciones del Meetup de Agiles Colombia)

Nota: Sí solo deseas ir al video del que explica la hoja de cálculo y como se obtuvieron los valores, el video a continuación es para tí (duración 41:20).

---

Video del Meetup de AgilesColombia sobre este ejemplo de Agilidad del Portafolio

Nota: El video a continuación incluye toda la sesión que se hizo en ÁgilesColombia el pasado 22 de septiembre (clic aquí para ir a sitio del meetup) : explicación del ejemplo, conversaciones, discusiones y reflexiones al respecto (duración 1:52:46)

---

Artículo en Linkedin:

Un Ejemplo Práctico de Agilidad en el Portafolio - clíc aquí -

---

Los 8 grandes desperdicios del Top Management en TI

Estamos en tiempos disruptivos, los cambios saltan y avanzan por doquier, las innovaciones, el cambio climático, la inteligencia artificial, el Internet de las cosas, los virus (escribo esto cuando el COVID-19 está conquistando el mundo – por si lo lees en un futuro cercano o lejano –), la economía, la política entre otras cosas, se han vuelto impredecibles, bien etiquetaba el Ejército de los Estados Unidos esta era como VUCA (1), tiempos en los que el más rápido le quita el mercado al más lento.

Dado este contexto, la forma como hemos venido haciendo las cosas, aunque nos trajo hasta donde estamos hoy, no es muy útil para este presente ni para la supervivencia en el futuro, pues necesitas generar en tu organización la capacidad de adaptarte rápido a los cambios o de ser el causante del de ellos, es allí donde es necesario un liderazgo Lean-Agile: Lean (2) desde el enfoque de generación de flujo continuo de valor y eliminación del desperdicio, como Agile(3) desde su enfoque en la adaptación, mejora continua, generación de valor y colaboración.

Es desde la óptica Lean y su guerra sin cuartel contra el desperdicio, que quiero poner foco en este artículo, ya que desde TI y de las Áreas de Negocio “hoy en día” no podemos darnos el lujo de tener desperdicios a granel y no hacernos cargo de ellos, permitiéndole a la competencia ganar donde nosotros estamos perdiendo, ergo cualquier desperdicio tarde o temprano será valor que se dejó de generar, energía que dejamos ir y no podremos recuperar.

Los Ocho Desperdicios de Lean en Desarrollo y Mantenimiento de Productos de Software

Lean tiene identificado ocho desperdicios:

·     Sobreproducción

·     Inventario

·     Sobreprocesamiento

·     Defectos

·     Movimientos

·     Transporte

·     Esperas

·     Creatividad de los empleados no utilizada

Las áreas de TI no son ajeas a estos desperdicios. Seguramente han o has tenido que lidiar con algunos de los que enumero a continuación:

Sobreproducción: hacer más producto del que es requerido
Síntoma	Consecuencias	Sugerencias y Comentarios
Hacer más software o producto del que es requerido	·       Pérdida de dinero ·       Pérdida de tiempo invertido en hacer definiciones que no son requeridas ·       Pérdida de tiempo y dinero probando funcionalidades que no serán usadas ·       Pérdida de tiempo haciéndole mantenimiento a software que nadie usa ·       En el futuro, migrar a otros sistemas funcionalidades innecesarias ·       Software innecesario siendo causa de posibles errores y ocupando espacio en los servidores	·       Aplicar un enfoque ágil para el desarrollo de productos software ·       Construir MVP (Productos Mínimos Viables) (4) y validar hipótesis de valor lo antes posible ·       Comenzar a migrar a un paradigma enfocado en Valor y no en el Alcance. No se trata de hacer mucho, se trata de trabajar de forma inteligente ·       Priorizar los desarrollos de iniciativas, mantenimientos evolutivos y correctivos por valor, no le diga a todas las áreas ¡sí!

Inventario: almacenamiento de producto que no está siendo usado
Síntoma	Consecuencias	Sugerencias y Comentarios
Versiones o actualizaciones de software que se encuentran desarrolladas y probadas, pero “NADA” que pasan a producción, “NINGÚN” área de negocio las reclama, estan en los servidores de staging esperando que alguien se acuerde de ellas para pasar a producción	·       Costos y tiempos de actualización de versiones (ej: he visto pagar ingenieros por más de un año actualizando versiones que no salen a producción) ·       Costos y tiempos de pruebas de versiones que no están siendo usadas	·       Borre de su servidor las versiones que no han sido puestas en producción hace más de 4 meses, si nadie las reclama, es que nadie las necesita. ·       Priorice las versiones por valor (nuevamente no diga a todo sí, recuerde, no hay tiempo para construir desperdicio)
Software subutilizado o no utilizado	·       Millones de dólares en tiempo y dinero que no están siendo usados.	·         Identifique si el pareto (20%) de las funcionalidades le genera un 80% de impacto en el negocio. ·       Haga programas de gestión del cambio que le permita usar al menos el 20% de lo que compró.

Movimientos innecesarios: movimientos innecesarios por parte del equipo de trabajo
Síntoma	Consecuencias	Sugerencias y Comentarios
Demasiados procesos manuales de parte de su equipo	·       Emerge un gran número de errores durante los procesos debido a esos procesos manuales	·       Reemplace y priorice toda tarea repetitiva en su equipo por otra automatizada, de manera que tenga foco en la generación de valor, no tiene sentido que un desarrollador de software esté haciendo trabajo manual en pleno siglo 21. ·       Adopte una mentalidad y cultura de DevOps en su equipo, “automatice todo lo automatizable” ·       Genere pipelines de CI, CD ·       Cree macros que ayuden a poblar datos ·       Automatice las pruebas (de todo tipo) ·       Use bots ·       Tenga herramientas que le den tracking de todo su ciclo de desarrollo de software

Sobreprocesamiento: se está volviendo a realizar un proceso sobre un componente de forma innecesaria.
Síntoma	Consecuencias	Sugerencias y Comentarios
Las versiones no salen oportunamente debido a cambios en el entorno	·       Las versiones deben ser construidas de nuevo. ·       Pérdida de tiempo y dinero de todos los involucrados.	·         Ver las sugerencias de “desperdicios por inventario”
Se especificaron requisitos o historias de usuario que ya no son necesarias porque el negocio cambió, y es necesario volver a hacer definiciones	·       Pérdida de tiempo y dinero de todos los involucrados	·       Abandone la idea de tener en productos de software “todo” definido a priori, avance hacia realizar una definición progresiva de las funcionalidades, en vez, de una definición “completa” desde el inicio.
Refactor por componentes mal desarrollados (deuda técnica)	·       Pérdida de tiempo, dinero y performance del producto	·       Monitoreé y reduzca la deuda técnica, la Agilidad dependerá de ello. ·       Exija excelencia técnica tanto de sus colaboradores como de proveedores
Rediseño por componentes mal concebidos	·         Pérdida de tiempo, dinero y performance del producto.	·        Aplique principios de Arquitectura Evolutiva y Arquitectura Ágil que le permita ser resiliente a los cambios

Espera: tiempos muertos mientras se espera el próximo paso del proceso
Síntoma	Consecuencias	Sugerencias y Comentarios
Controles de cambio demasiado lentos	·       Pérdida de tiempo y dinero de los involucrados ·       Falta de generación oportuna de valor	·       Automatice su proceso de control de cambios, si es necesario ponga puntos de control, pero que no dependan de un comité, sino de un experto, y que este experto pueda aprobar sobre la herramienta directamente
Procesos de aprobación de paso entre plataformas demasiado lentos	·      Ibídem	·         Ibídem
Al cliente le llega el producto cuando: ·        no lo necesita ·        la  competencia le quito la porción de valor que esperaba ganar ·        ya no es necesaria la solución	·        Íbidem	·        Adopte una forma de pensar ágil en su organización ·        Aprenda a salir a producción con MVP lo más temprano posible (ojala al segundo mes ya tenga software funcionando en manos del cliente)

Defectos: defectos visibles e invisibles de los productos
Síntoma	Consecuencias	Sugerencias y Comentarios
Deuda técnica (defectos invisibles)	·       Pérdida de tiempo y dinero de los involucrados en la corrección ·       Impacto en el negocio por mal desempeño del producto	·       Monitorée y reduzca la deuda técnica, la Agilidad dependerá de ello. ·       Exija excelencia técnica tanto de sus colaboradores como de proveedores
Defectos en el producto (defectos visibles)	·        Íbidem	·        Exija excelencia técnica tanto de sus colaboradores como de proveedores ·        Es una buena estrategia que el equipo que desarrolla el producto sea el mismo que le da mantenimiento en producción, esto genera responsabilidad con lo construido. ·       Adopte DevSecOps, o el concepto de ShiftLeft y rete constantemente a su equipo de operaciones y desarrollo.

Movimientos innecesarios de los productos: el producto es movido a una fase anterior o a un punto innecesario
Síntoma	Consecuencias	Sugerencias y Comentarios
El producto se devuelve a la fase previa por mala calidad o problema en los requisitos.	·    Pérdida de tiempo y dinero de los involucrados Falta de generación oportuna de valor	·       Exija excelencia técnica tanto de sus colaboradores como de proveedores ·       Tenga una aproximación ágil en la construcción de productos, haciendo definición progresiva de los mismos.
El producto debe ser “bajado” de producción porque la versión salió defectuosa	·         Pérdida de tiempo y dinero de los involucrados ·        Mal impacto ante el cliente	·       Use estrategias de DevOps como: “Canary Releases” (5), “Dark launches” (6) , “Feature Toogles”(7). ·        Desacople Release (Liberación) de Despliegue (8), le dará más maniobrabilidad

No emplear el talento de las personas
Síntoma	Consecuencias	Sugerencias y Comentarios
Solo su voz es la que importa y usted es el dueño de la estrategia	·         Está perdiendo la oportunidad de recoger recomendaciones importantes de su equipo de trabajo	·       Reúnase una vez al mes con su equipo y encuentren 2 a 3 cosas a mejorar para el siguiente mes.
Estamos demasiado ocupados para sentarnos a conversar y mejorar	·       Íbidem	·       Rompa el círculo vicioso y frenético de: “no mejoramos porque no tenemos tiempo, no tenemos tiempo porque no mejoramos” ·       Reúnase una vez al mes con su equipo y encuentren 2 a 3 cosas a mejorar para el siguiente mes y en efecto mejórelas (sino esta reunión tambien será desperdicio)

Llamado a la acción

Si desde TI o las Áreas de negocio vamos a generar desperdicios, que estos sean experimentos controlados de productos rápidos y baratos, que nos permitan capturar aprendizaje y nos den pistas sobre cómo avanzar en este terreno de volatilidad, incertidumbre, complejidad y ambigüedad, pero que no sean pérdidas de energía que terminen dando oportunidad a la competencia.

Si como CIO, o parte del Equipo del Top Management de TI has identificado al menos uno de estos síntomas, priorízalo, haz de la mejora continua la costumbre de tu equipo, toma métricas y comienza tu camino hacia la excelencia operativa y de negocios de una forma decidida y constante.

Como siempre, bienvenida la retroalimentación

Saludos Ágiles

Jorge Abad.

Notas, Aclaraciones, Comentarios, Referencias y Observaciones.

1.      VUCA es un acrónimo utilizado para describir o reflejar la volatilidad, incertidumbre (uncertainty en inglés), complejidad y ambigüedad de condiciones y situaciones. Más información en https://es.wikipedia.org/wiki/VUCA

2.      Lean es la forma como Jame Womack acuño la esencia del Toyota Production System. Más información en https://en.wikipedia.org/wiki/Lean_thinking

3.      Agile es la forma como es conocido el Agile Software Development, comprende varios enfoques para el desarrollo de software bajo los cuales los requisitos y las soluciones evolucionan a través del esfuerzo colaborativo de equipos autoorganizados y multifuncionales y sus clientes / usuarios finales, es representado condensado en cuatro valores y doce principios. Ver más en https://en.wikipedia.org/wiki/Agile_software_development.

4.      Un Producto Mínimo viable (MVP – Minimum Viable Product por sus siglas en Inglés ) es una versión de un producto con características suficientes para satisfacer a los primeros clientes y proporcionar comentarios para el desarrollo futuro del producto.  Ver más en https://en.wikipedia.org/wiki/Minimum_viable_product.

5.      Canary releases: Técnica que proporciona un mecanismo para lanzar la solución a producción a un segmento de Cliente específico y medir los resultados, antes de expandirse y lanzar a más clientes. Ver más en https://www.scaledagileframework.com/release-on-demand/.

6.      Dark Launches: Esta técnica proporciona la capacidad de desplear en un entorno de producción de forma “apagada” sin liberar la funcionalidad a los usuarios finales.

7.      Feature Toogles: Esta es una técnica para facilitar los “Dark launches” mediante la implementación de conmutadores en el código, que permite cambiar entre funcionalidad antigua y nueva. Ver más en https://www.scaledagileframework.com/release-on-demand/.

8.      Desacople el Release del Despliegue, estrategia de DevOps que permite poner código constantemente en producción y habilitarlo cuando este vaya a ser usado, reduciendo el impacton impacto la estabilidad del sistema por cambios realizdos. Ver más en https://www.scaledagileframework.com/release-on-demand/.

9.      Gracias a mis amigos Lucho Salazar- https://www.linkedin.com/in/luchosalazar/ -  y Ricardo Cruz - https://www.linkedin.com/in/ricardocruzmartinez/ -  por sus aportes y correcciones.