Categoría: Predictiva

METODOLOGÍA DE GESTIÓN DE PROYECTOS PM²

Dejar un comentario

QUÉ ES PM²

Ahora que tanto se habla del Brexit, la retirada del Reino Unido de la Unión Europea, parece un buen momento para conocer una metodología de gestión de proyectos que tiene su origen en la Comisión Europea. Estamos hablando de la metodología de gestión de proyectos PM².

Y a esta cuestión del Brexit, se añadió la discusión sobre la gestión de los fondos europeos que buscan paliar los efectos de la pandemia. Se debe señalar que entre 2014 y 2020 España solo ha gastado el 39% de las ayudas que recibe.  Esto ha valido para que empresas y asociaciones de gestión de proyectos se hayan unido presentando un Manifiesto por la adopción de Buenas Prácticas de Dirección de proyectos en la gestión de los Fondos Europeos Next Generation, redactado por PMI Andalucía/Valencia, AEIPRO IPMA Spain y PM2 Alliance. Este tipo de manifiestos ponen en valor la necesidad de adoptar una metodología de gestión de proyectos para la adecuada gestión de los fondos europeos, pues de esta forma es mucho más sencillo garantizar la efectiva gestión del proyecto, así como el control de la documentación y de los entregables del mismo.

PM² es una metodología de gestión de proyectos desarrollada y respaldada por la Comisión Europea. Su propósito es permitir que los equipos de proyecto gestionen sus proyectos de manera efectiva y brinden soluciones y beneficios a sus organizaciones y partes interesadas. Esta metodología toma elementos de PMBOK, PRINCE2, IPMA-ICB y Agile.

PM² es una metodología ligera y fácil de implementar adecuada para cualquier tipo de proyecto. PM² ha sido desarrollado a medida para adaptarse a las necesidades específicas, la cultura y las limitaciones de las instituciones de la UE, pero también incorpora elementos de las mejores prácticas, estándares y metodologías aceptadas a nivel mundial.

Ya no debería de haber excusa para estudiar PM² como alternativa para gestionar proyectos al PMBOK (PMP) del PMI y a Prince2 de Axelos. La PM² Alliance es una iniciativa de la Comisión Europea, que acerca la Metodología PM² y sus beneficios a toda la comunidad de usuarios y partes interesadas. Proporciona a las instituciones de la Unión Europea, contratistas y administraciones públicas, así como a toda parte interesada, un acceso abierto a la Metodología PM² y a sus recursos.

Qué ofrece esta nueva metodología:

  • Un vocabulario común (glosario) que facilita a los equipos de proyecto la comunicación y aplicación de conceptos de gestión de proyectos.
  • Mejores prácticas – corresponde a los Directores de Proyecto (DP) y los equipos de proyecto elegir las prácticas PM² que aporten el mayor valor añadido a sus proyectos.
  • Un enlace a los modelos PM² Ágil y Gestión de Carteras PM².
  • Enlaces a recursos PM² (recursos en línea, plantillas de Artefactos y ejemplos).

Los puntos fuertes de PM² son:

  • Está muy orientado a negocio, de hecho, existe una figura complementaria al Project Manager llamada Business Manager, cuya función es ayudar al propietario del proyecto a definir los objetivos de negocio y coordinar las diferentes actividades y roles desde la perspectiva del cliente
  • Existe un buen gobierno del proyecto a través de las diferentes capas del proyecto
  • Los mindsets en los que se sustenta son muy beneficiosos (actitudes y comportamientos).
  • Existen disponibles unas plantillas muy útiles para el uso de los artefactos.
  • Al ser una metodología (y no un compendio de buenas prácticas como el PMBOK del PMI) es de aplicación directa en las empresas
  • Al ser una metodología creada por la Comisión Europea, permitiría un mejor seguimiento y control de proyectos financiados y/o subvencionados por la Unión Europea.

Esta metodología se basa en 4 pilares:

  • Un ciclo de vida del proyecto (las Fases del proyecto)
  • Un modelo de gobernanza del proyecto (los Roles y Responsabilidades)
  • Un conjunto de Procesos (las actividades de gestión del proyecto)
  • Un conjunto de Artefactos del proyecto (las plantillas de documentación y guías)

Entrando en materia, las fases del ciclo de vida en las que se basa son las mismas que en el PMBOK V6, es decir:

  • Initiating:
    • Su propietario es el Project Owner
    • Busca definir los resultados esperados y establecer el alcance del proyecto
    • Debe incluir la creación de los siguientes documentos:
      • Project Initiation Request
      • Business Case (muy importante)
      • Project Charter (Acta de Constitución)
  • Planning:
    • Su propietario es el Project Manager
    • Se debe asignar un equipo y un Project Manager al proyecto
    • Debe incluir una Kickoff Meeeting y una identificación de los interesados
    • El Project Manager debe crear los siguientes documentos:
      • Project Handbook
      • Project Work Plan (incluyendo la EDT)
  • Executing:
    • Sus propietarios son el project Core Team
    • Debe incluir una reunión de lanzamiento de la ejecución
    • Sus hitos/entregables son:
      • Project Deliverables (en base al Plan de Aceptación de los Entregables)
  • Closing:
    • Sus propietarios son los Stakeholders
    • Debe incluir un cierre administrativo del proyecto y una Reunión de Cierre del Proyecto. El PM debe cerciorarse de que los entregables son aceptados por el cliente
    • Su artefacto es el:
      • Project End Report
  • Y por encima de todas ellas está la actividad de Monitoring and Controlling, en la cual se miden todas las actividades del proyecto y se comparan con las respectivas líneas base de coste, alcance, tiempo y esfuerzo.

La organización del proyecto se basa en las siguientes capas:

  • Business Governing Layer. Nivel que determina la estrategia de la empresa
  • Steering Layer. Nivel que proporciona dirección y guía
  • Directing Layer.  Nivel que otorga los recursos necesarios y que controla el desempeño. Son el Product Owner y el Solution Provider
  • Managing Layer. Nivel que gestiona el día a día del proyecto. Son el Business Manager y el Project Manager
  • Performing Layer. Nivel que ejecuta el trabajo. hablamos del Business Implementation Group y el Project Core Team

A su vez, he de destacar que los participantes en un proyecto se dividen en dos categorías:

  • Requestor Side:
    • Project Owner (PO). Es el propietario del proyecto.
    • Business Manager (BM).  Representa a negocio en el día a día del proyecto y colabora con el Project Manager
    • Business Implementation Group (BIG). Son los representantes de negocio y de los usuarios
  • Provider Side:
    • Solution Provider (SP). Quien debe entregar el trabajo
    • Project Manager (PM).  Es quien dirige el proyecto
    • Project Team Core (PCT). Crean los entregables del proyecto

De forma opcional, puede existir una Oficina de Soporte a Proyectos (OSP), que es definida como “Un cuerpo (o entidad) organizacional que proporciona servicios que apoyan la gestión de los proyectos. Dichos servicios pueden ir desde la prestación de funciones de apoyo sencillas hasta la ayuda para vincular los proyectos a los objetivos estratégicos.”

La OSP puede ofrecer las siguientes funciones dentro de su catálogo de servicios:

  • Ofrecer apoyo administrativo, asistencia y formación a los Directores de Proyectos (DP) y otros miembros del equipo.
  • Recopilar y analizar datos e información del progreso del proyecto y elaborar informes.
  • Ayudar en la definición del cronograma de los proyectos, la planificación de recursos, la coordinación y el uso del Sistema de Información de Gestión del Proyecto (SIGP).
  • Mantener un repositorio centralizado del proyecto (de Documentos, Riesgos, Lecciones Aprendidas).
  • Coordinar las actividades de gestión de la configuración y aseguramiento de la calidad.
  • Supervisar el cumplimiento de las directrices de la metodología y otras normas de la organización.
  • Adaptar la metodología de gestión de proyectos a nuevas mejores prácticas y ayudar a los equipos de proyecto a aplicar eficazmente la metodología actualizada.

Por último, hay que señalar que PM² reconoce la naturaleza compleja e incierta de muchos tipos de proyectos y la contribución positiva del pensamiento Ágil a su gestión efectiva. En el manual de PM² se explica que los enfoques Ágiles se enfrentan a varios desafíos que crecen con el tamaño de las organizaciones en las que se aplican. En el caso de muchas organizaciones, estos desafíos incluyen la coordinación entre equipos Ágiles y no Ágiles, el cumplimiento de variados requisitos de auditoría y gobernanza organizacional, y la arquitectura y las restricciones organizacionales.

Es por eso por lo que existe una versión Agile de esta Metodología, así como su certificación correspondiente.

 

ENLACES ÚTILES:

 

SLIDESHARE DEL ORIGEN DE PM2

 

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

Dejar un comentario

En fin… ¿Qué metodología es más adecuada para gestionar un proyecto?

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 o predictivos decía que, si se responde NO a estas cuestiones en su mayoría, conviene que la metodología sea iterativa o ágil y que 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”.

La cuestión del enfoque que se debe utilizar es importante y ha sido abordada por el PMI y por la Agile Alliance. En el libro “Guia Práctica de Ágil“, mencionado en este blog, en su apéndice X3 existe un interesante “Filtro de Idoneidad” que se puede utilizar para determinar en base a unas preguntas qué ciclo de vida es el más adecuado utilizar.  La clasificación se basa en tres categorías principales:

  • Cultura (con los factores aceptación, confianza y toma de decisiones)
  • Equipo (tamaño, experiencia, acceso)
  • Proyecto (cambios, criticidad y entrega)

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.

Por último, hay que destacar que Google deja libertad a sus Project o Product Managers para escoger la metodología que por las características del proyecto puede ayudar a tener éxito en el mismo.

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.

Actualización: