Actualmente es imposible no encontrar referencias a las IA (Inteligencias Artificiales) en cualquier medio de comunicación. Y, aprovechando la salida a finales del años pasado de la IA Infinity de PMI, me parece interesante comprobar cuales son sus capacidades en materia de gestión de riesgos en los proyectos en primera instancia, antes de comprobar sus capacidades de ayuda a la gestión de proyectos de forma global.
El PMI proporciona una herramienta basada en AI Co-Pilot y GPT 4 denominada PMI Infinity.
Esta herramienta ofrece respuestas y recomendaciones confiables y precisas para solucionar problemas que se puedan presentar a lo largo de la ejecución de los proyectos, gracias a que cuenta con una interfaz conversacional, que selecciona información relevante de la amplia biblioteca del PMI y aprovecha la arquitectura abierta de AI GPT 4.
Se debe tener en cuenta que esta aplicación se ha construido sobre un servicio OpenAI privado y dedicado, por lo tanto, sólo el PMI, lo mantiene, entrena y utiliza. Ninguna información con la que se ha entrenado, ni ninguna entrada o salida de las interacciones del usuario, se agrega a ningún servicio público de IA.
Para acceder a PMI Infinity, es necesario iniciar sesión utilizando tu nombre de usuario y contraseña del PMI. A partir del 12/Feb/24 solo pueden acceder los miembros del PMI , pues hasta esa fecha el acceso era libre).
Una vez que se ingresa a https://infinity.pmi.org/login, se encuentra la interfaz conversacional y se podrá iniciar la búsqueda.
CONSIDERACIONES:
Antes de utilizar PMI Infinity hay que tener en cuenta las siguientes consideraciones:
PMI Infinity es una herramienta complementaria para los Project Managers, si bien puede brindar información valiosa y recursos útiles, no reemplazan la experiencia y el juicio del Director de Proyecto. Por lo tanto, es él quien debe guiar y refinar el proceso de búsqueda, así como saber interpretar, aplicar y utilizar la información que encuentra para facilitar su gestión.
La calidad y precisión de las respuestas que se obtienen, depende de cómo se formulen los “prompts”, es decir “las instrucciones de búsqueda” que están representadas por las situaciones y/o escenarios que se plantean a la herramienta.
Para encontrar las respuestas esperadas se debe utilizar técnicas denominadas “prompt engineering”, las cuales buscan asegurar aspectos como:
•Reducir las malas interpretaciones
•Proporcionar contexto, limitaciones específicas y resultados deseados
•Presentar ideas coherentes, siguiendo un flujo estructurado de información
“Una IA puede disminuir el tiempo dedicado a la creación, pero incrementa el tiempo dedicado a la supervisión”
Se recomienda empezar con conversaciones simples y no estructuradas:
¿CÓMO PMI PUEDE FACILITAR LA GESTIÓN DE RIESGOS?
Para facilitar la gestión de riesgos de los proyectos que están a cargo de la OGTP, PMI Infinity puede ser una herramienta valiosa y que se puede aplicar en las siguientes etapas que conforman el proceso de riesgos:
Para lograr que la herramienta ofrezca una ayuda adecuada, se deben formular “Prompts” precisos, claros y según el contexto de cada proyecto, por lo tanto se recomienda tener en cuenta los siguientes tips:
A continuación, se presentan algunos “PROMPTS” GENERALES de ejemplo que pueden servir de apoyo:
Por favor, enumera las principales causas de riesgos en un proyecto de… (Ejemplo: desarrollo de software, infraestructura, automatización, mantenimiento, entre otros)
¿Podrías darme una lista de riesgos potenciales que se pueden presentar en proyectos de… (Ejemplo: desarrollo de software, automatización, suministros, entre otros)
¿Puedes mencionar cuáles son las categorías de riesgo que se deben considerar en un proyecto de… (Ejemplo: desarrollo de software, automatización, suministros, entre otros)
Dame los 10 mejores consejos referentes a la gestión de riesgos.
¿Me puedes explicar cómo un bajo nivel de… (Ejemplo: comunicación, planificación, coordinación, entre otros) puede impactar en la ejecución de un proyecto de… (Ejemplo: desarrollo de software, suministros, mantenimiento, entre otros)
¿Cuáles son los riesgos de no completar un proyecto de… (Ejemplo: desarrollo de software, mantenimiento, suministros, entre otros) dentro del tiempo y presupuesto asignado?
A continuación, se presentan algunos “PROMPS” ESPECÍFICOS de ejemplo, que pueden servir de apoyo:
Actualmente estoy asignado a un proyecto como Gerente de Proyecto. El proyecto está en su fase de… (Ejemplo: “inicio”). El objetivo de este proyecto es… (Ejemplo: “realizar mejoras sobre la herramienta que se utiliza para realizar al proceso de autenticación biométrica a los clientes”), buscando… (Ejemplo: “mejorar los indicadores de atención de clientes y número de créditos aprobados”). Para asegurar una ejecución y gestión adecuada del proyecto, necesito realizar una identificación de riesgos potenciales que pueden impactar el proyecto.
Por favor identifica los riesgos potenciales y para cada uno de ellos debes incluir los siguientes detalles en una tabla: nombre del riesgo, con un título breve que resume la esencia del riesgo; descripción del riesgo, con una explicación detallada del mismo, indicando probabilidad e impacto por orden de importancia y cómo puede impactar en los objetivos del proyecto.
Hola, soy Project Manager y me gustaría que me plantearas preguntas que me permitan realizar una identificación oportuna de los riesgos que pueden impactar a mi proyecto. Mi proyecto tiene el objetivo de… (Ejemplo: “realizar mejoras en la aplicación que se utiliza en la empresa para la gestión de incidentes reportados por los empleados a través de la intranet”.
¿Qué tipo de respuesta al riesgo: aceptar, escalar, mitigar, evitar o transferir, se debería de escoger para un riesgo de… (Ejemplo: “retraso en el cronograma debido a ampliación del alcance”)?
¿Cómo mitigar un riesgo de…(Ejemplo: “cambios de alcance”) en un proyecto de… (Ejemplo: “desarrollo de software”).
¿Cómo crear un plan de contingencia para un riesgo de… (Ejemplo: “retrasos de cronograma”) en un proyecto de… (Ejemplo: “diseño de una aplicación web”).
ANEXO, VIDEO:
FUENTES CONSULTADAS:
•https://www.pmi.org/membership/infinity
•(2024) Project Management Institute: Talking to the machine
•(2024) Project Management Institute: An Overview of PMI Infinity
•(2023) Project Management Institute: Shaping the future of Project Management with AI
Consciente de la importancia que está teniendo últimamente en materia de proyectos el movimiento de mezclar elementos de las metodologías predictivas o waterfall, agile, Six Sigma y otras, el PMI ha lanzado una nueva certificación orientada a cubrir esta necesidad formativa.
La micro-credencial ágil / híbrida se alinea con la Guía para el cuerpo de conocimiento de la gestión de proyectos, la Guía del PMBOK, (que ya está en su versión 7) y que es el estándar global preeminente para la gestión de proyectos y que proporciona las prácticas fundamentales de la profesión.
Según el PMI «Los poseedores de la certificación Agile Hybrid Project Pro Micro-Credential han demostrado su amplio conocimiento de conceptos, tareas y técnicas de gestión de proyectos ágiles / híbridos que son aplicables en prácticamente cualquier industria. Los poseedores pueden hablar y comprender el lenguaje global de la gestión de proyectos ágiles / híbridos. Los poseedores han demostrado el conocimiento y las habilidades necesarias para gestionar los planes, el alcance, las partes interesadas, los riesgos, los presupuestos, el cumplimiento, los recursos, la resolución de problemas y la entrega de valor del proyecto.»
La certificación Project Pro Micro-Credential se está introduciendo para ayudar a los gerentes de proyectos tradicionales, titulares de la certificación PMP existentes, gerentes de proyectos con conocimientos ágiles / híbridos y / o experiencia, para alinearse con los últimos estándares de la industria.
Y es que, como ya vimos en la entrada correspondiente a la certificación Google de Project Management, es ya un hecho que, en lugar de seguir una sola metodología para la gestión de un proyecto, lo más adecuado es estudiar tanto las características del proyecto como las peculiaridades de la empresa y decidir qué es lo más adecuado para lograr el éxito.
Se trata de un movimiento imparable que se ha convertido en tendencia. Mal que le pese a los apóstoles del agilismo o del waterfall puros, muchos responsables de proyectos se han dado cuenta, a través de la experiencia, de que el éxito de un proyecto depende mucho de la cultura de la empresa y que el uso de prácticas o artefactos de las diferentes metodologías puede ayudar enormemente a llevar a buen fin un proyecto.
Ya nadie duda que las daylies que provienen del agilismo ayudan mucho a mejorar la comunicación del equipo y fomentan la transparencia. Y lo mismo ocurre con las «Retrospectivas«, que proporcionan un feedback excelente acerca de lo que ha sucedido en una fase, iteración o proyecto. Por otra parte, el Business Case de la metodología Prince2 se ha demostrado que proporciona claridad en la definición de los objetivos del proyecto y la búsqueda de rentabilidad o de valor añadido. Es un hecho que muchos proyectos hacen un kickoff para iniciar sus proyectos y completan un Project Charter para definir lo que el proyecto debe cumplir.
A continuación, muestro un resumen de algunos de los enfoques de gestión de proyectos que pueden componer el enfoque híbrido:
Predictiva o Waterfall es una metodología tradicional en la que las tareas y fases se completan de manera lineal y secuencial, y cada etapa del proyecto debe completarse antes de que comience la siguiente. El Project Manager es responsable de priorizar y asignar tareas a los miembros del equipo. En el enfoque predictivo, los criterios utilizados para medir la calidad están claramente definidos al inicio del proyecto. Es ideal para proyectos en los que los requisitos están claros desde el principio (lo que no suele ser muy normal).
Agile implica fases cortas de trabajo colaborativo e iterativo con pruebas frecuentes y mejoras implementadas regularmente. Algunas fases y tareas ocurren al mismo tiempo que otras. En los proyectos ágiles, los equipos comparten la responsabilidad de gestionar su propio trabajo. Scrum y Kanban son ejemplos de marcos ágiles, que son enfoques de desarrollo específicos basados en la filosofía Agile.
Scrum es un marco ágil que se enfoca en desarrollar, entregar y mantener proyectos y productos complejos a través de la colaboración, la responsabilidad y un proceso iterativo. El trabajo lo completan equipos pequeños y multifuncionales dirigidos por un Scrum Master y un Product Owner y se divide en Sprints cortos con una lista seleccionada de entregables.
Kanban es tanto un enfoque ágil como una herramienta que proporciona retroalimentación visual sobre el estado del trabajo en progreso mediante el uso de tablas o gráficos Kanban. Con Kanban, los gerentes de proyecto usan notas adhesivas o tarjetas de notas en un tablero Kanban físico o digital para representar las tareas del equipo con categorías como «Por hacer», «En progreso» y «Listo».
Prince2 es una metodología de gestión de proyectos que se plantea sean realizados entre otras actividades considerando 7 temas: la Calidad, el Cambio, la estructura de roles del proyecto (Organización), los planes (Cuánto, Cómo, Cuando), el Riesgo y el Progreso del proyecto, justificado por un Business Case (o necesidad del negocio) que es la que evidencia la realización de ese proyecto.
Lean utiliza la herramienta de calidad 5S (clasificar, ordenar, limpiar, estandarizar, disciplina) para eliminar ocho áreas de desperdicio, ahorrar dinero, mejorar la calidad y agilizar los procesos. Los principios de Lean establecen que puede hacer más con menos al abordar las disfunciones que generan desperdicio. Lean implementa un sistema de programación Kanban para administrar la producción.
Six Sigma implica reducir las variaciones asegurando que los procesos de calidad se sigan en todo momento. El método Six Sigma sigue un enfoque de mejora de procesos llamado DMAIC, que significa definir, medir, analizar, mejorar y controlar.
Lean Six Sigma es una combinación de enfoques Lean y Six Sigma. A menudo se utiliza en proyectos que tienen como objetivo ahorrar dinero, mejorar la calidad y avanzar rápidamente en los procesos. Lean Six Sigma también es ideal para resolver problemas complejos o de alto riesgo. La herramienta de calidad 5S, el proceso DMAIC y el uso de tableros Kanban son todos componentes de este enfoque.
El examen de certificación se basa en la aplicación de los siguientes principios y conceptos:
Manejar conflictos y liderar un equipo
Apoyar el desempeño del equipo, empoderar a los miembros del equipo y a las partes interesadas
Abordar y eliminar impedimentos, obstáculos y bloqueos para el equipo
Colaborar con las partes interesadas e involucrar a las partes interesadas
Desarrollar un entendimiento compartido, involucrar y apoyar a equipos virtuales
Ejecute el proyecto con la urgencia necesaria para ofrecer valor empresarial
Gestionar comunicaciones, evaluar y gestionar riesgos
Planificar y administrar el presupuesto, el cronograma, la calidad de los productos / entregables, el alcance, los cambios y los problemas del proyecto
Planificar y gestionar el cumplimiento del proyecto
Evaluar y entregar los beneficios y el valor del proyecto
Los dominios en los que se basa el examen son los siguientes:
People,
Process
Business Environement.
La siguiente tabla identifica la proporción de preguntas de cada dominio que aparecerán en el examen:
Por último comentar que el examen de certificación se puede realizar «on line» en modo «unproctored» y consta de 60 preguntas, que se deben completar en 75 minutos. Superar el examen proporciona 13 PDUs válidos para el mantenimiento de los poseedores de la certificación PMP.
Interesante este libro escrito conjuntamente entre PMI y Agile Aliance. Un apunte, si formas parte de PMI y pagas las cuotas anuales de socio, puedes descargar este libro de forma gratuita en formato pdf desde la web de www.pmi.org
Y da que pensar que el PMI (que ya cuenta con una certificación especifica en materia de agilidad) da por sentado que la agilidad es una metodología que ha llegado para quedarse durante mucho tiempo entre los Project Managers.
Dado que la agilidad se ha expandido a otros ámbitos de desarrollo, el enfoque de este libro se expande más allá del mundo de desarrollo de software
Esta guía está dividida en siete secciones.
1. Introducción
¿Por qué un manual de este tipo ahora? Porque la agilidad es una metodología que busca proporcionar al cliente una inmediata entrega de valor, a través de varias interacciones y esto es muy valorado ahora, pues las empresas buscan ser competitivas orientándose a la experiencia que obtiene el usuario. Son adecuadas para manejar la disrupción.
Los autores comentan que no está en alcance de este libro estudiar cómo extender la agilidad entre toda la organización sino extenderla a uno o varios proyectos. Es una lástima, porque si la organización no cambia es difícil que los proyectos ágiles tengan éxito.
2. Introducción a la agilidad
Esta sección trata fundamentalmente del origen de la agilidad y de los principios que lo sustentan
la justificación de la agilidad se basa en que el manejo de la incertidumbre es algo que las metodologías predictivas no manejan bien, pues no están orientadas a aceptar el cambio, la complejidad y el riesgo.
El manifiesto ágil de desarrollo de software del año 2001 puso por encima de todo a las personas por encima de los procesos. Se crearon cuatro valores y doce principios
Me llama la atención la referencia a la relación entre Lean/agile, pero el enfoque de ambos es diferente
Interesante la matriz de complejidad de Stacey. Un proyecto puede empezar en un sitio de la matriz y acabar en otro.
Resumiendo, los proyectos más adecuados para ser abordados por la metodología agil son aquellos que:
Requieren de investigación
Tienen altas posibilidad de sufrir cambios
Presentan requerimientos desconocidos o poco claros
Tienen un propósito difícil de describir
3. Selección del ciclo de vida
Es la parte más interesante del libro, con diferencia.
Habla de los cuatro tipos de ciclos de vida de los proyectos: predictiva, iterativa, incremental y ágil y de sus características. Estoy de acuerdo con su apreciación de que no hay un ciclo de vida perfecto para todos los proyectos:
Los ciclos de vida predictivos se benefician de entornos en los cuales los requerimientos están bien definidos y marcados (ej. un proyecto fruto de una exigencia legal). Su punto débil son los cambios y que no entregan valor hasta el final del proyecto.
Los ciclos de vida iterativos son beneficiosos si existe una alta complejidad, si hay cambios frecuentes o si el alcance depende de diferentes interesados. Están optimizados para el aprendizaje. Un ejemplo son las «refactorizaciones» de software.
Los incrementales se orientan a la velocidad de la entrega. Se entregan frecuentes y pequeños entregables. Un ejemplo puede ser completar un aplicativo de software mediante el desarrollo de diferentes módulos. O mostrar cómo quedaría una habitación en el proyecto de construcción de un edificio.
Los agiles son excelentes aproximaciones cuando se espera una gran cantidad de cambios en un proyecto. La diferencia de ágil con los ciclos interactivos e incrementales es que estos últimos proporcionan feedback para la siguiente parte del proyecto, pero, sin embargo, en proyectos ágiles, la entrega incremental descubre ocultos o requisitos incomprendidos. A su vez, los ciclos agiles pueden basarse en iteraciones o en flujos de trabajo. los ciclos ágiles combinan aproximaciones incrementales e iterativas para entregar valor de forma frecuente al cliente.
Como síntesis de todo lo anterior surgieron los ciclos de vida híbridos, que son los que se combinan para obtener ciertos objetivos. Por ejemplo, se puede trabajar en las primeras fases de un proyecto con metodologías ágiles (si se necesita investigación) y luego pasar a una metodología predictiva (si se debe cumplir una certificación). O combinar ambas metodologías según para qué aspectos (a mí esto me parece más complejo). Hay muchas combinaciones posibles.
Este apartado es tan interesante y está descrito a tan alto nivel, que necesita más desarrollo.
4. Implementando ágil: Creando un entorno ágil
Mencionan que un entorno ágil exige un líder «sirviente», (que haga de facilitador del éxito del equipo), en lugar de un líder tal y como se describe en los proyectos predictivos. Este tipo de lider debería de pasar de «gestionar» la coordinación a «facilitar» la coordinación.
No se ha tocado la parte correspondiente al «mapeo» de roles entre metodologías predictivas/ágiles. Otro tema interesante pendiente.
Y le impone al líder «sirviente» una tarea adicional, tratar de remover los impedimentos organizativos al equipo del proyecto que pudieran hacer de «cuello de botella». Sinceramente pienso que si la organización no se orienta a la agilidad, es bastante complejo que el líder sirviente pueda solucionar por sí solo este problema.
Precisamente y dado que el papel del project manager no se contempla dentro de la agilidad, pues según el PMOK 6 son los encargados de obtener los resultados del proyecto y esta responsabilidad en ágil se distribuye por igual en el equipo del proyecto, propone que hagan de lideres «sirvientes», es decir, que sirvan al equipo del proyecto, allanando su camino.
Si el enfoque predominante es ágil, entonces el papel del PM cambia radicalmente y debe orientarse hacia el liderazgo servil que requiere este tipo de enfoque.
Se habla de los atributos de los equipos agiles exitosos. Comenta que a los equipos ágiles se les debe evitar el coste que supone la «multitarea» de trabajar en varios proyectos de forma simultánea, así como que idealmente deberían de compartir el mismo espacio físico. Se alerta contra el peligro de querer trabajar en forma de «mini waterfalls» que es lo que sucede si se presupone que ya se tienen todos los requerimientos y ya se puede hacer todo el diseño (por ejemplo) o todo el desarrollo. El equipo se dará cuenta de que esa asunción en el mundo ágil no es válida.
Los tres roles que menciona son: product owner, equipo multifuncional y facilitador del equipo (llámese scrum master, project manager o team coach). Apunta que lo ideal es contar con especialistas de tipo «T», que son los que complementan ser expertos en una materia con conocimientos en otras areas.
Alerta acerca de evitar «silos» en la empresa que impidan que la comunicación fluya en el equipo.
5. Implementando ágil: entregando en un entorno ágil
Todo proyecto necesita un acta de constitución donde se defina el proyecto. Pero esto no es suficiente n un entorno ágil. También necesita una visión, un propósito y unas normas de cómo trabajar en equipo.
Las prácticas agiles más importantes son:
Retrospectivas. Permite al equipo aprender, mejorar y adaptar su proceso. No es necesario que sea al final de una iteración de dos semanas. se puede solicitar en cualquier momento. Busca las causas raíz de los problemas sufridos y se desarrolla un plan de acción para solucionarlos.
Preparación del backlog (lista del trabajo presentado en forma de historias de usuario). No es necesario tener todo el trabajo que el proyecto requiera sino solo el que se va a desarrollar en siguiente sprint o iteración. Esta es tarea del product owner
Refinamiento del backlog. Es la preparación de historias de usuario para la siguiente iteración. Si no se conocen las dependencias entre tareas entonces el product owner puede solicitar al equipo la realización de un «spike«, con el fin de conocer los riesgos. Señala que el equipo no debería de emplear más de una hora a la semana en refinar historias. En caso contrario podría indicar que al equipo le faltan habilidades técnicas necesarias para evaluar y refinar el trabajo.
Reuniones diarias. Las mini reuniones diarias (de no más de 15 minutos) se usan para declarar lo trabajado, lo que se va a trabajar, así como para hacer aflorar posibles problemas. No se deben convertir en sesiones de análisis de situación del proyecto ni tampoco se deben usar para tratar de resolver problemas.
Demos/reviews. Para proporcionar feedback al product owner, se organizan demos de lo desarrollado en cada iteración. Deben ser frecuentes para así poder dar con la dirección adecuada.
Planificación de la iteración. La capacidad de cada equipo es diferente. Se debe hacer una estimación de la capacidad.
Prácticas de ejecución que ayudan a los equipos a entregar valor:
Integración continua
Test en todos los niveles
ATDD test de aceptación.
TDD y BDD test driven development y behavior driven development
Spikes. Útiles para aprender sobre elementos técnicos o funcionales críticos.
Cómo las iteraciones y los incrementos ayudan a entregar producto. Las iteraciones ayudan al equipo a crear una cadencia de entrega y muchos tipos de feedback. Las demos son una parte necesaria dentro del flujo de los proyectos ágiles.
Por otra parte, se señalan los desafíos que implican los proyectos ágiles y las posibles soluciones. Muy interesante esta parte.
Medidas en los proyectos ágiles:
Es un desafío tratar de determinar la medida de avance en un proyecto ágil. Además de las medidas cuantitativas habituales, cobra importancia añadir medidas cualitativas, como la satisfacción del usuario o la moral del equipo de desarrollo.
Los valores de avance en agil son empíricos y tratan de lo que se ha hecho, en lugar de que va a realizar. Por su naturaleza, la estimación se limita a unas pocas semanas.
La velocidad del equipo calculada en story points es lo que realmente puede permitir hacer una estimación de cuando se podrá terminar el proyecto.
Si el quipo depende de las tareas de externos al proyecto, esto puede interferir en su velocidad notablemente.
Para que el progreso de un proyecto ágil sea comprensible a un project no iniciado en ágil, se hace una equivalencia de cómo calcular el Valor Ganado (EMV) haciendo un sencillo cálculo del índice SPI (cronograma) características completadas/características planificadas y del CPI (coste) valor ganado/costes actuales
6 Consideraciones organizativas para proyectos agiles
Los autores son conscientes de que los proyectos existen en un contexto determinado. Por eso se considera fundamental el cambio organizativo que permita aplicar la agilidad, en especial se consideran fundamentales los cambios asociados a la entrega rápida y frecuente y a los cambios constantes en los requerimientos. El mismo PMI publicó una guía para gestionar el cambio en las organizaciones: Managing Change in Organizations: a Practice Guide
Dice la frase de Peter Druker «Culture eats strategy for breakfast», la cultura de la empresa, que es su ADN, siempre impacta de forma intensa en las estrategias y en especial en el uso de aproximaciones ágiles en la gestión de proyectos.
Respecto a la parte de la gestión de contratos con proveedores, los autores animan a seguir un esquema de contratos de tipo «win-win», (todos ganan con el acuerdo) que no es una característica en absoluto privativa de los enfoques ágiles.
Por otra parte, los típicos contratos con proveedores que se firman en ciclos de vida predictivos pueden generar grandes riesgos si se trasladan a ciclos de vida ágiles. En especial, puede ser muy arriesgado firmar tanto contratos de tipo «Time and Materials» o «llave en mano» con precio cerrado.
Se menciona cómo gestionar varios equipos ágiles, cuando se requiere la gestión de un portfolio o un programa se hace necesaria. En Scrum se desarrolla el «Scrum of Scrums«.
Es destacable la parte que habla de la relación entre proyectos ágiles y la PMO (Oficina de Gestión de Proyectos). La PMO ayuda a los equipos de proyectos a tener éxito. Y dado que la agilidad crea un cambio, por consiguiente, la PMO debe cambiar y debería perseguir ayudar a los equipos ágiles, una PMO ágil debería de ser una PMO que busque la satisfacción de los usuarios y compatibilizar este objetivo con ser un centro que busque la excelencia.
7 Llamada a la acción
La demanda de agilidad está incrementándose en todos los sectores, la cuestión es cómo enfocar los proyectos para que se aprovechen los beneficios de la agilidad. Y los autores son conscientes de que sus lectores pueden haber echado en falta más información. Precisamente por eso apuntan a seguir cubriendo este interesante tema en sucesivas entregas.
APÉNDICES:
El libro finaliza con una interesante selección de apéndices, entre los cuales destaca el Apéndice X3 Modelo para la Idoneidad del Enfoque Ágil, enfocado a determinar cuándo es mejor utilizar un enfoque ágil en los proyectos
CONCLUSIÓN:
¿Cuál es el objetivo de este libro? Se trata de buscar una aproximación e integración entre las metodologías predictivas y el mundo ágil. ¿Y cómo enfocar esa integración? Está claro que no se trata solamente de añadir más apartados al PMBOK que ya está en su sexta edición. Se trata de construir una versión unificada de ambos puntos de vista. Creo que, aunque se trate de metodologías muy diferentes, el Project manager deberá escoger la más adecuada que dependerá del tipo de proyecto de que se trate. Tan sencillo como que se aproveche lo mejor de cada una de ellas, es decir, la aproximación «híbrida» a la gestión de proyectos. Un Project manager que se precie, debería saber qué enfoque adoptar, en base a las características del proyecto. Una tendencia que se destaca después de una lectura del PMBOK 6 es que las diferentes metodologías empiezan a converger y cada una adopta lo mejor de las otras.
Es un libro hecho para ser leído por Project managers expertos en proyectos predictivos, que deseen conocer lo que les puede aportar el enfoque agile. A un experto en agilidad no le va a aportar nada nuevo.
Esta lectura me ha sabido a poco. Es un tema muy interesante y que tiene mucho recorrido por delante. Esperemos que no tarden en publicar más libros sobre esta temática.
Utilizamos cookies para asegurar que damos la mejor experiencia al usuario en nuestro sitio web. Si continúa utilizando este sitio asumiremos que está de acuerdo.Estoy de acuerdoNoPolítica de privacidad
CONSIDERACIONES:
A continuación, se presentan algunos “PROMPTS” GENERALES de ejemplo que pueden servir de apoyo:
A continuación, se presentan algunos “PROMPS” ESPECÍFICOS de ejemplo, que pueden servir de apoyo:
Consciente de la importancia que está teniendo últimamente en materia de proyectos el movimiento de mezclar elementos de las metodologías predictivas o waterfall, agile, Six Sigma y otras, el 
Se trata de un movimiento imparable que se ha convertido en tendencia. Mal que le pese a los apóstoles del agilismo o del waterfall puros, muchos responsables de proyectos se han dado cuenta, a través de la experiencia, de que el éxito de un proyecto depende mucho de la cultura de la empresa y que el uso de prácticas o artefactos de las diferentes metodologías puede ayudar enormemente a llevar a buen fin un proyecto.
