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 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 el 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 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.

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

Eso si, un aviso a navegantes, durante el año 2017 se ha producido 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 van a  estar 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 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 para evitar sorpresas desagradables.
    • ¿Su nivel de dificultad? Pues depende, si se compara con el de PMP  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 exámen en papel, en lugar de escoger hacerlo on line, pues es muy recomendable tener a la vista la información de cada pregunta
    • Tipos de pregunta:
      • Con una respuesta correcta
      • Con múltiples respuesta y se deben escoger dos.
    • Material permitido: el manual original y oficial “É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 para el 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 fin del proyecto.

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 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.