SESIÓN RETROSPECTIVA

La pasada semana realizamos una sesión retrospectiva de cierre de un proyecto que, por sus especiales características, se gestionó de forma predictiva. Está muy claro que se obtienen mejores resultados estudiando el tipo de iniciativa de que se trate y aprovechando las mejores prácticas de cada metodología de gestión de proyectos.

Además, este proyecto tiene otra particularidad y es que es un proyecto que se repite todos los años (con un contenido muy diferente, pues entonces  sería un proceso).  Esto es especialmente relevante de cara al propio ejercicio de retrospectiva, ya que nos permite recoger las “lecciones aprendidas” como acciones de mejora continua, y así aplicarlas para el año siguiente.

Aún así, el año pasado ya habíamos hecho una sesión retrospectiva y todos los participantes salieron muy contentos de la experiencia.

El resultado fue interesante y enriquecedor. El equipo se siente más implicado porque es tenido en cuenta, como debe ser. Es más, las aportaciones más sorprendentes surgieron de quien menos se espera.

Comenzamos explicando antes de la reunión el enfoque que necesitábamos, pues es muy importante que todos los participantes conocieran su propósito:

No perdimos ni un minuto en el tema de las culpas, se trata de mantener una actitud de mejora, que se obtiene mirando al pasado para mejorar el presente. Todos los asistentes participaron activamente en la sesión y se abordaron todos los puntos, incluso los que pudieran ser más conflictivos.

“La sesión retrospectiva es una mirada al pasado para mejorar el presente”

Hay muchas formas de hacer una sesión retrospectiva. Escogimos el formato de  la “Estrella de mar” (Starfish) porque nos sentíamos cómodos con ella. Pero hay un montón de otras opciones. En este interesante sitio se pueden encontrar muchos recursos y artefactos: Funretrospectives

En concreto, tocamos los siguientes  puntos:

1. SEGUIR HACIENDO: Qué cosas nos han funcionado bien en este proyecto y otros años, para repetirlas.

2. HACER MÁS: Prácticas que aportan valor o bien “pilotos” que han obtenido resultados positivos (como acciones de mejora continua surgidas de la anterior retrospectiva).  Por lo tanto, las exprimiremos al máximo, les sacaremos todo el jugo posible, ya que son útiles y positivas en nuestro proyecto.

3. DEJAR DE HACER: Prácticas que consideramos que no son útiles o no agregan valor. Por lo tanto hemos decidido eliminarlas completamente.  Es importante enfocar estas acciones como espacios de mejora y no como fracaso de iniciativas, especialmente si se trataron de acciones surgidas de anteriores retrospectivas. Por ejemplo, si se decidió comenzar a hacer dailys que no han funcionado, quizás en lugar de simplemente dejar de hacerlas podemos buscar el por qué no han funcionado (asistentes, horario, falta de foco…).

4. HACER MENOS: Prácticas que no están ayudando tanto como se esperaba, o que simplemente no son útiles en nuestro escenario actual.

5. COMENZAR A HACER: Cosas nuevas a probar que nos gustaría poner en marcha pero entrañan riesgo por su novedad y nuestra inexperiencia. Constituyen una verdadera apuesta que puede salir bien o mal en nuestro proyecto.

LECCIONES APRENDIDAS:

En  realidad, de una sesión retrospectiva no se extraen exactamente lecciones aprendidas sino que sirven para aprender cómo han ido las cosas, junto con la implementación de planes de acción. En nuestro caso lo usamos para la preparación del nuevo proyecto anual.

Observamos ya de otras sesiones la pelea por descifrar las letras. Curiosamente, cuando algún participante sale a exponer al tablero físico las notas algunas veces no puede entender  lo que el mismo escribió (la letra de “médico” ya es común entre nosotros).   😉

Es muy importante destacar que si hay niveles de autoridad dentro de los participantes, se debe dar la opción de hablar primero a los de menor nivel de autoridad, para que no se puedan sentir coaccionados por las opiniones que manifiesten los participantes  de mayor nivel de autoridad.  Es importante recordar que la utilidad de las retrospectivas es que todos puedan aportar su visión y opinión, lo que puede suponer un auténtico reto cuando se realizan en entornos jerarquizados.

El uso de vídeo conferencia hace perder un poco de fuerza a una sesión de este tipo, aunque era eso o renunciar a  las valiosas aportaciones de compañeros que no podían asistir presencialmente y esto no era una opción, claro está. Con el uso de la vídeo conferencia salimos ganando, ampliando perspectivas y obteniendo más puntos de vista.

Otra idea interesante es utilizar una herramienta “on line” de gestión de los tableros. Por ejemplo, nosotros usamos la herramienta GOREFLECT (aunque se puede utilizar también la aplicación Trello) y fue útil para trasladar el tablero físico final a un tablero virtual. De esta forma pudimos tirar las notas de otras sesiones retrospectivas (antes de que pierdan los colores por el polvo que acumulan)  y empezar la sesión recordando el tablero virtual del anterior proyecto. Esto es particularmente útil para evitar pensamientos pesimistas del tipo de que estas prácticas no valen para nada, pues, analizando las pasadas notas, se pudo comprobar que  una buena cantidad de ellas si que se habrían llevado  a la práctica. Una prestación genial que tiene esta herramienta es la de exportar  las notas a un archivo excel, lo que permite trabajar con detalle las notas.

Muchas gracias a todos los compañeros que participaron en la sesión y en especial a Jorge Cruañes por sus acertados consejos y  aportaciones a esta entrada.

LIBRO AGILE PRACTICE GUIDE

Título original: Agile Practice Guide

Autores: PMI + Agile Alliance

Editorial: Project Management Institute, año 2017

Páginas: 210

Idioma: inglés

ISBN: 978-1628251999

Palabras clave: Proyectos, Metodología, Agile, PMP, Project Management, Predictiva

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 ágil) da por sentado que es una metodología que ha llegado para quedarse durante mucho tiempo entre los Project Managers.

Dado que la agilidad  se ha expandido a otro á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 agil 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 dificil 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 de ciclos de vida de los proyectos: predictiva, iterativa, incremental y agil 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 constucción de un edificio.
  • Los agiles son excelentes aproximaciones cuando se espera una gran cantidad de cambios en un proyecto. La diferencia de agil con los ciclos interactivos e incrementales es que estos ultimos 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 cicloes á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 investigacion) y luego pasar a una metodología predictiva (si se debe cumplir una cerf¡tificación). O combinar ambas metodologías según para qué aspectos (a mi 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 lider “sirviente”, (que haga de facilitador del éxito del equipo), en lugar de un lider 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 coordinacion.

No se ha tocado la parte correspondiente al “mapeo” de roles entre metodologías predictivas/ágiles. Otro tema interesante pendiente.

Y le impone al lider “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 lider 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 agil 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 simultanea, asi 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 ejmplo) 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 raiz de los problemas sufridos y les 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 maás de 15 minutos) se usan  para declarar lo trabajado, lo que se va a trabajar, asi como para hacer aflorar posibles problemas. No se deben convertir en sesiones de analisis 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 asi 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 contínua
    • Test en todos los niveles
    • ATDD test de aceptacion.
    • TDD y BDD test driven development y behavior driven development
    • Spikes. Utiles 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 desafios 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. Ademas 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 poryecto á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) caracteristcas completadas/caracteristicas 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 cambos 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 cuando es mejor utilizar un enfoque ágil en los proyectos

CONCLUSIÓN:

¿Cual 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 como 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 leido 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.

REFERENCIAS:

What is the Purpose of the New PMI Agile Practice Guide?

ACTUALIZACIÓN DE 2018:

Ya ha salido publicada en español la Agile Practice Guide.

Este libro se puede obtener en estos dos sitios:

  • Siendo miembro de PMI:
    • Se puede descargar de forma gratuita en formato pdf (protegido) desde la web de PMI
    • Alternativamente, se puede encargar en formato papel a mitad de precio que los no miembros
  • No siendo miembro de PMI:

 

CERTIFICACION PRINCE2 PRACTITIONER

Después de haber realizado la certificación de Scrum Level y para cerrar el círculo de las metodologías, me propuse conocer lo que me podía aportar Prince2 Practitioner a la gestión de proyectos.

Para superar los exámenes de Prince2 no es obligatorio pasar un curso en un preparador oficial (como se exige en la certificación PMP) pero es muy recomendable realizarlo. El pasado octubre, junto con un compañero de trabajo, me matriculé en un curso de preparación de la certificación Prince2. El examen de certificación se planificó para enero de 2017.

¿Que es Prince2?. La web de QRP lo define así:  “Es un método estructurado de gestión de proyectos. Es una aproximación a las “buenas prácticas” para la gestión de todo tipo de proyectos que se ha convertido en el estándar de facto para la organización, gestión y control de proyectos El método divide los proyectos en fases manejables permitiendo el control eficiente de los recursos y el control periódico de su evolución. PRINCE2 está “basado en los productos”, es decir, los planes del proyecto se centran en obtener resultados concretos, y no sólo en la planificación de las actividades que se llevan a cabo; PRINCE2 proporciona un lenguaje común en los proyectos.”

Más que un conjunto de buenas practicas (como es el PMBOK de PMI), PRINCE2 propone una metodología específica de gestión de proyectos, es decir, cubre todas las temáticas y propone cómo llevarlas a la práctica.

PRINCE2 es el estándar de facto para la gestión de proyectos en varios países, empresas privadas y organizaciones, especialmente en el Reino Unido.

Existen dos niveles de certificación:

  • Foundation: certifica el conocimiento de la terminología y metodología de gestión de proyectos con PRINCE2
  • Practitioner: certifica la capacidad para gestionar proyectos según la metodología PRINCE2. Se necesita aprobar el nivel Foundation para presentarse a este nivel.

Un apunte, si ya dispones de uno de estos  certificados: CAPM, PMP o IPMA no es necesario examinarse previamente del nivel  Foundation, pues se convalida automáticamente.

Adicionalmente, Prince2 también dispone de una solución enfocada al mundo Agile. Esta certificación proporciona la guía para adaptar PRINCE2 en un contexto ágil e incluye:

  • Cómo adaptar el conjunto integrado de principios, temáticas y procesos de PRINCE2
  • Cómo crear los productos de gestión de PRINCE2
  • Cómo mapear los roles ágiles a la estructura de equipo de gestión de PRINCE2
  • Cómo incorporar los comportamientos, conceptos y técnicas ágiles fundamentales dentro de PRINCE2

Durante el año 2017 se produjo una gran actualización de Prince2, tanto a nivel de guía como de exámenes. Una de las consecuencias de este cambio es que los exámenes no están disponibles en español, como hasta ahora.

No es mi intención hablar en detalle de la metodología, pues existen otros blogs donde detallan este punto, solo destacar que Prince2 se basa en:

  • Siete temáticas:
    1. Caso de negocio: manera en que se desarrolla una idea hasta convertirse en un proyecto viable para la organización.
    2. Organización: puestos, funciones y responsabilidades del equipo encargado de ejecutar el proyecto.
    3. Calidad: Se ocupa de desarrollar la comprensión de los interesados respecto a los atributos de calidad de los productos a entregar.
    4. Planes: Describe los pasos requeridos para desarrollar los planes establecidos y las técnicas de PRINCE2 que se deben aplicar.
    5. Riesgo: gestión de las incertidumbres en sus planes.
    6. Cambio: cómo se evalúa y actúa para incorporar los posibles cambios a la línea base del proyecto
    7. Progreso: proceso de toma de decisiones para aprobar planes, seguimiento del avance real y el manejo de excepciones cuando los planes no se cumplen.
  • Siete procesos:

    1. Puesta en Marcha de un Proyecto.
    2. Dirección del Proyecto.
    3. Inicio del Proyecto.
    4. Control de Fase.
    5. Gestión de la Entrega de Productos.
    6. Gestión de los Límites de Fase
    7. Cierre de Proyecto
  • Siete  principios (que se deben seguir obligatoriamente):
    1. Justificación comercial continua
    2. Aprender de la experiencia
    3. Roles y Responsabilidades definidos
    4. Gestión por Fases
    5. Gestión por excepción
    6. Orientación a productos
    7. Adaptación al entorno del proyecto (un proyecto de PRINCE2 se debe adaptar al tamaño, el entorno, la complejidad, la importancia, la capacidad de la empresa y el riesgo del proyecto).

Ahora vamos a hablar de los exámenes de las dos certificaciones:

  • El examen Foundation:
    • Se puede hacer on line.
    • Duración: una hora
    • Nivel de dificultad: es bastante sencillo
    • Material permitido: ninguno
    • Son 75 preguntas. Se necesitan 35 aciertos para aprobar
    • Renovación: no es necesario
  • El examen Practitioner:
    • Duración: son dos horas y media. Os aseguro que no sobra ni un minuto de tiempo. Se debe gestionar bien el tiempo para evitar sorpresas desagradables.
    • ¿Su nivel de dificultad? Pues depende, si se compara con el examen PMP de PMI  el Practitioner es mucho más sencillo pero exige dedicación y conocer los tipos de preguntas de las que se compone el examen.
    • Se basa en un escenario. Por eso es muy interesante poder realizar el examen en papel, en lugar de escoger hacerlo on line, pues es muy recomendable tener a la vista la información de cada pregunta y también del escenario propuesto.
    • Tipos de pregunta:
      • Con una respuesta correcta
      • Con múltiples respuesta y se deben escoger dos.
    • Material permitido: el manual original y oficial del año 2017: “Éxito en la gestión de proyectos con Prince2
    • Son 80 preguntas. Se deben conseguir 44 aciertos
    • Renovación: cada 5 años
    • En 48 horas ya se proporciona la nota del examen

En este sitio web puedes encontrar unos excelentes Consejos para aprobar.

Diploma Prince2
Diploma Prince2

Lo que me ha gustado de Prince2:

  • El enfoque basado en el Business Case. Un proyecto debe tener una justificación comercial continua.  Esto significa que la razón para iniciar el proyecto debe tener sentido desde un punto de vista empresarial y debe haber un claro retorno de la inversión. El “Business Case” se debe revisar periódicamente durante toda la vida del proyecto para comprobar su continua justificación para el negocio Si la justificación desaparece,  el proyecto debe cerrarse.
  • La gestión por excepción. Las tolerancias a los cambios están perfectamente definidas. Esto proporciona cierta independencia al director de proyectos para tomar decisiones, siempre que se esté dentro de las tolerancias establecidas dentros de las normas de gestión del proyecto.
  • Al ser una metodología (y no un conjunto de buenas prácticas como el PMBOK) si no se dispone de experiencia en proyectos, aporta una guía  y un marco para gestionar el proyecto, que es aplicable desde el primer momento. Esto es una gran ayuda para los que se inician en la gestión de proyectos, pues Price2 les va a guiar punto por punto desde el principio hasta el final del proyecto.
  • Prince2 prefiere que el Project Manager se centre en el producto/proyecto y no se implique en la realización de tareas técnicas (se separan las capas técnica y de gestión).

Lo que veo mejorable:

  • El responsable del proyecto y del éxito del mismo es la Junta del Proyecto (Directivo, Usuario Principal y Proveedor Principal) . El Project Manager es responsable de dirigir el día a día del proyecto. Puede parecer un “secretario de lujo” de la Junta de Proyecto.
  • No incluye la administración o desarrollo de los Requerimientos. Estarían incluidos  dentro de la temática de “Calidad”.
  • Da por sentado que se conocen conceptos que requieren tener conocimientos previos en materia de proyectos. Por ejemplo, el WBS (Work Breakdown Structure) o el  PBS (Product Breakdown Structure)

Recursos:

¿QUÉ METODOLOGÍA ELEGIR PARA GESTIONAR UN PROYECTO?

En fin… ¿Qué metodología es más adecuada para gestionar un proyecto?, ¿Predictiva, iterativa, incremental o ágil?

La respuesta más adecuada es que ninguna es mejor que otra. Dependerá del tipo de proyecto.

El cuestionario del interesante libro “Software Engineering” de Ian Sommerville, para valorar cuándo ser ágil o cuando usar métodos formales decía que si respondes a estas cuestiones en su mayoría NO,  conviene que la  metodología sea iterativa o ágil y si se responde SÍ, entonces conviene que sea predictiva o formal:

  • ¿Se requiere una especificación?
  • ¿Los clientes son inaccesibles?project-managemet
  • ¿El sistema a construir es muy grande?
  • ¿El sistema es muy complejo?
  • ¿Se trata de un producto con mucho tiempo de vida previsto?
  • ¿Tienes herramientas de desarrollo limitadas?
  • ¿El equipo está distribuido?
  • ¿El equipo viene de una cultura de la documentación?
  • ¿El equipo tiene conocimientos técnicos limitados?
  • ¿El sistema a construir está sometido a regulación legal?

Antes de escoger una metodología, es importante tener en cuenta  el ciclo de vida por el cual va a transcurrir  el proyecto:

  1. Predictivo o en cascada. Aquí el proyecto discurriría por fases secuenciales (unas tareas detrás de otras). Los requerimientos son fijados al inicio. Su objetivo fundamental es controlar el coste.
  2. Iterativo. Los requerimientos son dinámicos y las tareas se repiten hasta la corrección de los prototipos. Mejorar el producto a través de sucesivos prototipos o pruebas de concepto. Su objetivo es la corrección de lo entregado.
  3. Incremental. El proyecto se basará en varios desarrollos incrementales y solo se planificaría una fase, pues las siguientes se van definiendo conforme avanzan los trabajos de la fase actual. El cliente desea frecuentes entregas de pequeños entregables del producto. Su objetivo es la velocidad de entrega.
  4. Ágiles. Son proyectos donde no se conoce el alcance y se desarrollan pequeñas porciones del proyecto marcadas por los sprints, al final de las cuales el cliente puede ver lo que se ha desarrollado. Es ideal si no se conocen los requerimientos o si se sospecha que los mismos pueden cambiar, puesto que en cada sprint se descubren requerimientos ocultos o mal interpretados. Su objetivo es entregar valor de forma frecuente a los clientes. Para estos proyectos lo ideal es usar una metodología del tipo Scrum, kanban o XP.
Características de los ciclos de vida (Fuente PMBOK 6 Ed.)

Para los proyectos que se adivinan predictivos lo mejor es usar tanto la metodología del PMBOK como Prince2.

El PMBOK no está en absoluto en contra de desarrollos incrementales, es más, el PMBOK asume que en muchas ocasiones durante la gestión del proyecto no está disponible toda la información. Es lo que se llama “Rolling Wave Planning“, es decir, es planificar en detalle lo que se va a realizar en el corto plazo. También se la conoce por  “Planificación continua con incremento de detalle”.

En el excelente Blog de Sinnaps comentan con buen criterio que las metodologías ágiles potencian conversaciones directas frente a la comunicación basada en documentación escrita, los equipos de trabajo se auto-gestionan, dando libertad a los roles, según las necesidades de un proyecto que está en continua evolución. Además, su empleo supuso la optimización de sus recursos, al clasificar las tareas que tienen un mayor impacto en el proyecto, estableciendo un sistema de prioridades.

Sin embargo, este tipo de metodologías y herramientas de gestión no son aconsejables para proyectos en los que se precisa de una constante toma de decisiones técnicas por parte del Project Manager, donde la gestión de la incertidumbre ha de ser clave para enfrentarse a contratiempos de proyectos largos. Por eso, no todas las empresas han recibido con el mismo entusiasmo la llegada de metodologías ágiles. Y es que su uso requiere una fuerte dependencia y centralización del control continuo y toma de decisiones de la persona responsable del proyecto. Además, podría existir una falta de documentación importante del propio proyecto y las soluciones para etapas largas suelen ser, en la mayoría de las ocasiones, inadecuadas.

En este enlace, recomiendan hacerse cuatro preguntas antes de seleccionar una metodología para gestionar un proyecto

Las cuatro preguntas antes de seleccionar una metodología:

  • …¿Qué resultados debería obtener al finalizar el proyecto? Ejercicio de objetivos.
  • …¿Qué tipo de metodologías nos ha dado mejores resultados? Ejercicio de análisis.
  • …¿Cómo funciona mejor nuestro equipo de trabajo? Ejercicio de análisis.
  • ….¿Qué metodología combina mejor con las dos preguntas anteriores? Ejercicio de estudio e identificación.

Muy interesante es la visión de Juan Palacio, en su libro gratuito descargable aquí: Flexibilidad con Scrum. En el mismo se comenta que la gestión predictiva equivale a la persona que decide irse de viaje y planifica con exactitud que ciudades, vuelos y hoteles va a visitar o reservar. Por otra parte, la gestión ágil corresponde a project-manager-1una persona que sabe que quiere conocer un país y que empezará la visita por la capital, pero deja la decisión de que ruta seguir para cuando haya llegado.

No se trata de elegir un modelo como el mejor, simplemente habrá casos en los que convendrá una gestión predictiva (por .ejemplo la construcción de un puente) y otros en los que la opción ágil puede ser más beneficiosa (p.ej. desarrollo de software). El software es mucho más maleable, adaptable y fácil de reconstruir. Sin embargo, en la construcción de un puente no se pueden destruir parte de los cimientos para volver a rehacer con un diseño diferente a mitad de proyecto.

Otro aspecto importante es identificar donde se encuentra el valor en el sector donde va a tener lugar el proyecto. Podemos considerar tres elementos fundamentales entre los cuales se reparte el valor:

  • Personas
  • Tecnología
  • Procesos

La gestión predictiva tiende a valorar más los procesos (p.ej. planes preestablecidos, modelos de comunicación y autorización estrictos, etc.), mientras que la gestión ágil da una mayor importancia a las personas (p.ej. dando libertad, confianza y autonomía al equipo, potenciando la motivación, participación y creatividad, etc.)

Es importante remarcar que una práctica que ha cobrado mucha fuerza por los buenos resultados que proporciona es la de utilizar un sistema mixto  gestionando el proyecto siguiendo las directrices del PMBOK pero usar otra metodología para gestionar partes específicas del proyecto. Un buen ejemplo de esto sería utilizar una metodología ágil exclusivamente para la parte correspondiente al desarrollo de software (si lo hubiere).

Además, PMBOK llega donde Agile no llega (ni quiere llegar) como es la gestión de las diez áreas de conocimiento  definidas para cada proyecto (interesados, integración , tiempo, costes, adquisiciones, calidad, etc).

De esta forma, el proyecto  tiene un Project Manager que se ocupa de la gestión de todo el proyecto y un Scrum Master y un Product Owner que trabajan exclusivamente la parte de desarrollo de software a través de ciertas iteraciones acordadas.

Las ventajas de este sistema mixto son grandes, como es el poder controlar tanto el trabajo interno como el trabajo que está siendo gestionado externamente (por ejemplo, por proveedores). Además, se trata de evitar uno de los grandes riesgos de las metodologías ágiles como es la escalabilidad.

Resumiendo, no es necesario utilizar una sola aproximación para todo el proyecto. Los proyectos frecuentemente pueden combinar elementos de diferentes ciclos de vida para obtener sus ventajas. Una combinación de las aproximaciones predictivas, iterativas, incrementales o ágiles es lo que se llama un “sistema híbrido“.

Lo que nadie debería hacer es utilizar exclusivamente una sola metodología para gestionar todos sus proyectos. Lo más adecuado es estudiar primero las características inherentes al futuro proyecto para encontrar el ciclo de vida que mejor encaje.

NORMA ISO 21500 SOBRE GESTIÓN Y DIRECCIÓN DE PROYECTOS

Llegó a mi poder información acerca de la norna ISO 21500 sobre Gestión y Dirección de Proyectos y me pareció interesante profundizar en la misma.

Objeto y campo de aplicación de esta norma:

  • Describir conceptos y procesos que se consideran que forman parte de las buenas prácticas en dirección y gestión de proyectos.
  • Ayudar a las organizaciones de cualquier sector económico, que tengan que desarrollar proyectos de cualquier tamaño, a alcanzar sus objetivos de negocio.
  • Contribuir a un correcto desarrollo de los proyectos, mejora en su calidad y en el cumplimiento de plazos y costes

 

La norma va dirigida a:iso215001

  • Alta dirección y patrocinadores de proyectos para ayudar a dar apoyo y orientación a sus directores de proyecto, equipos de dirección de proyectos y equipos de proyecto.
  • Directores de proyecto, equipos de dirección de proyectos y equipos de proyecto ya que tendrán una base común para poder comparar sus normas y prácticas de proyectos con las de otros.
  • Redactores de normas, como base para el desarrollo de normas sobre gestión de proyectos, de modo que sean consistentes unas con otras.

Para su elaboración se tuvieron en cuenta los siguientes estandares:

  • PMBOK. Project Management Body of Knowledge
  • ICB. International Competence Baseline
  • PRINCE2. Project in Controlled Environments5affd11ab6
  • P2M. Project and Program Management for Enterprise Innovation
  • BS 6079 partes 1 a 4. Guide to Project Management
  • DIN 69901 partes 1 a 5. Project Management. Project Management Systems
  • ISO 10006. Quality Management Systems. Guideline for Quality Management in Project
  • AS 4915. Project Management. General Conditions

Y manos a la obra, me matriculé en un curso de Auditor Interno de ISO 21500 sobre Dirección y Gestión de Proyectos de una conocida empresa del sector.

Según se comenta en la web del curso “La auditoria de gestión de proyectos es una herramienta de gestión empleada por las organizaciones para evaluar la eficacia de su sistema de gestión de proyectos conforme a las directrices establecidas por la Norma ISO 21500:2013. Todo ello con el objetivo de establecer y mejorar sus políticas, objetivos y procesos, así como velar por una adecuada aplicación de los métodos, herramientas, técnicas y competencias para una eficiente dirección y gestión de los proyectos que acometen las organizaciones. Así pues, las auditorías del sistema de gestión de proyectos ofrecen a las organizaciones confianza sobre la eficacia de su sistema de gestión y su capacidad para cumplir los requisitos de las partes interesadas o stakeholders. Igualmente, las organizaciones pueden acceder a la obtención de certificados de gestión de proyectos a través de un proceso de auditoria, el cual debe ser llevado a cabo por una entidad de certificación.”

Este curso se divide en dos asignaturas bien diferenciadas:

  • Metodología para la Dirección y Gestión de Proyectos Basada en ISO 21500:
    • Esta parte busca que el alumno conozca el sistema de dirección de proyectos.
    • Si se ha aprobado alguna certificación en materia de proyectos, (PMP o Prince 2) esta parte es muy sencilla.
  • Auditoria y Certificación de Sistemas de Gestión y Dirección de Proyectos según ISO 21500. Esta asignatura se orienta a:
    • Aplicar los conocimientos sobre auditorías de proyectos en cualquier organización para verificar el cumplimiento de su Sistema de Gestión.
    • Poder asumir responsabilidades en cualquier etapa del proceso de auditoría.
    • Conocer las funciones y competencias que debe tener un auditor tanto en auditorías internas como en auditorías de certificación.
    • Conocer el proceso de certificación en una organización.
    • Reconocer las características y problemas más habituales en la consecución de la certificación de gestión de proyectos.

Este curso permite disponer del Certificado de Auditor Interno de Sistemas de Gestión de Proyectos ISO 21500 (con examen final)

Para la empresa esta norma puede tener un  gran valor añadido. pues ya es posible que empresas individuales se certifiquen en gestión de proyectos. Puede ser un potente argumento de venta. La primera empresa en certificarse  fue Sach Consultores. Más abajo disponéis de una entrevista a la General Manager de Sach Consultores.

Enlaces interesantes:

CERTIFICACIÓN PMP®

Antecedentes:

Después de haber pasado por un período de “Coaching” en materia de proyectos a cargo de una consultora, en mi empresa estábamos pensando en la posibilidad de seguir mejorando en el  desempeño en materia de proyectos de los Project Managers.

PMP

Y nos pareció una buena idea preparar la certificación PMP, es decir, la certificación Project Management Professional  que expide el Project Mangement Institute (PMI)

Dicho y hecho. A mi me tocó romper el hielo y ser el primero en preparar la certificación.

Requerimientos para poder examinarse:

Hay que acreditar los siguientes puntos:

  • Justificar el nivel de estudios, pues la horas exigidas de experiencia profesional dependen del nivel de estudios:
    • Acreditar 4.500 h de experiencia profesional en gestión de proyectos si se posee una diplomatura o superior.
    • Acreditar 7.500 horas en caso contrario.
  • Completar un curso de 35 h de formación en materia de Dirección de Proyectos.
  • Cumplimiento del Código de Conducta Profesional del Director de Proyectos.

Lo primero que hacía falta: tomar un curso de 35 horas de duración a cargo de un preparador homologado por el PMI para dar ese cursillo.  Buscamos  y encontramos un preparador cerca de la empresa y con muy buenas referencias de aprobados: Wolf Project.

diploma_certificacion_pmp

Es muy interesante darse de alta como miembro del PMI en su web, pues esto te permite obtener una buena rebaja en los derechos de examen, así como te permite descargar material interesante de su intranet. Es imprescindible bajarse un ejemplar del PMBOK. También merece la pena hojear los ejemplares de sus publicaciones PMI Today y PMI Network.

Durante las horas obligatorias de clase se busca una aproximación  al mundo de los proyectos, en especial al enfoque que marca el PMI.

Una puntualización importante: todos los ejemplos están basados en empresas americanas de tamaño medio grande, por eso choca con nuestra experiencia en empresas españolas. Es más, los test realizados durante las primeras clases suelen ser decepcionantes por no se respondidos adoptando el punto de vista de una empresa americana. Son los llamados PMIsmos (ideas o planteamientos que se presuponen para el examen), en el libro de Rita existe un apartado que los estudia.

Es importante destacar que completar el proceso de inscripción dentro de la web de www.pmi.org es un trabajo laborioso y que requiere unas cuantas horas de dedicación. Es mejor reservar dedicación suficiente para hacerlo.

Además, el PMP puede auditar en cualquier momento toda la información contenida en la solicitud. Suele tocar auditoria a uno de cada cuatro alumnos.

Material empleado para la preparación de la certificación:

  • PMBOK. Por supuesto. Pero no es suficiente para aprobar.Project Management - Business Concept. Green Arrow with "Project Management" Slogan on a Grey Background. 3D Render.
  • PMP Exam Prep Rita Mulcahy, 8ª edición. Es la base de la preparación, complementado con la lectura del PMBOK . Dispone de exámenes que hay que realizar un par de veces cada uno. Es interesante sacar un 85 % de nota en ellos antes de presentarse al examen
  • Apuntes de las clases del preparador. Muy interesantes, pues con ellos se pueden hacer resúmenes muy útiles en los últimos días antes del examen.
  • Head First: PMP, de Jennifer Greene. Es un libro muy básico pero es muy útil para los que desconocen alguno de los conceptos que se manejan.
  • Simuladores de examen:
    • Existen muchos. Son de dos tipos: basados en web o instalables bajo windows. He probado los dos y prefiero los basados en web pues están mucho más actualizados.
    • Utilicé el simulador instalable de Rita Mulcahy (RMC Project) en su versión 6 y me pareció muy desactualizado.
    • Recomiendo el simulador on line de Pablo Ledó que es de pago pero es muy útil para hacer test un poco diferentes a los del libro de Rita Mulcahy.
    • También son interesantes los simuladores de UDEMI, aunque los hay de calidad desigual. Mejor fiarse de las valoraciones de los usuarios.

 

Tipos de examen:

  • PBT, basado en papel:
    • Los preparadores hacen grupos para poder examinar “en papel”.
    • Se puede hacer tanto en español como en inglés.
    • La nota se entrega en un par de semanas.
  • CBT, basado en ordenador:
    • Es más caro. Puede hacerse en cualquier centro homologado de Prometric.
    • Se puede hacer tanto en español como en inglés.
    • La nota se entrega una vez finalizado el examen en el acto.

Nivel de dificultad:

  • Alto. Requiere dedicación y es difícilmente compatible con el desempeño laboral. Lo ideal es tomar unos días libres para prepararlo.
  • Son cuatro horas de examen, que se dice pronto. Se debe practicar progresivamente hasta llegar a hacer varios exámenes completos y en parecidas condiciones que el examen real.
  • Requiere tener muy claro el escenario del examen, es decir, una empresa americana de tamaño medio/grande.
  • Muy interesante conocer y asumir los PMismos es decir,  principios que el PMI asume como ciertos y que hay que conocer y entender para afrontar el examen de certificación, por norma general están localizados en la bibliografía relacionada (por ejemplo en el libro de Rita Mulcahy o en el PMBOK). Son importantes porque nos ayudaran a situar el marco de la pregunta del examen e incluso puede en algunas ocasiones ayudarnos a descartar alguna respuesta incorrecta.

Lo mejor de la certificación PMP:

  • Proporciona un visión muy completa de la gestión de proyectos. Incluye todas las posibilidades de gestión.
  • Proporciona un lenguaje común en el que se pueden entender proveedores y clientes.
  • Hay metodologías que se remiten al PMBOK para gestionar ciertas materias donde ellos no llegan o no quieren llegar. Es un excelente complemento.

Lo mejorable:

  • No es la mejor forma de acercarse a la disciplina de la gestión de proyectos. Es recomendable tener conocimientos previos.
  • Al ser el PMBOK un compendio de buenas prácticas (y no una metodología), no proporciona una forma definida de hacer las diferentes tareas en el día a día del proyecto.