Categoría: Metodología

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

 

GOOGLE PROJECT MANAGEMENT CERTIFICATE

Certificate of completion¿A QUIÉN SE DIRIGE?

Explorando en Internet acerca de novedades en materia de gestión de Proyectos, recientemente descubrí que la mismísima GOOGLE está proponiendo un certificado profesional en materia de Project Management, y como todo lo que hace el gigante tecnológico es interesante, creo que es digno de echarle un buen vistazo.

¿Cuál es el origen de este Google Project Management Certificate?. Los certificados de carrera de Google son parte de Grow with Google, una iniciativa que se basa en los 20 años de historia de Google en la creación de productos, plataformas y servicios que ayudan a las personas y las empresas a crecer. El objetivo de los certificados profesionales de Google es proporcionar formación específica para cubrir las futuras demandas de profesionales que exigirá el mercado laboral. Afirman que se han decidido a lanzar esta certificación porque los gerentes de proyecto tienen una gran demanda. De hecho, comentan que un estudio del Project Management Institute descubrió que, para el año 2027, los empleadores necesitarán 87,7 millones de personas para ocupar puestos relacionados con la gestión de proyectos. A medida que el lugar de trabajo continúa creciendo y evolucionando, los gerentes de proyecto sirven como una pieza fundamental de la capacidad de una organización para adaptarse y permanecer ágil.

“Los gerentes de proyectos son solucionadores de problemas por naturaleza. Además de establecer el plan y guiar a los compañeros de equipo a través del proyecto, tienen la tarea de gestionar los cambios y los riesgos. ¡Cada día es dinámico y diferente para un gerente de proyecto porque está en el centro del proyecto, construyendo relaciones, priorizando tareas y entregando resultados! Usando varias herramientas y plantillas, así como un conjunto de habilidades únicas, el gerente de proyecto pone orden en el caos.” Google

La certificación no exige experiencia previa en la materia, se imparte 100 % en línea, se dicta exclusivamente en inglés y está pensada para poder ser compaginada con otras dedicaciones y ser completada en seis meses, a un ritmo de estudio sugerido de entre 5 y 10 horas por semana. Exige unas 140 horas de trabajo. Pero se puede completar antes.  Eso sí, si se completa antes de ese período mucho mejor, pues se paga por cada mes que se esté cursando, a razón de 32 €/mes.

El formato es tipo MOOC (Massive Open Online Course) y se realiza utilizando la conocida plataforma de formación on line Coursera. 

Los cursos están compuestos de diferentes tipos de ejercicios. Unos son de tipo test, en los cuales es necesario obtener un 80% mínimo para aprobarlo. También existen ejercicios interactivos situacionales. Y se deben completar diferentes plantillas (artefactos) como elaborar un Project Charter o cumplimentar un Impact Report que deben ser calificados por los compañeros de curso.  Y también existen preguntas abiertas que se lanzan al foro del curso para su análisis y discusión.

Además de enfocarse en adquirir conocimientos de Project Management, existe una parte del curso orientada a poder obtener empleo como Project Manager, presentando situaciones en las cuales se entra en un proceso de selección para ese puesto en una empresa. Google también apoya durante todo el proceso de preparación del trabajo con una herramienta de creación de currículum, entrevistas simuladas y soporte de redes profesionales para ayudarlo a conseguir un trabajo después de completar el programa.

En general, las habilidades que adquirirán con estos cursos incluirán:

  • Crear planes de gestión de riesgos
  • Comprender las técnicas de mejora de procesos
  • Gestionar escaladas, dinámicas de equipo y partes interesadas
  • Creación de presupuestos y navegación por adquisiciones
  • Utilizar software, herramientas y plantillas de gestión de proyectos
  • Practicar la gestión ágil de proyectos, con énfasis en Scrum

CURSOS QUE LO COMPONEN:

En concreto, este certificado se divide en seis cursos, que se pueden cursar de forma independiente:

Curso 1. Foundations of Project Management.

Los objetivos de este curso son:

Google Project Management

  • Definir la gestión de proyectos y describir qué constituye un proyecto.
  • Explorar las funciones y responsabilidades de la gestión de proyectos en una variedad de industrias.
  • Detallar las habilidades básicas que ayudan a un gerente de proyecto a tener éxito.
  • Describir el ciclo de vida de un proyecto y explicar el significado de cada fase.
  • Comparar diferentes metodologías y enfoques de gestión de programas y determinar cuál es más eficaz para un proyecto determinado.
  • Definir la estructura y cultura organizacional y explicar cómo impacta la gestión de proyectos.
  • Definir la gestión del cambio y describir el rol del director del proyecto en el proceso.

Curso 2. Project Initiation. Starting a Successful Project:

  • Comprender la importancia de la fase de inicio del proyecto del ciclo de vida del proyecto.
  • Describir los componentes clave de la fase de inicio del proyecto.
  • Determinar los beneficios y costos de un proyecto.
  • Definir y crear objetivos y entregables del proyecto medibles.
  • Definir el alcance del proyecto y diferenciar entre las tareas que están dentro y fuera del alcance.
  • Comprender cómo gestionar el deslizamiento del alcance para evitar afectar los objetivos del proyecto.
  • Definir y medir los criterios de éxito de un proyecto.
  • Completar un análisis de las partes interesadas y explicar su importancia.
  • Utilizar gráficos RACI para definir y comunicar las responsabilidades de los miembros del equipo del proyecto.
  • Comprender los componentes clave de los estatutos del proyecto y desarrollar un estatuto del proyecto para el inicio del proyecto.
  • Evaluar varias herramientas de gestión de proyectos para satisfacer las necesidades del proyecto.

Curso 3. Project Planning. Putting It All Together:

  • Describir los componentes de la fase de planificación del proyecto y su importancia.
  • Explicar por qué los hitos son importantes y cómo establecerlos.
  • Realizar estimaciones de tiempo precisas y describir técnicas para adquirirlas de los miembros del equipo.
  • Identificar herramientas y mejores prácticas para construir un plan de proyecto y un plan de gestión de riesgos.
  • Describir cómo estimar, rastrear y mantener un presupuesto.
  • Explicar el proceso de adquisiciones e identificar la documentación clave de adquisiciones.
  • Redactar un plan de comunicación y explicar cómo gestionarlo.
  • Explicar por qué los hitos son importantes y cómo establecerlos.
  • Explicar por qué es necesario un plan de proyecto y qué componentes contiene.
  • Realizar estimaciones de tiempo precisas y describir técnicas para adquirirlas de los miembros del equipo

Curso 4: Project Execution. Running the Project:

  • Identificar qué aspectos de un proyecto rastrear y comparar diferentes métodos de rastreo.
  • Discutir cómo gestionar y comunicar de forma eficaz los cambios, las dependencias y los riesgos.
  • Explicar los conceptos clave de gestión de la calidad de estándares de calidad, planificación de la calidad, garantía de calidad y control de calidad. –
  • Describir cómo crear una mejora continua y mejora de procesos y cómo medir la satisfacción del cliente.
  • Explicar el propósito de una retrospectiva y describir cómo realizar una.
  • Demuestre cómo priorizar y analizar datos y cómo comunicar la historia basada en datos de un proyecto.
  • Identificar herramientas que proporcionen una comunicación eficaz del equipo del proyecto y explorar las mejores prácticas para comunicar las actualizaciones del estado del proyecto.
  • Describir los pasos del proceso de cierre para las partes interesadas, el equipo del proyecto y los gerentes de proyecto.

Curso 5. Agile Project Management:

  • Explicar el enfoque y la filosofía de gestión de proyectos ágiles, incluidos los valores y principios.
  • Explicar los pilares de Scrum y cómo apoyan los valores de Scrum.
  • Identificar y comparar los roles esenciales en un equipo Scrum y qué los hace efectivos.
  • Construya y administre un Product Backlog y realice un Refinamiento del Backlog.
  • Describir los cinco eventos Scrum importantes y cómo configurar cada evento para un equipo Scrum.
  • Implementar las estrategias de entrega impulsadas por el valor de Agile y definir una hoja de ruta de valor.
  • Explicar cómo entrenar a un equipo ágil y ayudarlo a superar los desafíos.

Curso 6. Capstone. Applying Project Management in the Real World:

  • Completar una carta del proyecto, completando la información clave, incluido un resumen del proyecto, objetivos SMART, alcance, beneficios y costos.
  • Examinar la documentación del proyecto y realizar una investigación para identificar las tareas de un proyecto y organizar esas tareas e hitos del proyecto en un plan de proyecto.
  • Determinar los estándares de calidad y evalúe contra esos estándares para asegurarse de que el proyecto está logrando el nivel de calidad requerido.
  • Desarrollar informes efectivos para las partes interesadas aplicando estrategias de narración para describir los datos.

CONCLUSIONES

Sobre su nivel de dificultad, no es muy alta, pues es un curso de entrada en el mundo del Project Management y en ningún caso se acerca a dificultad de la certificación Prince2 Practitioner ni al certificado PMP, que requieren una preparación mucho más exigente y un examen rigurosamente vigilado por Pearson Vue (en el caso del PMP) y por Axelos (en el caso de Prince2). Pero es una excelente forma de acceder al Project Management, pues ofrece las técnicas para poder empezar a gestionar proyectos.

Lo más interesante de esta iniciativa es estudiar el enfoque de Google en materia de metodologías utilizadas en la gestion de proyectos. Y destacan que los Project o Product Managers en Google no utilizan una sola metodología en sus proyectos. Al contrario, tienen la prerrogativa de utilizar todas las metodologías que consideren oportunas según el tipo de proyecto, su entorno y sus circunstancias, lo que viene a ser una especie de enfoque híbrido.  Así pues, pueden utilizar waterfall, Agile o Lean Six Sigma en cada una de las partes del proyecto, si consideran que este enfoque será el más adecuado para obtener los objetivos previamente definidos y previstos del proyecto.

Como conclusión, se trata de una muy interesante iniciativa que puede ser de ayuda a varios grupos de profesionales.

Para quien es este curso:

  • Por un lado, puede ayudar a los profesionales del Project Management que deseen actualizar o refrescar sus conocimientos. La visión de Google de la gestión de los proyectos es muy interesante. Su enfoque es muy práctico y toma lo mejor de cada una de las metodologías más conocidas. Y con los “artefactos” o plantillas hacen igual, usan el Project Charter, el análisis de stakeholders o el Project Plan de las metodologías “Waterfall” junto con los “burndown charts”, la pila de producto o los informes de retrospectivas de las metodologías ágiles. O los “Diagrama de Ishikawa” propios de Lean Six Sigma.
  • Por otra parte, puede ser una gran ayuda para los profesionales sin conocimientos en este campo (que es el verdadero público objetivo de este curso) y que deseen iniciarse en esta disciplina. Completar este curso puede contribuir para poder obtener la ya mencionada certificación CAPM del PMI. Y una vez adquirida la CAPM sería el momento adecuado para lanzarse a obtener el certificado PMP, que es sin ninguna duda la certificación más completa en materia de gestión de proyectos.  Disponer de la certificación PMP no significa ser mejor Project Manager, pero sí que se conocen todas las técnicas para hacer que un proyecto sea un éxito.
  • Y también puede ser un excelente recurso para los profesionales de otros sectores que, de un día para otro y en virtud del conocido y famoso artículo 33 , deben hacerse cargo de la gestión de un proyecto en una empresa, sin contar con conocimientos y/o experiencia, los llamados project managers “por accidente“.

Una nota final a tener en cuenta: dado que los MOOC tienen una tasa de finalización promedio de entre el 4% y el 10%, es importante prepararse para el éxito desde el principio y meditar cómo se tiene pensado estudiar para este certificado. Tener un plan de estudio, especialmente si el auto estudio no es lo tuyo, te ayudará a superar este curso y a retener todo lo que hayas aprendido. ¡Mucho Animo!

 

INICIACIÓN A KANBAN (II) – ENTENDER EL SISTEMA

Dejar un comentario

INTRODUCCIÓN

Tras el primer post donde os enseñé los conceptos básicos y la filosofía de Kanban, en este vamos a introducir algunos conceptos ya aplicados al trabajo diario y a entender como funciona un sistema Kanban. Vamos a focalizarnos en ver como trabajar con los famosos tableros Kanban, ver que significa cada elemento del tablero y una pequeña introducción a las métricas, donde veremos dos métricas muy sencillas y dos tipo de gráficas muy simples que nos permitirán hacernos una idea de las posibilidades que vamos a poder obtener.

Representación del “trabajo en curso” (WIP)

  • En primer lugar, cuando hablamos de “Kanbans”, estamos hablando de “huecos” que hay en un determinado espacio. Si trasladamos esto a un panel, donde tenemos identificadas las columnas como los diferentes estados en los que pasa una tarea, podemos decir que en nuestro sistema, en cada estado, tenemos una cantidad limitada de trabajo que podemos hacer, definido por los kanbans que tengo en cada estado. Es muy común confundir los tickets con “kanbans”, pero realmente los tickets son tareas y los kanbans son los huecos que hay para hacer estas tareas. Un hueco vacío en el panel esta emitiendo una señal “pull” para que se traiga una tarea desde el estado anterior.

  • Esta forma de mostrar la capacidad de trabajo por cada estado en forma de huecos resulta engorrosa, por lo que la forma de representar la capacidad de cada estado e incluyendo un número con la capacidad encima de cada columna. Esta capacidad es un concepto fundamental de Kanban y es el “Work In Progress” (WIP) y define los número de tickets que pueden estar a la vez en un determinado estado. En el próximo post veremos un poco más en detalle este concepto y porque debemos de tener este valor lo más bajo posible para que el trabajo fluya lo más rápido posible. Si indicamos un símbolo de infinito o un “-“, significa que no hay WIP en esas columnas.

 

Sistemas push vs sistemas pull

  • Kanban es un sistema basado en “pull”. Esto quiere decir que busca la máxima eficiencia y optimización, adaptando en tiempo real la producción a la demanda.  Mediante este sistema, sólo producimos los que sabemos que vamos a realizar. En un sistema de fabricación, no tendría un stock o tendría un stock mínimo y solo fabricaría aquellos pedidos que ya tengo confirmados (Just-In-Time). En este caso, solo voy cogiendo tickets cuando tengo huecos, de forma que el trabajo fluya más rápido.
  • Un sistema “push” consistiría en coger muchos tickets e ir pasándolos de estado a estado, de forma que pueda asegurarme que tengo tickets suficientes en el siguiente estado (tengo stock suficiente para abastecer a la siguiente fase). Esta forma de trabajar nos rompería completamente la filosofía Kanban, ya que no tendría un WIP limitado y el tiempo de finalización de cada tarea se ralentizaría.

 

Compromiso diferido y políticas

  • El compromiso sobre cuando vamos a hacer algo se retrasa (lo diferimos) hasta el punto de compromiso. En ese momento, ya podemos comprometernos a un determinado tiempo si sabemos como se comporta nuestro sistema Kanban.
  • Hasta que llegamos a ese punto de compromiso, las diferentes ideas que se tienen son opciones para realizar tareas, que deben de ser priorizadas (en Kanban se llama Upstream y en siguientes post hablaremos más en detalle de ello). Una vez se ha priorizado la idea, se pasa a un estado en el que empezamos a contar y del que no podemos tirar hacía atrás. Una vez pasamos al estado de compromiso, la tarea tiene que finalizarse o cancelarse (habría que evitar siempre la cancelación ya que suponemos que ha pasado todo los filtros necesarios para asegurarnos que hay que realizar dicha tarea)
  • Uno de los principios de Kanban es hacer las políticas explícitas. Podemos ayudarnos de esto en los paneles indicando las políticas que tenemos que aplicar en cada uno de los estados. Por ejemplo, las entregas listas, por política, siempre se grabará en un determinado registro, se almacenará en una determinada base de datos, etc. Otro ejemplo podría ser que para las pruebas de usuario solo tendremos 15 días, etc., pero si podemos indicarlas en el panel, será transparente para todo el mundo.

Trabajo por lotes

  • Kanban también permite el trabajo por lotes (push). Estos se suele utilizar cuando realizamos tareas de priorización periódicas donde indicamos las tareas que están listas para desarrollarse. Por ejemplo, cada dos semanas se traspasa una carga de trabajo a la columna de listo con las tareas que ya están aprobadas para realizar. Es importante señalar que cuanto más largo en el tiempo sea esta carga de tareas, menos flexibilidad tendrá el sistema (ver el punto de replanificaciones y entregas frecuentes)

 

Descartes

  • Es importante tener en cuenta que debemos descartar ideas. Las ideas son opciones que tenemos para elegir y tenemos que seleccionar la que más valor aporta a la compañía. Si descartamos muchas y hacemos pocas, quiere decir que nuestra capacidad no es la adecuada ya que hay muchas necesidades pero poca capacidad. Un ratio muy bajo de descartes quieres decir que hacemos prácticamente todo lo que pedimos, sean ideas buenas o tal vez ideas que no aporten el beneficio esperado. Hay que tener en cuenta que el futuro es incierto, no sabemos si una idea va a acabar teniendo éxito o no. Un ratio equilibrado sería un 50% de descartes.

Replanificaciones y entregas frecuentes

  • Esta característica es una de las principales diferencias con respecto a Scrum. Mientras que en Scrum, tenemos un Sprint donde no se puede replanificar nada y no se entrega nada hasta el final del Sprint (normalmente 15 días), en Kanban tenemos más flexibilidad para gestionar las replanificaciones y las entregas. Lo ideal sería replanificar a demanda, es decir, en cuanto el sistema requiera una tarea, que en ese momento se pueda evaluar que tarea realizar y seleccionarla (planificación a demanda). Una mala idea es hacer una planificación a largo plazo (por ejemplo mensual) ya que en determinados sistemas, siempre surgen necesidades no planificadas que hacer que no se pueda cumplir dicha planificación. Kanban recomienda realizar reuniones de planificación semanales, para adecuar las tareas a las necesidades actuales.
  • El mismo criterio se aplica a las entregas. Si podemos realizar una entrega lo más rápido posible, antes se podrá aportar valor a la compañía. Una entrega a demanda es lo más ágil, aunque esto también tiene un coste, ya que no es lo mismo hacer 10 entregas en 10 días distintos que hacer una entrega un día de 10 tareas.
  • El concepto de agilidad consisten en entregar el trabajo correcto en el tiempo correcto, ni antes ni después.

Compromisos de entrega

  • Los compromisos de entrega se pueden retrasar hasta una fase posterior. Muchas veces, sobre todo si durante el proceso tenemos factores externos al sistema que no controlamos, no podremos tener un compromiso de entrega fiable. Por poner un ejemplo, en equipo de desarrollo de Software que una vez termine su desarrollo y sus pruebas, necesite otro equipo que realice pruebas de usuario. En este caso, Kanban permite crear compromisos de dos fases, con lo cual podremos medir el tiempo de nuestro sistema y su eficiencia por fases.

Métricas

En este punto vamos a ver dos tipos de métricas muy sencillas que podemos obtener de nuestro sistema, además de dos tipos de gráficas para medir, por ejemplo, las dos métricas que vamos a ver y poder estudiarlas.

Tiempo de espera del sistema y del cliente e Histogramas

  • Las primeras métricas que vamos a tener son los tiempos de espera del sistema y tiempo de espera del cliente. Mediante estas métricas, vamos a poder medir la velocidad de nuestro flujo de trabajo. Muy utilizadas para poder definir SLAs (acuerdos de niveles de servicio)
  • Tiempo de espera del sistema: Es el tiempo que transcurre desde que pasa el punto de compromiso hasta que pasa al primer estado con un WIP infinito. Con esto, podemos medir el tiempo que tarda una tarea desde que se empieza a trabajar en la tarea hasta que llegamos a un estado que no controlamos. Es importante avanzar que mediante el WIP de los estados vamos a poder controlar la velocidad del sistema y ajustarlo a nuestras necesidades, aunque lo veremos en el siguiente post.
  • Tiempo de espera del cliente: Es el tiempo desde el punto de compromiso hasta que ya lo tiene listo el cliente para utilizar. Con esta métrica, podemos indicar al cliente cuando tardará en tener disponible la petición.
  • Mediante un Histograma, vamos a poder visualizar de forma clara, por ejemplo, los días que tarda el cliente en tener la tarea disponible. En el siguiente ejemplo, podemos ver en primer lugar una tabla con todas las tareas realizadas y los días que hemos tardado en finalizarla. Si transformamos esta tabla desde el punto de vista de los días de espera, podemos ver la cantidad de tareas que se han realizado en unos determinados días. En este ejemplo, podemos ver que lo normal es que tardemos entre 3 y 4 días en realizar las tareas. Este estudio podemos ampliarlo añadiendo tipología de tareas para saber cuando tarda el sistema en realizar determinados tipos de tareas e ir dando aproximaciones de nuestra velocidad del flujo de trabajo.

Rendimiento y Run-Chart

  • En la métrica de rendimiento vamos a poder medir las tareas terminadas por unidad de tiempo, midiendo el ratio de tareas completadas.
  • Es una métrica muy útil para medir la productividad de un equipo. Por ejemplo, vamos a poder medir que un equipo hace, por ejemplo, 10 tareas a la semana o 30 tareas al mes y podremos ver como evoluciona el sistema.
  • Mediante un Run-Chart, podemos buscar tendencias o impactos en nuestro rendimiento. Por ejemplo, podemos incorporar nuevas acciones para mejorar nuestro sistema (mejora continua) y medir dicho impacto para saber si estamos mejorando por el contrario, estamos empeorando nuestro rendimiento.

Conclusiones

En este post hemos visto algunos conceptos claves de Kanban para poder diseñar los primeros paneles Kanban y un par de métricas muy sencillas de calcular para poder medir nuestro sistema. Recordar que no podemos mejorar lo que no medimos.

Próximo post

En el próximo post hablaremos de lo siguiente:

  • Diseño de los paneles: Algunas ideas para crear un buen panel Kanban
  • Diseño de tarjetas para ponerlas en el panel
  • La Ley de Little: Como mediante el WIP vamos a poder controlar nuestro flujo de trabajo
  • Métricas: Vamos a ver varias métricas más y entender un Diagrama Acumulativo de Flujo (CFD) para poder estudiar nuestro sistema.

 

 

INICIACIÓN A KANBAN (I) – CONCEPTOS PREVIOS

1 comentario

¿Qué significa Kanban?

Si nos vamos a la definición estricta, podemos decir que Kanban es un método para definir, gestionar y mejorar servicios que entregan trabajo del conocimiento, tales como servicios profesionales, trabajos o actividades en las que interviene la creatividad y el diseño, tanto de productos de software como físicos.

Un sistema Kanban consiste realmente en una cantidad de “tarjetas señales” o “Kanbans” en circulación. Algunos ejemplos de un sistema Kanban son:

  • En el palacio imperial de Tokio, para entrar te dan un ticket para poder entrar y cuando se acaban los tickets, ya no pueden entrar hasta que sale alguien y devuelve el ticket.
  • En la atracción de feria de los famosos “coches de choque” (¡Quien no ha subido alguna vez!), hay un número limitado de coches que pueden estar circulando a la vez.  Se podría decir que es un sistema Kanban.

Imaginaros un sistema donde no se controle la cantidad de “entes” en curso. Por ejemplo, Madrid en Navidad, entrar a ciertos pubs sin control de acceso, subir al metro en hora punta….. ¿Es un sistema un poco caótico? ¿Quién esta más cerca del grupo en un concierto? ¿Quién entra antes al metro?

Pues esto pasa cada día en nuestra vida diaria y en nuestro trabajo. Vamos asumiendo tareas y más tareas mientras que no nos damos cuenta inconscientemente que tenemos una capacidad límite. Mediante un sistema Kanban, se pretende controlar la cantidad de tareas que ponemos estar haciendo a la vez, para mejorar la calidad de vida, que no se acumulen las cosas sin hacer o a medias y poder estimar cuando vas a terminar las tareas. En definitiva, adaptamos la demanda a la capacidad de producir. Seguro que a nadie le ha pasado esto, ¿verdad?.

Principios directores

Kanban tiene 3 principios directores:

  • Sostenibilidad. A nivel individual, evita sobrecarga, mejora la calidad y produce orgullo profesional y satisfacción en el cliente
  • Orientación al servicio. A nivel de gestión intermedia, se entrega valor de forma rápida, predecible y realista. Hacia un nivel superior, podremos responder a cuestiones complejas con confianza. Hacia un nivel inferior, podremos tomar decisiones difíciles con confianza
  • Supervivencia. A nivel de gestión senior: Realizar promesas que puedes cumplir y liderar el negocio, a nivel de estrategia y posicionamiento.

 

El método Kanban

El método Kanban consiste en una serie de valores y principios que rigen el sistema. En concreto, existen los valores de Kanban, los principios de entrega de servicio, los principios del cambio y las prácticas generales.

Valores Kanban

Hay un valor fundamental que engloba a todos que consiste en respetar a todos los individuos que contribuyen colaborativamente en una organización. Además, hay una serie de valores también que son necesarios para poder aplicar este método:

  • Transparencia: La creencia de que compartir información abiertamente mejora el flujo de valor de negocio. Utilizar un lenguaje claro y directo es parte del valor.
  • Equilibrio: El entendimiento de que los diferentes aspectos, puntos de vista y capacidades deben ser equilibrados para conseguir efectividad. Algunos aspectos (como demanda y capacidad) causarán colapso si no se encuentran equilibrados por un periodo prolongado.
  • Colaboración: Trabajar juntos. El Método Kanban fue formulado para mejorar la manera en que las personas trabajan juntas, por ello, la colaboración esta en su corazón.
  • Foco en el cliente: Conociendo el objetivo para el sistema. Cada sistema Kanban fluye a un punto de valor realizable — cuando los clientes reciben un elemento solicitado o servicio. Los clientes en este contexto son externos al servicio, pero pueden ser internos o externos a la organización como un todo. Los clientes y el valor que estos reciben es el foco natural en Kanban.
  • Flujo: La realización de ese trabajo es el flujo de valor, tanto si es continuo como puntual. Ver el flujo es un punto de partida esencial en el uso de Kanban.
  • Liderazgo: La habilidad de inspirar a otros a la acción a través del ejemplo, de las palabras y la reflexión. Muchas organizaciones tienen diferentes grados de jerarquía estructural, pero en Kanban, el liderazgo es necesario a todos los niveles para alcanzar la entrega de valor y la mejora.
  • Entendimiento: Principalmente conocimiento de si mismo (tanto individual como de la organización) para ir hacia adelante. Kanban es un método de mejora, por lo que conocer el punto de inicio es la base de todo.
  • Acuerdo: El compromiso de avanzar juntos hacia los objetivos, respetando — y donde sea posible, acomodando — las diferencias de opinión o aproximaciones. Esto no es gestión por consenso sino un co-compromiso dinámico para mejorar.
  • Respeto: Valorando, entendiendo y mostrando consideración por las personas. De manera apropiada al pie de esta lista se encuentra la base sobre la cual reposan el resto de valores.

Principio de entrega de servicios

¿Qué es un servicio?

Un cliente tiene una necesidad y el servicio responde a esa necesidad con una serie de actividades. El cliente acepta el resultado.

La organización es una red de servicios interdependientes con políticas que terminan su comportamiento:

  • Entiende y pon foco en las necesidades y expectativas del cliente
  • Gestiona el trabajo, deja que los trabajadores se gestionen alrededor de dicho trabajo
  • Revisa regularmente la red y sus políticas para mejorar los resultados

 

Principio de gestión del cambio

  1. Empieza por lo que haces
    1. Entiende los procesos actuales
    2. Respecta los roles actuales, responsabilidades y puestos
  2. Acordar en buscar mejoras a través del cambio evolutivo
  3. Fomentar el liderazgo en todos los niveles de la organización

El método Kanban usa ….

… tableros Kanban para visualizar el trabajo invisible, los flujos y los riesgos del negocio junto con sistemas Kanban para limitar el trabajo en curso.

El método Kanban entrega ….

… velocidad, entrega de servicios más predecibles y capacidades de adaptación que permite que puedas responder eficientemente a los cambios en las demandas de los clientes o de tu entorno de negocio.

Prácticas Generales

Visualizar:

  • Ver el trabajo y su flujo
  • Visualiza los riesgos
  • Construye un modelo visual que refleje tu trabajo

Limitar el WIP:

  • Para de empezar y empieza a terminar
  • De izquierda a derecha
  • Limita el trabajo a la capacidad

Gestionar el flujo de trabajo:

  • Flujo es el movimiento del trabajo
  • Gestiona el flujo de forma suave y predecible
  • Usa datos

Hacer explícitas las políticas:

  • Haced visibles las políticas a todos
  • Clases de servicio, límite WIP, criterio de siguiente tarea, dependencias, gestión de bloqueos …

Circuitos de retroalimentación:

  • Establecimiento de circuitos de retroalimentación mediante cadencias (reuniones periódicas)
  • Rapidez en la colaboración, aprendizaje y mejoras
  • Conducción por datos

Mejorar & evolucionar:

  • Usa el método científico
  • Cambio guiado por las hipótesis
  • Ejecuta experimentos seguros ante fallos

 

Conclusiones

  • “Kanbaniza” tus procesos existentes. No es necesario un cambio brusco. Empieza con los procesos que tienes y como funcionan ahora y verás como poco a poco vas cambiando cosas y detectando mejoras en tus procesos que hacen que sean más óptimos.
  • Provoca cambios para mejorar los procesos existentes. No tengas miedo a equivocarte. Todos nos equivocamos pero si no eres valiente e intentas provocar cambios, nunca podrás mejorar un proceso. Lo importante es saber rectificar a tiempo y aprender de dichos errores. Quien no se equivoca, no aprende.
  • Cada flujo engloba a una ventana de un proceso, dentro de su contexto. Kanbaniza primero una ventana de un proceso y esto hará que poco a poco vayas Kanbanizando todo el proceso de forma escalada. Pensemos que con Kanban optimizamos cada flujo. Más adelante, ya veremos como realizar Kanban Escalado para toda una organización.
  • Los clientes y empleados mejorarán su satisfacción. Menos sobrecarga de las personas, menos tareas que se eternizan y producen frustración, menos tiempo en terminar las tareas ( y antes están a disposición del cliente)

 

Próximos post:

  • Entender sistemas Kanban: ¡Empecemos a diseñar un sistema Kanban y a obtener algunas métricas sencillas !
  • Introducir Kanban en las organizaciones con el método STATIK
  • Cambio evolucionario: Protokanban
  • Kanban para la empresa: Orientación al servicio, Escalabilidad, Gestión de la demanda (Upstream) y Roles
  • Cadencias Kanban. ¿Los clientes están contentos? Circuitos de retroalimentación
  • Flujos de comunicación y técnicas de mejoras: Métricas avanzadas, interrupciones y dependencias, cuellos de botella y sobrecarga e ineficiencia

 

 

 

 

 

 

 

SESIÓN RETROSPECTIVA

Dejar un comentario

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.

 

 

 

 

 

 

 

 

 

 

EXAMEN DE CERTIFICACIÓN PMI RISK MANAGEMENT PROFESIONAL (PMI-RMP)

1 comentario

A petición de algunos colegas de profesión, comparto mi experiencia acerca del examen correspondiente a la de certificación PMI Risk Management Professional (PMI-RMP) realizado con fecha 03-09-18.

Me voy a centrar en la preparación y en el examen propiamente dicho. Los requerimientos para poder presentarse al examen se pueden encontrar en la web de PMI, dentro del manual oficial de PMI (PMI-RMP Handbook). En ese documento se pueden encontrar los pre-requisitos de eligibilidad para poder optar a la certificación:

  1. Un título de 4 años (título universitario o equivalente):
    • 3.000 horas de experiencia en gestión de riesgos en proyectos en los últimos cinco años
    • 30 horas de educación en materia de gestión de riesgos
  2. Un diploma de educación secundaria:
    • 4.500 horas de experiencia en gestión de riesgos en proyectos en los últimos cinco años
    • 40 horas de educación en materia de gestión de riesgos

Por otra parte, el esquema del contenido del examen se puede encontrar aquí: …ESQUEMA EXAMEN PMI-RMP

IMPRESIONES TRAS SALIR DEL AULA DEL EXAMEN:

Me ha parecido un examen más fácil que el examen PMP, pues está más centrado y es más específico.

Las preguntas está mucho mejor redactadas que en los simuladores. Esto hace que algunas preguntas puedan responderse “por descarte”.

En mi caso en el examen no tuve tiempo para repasar las preguntas que se pueden “marcar” para revisión. El tiempo (tres horas y media) me pareció muy justo, pues el rendimiento es decreciente. Me costó más responder a las últimas 40 preguntas que a las 130 anteriores.

Ya no se puede realizar el “volcado de memoria” durante los 15 minutos que dura el tutorial del examen basado en ordenador. Personalmente creo que tampoco valía para mucho.

Si no se ha  estado nunca en un examen por ordenador auditado por Prometrics, puede desconcertar el nivel de exigencia del mismo. No se puede llevar al aula de examen ni agua ni snacks. Todo debe guardarse en la taquilla (monedas, llaves, cartera, pañuelos). Las gafas son sometidas a revisión y  se realiza un examen de detección de metales cada vez que se entra en la sala de examen.

SOBRE LAS PREGUNTAS:

Varias preguntas (5 o 6) sobre el Análisis Montecarlo

Sobre 3 o 4 preguntas sobre EMV

Muchas preguntas situacionales, del tipo ¿Qué harías tú? o del tipo ¿Qué es lo siguiente que se debe hacer?

Ninguna pregunta sobre teorías motivacionales (Maslow, McGregor, Vroom, Herzberg…)

Bastantes cuestiones sobre gestión y manejo de Stakeholders

Bastantes preguntas sobre escoger la herramienta más adecuada para ciertas situaciones.

No obsesionarse con los ITTOS (entradas, herramientas, salidas de cada uno de los procesos de gestión de riesgos). No salen tantas preguntas que justifique tener que aprendérselos todos. Solo se deben memorizar los más importantes

No observé demasiadas preguntas con “distractores” (datos insertados sin relación con la pregunta).

Hay referencias a la agilidad en algunas preguntas

Ninguna pregunta sobre:

  • Norma ISO 31000
  • Heurística
  • Tuckman
  • Estilos de liderazgo
  • Aplicación directa de fórmulas de Valor Ganado

Sobre 5 o 6 preguntas directas sobre respuestas al riesgo

Varias cuestiones sobre cuál sería el riesgo más alto, considerando Probabilidad e Impacto

MATERIAL DE ESTUDIO:

Libros recomendados:

  1. Libro Secretos para Dominar la Gestión de Riesgos en Proyectos de Liliana Buchtik:
    • Idioma español
    • Muy completo. Trata con detalle la parte de las herramientas de cada parte del proceso
    • Muy interesante cuando se inicia el estudio, pues se avanza rápido.
  2. Libro Secretos para salvar el PMI-RMP (300 preguntas de examen) de Liliana Buchtik:
    • Idioma español.
    • Son 300 preguntas con sus correspondientes respuestas
    • Muy interesante cuando se inicia el estudio, pues se avanza rápido.
    • Es un material complementario al libro de la misma autora “Secretos para dominar la gestión de proyectos”
  3. Libro PMI-RMP Exam Prep Study Guide, de Belinda Freemow:
    • Idioma inglés
    • Muy práctico y sencillo de entender
    • Al final de cada tema hay una serie de preguntas para responder
    • Cuenta con 150 preguntas de examen
  4. Apuntes y otro material del preparador Wolf Project:
    • Amplio resumen de los temas.
    • Ahorra mucho tiempo de estudio
  5. Libro Risk Management Tricks of the Trade for Project Managers + PMI-RMP Exam Prep Guide de Rita Mulchay:
    • Idioma inglés
    • Es obligatorio leerlo, pero a este libro ya se le nota mucho el paso de los años (fue editado en 2010)
    • Cuenta con un apartado final de 75 preguntas de examen
  6. PMBOK Versión 5:
    • Versión Español
    • Descarga gratuita digital siendo socio de PMI
    • Es interesante leerse los siguientes procesos:
      • Riesgos, Stakeholders, Comunicaciones y Adquisiciones
    • Se deben repasar los ITTOs (entradas, herramientas, salidas) de esos procesos
    • El examen se basó en el PMBOK 5, pero ya ha ido publicada la versión 6.
    • Ojo, que la versión 6 difiere de la versión 5 (se ha incorporado un nuevo proceso denominado “implementar la respuesta de los riesgos” y se ha creado una nueva respuesta al riesgo llamada “escalar”, tanto para amenazas como para oportunidades). Se debe averiguar qué versión estará vigente para cuando se planifique el examen.
  7. Libro Practice Standard for Project Risk Management, editado por PMI:Idioma inglés
    • Lectura obligatoria
  8. Libro Passing the Risk Management Professional (PMI-RMP) Certification Exam the First Time! De Daniel Yeomans:Idioma inglés
    • Sencillo de entender
    • Al final de cada tema hay una serie de preguntas para responder
    • Cuenta con un apartado final de 150 preguntas de examen

Simuladores de examen:

  1. Es muy importante escoger bien los simuladores, pues existe una gran variedad en el mercado y no todos son adecuados para preparar el examen.
  2. Existen varios simuladores de preguntas recomendables sobre esta materia:
    • Simulador de Simplilearn. Es gratuito
    • Yo recomiendo seleccionar y comprar dos o tres paquetes de preguntas de la web de Udemi. De pago.
    • Es muy importante responder preguntas de varios simuladores, no solo de uno, pues así se logran entender más planteamientos de las posibles preguntas.

CALENDARIO Y PREPARACIÓN:

Considero que la preparación de este examen es difícilmente compatible con el desempeño laboral a tiempo completo. Yo he aprovechado la jornada continua del verano para prepararlo.

Recomiendo realizar el curso de preparación de 30 o 40 horas en un proveedor de confianza. Es tiempo de estudio ganado.

Tiempo de preparación. En un intervalo de un mes y medio o dos meses se puede preparar.

Es muy importante saber que este examen actualmente sólamente se administra en inglés, por lo que:

  • Recomiendo estudiar en español al inicio de la preparación (pues se avanza muy rápido)
  • Pero me parece interesante pasar a estudiar en inglés pasada la mitad de la fase de preparación, pues es necesario familiarizarse con los términos en inglés que se encontrarán en el examen final.

Como rutina de estudio, es recomendable repasar cada día uno o dos temas y completar el estudio respondiendo una serie de preguntas sobre lo estudiado. Los libros de Fremow, Mulcahy y de Yeomans mencionados permiten hacer eso.

Es muy útil días antes del examen real realizar dos exámenes completos de 170 preguntas y hacerlos a la misma hora que el examen que se ha programado en Prometrics (si se hace el examen por ordenador). Para poder presentarte con garantías al examen, es recomendable sacar al menos un 75 /80 % de aciertos.

 

 

El examen ya se ha adecuado tanto al PMBOK versión 6 como a la actualización del Standard for Risk Management. Se debe tener este punto en cuenta a la hora de planificar el examen de certificación.

¿Por qué certificarse en PMI-RMP?. Porque mejorarás tus habilidades en materia de gestión de proyectos, en concreto, mejorarás tus capacidades para gestionar riesgos y por tanto, para mejorar tu tasa de éxito de los proyectos que dirijas. Adicionalmente, tu empresa saldrá beneficiada de este conocimiento de gestión de los riesgos.

5 Reasons to Get Your PMI-RMP® Certification

Y por último, mucho ánimo. Es una materia muy interesante y es un examen más sencillo que el  PMP. El resultado merece el esfuerzo.

 

Actualizaciónes importantes:

  • Además, desde el 30-06-2019 ya no será posible examinarse de esta certificación en un centro PROMETRIC, pues desde esa fecha los centros oficiales para examinarse pasan a ser los de PEARSON VUE. Se trata de un gran avance, pues esto proporcionará  una mayor disponibilidad a la hora de sentarse a realizar el examen.
  • Certificación PMP® frente a PMI-RMP® https://projectriskcoach.com/pmp-vs-pmi-rmp-certification/ 

 

 

TALLER Y CERTIFICACIÓN PMO-CP

1 comentario

TALLER PMO-CP  (CERTIFIED PRACTITIONER)

El pasado día 12 de junio asistí a un taller de metodología PMO-CP que, opcionalmente, permite acceder a la certificación oficial.

En el curso nos encontramos varios profesionales habituales de los eventos relacionados con proyectos que, como me pasó a mí, se sintieron interesados por lo que podía aportarles este curso.

Todos coincidimos en que la formación en materia de Oficina de Gestión de Proyectos (PMO) se da por supuesta a los profesionales que han superado el examen PMP de PMI, pero eso no es cierto. La información que proporciona el PMBOK sobre las PMO se limita a unas pocas páginas de contenido.

La metodología ha sido creada por la empresa PMO GLOBAL ALLIANCE, que cuenta con una comunidad de mas de 5.000 miembros en varios países. Su foco es la creación, desarrollo y gestión de una comunidad global de profesionales que trabajan de forma cotidiana en la gestión de PMOS. Su enfoque está basado en un benchmarking realizado sobre las experiencias de una comunidad internacional, formada por profesionales de la PMO.

Según el folleto del curso, “Este curso tiene como objetivo principal certificar profesionales en la metodología internacional denominada PMO VALUE RING, que se puede utilizar para crear, evaluar y reestructurar una Oficina de Proyectos – PMO, centrándose en la generación de valor para la cartera de proyectos para toda organización tanto para proyectos Waterfall como Agile”. El profesional certificado PMO-CP puede demostrar la alineación con la metodología más importante en el mundo para la gestión estratégica de las PMO, basada en las mejores prácticas y la investigación internacional.

De forma adicional, existe un software opcional, basado en esta metodología, que hace más sencilla su implantación y mantenimiento. Durante el curso se va haciendo referencia a los diferentes pasos en la herramienta, pero se debe destacar que se puede hacer uso de la metodología sin necesidad de adquirir una licencia de uso de la herramienta.

Su mindset (o mentalidad) es la de proponer que la PMO sea vista como un “proveedor de servicios” y como tal, posee sus clientes, los stakeholders, cada uno con necesidades y  expectativas específicas. Atender esas expectativas es la mejor forma de generar valor percibido. La PMO cumplirá este objetivo proporcionando “servicios” (funciones) de la mejor manera posible.

Según esta metodología, existen 8 pasos que es necesario seguir para asegurarse de que una PMO aporta valor:

  1. Definir las funciones de la PMO, de acuerdo con las necesidades de los stakeholders.
  2. Equilibrar las funciones de la PMO. Las funciones que la PMO deberá desempeñar deberán ser elegidas considerando su capacidad de generar valor percibido permanente (corto, medio y largo plazo) en los stakeholders.
  3. Estabilizar los procesos de la PMO. Es esencial describir como será ejecutado cada proceso elegido, pues es la vía más efectiva de asegurarse de que la PMO entrega valor.
  4. Seleccionar indicadores de desempeño, para poder monitorizar la calidad y demostrar que la PMO está generando valor
  5. Evaluar al equipo, asegurarse de que los miembros del equipo de la PMO cuentan con las competencias adecuadas y elaboración de planes de desarrollo
  6. Evaluar la madurez de la PMO y planificar su evolución
  7. Determinar el ROI de la PMO, considerando la realidad de la empresa.
  8. Establecer un panel de control que monitorice ciertos indicadores estratégicos, que determinen si la PMO cumple con lo prometido
PMO Value Ring

De forma paralela, existen varios mitos sobre la gestión de las PMO que consideran que se deben desmontar:

  1. Mito Nº 1: “El primer paso es elegir el tipo ideal de PMO“. Adherirse a un tipo de PMO establecido no va a hacer que la PMO tenga éxito. Lo que realmente importa es que la PMO ofrezca servicios que atiendan las necesidades de sus stakeholders. Las funciones pueden ser estratégicas, de soporte, centro de excelencia o de varios tipos mezclados.
  2. Mito Nº 2: “Proveer una metodología y herramientas para gestionar proyectos es  suficiente para que una PMO sea exitosa“.  Las expectativas diferentes deben ser atendidas por un conjunto de funciones diferentes. Por lo tanto, no hay estándares para las PMOs. Cada una debe proveer una mezcla específica de funciones.
  3. Mito Nº 3: “Primero defina el equipo de la PMO, después qué va hacer la PMO“. Comúnmente, las PMOs son creadas de forma contraria a lo que se recomienda. Primero se establece el equipo de la PMO, a continuación, se define lo que hará la PMO.  Lo recomendable es hacer esto justo al revés.
  4. Mito Nº 4: “El éxito de los proyectos de la organización es la mejor prueba del  éxito de la PMO”.  No siempre el éxito de los proyectos indica el éxito de la PMO
  5. Mito Nº 5: “Las competencias  necesarias para un profesional en PMOs son  las mismas de un director de proyectos.” Todos los asistentes al taller estuvimos de acuerdo en que las competencias no son necesariamente las mismas. Esta metodología propone 10 competencias básicas: Capacidad de influenciar, Capacidad de integración, Gestión de conflictos, Comunicación efectiva, Gestión de proyectos, Gestión de procesos, Proactividad, Relación interpersonal, Enfoque al cliente,  Gestión del conocimiento.
  6. Mito Nº 6: “Una PMO entre más estratégica, más  madura será“. Ser estratégico o operativo no es una señal de madurez, sino una  consecuencia de las necesidades de las partes interesadas.
  7. Mito Nº 7: “Es imposible calcular el retorno financiero de la PMO“. Es obligatorio descubrir el retorno financiero de una PMO, considerando la realidad de la empresa
  8. Mito nº 8: “Monitorizar estratégicamente la PMO es lo mismo que monitorizar el porfolio estratégico de la organización”.  Monitorear el portafolio estratégico de proyectos es una función, no necesariamente un propósito.

 

Es interesante el enfoque práctico de esta metodología, es decir, si los stakeholders no perciben que la PMO les aporta valor, lo más probable es que la PMO acabe siendo cancelada. O peor aun, la PMO puede acabar siendo un “muerto viviente”, que no sabe que ya no está viva.

Enlaces interesantes:

 

CERTIFICACIÓN PMO-CP (CERTIFIED PRACTITIONER)

Realizado el taller formativo, lo siguiente es afrontar el examen de certificación.

El examen se compone de un total de cuarenta preguntas, de las cuales es necesario acertar un 75% de las mismas, es decir, treinta. No se permite la consulta de ningún tipo de material durante el examen. Las preguntas son de tipo test, con cuatro posibles soluciones. Las preguntas más complejas se pueden resolver por descarte.

El examen se realiza a través de la plataforma Moodle de PMOGA eso si, planificado y supervisado on line a través del sistema Proctoru.  Para lo que no conozcan este sistema, es bastante exigente en lo que se refiere a las condiciones en las cuales se desarrolla el examen, para asegurarse de que no se consulta ningún tipo de material durante el examen.

Sin sorpresas, asistiendo al taller de preparación (obligatorio) y estudiando los dieciséis Papers (en inglés), junto con el material complementario que compone el curso, es suficiente para poder aprobar la certificación.

 

 

 

 

 

 

 

 

 

SCRUM LEVEL

Dejar un comentario

Esto se había quedado en el tintero. Hace unos meses realicé un interesante curso de Scrum Level, que merece la pena ser comentado. 

Cuando se desea implantar la agilidad en las empresas, se pueden producir problemas  o conflictos con la “cultura” o las prácticas aceptadas dentro de la propia empresa, pues cada una es diferente del resto.

Scrum Level está orientado a evitar esos conflictos, estableciendo las mejores prácticas que se deben implantar y lo hace realizando un diagnóstico personalizado de lo que se necesita poner en práctica  para hacer que las empresa se aprovechen de los beneficios de los enfoques ágiles, sin romper con todo lo anterior.

¿Cómo se define Scrum Level? Es un modelo de evaluación y mejora de la agilidad de las empresas, tanto a nivel técnico, como de la organización en su conjunto.

Extraido de su web: “Propone un método sistemático con el que analizar y evaluar las dimensiones y aspectos que determinan el nivel de agilidad organizacional. El análisis obtenido con Scrum Level revela las fortalezas y debilidades de los diferentes ejes que define el modelo, y apunta las áreas susceptibles de mejora, así como las actividades o prácticas que pueden reforzarse”

http://scrumlevel.com

Scrum Level nace de la experiencia de un reducido número de profesionales y  busca reducir la variabilidad  típica de las implantaciones y progreso de la agilidad,  a partir de los proyectos desarrollados entre sus clientes.

Para ello Scrum Level analiza indicadores y evidencias deforma separada en dos dimensiones:

DIMENSIONES:

  • Dimensión técnica:  flexibilidad.
  • Dimensión organizativa:  fluidez.

FACTORES ANALIZADOS:

  • Ejes orgánicos.
  • Técnicas y prácticas de trabajo.
  • Capacitación técnica de las personas.

Las organizaciones que desean implantar o mejorar un entorno de trabajo ágil, necesitan una guía y criterios de referencia para identificar y analizar las áreas de mejora.

“Scrum Level cubre este objetivo, definiendo una guía de referencia y apoyo para mejorar la agilidad de las organizaciones”

En curso  se aprende el uso del modelo de evaluación y mejora Scrum Level, y se dispone de la guía, herramientas de protocolo y competencia necesarios para llevar a cabo procesos de evaluación con los que identificar las fortalezas y áreas de mejora en la agilidad organizativa de equipos y empresas. Es un curso eminentemente práctico.

Respecto al modelo de licenciamiento, derecho de uso del material y de la certificación, se distinguen tres niveles:

  1. Consultor independiente:
    El modelo y los materiales de Scrum Level se ofrecen con derechos de uso liberados (Creative Commons By). Pueden emplearse libremente en actividades profesionales de mejora o evaluación, con o sin ánimo de lucro.
  2. Consultor certificado:
    La certificación garantiza el conocimiento profesional del modelo Scrum Level adecuado para el desempeño en actividades de mejora o evaluación. Para conseguir la certificación es necesario aprobar el examen oficial de consultor Scrum Level que forma parte de los cursos profesionales de Scrum Manager®.
  3. Evaluador certificado:
    Profesional autorizado por ScrumLevel para realizar evaluaciones oficiales como evaluador responsable.
    Para ser evaluador certificado es necesario ser consultor certificado y acreditar los requisitos profesionales necesarios:

    1. Experiencia profesional mínima de 5 años en asesoría o gestión en organizaciones TIC.
    2. Experiencia profesional mínima de 3 años en asesoría o gestión en organizaciones TIC, y experiencia previa en evaluaciones Scrum Level independientes

Por otra parte, señalar que para los que hayáis realizado el curso de Scrum Manager, que la realización y superación del curso de certificado en  Scrum Level en un centro asociado os proporciona 65 PDUS válidos para el mantenimiento de la certificación  Scrum Manager. Recordad que Scrum Manager distingue entre Acreditación (examen aprobado con nota mínima de 8, pero no realizado ante centro asociado) y Certificación (examen aprobado con nota mínima de 8 y realizado en un centro homologado).

Usar técnicas y prácticas ágiles en un marco de producción sin una cultura ágil, no es propiamente agilidad, sino ingeniería concurrente (solapamiento de fases) con ciclo de vida incremental, o lo que se podría llamar “agilidad técnica”

 

Referencias:

 

 

 

 

 

 

 

 

 

 

CERTIFICACION PRINCE2 PRACTITIONER

Dejar un comentario

¿QUÉ ES PRINCE2?

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. Asi que, 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. Es la metodología seguida, por ejemplo, por la EUIPO.

CERTIFICACIONES:

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
  • La forma de crear los productos de gestión de PRINCE2
  • Cómo mapear los roles ágiles a la estructura de equipo de gestión de PRINCE2
  • La manera de 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 ya no están disponibles en español.

FUNDAMENTOS:

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

EXÁMENES:

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.

CONCLUSIÓN:

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?

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