¿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 4 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 3 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.

CERTIFICACIÓN PMP®

Antecedentes:

Allá por el año 2014 y después de haber pasado por un período de “Coaching” en materia de proyectos a PMPcargo de una consultora, en mi empresa estábamos pensando en la posibilidad de seguir mejorando en nuestro desempeño en materia de proyectos.

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:

Habrá que acreditar los siguientes puntos:

  • Justificar el nivel de estudios, pues la horas exigidas de experiencia profesional dependen del nivel de estudios.
  • 35 h de formación en Dirección de Proyectos.
  • 4.500 h de experiencia profesional en gestión de proyectos si tienes una diplomatura o superior / 7.500 horas en caso contrario.
  • 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 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 edición 5. 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.

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 responderlos 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 5. 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 5. 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 8ª edición.

 

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:

  • Ato. Requiere dedicación y es difícilmente compatible con el desempeño laboral. Lo ideal es tomar unos días libres para prepararlo.
  • 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. Hay metodologías que se remiten al PMBOK para gestionar ciertas materias donde ellos no llegan.

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.