Categoría: Lecturas

PMO PRACTICE GUIDE

Título original: Project Management Offices: A Practice Guide

Autor: Project Management Institute

Editorial: PMI (Project Management Institute)

Idioma: inglés

ISBN: ‎1628258225

Páginas: 340

Palabras clave: Proyectos, metodologías de gestión, metodologías, libros, lecturas, PMO, Oficinas de Gestión de Proyectos, Oficinas Técnicas

1. INTRODUCCIÓN:

Con fecha 26 de octubre de 2023, el Project Management Institute (PMI), la organización líder mundial para la profesión de Gestión de Proyectos, dió a conocer en su canal oficial que había firmado un acuerdo para adquirir la PMO Global Alliance (PMOGA), la comunidad global más grande de profesionales de las PMO. Y, como efecto directo de esta alianza, surge esta obra, pues en una era donde el éxito organizacional depende cada vez más de la gestión eficaz de proyectos, el rol de la oficina de gestión de proyectos (PMO) nunca ha sido tan crucial. Es un recurso innovador diseñado para conectar el conocimiento teórico con la aplicación práctica, a la vez que define el futuro de las PMO.

Esta guía, publicada el 9 de febrero de 2025, está diseñada para ayudar a las organizaciones a comprender, establecer y optimizar una Oficina de Gestión de Proyectos (PMO). Proporciona información sobre las estructuras, funciones y estrategias de implementación de la PMO. El objetivo es mejorar la gobernanza del proyecto, aumentar la eficiencia y alinear los resultados del proyecto con los objetivos de negocio.

 

2. PROPÓSITO:

Una PMO (Oficina de Gestión de Proyectos) es una entidad centralizada diseñada para estandarizar las prácticas de gestión de proyectos, mejorar la gobernanza y alinear los proyectos con los objetivos empresariales.

Las PMO mejoran las tasas de éxito de los proyectos, la utilización de recursos y la alineación estratégica con los objetivos empresariales.

 

3. TIPOS DE PMO:

En el PMBOK V6 se mencionaban tres tipos de PMO (de apoyo, de control y directiva), cada una con diferentes niveles de influencia, pero esto ya no es así, ya que existen muchos más tipos de PMO como, por ejemplo:

  • PMO Ágil: Una PMO ágil está diseñada específicamente para apoyar metodologías de gestión de proyectos ágiles, como Scrum, Kanban o Extreme Programming (XP). Se enfoca en fomentar prácticas, principios y valores ágiles, promoviendo la mejora continua y proporcionando orientación sobre herramientas y técnicas ágiles.
  • PMO Torre de Control: La PMO torre de control tiene un rol más activo en la gestión de proyectos, asegurando que los proyectos cumplan con las políticas, procesos y metodologías establecidas.
  • PMO Consultiva: Una PMO consultiva se enfoca en proporcionar asesoramiento, orientación y apoyo experto a los equipos de proyectos dentro de una organización. Similar a la PMO de apoyo, ofrece una variedad de servicios para mejorar las prácticas de gestión de proyectos y lograr el éxito en los proyectos, con la diferencia principal en su rol más proactivo como asesora.
  • PMO Controladora: La PMO controladora tiene un nivel moderado a alto de control dentro de la organización. Se encarga de hacer cumplir las políticas, metodologías y marcos de gestión de proyectos establecidos. Se enfoca en gestionar riesgos, problemas, garantizando  que sigan los procesos y estándares y solicitudes de cambio.
  • PMO Departamental: La PMO departamental es específica para un departamento o unidad de negocio dentro de la organización.
  • PMO Directiva: La PMO directiva tiene un alto nivel de control, gestionando y dirigiendo activamente los proyectos dentro de la organización. Es adecuada para organizaciones con una alta madurez en gestión de proyectos y una necesidad de control centralizado y consistencia.
  • PMO de Entrega: La PMO de entrega es responsable de gestionar y entregar proyectos dentro de la organización, proporcionando las herramientas, procesos y recursos necesarios. Con un nivel moderado de control, se enfoca en garantizar que los proyectos se entreguen a tiempo, dentro del presupuesto y con los estándares de calidad esperados. Apoya a los equipos de proyectos en la ejecución, monitorea el progreso y realiza informes sobre el desempeño de los proyectos, centrándose en la gestión diaria y en la finalización exitosa de los proyectos.
  • PMO Empresarial (EPMO): Un EPMO es una PMO de alto nivel con un alcance amplio y autoridad dentro de la organización. Es responsable de supervisar y coordinar todas las actividades de la PMO, asegurando que estén alineadas con los objetivos estratégicos de la organización y proporcionando un enfoque consistente en la gestión de proyectos a través de toda la empresa
  • PMO de Apoyo: La PMO de apoyo se enfoca en proporcionar soporte a los equipos de proyectos mediante herramientas, plantillas, prácticas aceptadas y capacitación. Tiene un bajo nivel de control y su objetivo principal es mejorar las prácticas de gestión de proyectos compartiendo conocimientos y recursos.
  • PMO Estratégica: La PMO estratégica se enfoca en alinear los portafolios, programas y proyectos de la organización con sus objetivos estratégicos, asegurando que entreguen valor. Involucra la priorización de proyectos, asignación de recursos, realización de beneficios y gobernanza.
  • PMO Táctica: La PMO táctica es responsable de gestionar y coordinar múltiples proyectos relacionados, asegurando que los procesos de gestión de proyectos se sigan de manera consistente y compartiendo buenas prácticas.
  • Oficina de Gestión de Transformación (TMO): La TMO impulsa y gestiona iniciativas de cambio organizacional a gran escala. Supervisa y coordina programas y proyectos críticos para alcanzar los objetivos estratégicos, asegurando su alineación con la visión y estrategia de la organización.
  • Oficina de Gestión de Valor (VMO): La VMO se encarga de asegurar que los proyectos entreguen el máximo valor a la organización. Se enfoca en la evaluación, priorización, seguimiento de beneficios de proyectos y retorno de inversión (ROI), asegurando que los proyectos estén alineados con los objetivos estratégicos y contribuyan al éxito organizacional.
  • xMO: Este concepto amplía el enfoque tradicional de las PMO sobre portafolios, programas y proyectos hacia otras áreas de la organización, donde el apoyo y la experiencia de gestión pueden agregar valor. Un ejemplo de xMO es la oficina de gestión del cambio (CMO), que se enfoca en gestionar el cambio organizacional, asegurando que la organización se adapte a nuevas estrategias, tecnologías o modelos de negocio.

 

4. PUNTOS CLAVE SOBRE LAS PMO:

La evidencia empírica muestra consistentemente que las PMOs más valoradas crean estructuras a la medida, adaptadas a su contexto organizacional único, en lugar de seguir un modelo rígido y predefinido.

En lugar de categorizar las PMOs de manera rígida o adherirse estrictamente a tipos predefinidos, las PMOs exitosas a menudo exhiben una mezcla de características de varios tipos. Esta hibridación les permite crear una estructura única que mejor sirva a su contexto y a las necesidades de las partes interesadas.

A medida que las organizaciones enfrentan nuevos desafíos y oportunidades, inevitablemente surgirán nuevos tipos de PMO. Sin embargo, el éxito no reside en adoptar estos tipos nuevos de manera masiva, sino en inspirarse en ellos para seguir refinando y adaptando las estructuras existentes de la PMO.

Los profesionales de las PMO deben centrarse en crear y evolucionar continuamente modelos personalizados basados en las necesidades específicas de su organización.

Las PMOs más exitosas del futuro trascenderán las categorizaciones rígidas y crearán estructuras verdaderamente personalizadas. Al abrazar la flexibilidad, enfocarse en las necesidades de las partes interesadas y adaptarse continuamente al cambio, las PMOs pueden posicionarse como socios estratégicos indispensables en el éxito organizacional.

En este nuevo paradigma, la “mejor” PMO no es aquella que encaja perfectamente en un modelo predefinido, sino la que se adapta perfectamente a su organización hoy, mañana y en el futuro. Al adoptar este enfoque flexible y adaptativo, las PMOs pueden garantizar su relevancia y valor continuos en un mundo empresarial cada vez más complejo y acelerado.

 

5. ECOSISTEMA ORGANIZACIONAL Y ESCENARIOS:

El marco de Escenarios Contextuales Organizacionales ofrece un marco detallado para comprender estas dinámicas, proporcionando información valiosa sobre los diversos desafíos y oportunidades que las PMO pueden enfrentar en diferentes etapas de su trayectoria. Para comprender plenamente la importancia de este marco, es esencial considerar su lugar en el contexto más amplio de la teoría organizacional y la práctica de la gestión de proyectos. El marco se alinea con los principios del pensamiento sistémico, reconociendo que las PMO no existen de forma aislada, sino que forman parte de un ecosistema organizacional complejo. Cada escenario del marco refleja el estado interno de la PMO, sus interacciones con las diversas partes interesadas y su respuesta a los factores ambientales externos.

Se han identificado ocho escenarios que suelen influir en las iniciativas de PMO, cada uno de los cuales presenta sus propios desafíos y oportunidades. Reconocer el contexto organizacional actual puede moldear significativamente la estrategia de la PMO. Comprender estos escenarios es crucial para adaptar la estrategia de la PMO. Cada escenario requiere un enfoque diferente, y reconocer el contexto organizacional actual es el primer paso para alinear la PMO con las necesidades de la organización. Las PMO que comprenden y se adaptan a estos escenarios prosperan a largo plazo.

 

6. ESTRATEGIAS FRENTE A LOS ESCENARIOS:

Cada escenario organizacional presenta desafíos y oportunidades únicos. Reconocer estos estados permite a las organizaciones implementar estrategias específicas que se ajusten mejor a su situación actual. Estas estrategias no son soluciones universales, sino enfoques a medida diseñados para maximizar el éxito. Para los profesionales de PMO, contar con un conjunto de estrategias para cada escenario es fundamental. Disponer de diferentes estrategias les permite abordar los desafíos de forma proactiva y aprovechar las oportunidades de crecimiento y mejora. Estas estrategias sirven como punto de partida para desarrollar enfoques a medida que consideren el contexto y las necesidades únicas de cada organización. Esta parte del libro es muy aprovechable y muy interesante, pues se destacan unas cuantas estrategias específicas para ser utilizadas en cada escenario.

 

7. LA PMO COMO PROVEEDORA DE SERVICIO:

Los proveedores de servicios se caracterizan por su intenso enfoque en comprender y satisfacer las necesidades de los clientes. Operan bajo acuerdos de servicio definidos, adaptando continuamente sus ofertas para satisfacer la demanda cambiante.

Esta adaptabilidad y enfoque centrado en el cliente han hecho que el modelo de proveedor de servicios sea cada vez más relevante en nuestro dinámico entorno empresarial. Las PMO se encuentran en un momento crítico de su evolución.

Tradicionalmente consideradas como organismos administrativos centrados en la aplicación de estándares y procesos, las PMO ahora tienen la oportunidad de re-imaginar su rol dentro de las organizaciones.

Al adoptar una mentalidad de proveedor de servicios, las PMO pueden transformarse de entidades rígidas y centradas en procesos en socios dinámicos y orientados al cliente, dedicados a mejorar el éxito de los proyectos e impulsar el rendimiento organizacional.

 

8. LA PMO CENTRADA EN EL CLIENTE:

La base de una PMO moderna reside en comprender claramente quiénes son exactamente clientes de una PMO.

En esencia, los clientes de una PMO son las partes interesadas dentro de una organización que reciben, utilizan o se benefician directamente de los servicios prestados por la PMO.

Si bien los términos «clientes» y «partes interesadas» a veces se utilizan indistintamente en el contexto de las PMO, representan conceptos distintos cuya comprensión es crucial.

Los tipos de clientes de una PMO se definen así:

  • Clientes de una PMO. Este grupo incluye a las partes interesadas que reciben y utilizan directamente los servicios de la PMO. Tienen necesidades específicas que la PMO busca satisfacer y pueden proporcionar retroalimentación directa sobre el valor y la calidad de las ofertas de la PMO. La relación es transaccional y orientada al servicio.
  • Otras partes interesadas de la PMO. Las partes interesadas de la PMO abarcan un grupo más amplio, que incluye a cualquier persona interesada o afectada por las actividades de la PMO, independientemente de si utilizan directamente sus servicios o no.

Los principios de una PMO centrada en el cliente son:

  • Mentalidad de priorizar al cliente. Todas las decisiones, procesos y servicios deben evaluarse en función de cómo satisfacen las necesidades de los clientes. Esta mentalidad ayuda a garantizar que cada acción de la PMO esté alineada con el objetivo de mejorar la satisfacción del cliente y generar beneficios tangibles.
  • Entrega de valor. El enfoque debe centrarse en brindar valor a los clientes de la PMO, en lugar de simplemente aplicar procedimientos o metodologías. La entrega de valor implica comprender qué constituye valor para los diferentes clientes.
  • Experiencias personalizadas. Los servicios e interacciones deben adaptarse a las necesidades, la cultura y el nivel de madurez de los clientes de la PMO. Esta personalización requiere un profundo conocimiento del entorno del cliente, incluyendo sus desafíos, preferencias y expectativas específicas
  • Interacción proactiva. La PMO debe atender activamente las inquietudes de los clientes en lugar de esperar a que se planteen, lo que ayuda a garantizar resultados satisfactorios. La interacción proactiva implica interactuar regularmente con los clientes para identificar posibles problemas con anticipación y abordarlos con prontitud.
  • Medición del éxito y la satisfacción del cliente. Defina y realice un seguimiento de las métricas que reflejen el éxito, la satisfacción, el compromiso y la promoción del cliente de la PMO. Estas métricas proporcionan información valiosa sobre el grado en que la PMO cumple con las expectativas del cliente y las áreas de mejora necesarias.
  • Retroalimentación constante y mejora continua. Recopilar periódicamente la retroalimentación de los clientes de la PMO para mejorar continuamente los puntos de contacto y los resultados del servicio. La retroalimentación es un componente fundamental de un enfoque centrado en el cliente, ya que proporciona información directa de los clientes sobre sus experiencias y necesidades.

Identificación de expectativas de los clientes de la PMO: Basándose en el enfoque centrado en el cliente, esta sección presenta un recurso valioso para los profesionales de PMO: una lista seleccionada de 30 posibles resultados de una PMO. Esta lista completa es el resultado de una extensa investigación dentro de la comunidad global de PMO, que abarca PMO de diversas regiones e industrias.

Los 30 posibles resultados de una PMO se detallan en La Evaluación de Expectativas del Cliente de la PMO, que se encuentra en el Apéndice X2 de la guía.

 

9. SERVICIOS Y MADUREZ DE LA PMO

Los servicios de la PMO abarcan una amplia gama de funciones diseñadas para apoyar y mejorar la gestión de portafolios, programas y proyectos dentro de una organización.

Los servicios se pueden clasificar en tres categorías:

  1. Estratégicos
  2. Tácticos
  3. Operativos

Además, estos servicios pueden aplicarse en los tres dominios: portafolio, programa y proyecto.

El libro ofrece una tabla de los 26 servicios más comunes de las PMO, que no vamos a reproducir aquí,  observados por la comunidad global de la PMO. Este contenido es muy interesante y aporta mucho valor.

Dependiendo del nivel de madurez  de cada cliente, se podrá ofrecer el mismo servicio, pero con diferente enfoque.

 

10. DESARROLLANDO COMPETENCIAS PARA LOS PROFESIONALES DE LA PMO

Basándose en la experiencia de líderes de PMO de todo el mundo, se han identificado 30 competencias clave como esenciales para los profesionales de PMO. Estas competencias abarcan una amplia gama de áreas, desde la experiencia técnica hasta las habilidades interpersonales. Al dominar estas competencias, los profesionales de PMO pueden estar capacitados para demostrar eficazmente el valor de la PMO a los clientes en todos los niveles.

La guía ofrece un listado detallado de estas 30 competencias y busca que a través de un ciclo de DISEÑO, OPERACIÓN y MEJORA se produzca el desarrollo de las mismas.

 

11 EL ANILLO DE VALOR.

El marco de trabajo del Anillo de valor de la PMO, representa una redefinición crucial del rol de las PMO dentro de las organizaciones. Centrarse en la creación de valor, la alineación estratégica y la orientación al cliente permite a las PMO pasar de ser unidades de soporte operativo a convertirse en facilitadores estratégicos del éxito organizacional.

La experiencia demuestra que las PMO exitosas en diversas organizaciones a nivel mundial exhiben características únicas, y esta diversidad es un factor crítico para el éxito. Reconociendo esto, el marco  del Anillo de Valor, no impone un único modelo ideal o tipo de PMO como estándar universal para las organizaciones. En cambio, reconoce el valor de las diversas perspectivas ofrecidas en la literatura como fuentes de inspiración, en lugar de soluciones predefinidas. Estas perspectivas sirven como ideas adaptables, brindando a los profesionales de PMO opciones de las que aprovechar al considerar las necesidades específicas, los objetivos estratégicos y el entorno único de su organización.

 

12 ELEMENTOS DE BASE ORGANIZACIONAL

Una PMO no existe de forma aislada ni opera en el vacío. Forma parte del ecosistema de su organización. Dado que la supervivencia y la prosperidad de un organismo vivo dependen de su integración con su entorno, una PMO exitosa depende de su capacidad para alinearse con sus cimientos y aprovecharlos. No considerar estos elementos puede llevar a que una PMO se distinga y a que no logre demostrar valor ni ganar impulso dentro de la organización.

Cuatro elementos críticos determinan cómo debe diseñarse y operarse una PMO:

  • Estrategia organizacional. La estrategia organizacional proporciona una dirección y un propósito claros para la PMO, actuando como una brújula. Alinearse estrechamente con la estrategia organizacional convierte a la PMO en un poderoso catalizador para la ejecución estratégica, que traduce los objetivos de alto nivel en resultados tangibles, impulsando así el éxito organizacional.
  • Estructura organizacional. Las PMO operan dentro del marco de la estructura organizacional. La capacidad de una PMO para funcionar bien depende principalmente de su capacidad para desenvolverse en la estructura preexistente de la organización y desarrollar procesos y métodos de apoyo que se integren fluidamente con las jerarquías y canales de comunicación ya establecidos. Es importante comprender la «estructura real», ya que las dependencias, el poder y la red de influencia reales a menudo difieren de lo que se muestra en los organigramas.
  • Cultura y madurez organizacional. Factores invisibles como la cultura y la madurez organizacional pueden impulsar el progreso de algunas PMO, pero obstaculizar el de otras. Las PMO exitosas deben considerar estas características a la vez que aumentan gradualmente el nivel general de madurez en la gestión de proyectos al abordar proyectos basados ​​en normas culturales.
  • Perfil específico de la industria. Este perfil proporciona el contexto más amplio en el que opera una PMO. Este elemento implica que cada industria tiene ciertas particularidades en términos de regulaciones, prácticas o desafíos que pueden obligar a cualquier PMO a ajustar sus estrategias, metodologías y áreas de enfoque según corresponda.

En conjunto, estos elementos conforman el ADN de una organización, integrando el entorno en el que opera una PMO e influyendo en su diseño, operación e impacto final en cada etapa del proceso.

Los componentes estructurales de una PMO son los siguientes:

  • Mandato de la PMO. Este componente define el «porqué» de la PMO, articulando su propósito y justificación dentro del contexto organizacional. El mandato garantiza que las actividades de la PMO se alineen con los objetivos estratégicos de la organización, proporcionando una justificación clara para su existencia y operaciones.
  • Gobernanza de la PMO. Este componente establece el «quién» y el «cuándo» de la PMO, estableciendo los procesos de toma de decisiones, roles, responsabilidades y mecanismos de rendición de cuentas. La gobernanza guía las operaciones de la PMO, manteniendo la coherencia en sus prácticas. La gobernanza de la PMO también define las políticas, procedimientos y estándares que rigen las actividades diarias de la PMO.
  • Estrategia de la PMO. Este componente describe el «qué» y el «cómo» de la PMO, estableciendo el plan a largo plazo que define cómo la PMO crecerá y evolucionará para generar valor continuamente a la organización. La estrategia de la PMO se centra en las acciones y mejoras específicas que la PMO puede implementar para aumentar su impacto a lo largo del tiempo.

 

13.PROFUNDIZANDO EN EL «VOLANTE» GENERADOR DE VALOR

Visión General del Volante o Flywheel: Se trata de un modelo dinámico de 10 pasos que operativiza el ciclo de experiencia del cliente de la PMO. Se inspira en la filosofía de «volante» de Jim Collins, donde esfuerzos incrementales sostenidos crean un ciclo de éxito auto-reforzante.

Los 10 Pasos son los siguientes:
1. Construcción de Conciencia: Educar y desarrollar la madurez de los clientes de la PMO.
2. Evaluación de Necesidades: Técnicas para descubrir desafíos y oportunidades más allá de las necesidades explícitas.
3. Propuesta de Valor: Articular declaraciones claras y convincentes del valor de la PMO.
4. Desarrollo de Servicios: Crear, refinar y evolucionar servicios de PMO impulsados por el valor.
5. Incorporación de Servicios (Onboarding): Introducir eficazmente servicios nuevos o mejorados.
6. Operación de Servicios: Prácticas para la gestión diaria de la entrega de servicios de PMO.
7. Monitoreo de Servicios: Seguimiento, medición y análisis del rendimiento de los servicios de PMO.
8. Mejora de Servicios: Mejorar la madurez y sofisticación de los servicios de PMO.
9. Entrega de Valor: Realizar y demostrar los beneficios tangibles de la PMO.
10. Reconocimiento del Valor: Asegurar que el valor entregado por la PMO sea reconocido y aprovechado por los clientes

 

14.CONCLUSIONES

Como conclusión, señalar que la Guía Práctica para Oficinas de Gestión de Proyectos (PMO) es un recurso integral para profesionales de PMO, que busca elevar el perfil de estas oficinas y desarrollar sus habilidades a nivel global. El documento aborda los desafíos y las oportunidades que enfrentan las PMO, enfatizando un cambio de paradigma hacia un modelo dinámico y centrado en el cliente, donde las PMO actúan como socios estratégicos en el éxito organizacional. Se exploran los escenarios contextuales que influyen en el diseño y la operación de una PMO, destacando la necesidad de adaptabilidad y soluciones personalizadas, en lugar de enfoques únicos para todos. El texto también detalla el ciclo de la experiencia del cliente de la PMO, un modelo de diez pasos que guía a las PMO a través de las etapas de creación de valor, desde la conciencia y la evaluación de necesidades hasta la entrega y el reconocimiento del valor. Además, se examinan las competencias esenciales y los componentes estructurales necesarios para una PMO eficaz, consolidando su papel como proveedor de servicios impulsado por el valor.

Una lectura muy recomendable a todas las personas que están interesadas en la gestión de las PMOs o que deseen actualizarse en este tema.

 

ANEXO 1: CERTIFICACIÓN PMO-CP

Con respecto a la certificación PMO-CP que antes gestionaba la PMO Global Alliance, señalar que, desde su fusión con PMI, ahora esta certificación es gestionada directamente por PMI.

Según la propia PMI, la certificación PMI-PMOCP enfatiza el valor estratégico de las PMO, priorizando la flexibilidad y los enfoques personalizados en lugar de un modelo universal. Demuestra su capacidad para contribuir al éxito de la PMO, posicionándose como un actor clave en el crecimiento organizacional. Es especialmente adecuada para:

  • Líderes de PMO
  • Miembros del equipo de PMO
  • Gerentes y coordinadores de proyectos

NOVEDADES DEL BORRADOR DE LA VERSION 8 DEL PMBOK

INTRODUCCIÓN:

Desde el 20 de diciembre de 2024, el Project Management Institute (PMI) abrió el Draft Comment Period (DCP) para la revisión del borrador de la 8ª edición de «A Guide to the Project Management Body of Knowledge» (PMBOK® Guide) y «The Standard for Project Management».

Lo primero que hay que entender es que a partir de esa fecha y por un periodo inicial de un mes, comenzó el periodo de revisión y comentarios a partir de lo que el PMI indica que es un borrador de esta reconocida Guía.

La Guía PMBOK® versión 8 se publicó como borrador, y no habrá una versión oficial publicada sino, tentativamente, hasta el último trimestre de 2025, pero por regla general, la publicación definitiva se dará muy posiblemente en el año 2026.

La nueva edición viene con cambios importantes que buscan equilibrar lo mejor de las versiones anteriores mientras integran tendencias actuales como la inteligencia artificial y la gestión estratégica de calidad.

Recordemos que el PMBOK es un material de obligado estudio e imprescindible para poder obtener la certificación PMP que otorga el PMI.

LINEA DE TIEMPO:

NOVEDADES:

Elementos que la propuesta de la versión 8 de PMBOK ha tomado de versiones anteriores.

Desde la publicación de  la versión 7 en el año 2021 y previamente, la versión 6, la cual fue publicada en 2017, el PMBOK ha realizado revisiones y atendido las inquietudes de la comunidad, por lo que ha procedido a la generación del borrador de la octava edición, integrando elementos de las últimas dos versiones.

Lo más natural sería pensar que tomaría la vigente versión 7 y sobre ésta se construiría la siguiente versión. Sin embargo, para sorpresa de la gran mayoría, se han incluido también elementos de la versión 6.

El borrador de la octava edición de la Guía PMBOK® introduce varios cambios significativos en la gestión de proyectos. A continuación, se destacan los más relevantes:

  • Actualización de Términos Clave
  • Agrupación en 7 Dominios de Rendimiento
  • Reintroducción de Procesos y Grupos de Procesos
  • Inclusión de Tecnologías Emergentes
  • Integración de Enfoques Ágiles

 

CAMBIO EN LA DEFINICIÓN DE PROYECTO:

Definición de Proyecto según PMBOK 7: Un proyecto es un esfuerzo temporal emprendido para crear un producto, servicio o resultado único. Los proyectos se diferencian de las operaciones porque son esfuerzos temporales con un comienzo y un final definidos, y porque entregan un resultado único.

Definición de Proyecto según PMBOK 8: El PMBOK 8 mantiene la base de la definición anterior pero incorpora un enfoque adicional en la gestión estratégica y el contexto en el que se realiza el proyecto. Un proyecto sigue siendo un esfuerzo temporal para crear un producto, servicio o resultado único, pero también se considera la alineación del proyecto con los objetivos estratégicos de la organización y la adaptabilidad a los cambios del entorno.

CAMBIOS EN LOS PRINCIPIOS Y EN LOS DOMINIOS:

Según el borrador del PMBOK 8 “Ser un líder responsable (Be an accountable Leader)”,  implica asumir la responsabilidad total por el éxito y los resultados del proyecto. Ser un líder responsable en el contexto del PMBOK 8 es actuar con integridad, transparencia y diligencia, asegurándose de que el proyecto no sólo cumpla con sus objetivos, sino que también se gestione de manera ética y sostenible.

PRINCIPIOS:

 

La «visión holística de los proyectos, (Adopt a Holistic View)», según el PMBOK 8, implica gestionar los proyectos de manera integral, considerando no sólo los objetivos y entregables específicos, sino también el contexto más amplio en el que el proyecto se desarrolla.

En el contexto del  borrador del PMBOK 8,“Enfocarse en el Valor (Focus on Value)» significa centrarse en crear y entregar valor real y tangible a los interesados y a la organización a lo largo del ciclo de vida del proyecto, lo que implica una gestión centrada en maximizar los beneficios y satisfacer las expectativas de todos los interesados, asegurando que cada esfuerzo del proyecto contribuya a generar valor significativo y sostenible.

El principio de ”Construir una Cultura Empoderada (Build an Empowered Culture)” en el PMBOK 8 se centra en crear un entorno donde los miembros del equipo se sientan valorados, apoyados y capacitados para tomar decisiones y actuar de manera autónoma. El contar con un entorno donde se empodere a los miembros del equipo fomenta  una mayor Innovación, una mejora sustancial en la productividad y la ejecución de las tareas y un entorno de trabajo positivo.

El hecho de «Incorporar la gestión de calidad desde el inicio (Embed Quality Into Processesand Deliverables)» es fundamental para asegurar que tanto los procesos como los entregables del proyecto cumplan con los estándares y expectativas establecidos.

En el contexto del PMBOK 8,“Integrar la sostenibilidad (Integrate Sustainability Within All Project Areas)” implica considerar los impactos ambientales, sociales y económicos en todas las fases del proyecto, buscando no dejar de lado ninguna de las áreas de los proyectos, lo que genera confianza  a los interesados del proyecto, y lo que a su vez facilita la aceptación y entrega de los mismos.

DOMINIOS:

Los dominios de desempeño han sido revisados y mejorados para ser más prácticos y aplicables. Los nuevos dominios son:

1. Gobernanza: Enfocado en establecer estructuras y procesos de toma de decisiones claros y efectivos.
2. Alcance: Mantiene el enfoque en definir y controlar lo que se incluye y excluye del proyecto.
3. Cronograma: Refuerza la planificación y gestión de los tiempos del proyecto.
4. Finanzas: (Anteriormente Costes) Enfocado en la gestión financiera del proyecto, incluyendo presupuesto y control de costes.
5. Interesados: (Ahora incluye Comunicaciones) Gestiona tanto a los interesados del proyecto como la comunicación efectiva con ellos.
6. Recursos: Optimiza la utilización de recursos personales y materiales.
7. Riesgos: Se ocupa de la identificación, evaluación y respuesta a los riesgos del proyecto.

 

GESTIÓN POR PROCESOS:

La octava edición incluye cuarenta (40) procesos distribuidos en siete (7) dominios de desempeño y  cinco (5) grupos de procesos.

El retorno de los procesos  marca  de nuevo una definición estructural sobre la gestión de proyectos, más acorde a la naturaleza propia y la dinámica de los mismos.

 

DOMINIOS DE DESEMPEÑO:

Los nuevos dominios de desempeño incluyen Gobernanza, Alcance, Cronograma, Finanzas, Interesados, Recursos y Riesgos.

Estos dominios sustituyen a las áreas de conocimiento de ediciones anteriores.

COMPROBACIÓN DE RESULTADOS:

En la octava edición del PMBOK, la comprobación de resultados se aborda de manera integral, alineándose con los principios y dominios de desempeño.

1. Evaluación Continua: Se enfatiza la importancia de la evaluación continua a lo largo del ciclo de vida del proyecto. Esto incluye la revisión periódica de los resultados y la comparación con los objetivos establecidos.

2. Indicadores de Desempeño: Se utilizan indicadores clave de desempeño (KPIs) para medir el progreso y el éxito del proyecto. Estos indicadores ayudan a identificar áreas que requieren ajustes y a asegurar que el proyecto se mantenga en el camino correcto.

3. Retroalimentación y Ajustes: La retroalimentación constante de los interesados y el equipo del proyecto es crucial. Esta información se utiliza para realizar ajustes necesarios y mejorar los procesos y resultados.

4. Documentación y Reportes: La documentación detallada y los reportes regulares son esenciales para la transparencia y la rendición de cuentas. Estos documentos ayudan a mantener a todos los interesados informados sobre el estado del proyecto y los resultados alcanzados.

 

GESTIÓN DEL CAMBIO:

La gestión del cambio en la octava edición del PMBOK se centra en asegurar que los cambios implementados en los proyectos no sólo se completen con éxito, sino que también sean sostenibles a largo plazo. Aquí hay algunos puntos clave:

  1. Planificación del Cambio: PMBOK enfatiza la importancia de planificar el cambio desde el inicio del proyecto. Esto incluye identificar los impactos potenciales del cambio y desarrollar estrategias para gestionarlos.
  1. Ejecución y Monitorización: Durante la ejecución del proyecto, es crucial monitorizar continuamente el progreso del cambio y hacer ajustes según sea necesario.
  1. Cierre del Proyecto: En la fase de cierre, PMBOK recomienda documentar las lecciones aprendidas y transferir el conocimiento a los equipos relevantes. Esto no sólo ayuda a mejorar futuros proyectos, sino que también asegura que el cambio se mantenga y se integre en la organización.
  1. Sostenibilidad del Cambio: Aunque PMBOK se enfoca en la entrega de resultados dentro de los plazos y presupuestos establecidos, también reconoce la importancia de la sostenibilidad del cambio. Esto implica seguir apoyando a la organización para que los nuevos procesos, herramientas o comportamientos sean plenamente adoptados.

 

PMO (APÉNDICE):

En el borrador de  la  octava edición del PMBOK, el enfoque de la Oficina de Gestión de Proyectos (PMO) ha evolucionado significativamente. Dentro de los cambios más importantes tenemos:

1. Enfoque en Socios y Clientes: La PMO ahora se centra más en ser un socio estratégico y en la satisfacción del cliente. Esto implica una mayor colaboración con las partes interesadas y un enfoque en la entrega de valor.

2. Flexibilidad y Adaptabilidad: Se reconoce la necesidad de que las PMO sean más flexibles y adaptables a diferentes metodologías y entornos de proyectos, incluyendo enfoques ágiles e híbridos.

3. Uso de Tecnología y Datos: La integración de tecnologías avanzadas y el uso de datos para la toma de decisiones son aspectos clave. Esto incluye el uso de inteligencia artificial y análisis de datos para mejorar la eficiencia y efectividad de la gestión de proyectos.

4. Énfasis en la Gobernanza: La PMO juega un papel crucial en la gobernanza de proyectos, asegurando que los proyectos se alineen con los objetivos estratégicos de la organización y cumplan con los estándares y regulaciones.

 

INTELIGENCIA ARTIFICIAL (APÉNDICE):

El apéndice de inteligencia artificial (IA) en la octava edición del PMBOK aborda varios aspectos importantes sobre la integración de la IA en la gestión de proyectos.  Es importante tener en cuenta tres factores claves al abordar este tema.

1. Importancia y Relevancia: Se destaca la importancia de la IA en la gestión de proyectos modernos, subrayando cómo puede mejorar la eficiencia y la toma de decisiones.

2. Casos de Uso Comunes: El apéndice incluye ejemplos de cómo la IA se puede aplicar en diferentes áreas de la gestión de proyectos, como la planificación, la monitorización y el control de proyectos.

3. Consideraciones Éticas: Se abordan las implicaciones éticas del uso de la IA, incluyendo la necesidad de transparencia, equidad y responsabilidad en su implementación.

 

ADQUISICIONES (APÉNDICE):

En el borrador de la octava edición del PMBOK se esperan varios cambios importantes en la gestión de adquisiciones.  Entre los aspectos a tener en cuenta sobre este tema estarían:

1. Enfoque en la Entrega de Valor: La gestión de adquisiciones se alineará más estrechamente con el sistema de entrega de valor.

2. Adaptación a Metodologías Ágiles e Híbridas: Se incorporarán prácticas ágiles (incluyendo métodos/herramientas) e híbridas en los procesos de adquisiciones, permitiendo una mayor flexibilidad y capacidad de respuesta a los cambios del entorno del proyecto.

3. Uso de Datos y Análisis: Habrá un mayor énfasis en el uso de datos y análisis para tomar decisiones informadas en las adquisiciones.

4. Enfoque en la Colaboración y las Relaciones con los Proveedores: Se promoverá un enfoque más colaborativo y estratégico en la gestión de relaciones con los proveedores.

5. Fundamentos en modelos de contratos: Se presenta un apartado sobre los distintos modelos de contractos a ser tenidos en cuenta en la gestión de adquisiciones.

6. Consideraciones Éticas y de Sostenibilidad: Se incluirán directrices más claras sobre la ética y la sostenibilidad en las adquisiciones.

EVOLUCIÓN:

 

CONCLUSIONES:

Las conclusiones sobre los cambios en la octava edición del PMBOK reflejan una evolución significativa hacia una gestión de proyectos más flexible, moderna y centrada en el valor:

  • La convivencia de un enfoque basado en procesos con otro enfoque basado en principios permite una mayor adaptabilidad y personalización, según el tipo de proyecto.
  • Se reconocen y adaptan las metodologías ágiles, dada su creciente importancia en la gestión técnica y seguimiento de los proyectos.
  • La vuelta de los procesos al cuerpo principal, con cuarenta (40) procesos distribuidos en siete (7) dominios de desempeño, proporciona una estructura más familiar y robusta para los gestores de proyectos.
  • La nueva edición pone un mayor énfasis en el uso de datos y tecnologías avanzadas, como la inteligencia artificial, para mejorar la toma de decisiones y la eficiencia.
  • Se mantiene y refuerza el enfoque en la gobernanza y la entrega de valor, asegurando que los proyectos se alineen con los objetivos estratégicos de la organización.

MANUAL PARA LA DIRECCIÓN DE PROYECTOS

Título original: Manual para la Dirección de Proyectos

Autor: Antonio Nieto Rodríguez

Editorial: Profit Editorial

Idioma: español

ISBN: ‎978-8419212535

Páginas: 336

Palabras clave: Proyectos, metodologías de gestión, metodologías, libros, lecturas

INTRODUCCIÓN

Bajo la idea de que es «todo lo que necesitas saber para definir, dirigir y patrocinar proyectos de éxito», no estamos ante un libro técnico solo para Project Managers, sino que está dirigido a todos los que participan de una forma u otra en un proyecto y enfocado a determinar lo que funciona para tener éxito y lo que no, en base a la experiencia de autor, Antonio Nieto Rodríguez.

Antonio nos explica que la economía global desde la pandemia de Covid-19 se ha convertido en una economía de proyectos, que busca crear cambios positivos para las empresas y para el mundo. Recordemos la diferencia entre operaciones y proyectos. La mejora continua típica de las operaciones no proporciona cambios disruptivos a las empresas, como sí lo hacen los proyectos. La productividad mundial se estancó porque los métodos de mejora de la eficiencia no generan grandes cambios, como sí lo hacen los proyectos. Por esto, la proyectificación del trabajo ha hecho que la gestión de proyectos no haya dejado de aumentar desde el año 2010 y no va a hacer más que acelerarse.

Muchas empresas dejarán de tener descripciones de roles en la empresa y pasarán a tener descripción de roles en proyectos. Las personas no se definirán por el departamento al que pertenecen sino por los proyectos en los que trabajan. La conclusión es que todos nos convertiremos, nos guste o no, en líderes de proyectos.

Es por eso por lo que el libro está dirigido a todos los stakeholders, interesados e implicados en los proyectos, no solo a los Project Managers, pues que los proyectos tengan éxito y cumplan sus objetivos es responsabilidad de todos.

PRIMERA PARTE: FUNDAMENTOS DE PROYECTOS PARA TODOS

Como es sabido, las operaciones hacen funcionar a la organización, pero los proyectos son los que cambian la organización. Y esto hace que la ambidestreza organizativa, es decir la capacidad de la empresa de explotar sus capacidades actuales y explorar nuevas competencias sea fundamental para que las organizaciones puedan sobrevivir en el mundo actual. La capacidad de hacer funcionar la organización depende del Departamento de Operaciones, en cambio, la capacidad de cambiar la organización es una competencia de los proyectos. El equilibro entre estos dos puntos es un gran reto.

En los siglos pasados, se primaron la eficiencia y la reducción de costes a través de las Operaciones, pero en el siglo presente y en el futuro, el mundo cambiará impulsado por los proyectos.

Antes de la pandemia, los proyectos tenían mala fama dentro de las organizaciones, era algo que se hacía junto con el trabajo habitual y la mayoría de los trabajadores lo veían como un esfuerzo extra que no estaba ni valorado ni renumerado adecuadamente. Todo esto cambió durante la pandemia, la situación exigió que proyectos que solían durar decenas de años (por ejemplo, el desarrollo de vacunas) se tuvieran que terminar en menos de un año. Y lo mismo sucedió en el sector de la construcción, de emplearse varios años para construir un hospital se pasó que tener que desarrollarlo en menos de seis meses. Una broma común en España en el año 2020 es que el Covid-19 había hecho más por la transformación digital de las empresas e instituciones que la mayoría de los CIO’S a cargo de los departamentos TIC de estas. Verdad verdadera.

El libro describe las definiciones básicas de la gestión de proyectos: qué es un proyecto, una operación, un programa, una PMO y los tipos de proyectos que existen. Además, habla de la gestión de proyectos y los diferentes métodos de gestión (en cascada o predictivos híbridos o agiles, ya adaptativos o iterativos) y cuando es adecuado utilizar cada uno de ellos, según las características de cada proyecto.

El autor del libro pide simplificar el complejo mundo de la gestión de los proyectos, poniendo un poco de sentido común, evitando el lenguaje demasiado técnico para acercarlo a todo el mundo y adecuándolo a los tiempos modernos.

SEGUNDA PARTE: EL PROJECT CANVAS

Esta parte referida al Project Canvas es muy interesante, pues Antonio Nieto tiene el objetivo en mente de hacer visibles los problemas más importantes que sufren los proyectos, que son, por ejemplo:

  • La ausencia de los sponsors de los proyectos
  • La ausencia de beneficios al final del proyecto
  • La ausencia de un equipo que pueda gestionar el proyecto

El Project Charter es una forma muy visual de comunicar y hacer públicos los puntos que se suelen revisar cuando se elabora el documento del «Acta de Constitución», al inicio del proyecto, según dicta el PMBOK V6 del PMI. Antonio se enfrentó al reto de enseñar gestión de proyectos a grupos de ejecutivos y profesionales que no eran gestores de proyectos y que no tenían ningún conocimiento sobre la materia. Para hacer más sencillo el aprendizaje tomó prestada la idea del «Business Model  Canvas» desarrollada por Alex Osterwalder e Ives Pigneur y lo adaptó para poder enseñar sobre los elementos clave de un proyecto.

Los puntos tratados dentro del Project Canvas son los siguientes:

  • Dominio de los Cimientos:
    • Propósito. Por qué vamos a hacer el proyecto.
    • Inversión. Cuánto costará el proyecto.
    • Beneficios. Qué beneficios e impacto generará el proyecto y cómo sabremos que tiene éxito.
  • Dominio de las Personas:
    • Patrocinio. Quién es el responsable del proyecto.
    • Recursos. Quién gestionará el proyecto y qué competencias se necesitan para llevarlo a cabo.
    • Partes interesadas. Quienes se beneficiarán y se verán afectados por el proyecto.
  • Dominio de la Creación:
    • Entregables. Qué es lo que el proyecto producirá, construirá o entregará.
    • Plan. Como y cuando se realizará el trabajo.
    • Cambio. Como vamos a involucrar a las partes interesadas y a gestionar los riesgos

Este enfoque es un gran acierto y aquí se nota que Antonio analizó en profundidad las causas principales por las cuales los proyectos fracasan, pues muchas veces los proyecto no son exitosos porque algunos o varios de estos puntos no están lo suficientemente claros y no se trabaja sobre ellos.

Para facilitar la definición de cada uno de estos puntos, el autor propone una serie de herramientas y técnicas para poder determinarlos y solucionarlos con claridad. Creo que esta es la parte más útil y aprovechable del libro. Solo con esta parte (que consta de unas 180 páginas) el coste del libro ya estaría muy bien amortizado.

Incorpora el libro un ejemplo de cumplimentación de los diferentes puntos que componen el Project Canvas y un análisis para determinar si está correctamente o no completado cada apartado. El objetivo es comprobar que las características clave y los impulsores clave del proyecto se han definido adecuadamente y comunicado correctamente.

En mi experiencia profesional, muchas veces encontré problemas con sponsors que eran nombrados solo por el hecho de ser directores de departamento y que no estaban de algún modo involucrados en la gestión de los proyectos a los que habían sido asignados y mucho menos implicados. En un caso en concreto, recuerdo que un patrocinador cumplimentó una hoja Excel de solicitud de proyecto y comentó al Departamento de Proyectos que se marchaba un mes de vacaciones de verano y que esperaba que a su vuelta el proyecto estuviera ya desarrollado y perfectamente finalizado.

TERCERA PARTE: COMPETENCIAS INDIVIDUALES Y ORGANIZATIVAS DE LOS PROYECTOS

Esta tercera parte del libro examina las competencias necesarias para convertirse en un gestor o patrocinador de proyectos eficaz y se divide en tres apartados:

  • Liderazgo de proyectos
  • Seleccionar y priorizar proyectos
  • La organización ágil y orientada a proyectos

Dentro del punto referido al liderazgo de proyectos Antonio remarcó la diferencia entre un gestor de proyectos frente a un líder de proyectos que es quien siendo gestor o patrocinador de proyectos eficaces muestra cualidades de liderazgo.

Las cualidades o competencias del liderazgo de proyectos son las siguientes:

  1. Conocimientos técnicos de gestión de proyectos. Para ser eficaces, los patrocinadores, los ejecutivos y los altos cargos deben conocer los aspectos esenciales de los proyectos y de la gestión de estos.
  2. Desarrollo de productos y experiencia en el sector. Tanto os gestores como los patrocinadores deben tener conocimientos de desarrollo de producto y experiencia para dirigir proyectos de alto impacto.
  3. Estrategia y visión empresarial. Un gestor de proyectos debe conocer bien la organización, sus estrategias, sus principales competidores y el entorno en el que se ejecutará el proyecto.
  4. Capacidad de liderazgo y gestión del cambio. Los gestores y los patrocinadores deben desarrollar un fuerte liderazgo y solidas capacidades de gestión del cambio.
  5. Agilidad y adaptabilidad. En el mundo actual, los gestores de proyecto deben sentirse cómodos trabajando en situaciones de mucha incertidumbre.
  6. Ética y valores. Los profesionales de la gestión de proyectos se rigen por altos estándares éticos par que las decisiones y acciones sean siempre honestas.
  7. Actitud. Además de las seis competencias anteriores, es esencial una buena actitud.

Respecto al punto de seleccionar y priorizar proyectos, las organizaciones necesitan priorizar hoy los recursos, especialmente los escasos recursos de tiempo, dinero, gestión y atención de los empleados. Esto les permite equilibrar sus proyectos. Hoy una priorización eficaz establece la agenda de las organizaciones y refleja su estrategia a corto y largo plazo. La priorización aumenta la tasa de éxito de los proyectos más estratégicos de una organización y aumenta la alineación y el enfoque de los equipos de alta dirección en torno a los objetivos estratégicos.

Hoy cada organización debe desarrollar un marco de gestión de carteras que se adapte a sus necesidades. No obstante, ese marco debe de incluir obligatoriamente ciertos elementos:

  1. Una junta de supervisión, selección y priorización de proyectos
  2. La recopilación y el análisis estructurados y coherentes de nuevas ideas de proyectos
  3. Un método para priorizar y seleccionar nuevas ideas de proyectos
  4. Una hoja de ruta estratégica
  5. Un ciclo de vida con puertas de financiación
  6. Un método para supervisar la ejecución de la hoja de ruta estratégica
  7. Vínculos con el ciclo presupuestario y gestión de riesgo empresarial
  8. Seguimiento de los beneficios

Por último, acerca de la organización ágil y orientada a proyectos, Antonio Nieto menciona en el libro que la estructura, la cultura y la forma de trabajar de tu organización influirán en el éxito de tus proyectos. Las organizaciones tradicionales y verticalistas tendrán dificultades en la Nueva Economía de Proyectos.

El autor menciona los ocho desafíos más comunes en la implementación de proyectos desde una perspectiva cultural organizativa y de procesos de trabajo y cómo tú y tu equipo de liderazgo podéis superarlos:

  1. Escasa responsabilidad por parte de los altos cargos e inadecuada gobernanza. Aquí hablo desde la experiencia personal, es fundamental que cada ejecutivo y promotor sean responsables del proyecto asignado y que también sea responsable de la entrega de los beneficios planeados de su proyecto.
  2. Laxitud y falta de enfoque. Este problema debe evitarse teniendo claras las prioridades de la organización.
  3. Bajo compromiso de los empleados. Esto debería solucionarse comunicando cual es el objetivo de cada uno de los proyectos para que todos los empleados se sientan involucrados y comprometidos.
  4. Organizaciones decisivamente jerárquicas y basadas en silos. Todos conocemos organizaciones de tipo funcional, matricial y basadas en proyectos. Las organizaciones deben ser más planas y los proyectos estratégicos deberian de tener cierta autonomía para ser gestionados.
  5. Una oficina de gestión de proyectos que no es estratégica ni se hace responsable. Las PMO generadoras de documentación no valen para nada y terminan siendo canceladas, las PMO deben generar valor y deben implementar las estrategias que marque la organización. Es la única forma en la que generan verdadero valor a la organización que las soporta y se hacen útiles.
  6. Métodos inadecuados ejecución de proyectos y competencias. Es hora de ampliar y diversificar las herramientas de gestión de proyectos y de ampliar el enfoque con métodos predictivos, agiles y otros.
  7. Un modelo financiero que no refleja los costes y beneficios del proyecto. Los proyectos parecen estar fuera del presupuesto anual de las organizaciones. Esta situación debe resolverse incorporando las inversiones en proyectos al ciclo presupuestario y poniendo foco en los beneficios de cada proyecto.
  8. Inadecuación de los sistemas y herramientas de seguimiento de la ejecución de los proyectos. Hay que aprovechar la tecnología para hacer el seguimiento y control de los proyectos, es decir, no vale con tenerlo todo en decenas de hojas Excel, lo mismo que Microsoft Project ha quedado ampliamente superado como herramienta de gestión y seguimiento de proyectos. El valor que proporciona un Project Manager no es hacer un seguimiento administrativo de la documentación del proyecto sino dialogar con el equipo, entrenando a las personas y cultivando una cultura de alto rendimiento, manteniendo conversaciones periódicas con las principales partes interesadas.

CUARTA PARTE: UN FUTURO MEJOR A TRAVÉS DE LOS PROYECTOS

En este capítulo se trata el tema de cómo la gestión de los proyectos se cruza con cuatro grandes tendencias globales que están afectando a todas las organizaciones del mundo:

  1. La gestión de crisis es gestión de proyectos. Ya vimos lo que la crisis del Covid-19 nos enseñó cerca de los proyectos. En el futuro deberemos estar preparados para gestionar una serie continua de crisis, pues la crisis del Covid-19 seguramente no va a ser la última crisis global a la que nos enfrentemos (el cambio climático, por ejemplo, ya genera desafíos importantes)
  2. La diversidad (y la variedad de pensamiento) y el éxito de los proyectos. Hoy en día hoy en día ya nadie duda de la importancia de la diversidad cada vez más organizaciones reconocen que la diversidad e inclusión y la equidad son cuestiones éticas que no se pueden ignorar para los líderes de proyectos promueve la variedad de sus equipos es una responsabilidad profesional esencial también hay beneficios empresariales asociados a la práctica eficaz de la diversidad y la igualdad. En el futuro veremos que la diversidad de los proyectos conduce a la diversidad de la organización, pues todos los proyectos exitosos implican cambio. Por último, muchas voces sostienen que los grandes proyectos públicos son motores de cambio y mejora social.
  3. El papel de la tecnología. En el presente estamos viendo una falta de soluciones tecnológica dirigidos a la buena gestión de los proyectos. En el futuro hay que determinar qué es lo que la inteligencia artificial y otras tecnologías van a alterar y mejorar en materia de gestión de proyectos.
  4. La revolución de la sostenibilidad. La revolución de la sostenibilidad es otra transformación a gran escala que se llevará a cabo mediante proyectos exitosos y una gestión eficaz de los mismos. Actualmente y ya en las próximas décadas, los gestores de proyectos y los patrocinadores ejecutivos serán los principales responsables interesados en la noción de prácticas procesos y resultados sostenibles. En el futuro la gestión de sostenible de los proyectos va a ser un punto absolutamente obligatorio. No hay que perderlo de vista.

En conclusión, se trata de un libro diferente a los típicos libros de gestión de proyectos, muy recomendable, que tiene varias lecturas y que está orientado a varios públicos. Está dirigido a Project Managers experimentados, que se darán cuenta de lo que suele fallar en los proyectos por falta de comunicación y de preparación de ciertos puntos señalados en el Project Canvas y que hacer para solucionarlo. Y también está dirigido al resto de las personas implicadas en los proyectos (patrocinadores o sponsors, ejecutivos, técnicos, etc) que no conocen las metodologías de los proyectos pero que están de una forma y otra implicados en los mismos y que ese libro les explica (como no expertos) de forma clara y sencilla los puntos esenciales que se deben aclarar y completar para tener éxito en los proyectos, que es el objetivo final del autor del libro.

 

LEGALTECH

Dejar un comentario

LEGALTECH

Me gustaría echar un vistazo al interesante mundo del Legaltech. Aunque mi formación universitaria es legal y mi formación especializada está orientada al Project Management, toda mi vida he trabajado en empresas del mundo tecnológico. Así que me encuentro cómodo en este sector de las Legaltech,  donde se cruzan las nuevas tecnologías con el sector jurídico.

Otra precisión. Mucho queda por hacer en el sector legar con respecto a las nuevas tecnologías, estamos hablando de uno de los sectores más reacios a la incorporación de la tecnología en sus tareas cotidianas.

Qué es Legaltech. Este término se refiere al uso de tecnología y software para proporcionar servicios jurídicos. Según Micha-Manuel Bues «Legal Tech describe el uso de tecnologías digitales modernas, asistidas por ordenador, para automatizar, simplificar y, con suerte, mejorar el proceso de búsqueda, aplicación, acceso y gestión de la justicia a través de la innovación».

Tengamos en cuenta que el mundo legal es uno de los menos influidos por las nuevas tecnologías. Los cambios tecnológicos producidos en bufetes y departamentos legales de empresas han sido los mínimos básicos para no quedar fuera del mercado.

Hablando de los tipos de tecnologías dentro  del LegalTech  y siguiendo al mencionado Bues, se puede hacer la siguiente distinción:

  1. Tecnologías facilitadoras, son soluciones en la nube con opciones de ciberseguridad añadidas, que facilitan el acceso y tatamiento de los datos y que permiten disponer de un acceso remoto a la información legal.
  2. Herramientas de apoyo, que permiten mejorar la gestión de los expedientes.
  3. Soluciones que ayudan o sustituyen, en parte, al asesoramiento juridico. Por ejemplo, son las soluciones de E-Discovery o la automatización de contratos, el blockchain o los smart contracts).

Hablando ya de las modalidades, Moisés Barrio, tomando como referencia el Tech Index of the CodeX Center for Legal Informatics de la Univesidad de Stanford, las clasifica en:

  • Productos de asesoramiento legal automatizado. Como requisito, deben ser sencillas y con  un sencillo árbol de decisiones. Las reclamaciones por retrasos en viajes podrían ser un buen ejemplo.
  • Plataformas digitales de encuentro entre clientes y abogados. Son los llamados marketplaces legales. Ponen en contacto a abogados y a clientes y puede incluir un sistema de reputación de los profesionales. Amazon ya ha entrado en este sector.
  • Externalización de procesos legales. Se trata de empresas que trabajan para proporcionar servicio a los abogados.
  • Automatización documental. Son sistemas automatizados de confección de documentos legales, ya sea para profesionales del Derecho o para usuarios finales. Aquí Rocket Lawyer brilla con luz propia.
  • Herramientas de e-Discovery y revisión documental. Estas herramientas pueden analizar enormes cantidades de información en poco tiempo  Un buen ejemplo es Luminance.
  • Análisis predictivo de casos. Aqui se busca la utilización del Big Data para obtener tendencias en las conductas y sentencias de los órganos judiciales.
  • E-Learning. Apoyo al aprendizaje basado en servicios on line.

 

FORMACIÓN EN LEGALTECH:

Me acerqué al mundo del Legaltech a través de un pequeño pero excelente curso subido en Coursera llamado LegalTech and Startups firmado por el Instituto de Empresa  (IE) y dirigido por Martí Manent (creador de El Abogado y elderecho.com). Se trataba de un curso de pocas horas pero muy interesante, en el cual se trataba el Legaltech de una forma global. Predominaba un enfoque práctico de la materia y orientado a emprendedores que quisieran desarrollar algún tipo de inciativa en este sector.

 

Respecto a los masters existentes en materia de Legaltech en España, existen tres que destacan especialmente.

Máster de la Universidad de Salamanca

Se trata de un master nuevo, es la primera edición.

Según su propia web: «Se dirige a Licenciados y Graduados en Derecho interesados en las nuevas tecnologías y que quieran conocer en profundidad el funcionamiento y gestión de despachos de abogados virtuales, así como las posibilidades presentes y futuras de un sector tan novedoso y con tanto potencial como el Legaltech. Asimismo, se dirige a abogados en ejercicio que pretendan dar impulso a su despacho a través de medios telemáticos».

Su punto diferenciador es el estudio que se realiza del Derecho comparado en esta materia en Europa  y en  Latinoamérica, pues se realiza en colaboración con FIADI (Federación Iberoamericana de Asociaciones de Derecho e Informática). Se trata de un master para abogados y consultores que busquen actualizarse.

También se trata del primer master en esta materia.

Segun la propia web del CEU: «Ha llegado el momento para el sector legal de reivindicar su papel en la revolución digital y este Máster te ayudará a hacerlo.  Gracias al exhaustivo conocimiento de cada tecnología, tanto desde la perspectiva jurídica como desde la perspectiva técnica, que habrá adquirido cuando finalice el programa, el jurista dispondrá de todas las herramientas necesarias para entender el mundo actual y el que está por venir, y abordará las nuevas realidades jurídicas con la seguridad, la clarividencia y la visión de negocio que solo tendrán los profesionales más despiertos, cualificados y formados en todas estas tecnologías».

Máster del Instituto de Empresa

En inglés. Orientado al mercado europeo y norteamericano. Muy enfocado  al muindo empresarial y a los futuros y actuales emprendedores. Con un primer período en el campus de Madrid, un segundo periodo “on line” y un tercer periodo en el Campus de Silicon valley (USA). Alterna periodos presenciales en Madrid, USA e Israel, con períodos “on line».

Sacado de su web: «El complejo mundo de hoy requiere un conjunto cada vez mayor de capacidades profesionales y habilidades técnicas que son vitales para el éxito futuro en el sector legal. Esta nueva realidad exige una nueva generación de abogados y profesionales que puedan adaptarse al paradigma emergente, al tiempo que comprenden la aplicación de la tecnología y su impacto en la esfera legal.»

 

INVERSORES EN LEGALTECH:

Por otra parte, destacar que la firma Cuatrecasas está muy involucrada en este campo del legaltech. Posee una iniciativa para promocionar este tipo de startups basadas en el mundo de Legaltech,  llamada Cuatrecasas Acelera.    En su web se menciona que Cuatrecasas Acelera es la primera aceleradora de startups europea promovida desde un despacho de abogados.

ESADE BAN es una red de inversores promovida por ESADE Alumni que actúa como punto de encuentro entre los inversores y startups innovadoras y con alto potencial de crecimiento.

 

LIBROS EN ESTA MATERIA:

Respecto a los textos de referencia en este campo, voy a hacer referencia a un par de libros destacados.

LEGALTECH. LA TRANSFORMACIÓN DIGITAL DE LA ABOGACÍA:

Existe un libro imprescindible para entender el mundo español de Legaltech,  llamado «Legaltech. La transformación digital de la Abogacía«de Moises Barrio Andrés y editado por Wolters Kluwer.

Según sus palabras: «Te explicamos en clave práctica las principales áreas en las que la aplicación de la transformación digital y la tecnológica están afectando a la abogacía y al resto de profesiones jurídicas. Te ayudamos a entender cómo ejercerá su profesión el abogado del futuro.»

Se trata de un libro recien editado, (en junio de 2019) que no es barato (ni mucho menos) y que hace una revisión de práctivcamente todos los puntos importantes relacionados con este sector. Moisés Barrio coordinó los contenidos del libro con expertos para que todas las materias punteras en este sector fueran incluidas. Curioso que, siendo un libro de más de 600 páginas, divididas en 27 capítulos, el lector quede con ganas de más.  Imprescindible si se desea estar a tanto de las implicaciones de la legaltech en el panorama actual español.

Desde este enlace Analizamos el libro ‘Legal Tech: La transformación digital de la abogacía’  se puede acceder a un interesante analisis del libro, realizado por José María Fernández para el imperdible blog «Derecho Práctico«, al que soy asiduo visitante y al que animo a visitar frecuentemente.

legal upheavalLEGAL UPHEAVAL: A GUIDE TO CREATIVITY, COLLABORATION AND INNOVATION IN LAW:

Otro libro remarcable es «Legal Upheaval: A Guide to Creativity, Collaboration, and Innovation in Law», escrito por Michelle Destefano y editado por la American Bar Asociation. Su enfoque es totalmente diferente al anterior libro reseñado.

Reseña del editor: «Este libro es para cualquier persona que invierta en el futuro de la profesión legal, ya sea alguien encargado de transformar su práctica, alguien que busque enfocar su trabajo de una manera nueva, alguien que busque un enfoque nuevo de las relaciones con los clientes o alguien nuevo en el campo. interesado en un pronóstico del mundo por venir».

Está basado en una investigacion realizada sobre más de 100 abogados, ejecutivos y directores de firmas de abogados.

En este caso de lo que trata la autora es dar un toque de atención a los abogados de la vieja escuela. Es un aviso para que vayan preparándose acerca de lo que les va a venir encima, que no es poco.  Y que vayan cambiando de forma de trabajar y de actitud. Menciona lo que llama «Discapacidad de habilidades», es decir, las mismas cualidades en mentallidad y comportamiento que hicieron triunfar a los abogados son las mismas que hacen que no puedan tener un pensamiento innovador.  Debe olvidar para poder mejorar.

Las habilidades que según  Destefano deben requerir los abogados están desvritas en la siguiente pirámide. El con9ocimiento clásico de la ley está en la base de la pirámide. Pero el desafío al que se someten los abogados es que los clientes ya no se conforman con eso y quieren más.  Por ejemplo, transparencia en los costes, conocimiento profundo del sector en el que se mueve el cliente y colaboración en innovación de su negocio.

La segunda parte llamada ‘Las tres reglas de compromiso» busca crear una cultura de creatividad y colaboración. Se centra en enfoques específicos para adoptar con éxito la innovación  en la industria legal. Las Reglas de compromiso están diseñadas para ayudar a los abogados a desaprender sus mentalidades. Implica tener una ‘mente abierta’, un ‘corazón abierto’ y una ‘puerta abierta’.

Durante la tercera y última parte del libro, la autora recomienda iniciar un «ciclo abreviado de innovación». Esto debe hacerse en el despacho, bufete o consultora lo antes posible.

Libro muy recomendable por lo que tiene de despertar conciencias. Ennumera por qué los abogados deberían de cambiar, el enfoque que deberían tomar y cómo hacer para que ese cambios suceda. Me ha gustado mucho el enfoque que propone para tener éxito de unir equipos con una combinación de personas procedentes de diferentes disciplinas, trabajando juntos en una especie de nutritiva «Stone Soup«.

 

ENLACES INTERESANTES:

Esta es una serie de enlaces interesantes para los que deseen produndizar en esta interesante materia:

 

 

 

 

 

 

 

 

 

 

 

 

LIBRO PEOPLEWARE Y EQUIPOS ÁGILES

Dejar un comentario

Título original: Peopleware y Equipos Ágiles

Autor: Javier Garzás

Editorial: 233gradosdeTI

Páginas: 200 (color)

Idioma: español

ISBN: 978-84-697-7450-2

Palabras clave: Proyectos, gestión equipos

Esta reseña nació cuando, hace unos meses, un grupo de compañeros de empresa asistimos a una keynote de Javier Garzás llamada  «Qué es la Agilidad y cómo te puede ayudar a no acabar en una empresa zombi«:  Keynote en la Universidad de Alicante.

La verdad es que nos pareció muy interesante, pues  ya seguíamos desde hace tiempo el blog de Javier.

Así que cuando saltó la noticia  de que Garzás había publicado un nuevo libro, varios fuimos los que nos apresuramos a adquirirlo.

Destacar que es todo un detalle que el autor te dedique el libro bajo petición. Adicionalmente, yo obtuve un dibujo de Darth Vader de bonus. ¡Mola!

Ya entrando en materia,  el objetivo del libro es profundizar en el cambio en la organización de las personas y en los equipos dedicados al software/hardware que se ha producido en las últimas décadas. Según la Wikipedia, Peopleware es «…cualquier cosa que tenga que ver con el papel de las personas en el desarrollo o uso de software y sistemas hardware, incluyendo cuestiones como productividad de los desarrolladores, trabajo en equipo, dinámicas de grupo, la psicología de la programación, gestión de proyectos, factores de organización, diseños de interfaces de usuario e interacción hombre-máquina.»

Originalmente, «Peopleware, Projects and Teams» es el título de un libro de los años 80 de los autores De Marco/ Lister, referido específicamente al desarrollo de software.

Javier desea remarcar la importancia de las personas en los proyectos/productos /equipos, pues en el fondo son la clave del éxito de cualquier proyecto.

El principal mensaje del autor, adquirido a través de una experiencia de haber trabajado en un montón de empresas remarcables, es que en el desarrollo de software se debe  dejar atrás el taylorismo y la industrialización. Pues se implantó esa visión también en los proyectos de desarrollo de software, un verdadero error, pues no es adecuado y ha generado muchos más problemas de los que ha solucionado. Desarrollar software no es lo mismo que construir un puente o levantar un edificio.

El nacimiento de la agilidad y del Manifiesto Ágil fue una reacción a lo poco apropiados que eran los métodos de trabajo tradicionales para gestionar el desarrollo de proyectos de software. Es más, cambiando la palabra «Software» por «soluciones» se puede aplicar el manifiesto ágil más allá del desarrollo de software.

La visión del Management ya no es gestionar a las personas como a máquinas y procesos (versión 1.0), sino orientada a personas y equipos en una estructura organizativa pensada para ello (versión 3.0).

Destaca que en las empresas existen «tribus» entendidas como la forma en la que trabajan, que hace que se entienda mejor el concepto de «Peopleware» y que van desde el tipo 1 (individualismo por la superviverncia)  hasta el tipo 5 (equipo ágil).

Se mencionan los equipos Good to Great, que cumplen con  siete pautas que distinguen  a las empresas punteras del sector, que pasaron de lo bueno a lo excelente.

Los equipos son complejos. Por eso, la adaptabilidad es adecuada para los sistemas complejos y para las incertidumbres.

Ante todo, en la gestión de equipos debería evitarse tratar de resolver problemas complejos con soluciones fáciles, que suelen acabar empeorando el problema que pretendían solucionar: es lo que se llama reduccionismo o «populismo tecnológico»  (véase el caso del efecto cobra). Pensad en ejemplos que se os ocurran (fomentar el presencialismo en la empresa en lugar de la productividad, montar sistemas para fichar todas las mañanas, exigir un montón de documentación, nombrar un comité para resolver un problema, etc…)

Los equipos de trabajo deberían de contar con las siguientes características:

  • Estar motivados. El tema de las motivaciones y recompensas tiene mucha miga. El autor alerta de que las recompensas pueden hacer que las personas trabajen casi exclusivamente para obtenerlas.
  • Ser Auto organizados, pero que un equipo sea dirigido y organizado por sus propios miembros no significa que non haya jefes o managers. lLa diferencia es que estos se reducen a lo necesario.
  • Ser Mutifuncionales, todos deberían de poder hacer casi cualquier tarea dentro del equipo
  • Por supuesto, ser Productivos. en este punto, ojo con medir el trabajo con sistemas que no favorecen la calidad, como el de contar las lineas de código/hora.

Y un equipo debería de estar orientado a la mejora continua, es preciso fomentar una cultura de la reflexión y de la mejora (a través de sesiones de Retrospectiva o de Lecciones Aprendidas).

Resumiendo, un gran libro que merece una lectura detenida, (yo ya lo he releído un par de veces), pues la gestión de los equipos y de las personas tiene actualmente más importancia que nunca si se desea obtener el éxito en  proyectos o iniciativas.

 

 

 

 

 

 

 

 

LIBRO CADENA CRÍTICA

Dejar un comentario

Título original: Critical Chain

Autor: Eliyahu M. Goldratt

Editorial: Ediciones Díaz de Santos, año 2014 (kindle)

Páginas: 296

Idioma: español

ISBN: 9788479784843

Palabras clave: Proyectos, gestión recursos, ruta crítica, cadena crítica

En esta entrada voy a hablar de «Cadena Crítica», un libro que ha obtenido la categoría de clásico en la materia de la gestión de proyectos y cuya edición impresa data de de más ni menos que del año 1997. Y el caso es que ya conocía la teoría de la cadena crítica de haberla estudiado para la certificación PMP (un par de preguntas fueron de esta materia).  Y aún así, su lectura me ha sorprendido. Mil gracias, Juan Carlos, por proporcionarme el libro.

El autor (Eliyahu M. Goldratt) es el creador de una serie de libros de Management y creador de la Teoría de las Restricciones (TOC). Este libro “Cadena Crítica” fue dedicado por su autor a la aplicación de TOC a la materia de la gestión de proyectos. Se ha convertido en la base de la teoría de la cadena crítica, apta para un esquema de limitación de recursos.

La lectura es novelada. No es muy habitual en libros de Management, pero eso hace que se lea con interés. Además de ser interesante para la gestión de proyectos, también es interesante para formadores que desean un enfoque diferente para sus clases. Esto se debe a que el relato presenta a un profesor que busca conjugar el conocimiento teórico de la universidad  en el entorno de la impartición de un MBA con las situaciones que le presentan sus estudiantes, procedentes de su día a día en sus empresas. Al final, estamos en presencia de interesantes clases de descubrimiento del conocimiento. Un  tema secundario que subyace en el libro está de plena actualidad, ¿Están preparadas las universidades para entregar verdadero conocimiento práctico a las empresas?.

Hablando ya de la gestión de los proyectos, en las clases se duda de la eficiencia de medir el grado de avance de los proyectos como medida eficaz para establecer su progreso. Irónicamente, el proyecto puede estar al 90% de progreso una vez transcurrido un año, y luego emplear otro año para cumplir con el restante 10 %. Si se pierde el foco en la ruta crítica ( secuencia de los elementos terminales de la red de proyectos con la mayor duración entre ellos, determinando el tiempo más corto en el que es posible completar el proyecto), entonces es fácil que se produzca retraso, pero que no se sepa, que es lo peor de todo.

El mensaje está claro, es un error el modo en el cual medimos el avance de los proyectos, pues:

  1. Las mediciones deberían inducir a las partes a hacer lo que sea bueno para para el sistema entero
  2. Las mediciones deberían de guiar a los gerentes hacia los puntos que necesiten su atención.

Por lo tanto, la conclusión a la que llegan en las clases es que en los proyectos las mediciones alejan al líder del proyecto.

A través de un técnico que trabajó en otra empresa, los protagonistas conocen la teoría de las restricciones (TOC). El autor del libro había sentado las bases de la TOC en su libro previo (1984) “La Meta, Un proceso de mejora continua”. Sus características son tres:

  1. Es una nueva filosofía gerencial
  2. Es un método de investigación
  3. introduce un amplio espectro de aplicaciones

La metodología de esta teoría se basa buscar la limitación del sistema estudiado y se compone de cinco puntos:

  1. Primer paso, identificar las restricciones del sistema  (el eslabón más débil)
  2. Segundo paso, diferenciar las restricciones físicas y políticas
  3. Tercer paso, subordinar todo lo demás a la decisión tomada
  4. Cuarto paso, elevar (superar) las restricciones del sistema
  5. Quinto paso, si se rompe una restricción, no permitir la rutina y volver al primer paso

Existen tres posibles tipos de limitaciones:

1. Limitaciones físicas: son por ejemplo los recursos personales o materiales

2. Limitaciones políticas: son por ejemplo las reglas empresariales

3. Limitaciones de mercado: por ejemplo los producidos por el propio mercado al que se dirige la empresa

La TOC exige definir un problema con precisión, pues un problema no está bien definido hasta que no puede representarse como un conflicto entre dos condiciones necesarias.

Otra experiencia que aportan los estudiantes del relato es el de tener prevención con los indicadores operativos obsoletos (en la novela se habla de la medición de tonelada/hora de la industria metalúrgica) . La gente se comporta según se la mide.

Para resolver problemas, el método que introduce la TOC es el de la «evaporación de las nubes«,  es decir,  proponer una estructura lógica diseñada para identificar e ilustrar todos los elementos en una situación conflictiva o dilema y sugerir formas de resolverlas. Por ejemplo, no puede haber arreglos a medias (un edificio o mide 30 o 40 metros, pero no se puede dejar a la mitad, pues esto es lo que pasaría si se tratara de optimizar la respuesta).  Si se detectan  situaciones ganar-perder, es porque no se está observando adecuadamente el problema: ganando en amplitud, identificaremos la situación ganar-ganar. Al estudiar y comprobar las suposiciones adyacentes es posible encontrar  soluciones en las que ambas partes ganen (win to win), y nos permitan “Evaporar la nube”.

Otra cosa que descubren los estudiantes del relato es que en sus propias empresas nadie quiere reconocer que mete un factor de protección en sus estimaciones de tiempo de las tareas que componen los proyectos. Es más, a mayor incertidumbre mayor protección se suele añadir. Y los managers agregan su propio factor de protección. Así las estimaciones de tareas de un proyecto están realmente infladas. Pero ¿que es lo irónico de todo esto?. Pues que si las estimaciones incluyen tanta protección, ¿Por qué tantos proyectos no se acaban a tiempo?. La conclusión a la que llegan los estudiantes en las clases es sencilla: si las tareas se acaban antes de lo planificado las siguientes no se inician antes, por lo que este tiempo se desperdiciará. Es decir, las demoras se acumulan, pero lo avances no.

Otros factores destacados que se suman para hacer que la protección se desperdicie son:

  • El síndrome del estudiante. Es decir, retrasar las tareas hasta las últimas fechas y pedir mas plazo para hacer un mejor trabajo.
  • La multitarea y el robo de tiempo que implica, por el gran trabajo que cuesta volver a enfocarse cuando se trabaja en múltiples proyectos a la vez
  • Las dependencias entre las tareas, pues las dependencias son las verdaderas culpables de que las demoras se acumulen, pero los retrasos se desperdicien

La idea surgió casi por sí sola, poner amortiguadores (o buffers) protegiendo la ruta crítica y claro está, teniendo cuidado de que las tareas que no estén en la ruta crítica se convierta en parte de ella. La experiencia dice que la ruta crítica cambia durante el proyecto.

Existen tres tipos de buffers:

  • Buffer de Proyecto: Para proteger el camino o ruta crítica del proyecto.
  • Buffers de Alimentación: Para proteger las tareas que podrían  convertirse en camino crítico en un futuro
  • Buffers de Recursos: se protege la cadena crítica avisando a los recursos críticos del comienzo inminente de sus tareas. Es una tarea virtual que queda insertada justo antes de las actividades de la cadena crítica, cuando requieren de la utilización de recursos de idéntica importancia.

Un problema especial se puede producir con las entregas de los proveedores. No están condicionados a entregar a tiempo sino que compiten en base al precio. En sus estimaciones de entrega se ponen un generoso colchón de tiempo para resolver conflictos entre los pedidos. Pero las demoras en la entrega cuestan mucho dinero a las empresas contratantes. La idea para solucionare esto es añadir a las RFP un «precio tope» pero también un «tiempo tope». Es interesante no dar una fecha de finalización al proveedor para evitar el mencionado «síndrome del estudiante» .

Respecto a la gestión de los recursos, hay que entender que la restricción es la cadena más larga entre pasos dependientes, tanto de tareas como de recursos. En este punto hay que tener cuidado, pues si si existe competencia por los recursos, entonces la cadena crítica puede ser muy diferente de la ruta crítica. Un problema con los recursos puede hacer que la ruta crítica salte por los aires. Por eso, la cadena crítica busca eliminar la competencia entre los recursos de un proyecto y debe esforzarse en tratar de eliminar la competencia entre los diferentes proyectos que compongan un  portfolio.

Por cierto, la traducción del libro es bastante pobre y muy mejorable. Dicho lo cual, se trata de una lectura imprescindible para todo Project Manager.

 

 

 

 

 

 

 

 

 

 

 

 

 

LIBRO AGILE PRACTICE GUIDE

Dejar un comentario

Título original: Agile Practice Guide

Autores: PMI + Agile Alliance

Editorial: Project Management Institute, año 2017

Páginas: 210

Idioma: inglés

ISBN: 978-1628251999

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

Interesante este libro escrito conjuntamente entre PMI y Agile Aliance. Un apunte, si formas parte de PMI y pagas las cuotas anuales de socio, puedes descargar este libro de forma gratuita en formato pdf desde la web de www.pmi.org 

Y da que pensar que el PMI (que ya cuenta con una certificación especifica en materia de agilidad) da por sentado que la agilidad es una metodología que ha llegado para quedarse durante mucho tiempo entre los Project Managers.

Dado que la agilidad se ha expandido a otros ámbitos de desarrollo, el enfoque de este libro se expande más allá del mundo de desarrollo de software

Esta guía está dividida en siete secciones.

1. Introducción

¿Por qué un manual de este tipo ahora? Porque la agilidad es una metodología que busca proporcionar al cliente una inmediata entrega de valor, a través de varias interacciones y esto es muy valorado ahora, pues las empresas buscan ser competitivas orientándose a la experiencia que obtiene el usuario. Son adecuadas para manejar la disrupción.

Los autores comentan que no está en alcance de este libro estudiar cómo extender la agilidad entre toda la organización sino extenderla a uno o varios proyectos. Es una lástima, porque si la organización no cambia es difícil que los proyectos ágiles tengan éxito.

2. Introducción a la agilidad

  • Esta sección trata fundamentalmente del origen de la agilidad y de los principios que lo sustentan
  • la justificación de la agilidad se basa en que el manejo de la incertidumbre es algo que las metodologías predictivas no manejan bien, pues no están orientadas a aceptar el cambio, la complejidad y el riesgo.
  • El manifiesto ágil de desarrollo de software del año 2001 puso por encima de todo a las personas por encima de los procesos. Se crearon cuatro valores y doce principios
  • Me llama la atención la referencia a la relación entre Lean/agile, pero el enfoque de ambos es diferente
  • Interesante la matriz de complejidad de Stacey. Un proyecto puede empezar en un sitio de la matriz y acabar en otro.

Resumiendo, los proyectos más adecuados para ser abordados por la metodología agil son aquellos que:

  • Requieren de investigación
  • Tienen altas posibilidad de sufrir cambios
  • Presentan requerimientos desconocidos o poco claros
  • Tienen un propósito difícil de describir

3. Selección del ciclo de vida

Es la parte más interesante del libro, con diferencia.

Habla de los cuatro tipos de ciclos de vida de los proyectos: predictiva, iterativa, incremental y ágil y de sus características.  Estoy de acuerdo con su apreciación de que no hay un ciclo de vida perfecto para todos los proyectos:

  • Los ciclos de vida predictivos se benefician de entornos en los cuales los requerimientos están bien definidos y marcados (ej. un proyecto fruto de una exigencia legal). Su punto débil son los cambios y que no entregan valor hasta el final del proyecto.
  • Los ciclos de vida iterativos son beneficiosos si existe una alta complejidad, si hay cambios frecuentes o si el alcance depende de diferentes interesados. Están optimizados para el aprendizaje. Un ejemplo son las «refactorizaciones» de software.
  • Los incrementales se orientan a la velocidad de la entrega. Se entregan frecuentes y pequeños entregables. Un ejemplo puede ser completar un aplicativo de software mediante el desarrollo de diferentes módulos. O mostrar cómo quedaría una habitación en el proyecto de construcción de un edificio.
  • Los agiles son excelentes aproximaciones cuando se espera una gran cantidad de cambios en un proyecto. La diferencia de ágil con los ciclos interactivos e incrementales es que estos últimos proporcionan feedback para la siguiente parte del proyecto, pero, sin embargo, en proyectos ágiles, la entrega incremental descubre ocultos o requisitos incomprendidos. A su vez, los ciclos agiles pueden basarse en iteraciones o en flujos de trabajo. los ciclos ágiles combinan aproximaciones incrementales e iterativas para entregar valor de forma frecuente al cliente.
  • Como síntesis de todo lo anterior surgieron los ciclos de vida híbridos, que son los que se combinan para obtener ciertos objetivos. Por ejemplo, se puede trabajar en las primeras fases de un proyecto con metodologías ágiles (si se necesita investigación) y luego pasar a una metodología predictiva (si se debe cumplir una certificación). O combinar ambas metodologías según para qué aspectos (a mí esto me parece más complejo). Hay muchas combinaciones posibles.
  • Este apartado es tan interesante y está descrito a tan alto nivel, que necesita más desarrollo.

4. Implementando ágil: Creando un entorno ágil

Mencionan que un entorno ágil exige un líder «sirviente», (que haga de facilitador del éxito del equipo), en lugar de un líder tal y como se describe en los proyectos predictivos. Este tipo de lider debería de pasar de «gestionar» la coordinación a «facilitar» la coordinación.

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

Y le impone al líder «sirviente» una tarea adicional, tratar de remover los impedimentos organizativos al equipo del proyecto que pudieran hacer de «cuello de botella». Sinceramente pienso que si la organización no se orienta a la agilidad, es bastante complejo que el líder sirviente pueda solucionar por sí solo este problema.

Precisamente y dado que el papel del project manager no se contempla dentro de la agilidad, pues según el PMOK 6 son los encargados de obtener los resultados del proyecto y esta responsabilidad en ágil se distribuye por igual en el equipo del proyecto, propone que hagan de lideres «sirvientes», es decir, que sirvan al equipo del proyecto, allanando su camino.

Si el enfoque predominante es ágil, entonces el papel del PM cambia radicalmente y debe orientarse hacia el liderazgo servil que requiere este tipo de enfoque.

Se habla de los atributos de los equipos agiles exitosos. Comenta que a los equipos ágiles se les debe evitar el coste que supone la «multitarea» de trabajar en varios proyectos de forma simultánea, así como que idealmente deberían de compartir el mismo espacio físico. Se alerta contra el peligro de querer trabajar en forma de «mini waterfalls» que es lo que sucede si se presupone que ya se tienen todos los requerimientos y ya se puede hacer todo el diseño (por ejemplo) o todo el desarrollo. El equipo se dará cuenta de que esa asunción en el mundo ágil no es válida.

Los tres roles que menciona son: product owner, equipo multifuncional y facilitador del equipo (llámese scrum master, project manager o team coach). Apunta que lo ideal es contar con especialistas de tipo «T», que son los que complementan ser expertos en una materia con conocimientos en otras areas.

Alerta acerca de evitar «silos» en la empresa que impidan que la comunicación fluya en el equipo.

5. Implementando ágil: entregando en un entorno ágil

Todo proyecto necesita un acta de constitución donde se defina el proyecto. Pero esto no es suficiente n un entorno ágil. También necesita una visión, un propósito y unas normas de cómo trabajar en equipo.

Las prácticas agiles más importantes son:

  • Retrospectivas. Permite al equipo aprender, mejorar y adaptar su proceso. No es necesario que sea al final de una iteración de dos semanas. se puede solicitar en cualquier momento. Busca las causas raíz de los problemas sufridos y se desarrolla un plan de acción para solucionarlos.
  • Preparación del backlog (lista del trabajo presentado en forma de historias de usuario). No es necesario tener todo el trabajo que el proyecto requiera sino solo el que se va a desarrollar en siguiente sprint o iteración. Esta es tarea del product owner
  • Refinamiento del backlog. Es la preparación de historias de usuario para la siguiente iteración. Si no se conocen las dependencias entre tareas entonces el product owner puede solicitar al equipo la realización de un «spike«, con el fin de conocer los riesgos. Señala que el equipo no debería de emplear más de una hora a la semana en refinar historias. En caso contrario podría indicar que al equipo le faltan habilidades técnicas necesarias para evaluar y refinar el trabajo.
  • Reuniones diarias. Las mini reuniones diarias (de no más de 15 minutos) se usan para declarar lo trabajado, lo que se va a trabajar, así como para hacer aflorar posibles problemas. No se deben convertir en sesiones de análisis de situación del proyecto ni tampoco se deben usar para tratar de resolver problemas.
  • Demos/reviews. Para proporcionar feedback al product owner, se organizan demos de lo desarrollado en cada iteración. Deben ser frecuentes para así poder dar con la dirección adecuada.
  • Planificación de la iteración. La capacidad de cada equipo es diferente. Se debe hacer una estimación de la capacidad.
  • Prácticas de ejecución que ayudan a los equipos a entregar valor:
    • Integración continua
    • Test en todos los niveles
    • ATDD test de aceptación.
    • TDD y BDD test driven development y behavior driven development
    • Spikes. Útiles para aprender sobre elementos técnicos o funcionales críticos.
  • Cómo las iteraciones y los incrementos ayudan a entregar producto. Las iteraciones ayudan al equipo a crear una cadencia de entrega y muchos tipos de feedback. Las demos son una parte necesaria dentro del flujo de los proyectos ágiles.

Por otra parte, se señalan los desafíos que implican los proyectos ágiles y las posibles soluciones. Muy interesante esta parte.

Medidas en los proyectos ágiles:

  • Es un desafío tratar de determinar la medida de avance en un proyecto ágil. Además de las medidas cuantitativas habituales, cobra importancia añadir medidas cualitativas, como la satisfacción del usuario o la moral del equipo de desarrollo.
  • Los valores de avance en agil son empíricos y tratan de lo que se ha hecho, en lugar de que va a realizar. Por su naturaleza, la estimación se limita a unas pocas semanas.
  • La velocidad del equipo calculada en story points es lo que realmente puede permitir hacer una estimación de cuando se podrá terminar el proyecto.
  • Si el quipo depende de las tareas de externos al proyecto, esto puede interferir en su velocidad notablemente.
  • Para que el progreso de un proyecto ágil sea comprensible a un project no iniciado en ágil, se hace una equivalencia de cómo calcular el Valor Ganado (EMV) haciendo un sencillo cálculo del índice SPI (cronograma) características completadas/características planificadas y del CPI (coste) valor ganado/costes actuales

6 Consideraciones organizativas para proyectos agiles

Los autores son conscientes de que los proyectos existen en un contexto determinado. Por eso se considera fundamental el cambio organizativo que permita aplicar la agilidad, en especial se consideran fundamentales los cambios asociados a la entrega rápida y frecuente y a los cambios constantes en los requerimientos. El mismo PMI publicó una guía para gestionar el cambio en las organizaciones: Managing Change in Organizations: a Practice Guide

Dice la frase de Peter Druker «Culture eats strategy for breakfast», la cultura de la empresa, que es su ADN, siempre impacta de forma intensa en las estrategias y en especial en el uso de aproximaciones ágiles en la gestión de proyectos.

Respecto a la parte de la gestión de contratos con proveedores, los autores animan a seguir un esquema de contratos de tipo «win-win», (todos ganan con el acuerdo) que no es una característica en absoluto privativa de los enfoques ágiles.

Por otra parte, los típicos contratos con proveedores que se firman en ciclos de vida predictivos pueden generar grandes riesgos si se trasladan a ciclos de vida ágiles. En especial, puede ser muy arriesgado firmar tanto contratos de tipo «Time and Materials» o «llave en mano» con precio cerrado.

Se menciona cómo gestionar varios equipos ágiles, cuando se requiere la gestión de un portfolio o un programa se hace necesaria. En Scrum se desarrolla el «Scrum of Scrums«.

Es destacable la parte que habla de la relación entre proyectos ágiles y la PMO (Oficina de Gestión de Proyectos). La PMO ayuda a los equipos de proyectos a tener éxito. Y dado que la agilidad crea un cambio, por consiguiente, la PMO debe cambiar y debería perseguir ayudar a los equipos ágiles, una PMO ágil debería de ser una PMO que busque la satisfacción de los usuarios y compatibilizar este objetivo con ser un centro que busque la excelencia.

7 Llamada a la acción

La demanda de agilidad está incrementándose en todos los sectores, la cuestión es cómo enfocar los proyectos para que se aprovechen los beneficios de la agilidad. Y los autores son conscientes de que sus lectores pueden haber echado en falta más información. Precisamente por eso apuntan a seguir cubriendo este interesante tema en sucesivas entregas.

 

 

 

APÉNDICES:

El libro finaliza con una interesante selección de apéndices, entre los cuales destaca el Apéndice X3 Modelo para la Idoneidad del Enfoque Ágil, enfocado a determinar cuándo es mejor utilizar un enfoque ágil en los proyectos

CONCLUSIÓN:

¿Cuál es el objetivo de este libro? Se trata de buscar una aproximación e integración entre las metodologías predictivas y el mundo ágil. ¿Y cómo enfocar esa integración? Está claro que no se trata solamente de añadir más apartados al PMBOK que ya está en su sexta edición. Se trata de construir una versión unificada de ambos puntos de vista. Creo que, aunque se trate de metodologías muy diferentes, el Project manager deberá escoger la más adecuada que dependerá del tipo de proyecto de que se trate. Tan sencillo como que se aproveche lo mejor de cada una de ellas, es decir, la aproximación «híbrida» a la gestión de proyectos. Un Project manager que se precie, debería saber qué enfoque adoptar, en base a las características del proyecto. Una tendencia que se destaca después de una lectura del PMBOK 6 es que las diferentes metodologías empiezan a converger y cada una adopta lo mejor de las otras.

Es un libro hecho para ser leído por Project managers expertos en proyectos predictivos, que deseen conocer lo que les puede aportar el enfoque agile. A un experto en agilidad no le va a aportar nada nuevo.

Esta lectura me ha sabido a poco. Es un tema muy interesante y que tiene mucho recorrido por delante. Esperemos que no tarden en publicar más libros sobre esta temática.

REFERENCIAS:

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

ACTUALIZACIÓN DE 2018:

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

Este libro se puede obtener en estos dos sitios:

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

 

 

 

 

 

 

 

 

 

LIBROS SOBRE GESTION DE RIESGOS EN PROYECTOS

Dejar un comentario

Dado que uno de mis objetivos de este año a nivel de empresa es poner en marcha un sistema de gestión de riesgos en nuestra PMO (Oficina de Proyectos), me puse a explorar por Internet para ver material de apoyo y encontré estos dos libros de la autora Liliana Butchik que son objeto de la reseña.

La verdad es que me llamaron la atención, puesto que  no suele haber mucha literatura sobre este tema en idioma español.

Por eso los compré. Destaco que el único sitio donde pueden adquirirse «on line» es en la web de la autora, exactamente aquí: libros Secretos Riesgos en Proyectos

El envío tardó unos 15 días en llegar vía Correo Uruguayo y lo recibí sin problemas, lo mismo que otro libro que compré, «Secretos para Dominar el Portfolio de Proyectos» y del que más adelante escribiré su reseña.

El libro Secretos para dominar la gestión de riesgos sigue la metodología establecida por PMI acerca de la gestión de riesgos y está enriquecido por las experiencias personales de la autora, que trabajó en el staff de PMI USA

Destaco que tiene una sección de plantillas, pues se trata de un libro pero que muy práctico, cuyo objetivo es  ayudar a poner en marcha la gestión de riesgos en una empresa.

Sobre su nivel, está orientado a ser utilizado tanto por personas sin experiencia previa, como por profesionales que desean investigar más en alguna faceta particular del campo de la gestión de riesgos.

A destacar la parte referente a la sección de software orientada para gestionar riesgos. No es sencillo encontrar este tipo de información comparada.

Otro uso de este libro es para preparar la certificación de RMP-PMI. En este aspecto, se complementa  con el siguiente libro adquirido.

Secretos para salvar el examen RMP-PMI

Este libro tiene dos partes, de los capítulos 1 al 4 habla de qué es la certificación PMI-RMP, qué memorizar, qué dominio y habilidades requiere y una serie de consejos para afrontar con garantía el examen.

La segunda parte (capitulo 5) se corresponde a trescientas  preguntas, muy similares a las que se pueden esperar en el examen oficial de PMI.

Una  vez leídos ambos libros, destaco que me han gustado mucho, me ha interesado especialmente su enfoque práctico, es decir, que la lectura sea util.  Un gran valor añadido está en la experiencia aportada por la autora. Por sacarle alguna pega, pediría que las plantillas estuvieran disponibles para su descarga, (manteniendo su autoría) pues esto evitaría tener que elaborarlas manualmente una a una.  Pero mi experiencia leyendo los libros ha sido muy positiva. Me gustaría que hubiera disponible más material de esta calidad en idioma español.

Ah, y si la autora se decidiera a escribir sobre su experiencia gestionando proyectos bajo metodologías ágiles, ya tiene un ejemplar vendido.

 

 

 

 

 

 

 

 

 

 

MÉTODOS ÁGILES Y SCRUM

Dejar un comentario

Título original: Métodos ágiles y Scrum mays

Autores: Alonso Álvarez, Rafael de las Heras, Carmen Lasa

Editorial: Anaya Multimedia, año 2012, 350 páginas, 

ISBN: 978-84-415-3104-8

Palabras clave: metodología, proyectos, software, scrum, métodos ágiles

QUÉ ES:

En la empresa hemos comenzado a gestionar varios proyectos por medio de metodologías ágiles, así que me he comprado este libro para ver de qué va la moda de los métodos ágiles y en concreto de Scrum.

Una peculiaridad de este libro es que el prólogo lo firma Mike Breedle, unos de los firmantes del llamado » Manifiesto Ágil», del que ya hablaremos. además, para ser prácticos, utilizan la realización de este libro como ejemplo de proyecto realizado en Scrum

Entrando en materia, los autores destacan que el origen de los métodos ágiles se basó en la frustración del mundo informático de poder tener éxito cuando los requerimientos son indefinidos, es decir, en proyectos donde la incertidumbre de lo que se busca es alta, pues si el cliente tiene claros los requisitos entonces es mucho más adecuado optar por una metodología de proyectos clásica (en cascada o waterfall).  El cambio de paradigma que implica es adoptar el enfoque de señalar un presupuesto y una fecha de entrega y que el trabajo sea lo que se pueda hacer aplicando el principio de que el desarrollo será interactivo.

Scrum es solo uno de los muchos métodos ágiles que existen, aunque es sin duda el más popular.

Un resumen rápido del modo en el que se trabaja en Scrum es el siguiente:

  • Ante al solicitud de un proyecto, el Product Owner crea un equipo, solicita unos recursos y fija los primeros requisitos.
  • Desarrolla el Product Backlog con los trabajos detectados necesarios, que se compone de temas, épicas e historias.
  • Se debe dividir el trabajo en varios Sprints, que se agrupan en Releases o entregas.
  • El equipo de trabajo valora el esfuerzo implicado y traduce las historias en las que se compone el proyecto en unidades menores o tareas.
  • El trabajo se va realizando y se expone en la Daily Meeting.
  • Los impedimentos detectados van a a un Impediment Backlog y el Scrum Máster vigila que se resuelvan.
  • El final del Sprint lo señala la Review Meeting
  • En la reunión de Retrospectiva el equipo revisa lo realizado y lo que se ha hecho bien y lo mejorable.
  • Y vuelta a empezar.

Y esto es todo…

Vamos a verlo con un poco más de detalle.

VALORES:

  • Mejora continua
  • Calidad
  • Time Boxing
  • Responsabilidad
  • Multidisciplinar
  • Flexibilidad
  • Ritmo (latido)
  • Compromiso
  • Simplicidad
  • Respeto
  • Coraje
  • Foco
  • Predictibilidad
  • Personas

cambio-de-paradigma2

 

 

 

 

 

 

 

 

ROLES:

  • Product Owner:
    • Es el intermediario entre el cliente y el equipo. Es la voz del cliente.
    • Fija las fechas de entrega y prioriza los distintos requisitos
    • Mantiene la «visión» actualizada del producto o proyecto. La «visión» es un resumen de las metas a medio y largo plazo donde se quiere llegar. es muy importante por ello disponer de un «caso de negocio». La «visión» del producto implica:
      • Unas características básicas u obligatorias, que el producto debe tener
      • Unas características de rendimiento o lineales
      • Características inesperadas o emocionantes
    • Mantiene al día el Product Backlog. Describe los elementos, con las condiciones de aceptación y priorizadas)
    • Traduce los requisitos de negocio en elementos del Backlog (temas, épicas e historias)
    • Es quien acepta o rechaza las entregas de trabajo
    • Asiste  a la Review y al Planning
    • Es el responsable del éxito o fracaso del proyecto y de su ROI. Controla el presupuesto
    • Gestiona las expectativas del cliente y de los stakeholders
    • Qué no debe ser un PO: Que no tenga poder, que esté saturado de trabajo.
    • Hay una interesante historia acerca de los roles dentro de Scrum y de lo que es estar implicado y estar comprometido.  Pues bien, el PO tendría el rol de «cerdo», pues está totalmente comprometido con el proyecto
  • Scrum Manager:
    • No es un jefe de proyecto. No tiene autoridad formal ante el equipo.
    • Supervisa todo el proceso. No está subordinado al PO.
    • Es un experto en la metodología Scrum debe enseñar esta metodología a cada integrante implicado en el proyecto, preocupándose de poner la metodología en práctica de modo que se encuentre dentro de la cultura de la organización y así entregue las ventajas previstas, asegurándose de que cada uno siga las Reglas y prácticas de Scrum.
    • Pilota los Sprints.
    • Debe velar por la productividad del equipo.
    • Debe procurar que fluya la comunicación y la colaboración.
    • Analiza la velocidad del equipo y debe buscar la calidad
    • Los roles de Scrum Manager y Product Owner son muy diferentes y es incompatible con que sean la misma persona.
    • Último objetivo: no ser necesario
  • Equipo:
    • El equipo se debe auto organizar
    • Debe estar comprometido con el proyecto
    • Su responsabilidad es entregar el producto, en base a lo que existe en el Product Backlog
    • Los equipos autosuficientes, auto organizados y funcionales, tienen la responsabilidad, en cada iteración, de transformar el Product Backlog en un incremento en la funcionalidad del producto y planificar su propio trabajo para lograrlo.
    • Debería de elegir al Scrum Máster, porque es su representante. debe confiar en él.
    • Debería de tener dedicación suficiente y continuada
  • Coach:
    • No es una figura obligatoria
    • Es un formador y mentor. Elabora las guías de actuación.

EL PROCESO:

  • Lo primero de todo, el Sprint Cero: 
    • Es responsabilidad del Product Owner
    • El él se define la misión, herramientas y el equipo
    • El objetivo es definir las condiciones y el contenido del trabajo
    • De esta forma se establece la primera versión del Producto Backlog
    • También se elige la duración de cada sprint y el calendario de releases o entregas
  • Sprints:
    • El Sprint Backlog contiene aquello que se llevará a cabo en cada sprint.
    • Hay tres etapas:
      • Sprint Planning, donde se realizan los criterios de aceptación y la valoración de los trabajos
      • Daily Meetings. Reunión diaria donde se revisa de forma rápida qué se hizo, que se va a hacer y los problemas encontrados
      • Review.
    • Sesión de Retrospectiva. Los resultados obtenidos en el sprint o fase se valoran aquí. Es una mirada al pasado para mejorar el futuro.

scrum de un vistazo

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ENTIDADES:

  • Tareas
  • Historias de usuario.
  • Épicas. Son agrupaciones de historias

ARTEFACTOS:

  • Product Backlog:
    • Es la lista de requerimientos. Los requisitos del sistema o del producto desarrollado se enumeran en el Product Backlog. Es responsabilidad del PO.
    • No contiene todos los requisitos. Cualquiera puede crear requisitos, es si, requieren de la aprobación del PO. El Backlog es dinámico
    • Tipos:
      • Funcionales. Son las Historias de Usuario.
      • No funcionales. Son las cualidades que debe tener el producto.
    • El nivel de detalle debe ser alto para los requisitos prioritarios y no tanto para el resto.
    • Estructuración:
      • Temas
      • Épicasscrum_2-4_week
      • Historias de Usuario
      • Tareas
    • Características de un buen Product Backlog:
      • Card. Deben caber en una tarjeta
      • Conversation. Deben ser resultado de conversaciones
      • Confirmation. Deben ser fácilmente confirmables
      • Con historias de usuario bien definidas
    • El mejor producto Backlog debe ser DEEP: Detallado, Emergente, Estimado, Priorizado
    • Es una lista ordenada por prioridad, esta tarea de priorización es del PO, pero el equipo le debe ayudar.
    • Técnicas de priorización del Product Backlog:
      • Priority Poker
      • Moscow (Must, Should, Could, Won’t)
      • Kano
      • Criba de temas
      • Puntuación de elementos
      • Posibles problemas del Product Backlog:
        • Es muy grande y detallado. Encubre una especificación de requisitos encubierta. En este caso no se debería de trabajar con Scrum
        • Historias de usuario siamesas. Encubre un problema con las dependencias. Se debería de dividir en partes más pequeñas y hacer historias de usuario conjuntas.
        • No se cierran las Historias de Usuario. Encubre un problema con las tres C’s: Card, Conversation, ConfirmationExample_Sprint_Task_Board
        • Infección Operativa. Si se dice cómo hay que hacer las cosas y no lo que hay que hacer. Se deben eliminar del PB las tareas operativas
        • Plaga de requisitos. Es síntoma de que el PB se está usando como una lista de peticiones.
        • No hay requisitos no funcionales. El PB no está completamente definido. Solución: prestar atención tanto a las Historias de Usuario como a los requisitos no funcionales
        • Inmunización tardía. Se deben priorizar todos los elementos sobre los que se tengan incertidumbres para poder trabajar sobre ellos. Si esto nop se hace pronto, luego será un problema
        • Muerte dulce por contrato. Si el PB funciona como un contrato con el cliente. El PB no es un acuerdo formal con el cliente.
        • No se debe consentir que el PO delegue la gestión del Product Backlog en el Scrum Master o en otra persona
  • Sprint Planning:
    • Los sprints son fijados en el Sprint 0. En el Sprint Planning el equipo junto con el PO y el SM planifican los sprints.
    • Cada Sprint se divide en:
      • Planificación del contenido del sprint
      • Desarrollo del trabajo
      • Revisión de los resultados
    • Se deben establecer los límites temporales adecuados (time boxing)
    • Se debe garantizar que el objetivo, mecánica y resultados sean conocidos
  • Sprint Backlog:
    • Son los trabajos a realizar durante un determinado Sprint
    • Es propiedad del equipo, que es quien lo gestiona y actualiza.
    • Su contenido es mucho más detallado y debe de disponer de una definición de lo que se debe alcanzar para poder saber cuándo se ha alcanzado el resultado
    • Dimensiones:
    • Prioridad
    • Detalle
    • Estado.  Será pendiente, en curso, terminado, impedida (se documenta y se asigna)
    • El Tablero de Tareas permite visualizar cómo va el sprint
  • Impediment backlog:
    • Es una lista de incidencias que tienen que ser resueltas por el equipo y que el Scrum Máster debe gestionar y asignar al alguien para que trabaje en ellas, y que será revisada en la reunión Scrum diaria
  • Burndown Chart.
    • Mide la evolución del trabajo. Lo mantiene el Scrum Master

MECÁNICA DE TRABAJO:

  • El PO lee la primera historia de usuario junto con su criterio de aceptación. los miembros del equipo le asignan «Story points» y se suman hasta que alcancen la velocidad media del equipo (si se sabe). Estas historias deben ser divididas en tareas.
  • El compromiso del equipo es muy importante. Por eso no se aceptan presiones del PO. La calidad debe ser el criterio que debe primar
  • La cantidad de historia de usuario cerradas por el equipo según el Product Owner es el valor de la velocidad real de ese equipo
    • el valor de la complejidad, dificultad o cantidad de trabajo se mide en story points
    • También puede medirse la velocidad por días ideales que se requerirían para hacer esas historias.
    • O también se podría poner un porcentaje, un focus factor.
  • La estimación es una acción colectiva. Puede usarse el Planning Poker
  • Si la estimación coincide se acepta, si no, se discute sobre ello.
  • Sumando todos los story points se obtiene la velocidad estimada de la iteración.
  • El seguimiento del cumplimiento se realiza a través de la  Burndown Chart

PILOTANDO EL SPRINT:

El Scrum Master:

  • No tiene poder real
  • No es el jefe del proyecto
  • Es un facilitador
  • No está subordinado al Product Owner
  • No persigue a los demás
  • Cometido: velar por el seguimiento de los principios del Scrum
  • Cómo lo hace:
    • Velando por la productividad del equipo
    • Procurando que fluya la comunicación y la colaboración
    • Responsable de introducir y fomentar las prácticas ágiles
    • Supervisa el backlog
    • Analiza la velocidad
    • Es el intermediario entre el mundo exterior y el equipo de trabajo
    • Es responsable de la formación del equipo
  • Muy importante: es incompatible que una sola persona sea el PO y el SC
  • Objetivo último: no ser necesario

Planificación detallada:

  • Objetivo: pasar las historias de usuario a unidades más manejables, como son las tareas
  • En esta tarea no se necesita al PO
  • La tarea es una descripción simple de lo que se va a hacer. No es validable

Mantenimiento del backlog, el grooming:

  • Es muy recomendable hacerlo mucho antes de cada planificación del Sprint Backlog
  • El PO revisa el product Backlog para depurarlo.
  • Es un trabajo continuo y puede asistir todo el equipo.

 DESARROLLO DEL SPRINT:

  • Duración de los sprints. es mejor que sean cortos al inicio o en actividades poco definidas o si el equipo es inmaduro
  • Frecuencia de los releases: es responsabilidad del PO
  • Aspectos del sprint: estabilidad, obtención de resultados, mejora continua, anticipación

Quien lo lleva a cabo: el equipo de trabajo:

  • Características: diversificado, autónomo, auto organizado, responsable, sin jerarquías o niveles, estable y dedicado
  • Responsabilidades:
    • Realizar el trabajo del proyecto
    • Identificar formas de mejorar su productividad, junto con el SC
    • Hacer la estimación de los elementos del backlog
    • Dividir las historias en tareas
    • Comprometerse a realizar una lista de historias en cada sprint
  • Dimensión del equipo: sobre 4 a 10 miembros
  • Es muy recomendable la proximidad física

La Daily Meeting:

  • Lo realizan el equipo y el SC, que no la dirige.
  • El PO puede asistir o no.
  • Contenido:
    • Qué se ha hecho
    • Qué se hará
    • Impedimentos

Backlog de impedimentos:

  • Recoge todo lo que impide alcanzar los objetivos
  • Se recogen los impedimentos, se describen y se asignan a un responsable
  • Es gestionado por el SC
  • Deben priorizarse

Sprint Review:

  • También llamado Customer Sprint Review
  • Se revisa qué se ha hecho y como se ha hecho
  • Finalidad:
    • Recoger comentarios
    • Recoger la aceptación de las tareas seleccionadas
    • Analizar si se necesitan mejoras en el trabajo realizado o si se precisan nuevos items
    • Pueden acudir personas de fuera del equipo
  • Posibles problemas:
    • Cambiar la fecha de la reunión frecuentemente
    • Que sea una presentación de resultados
    • Que se trabaje solo para el sprint review
    • Foco en los items del backlog y no en los objetivos
    • Desviación del propósito de la reunión por los asistentes
    • Convertir la review en una reunión de aprobación de requisitos
  • La mejor práctica:
    • Establecer normas y reglas.
    • Repasar los objetivos
    • Recapitulación del PO sobre lo finalizado y no finalizado
    • Revisión por el equipo de estadísticas y métricas

La retrospectiva:

  • Objetivo: mejorar la forma de trabajar de forma más efectiva
  • Debe concluir con las acciones de mejora que deben implementarse
  • Cuando: al final de un sprint, después de un release y al final del proyecto
  • Etapas: que se hizo bien, que se debe mejorar, que se va a hacer en la nueva iteración
  • Consejo: se debe ser positivo y debe haber un moderador (el SM)

LOS SCRUM BUTS:

  • Son malas prácticas. Se debe diferenciar entre Scrum Ands, que son modificaciones positivas, y Scrum Bad, que son modificaciones negativas
  • Los Scrum Buts exponen una disfuncionalidad que hay que solucionar. La culpa no es de Scrum.
  • Top 10 de Scrum Buts:
    1. No hacemos reuniones de fin de sprint
    2. No se eligen voluntariamente las tareas. Ojo esto es micro gestión
    3. No hacemos mejoras o corrección de problemas porque hay demasiadas funcionalidades que implementar.  A esto se le llama la Death March
    4. No hacemos retrospectivas. Esto puede ser un síntoma de que hay conflictos internos en el grupo
    5. No hacemos reuniones diarias ya que nos las necesitamos
    6. El Scrum Master y el Product Owner son la misma persona. Ojo, son roles que consumen mucho tiempo y que son incompatibles porque sus atribuciones pueden entrar en conflicto
    7. Usamos Scrum pero no hacemos el diseño, la implementación y las pruebas de cada historia de usuario en el mismo sprint, porque no os da tiempo a llevar a cabo todas estas tareas en el mismo sprint y las hacemos en sprints consecutivos. esto puede tener dos causas: el equipo no está estimando bien las historias de usuario y el product backlog no está suficientemente trabajado
    8. No se hacen iteraciones cortas porque todo está claro y las hacemos cada 3 meses. Entonces, ¿Por qué se usa Scrum? Puede ocultar disfuncionalidades
    9. No hacemos reuniones diarias porque no está el Scrum Master. Ojo, esto no es un reporte
    10. Nosotros no lo llamamos Srum pero ya estábamos haciendo todas esas cosas.

¿Cómo detectar Scrum Buts?. Con el método de los 5 porqués (Un ejemplo. ¿Por qué no asiste el SM al Daily Meeting del proyecto? –> Porque está muy ocupado. ¿Por qué está tan ocupado? —> Porque gestiona muchos proyectos— > ¿Por qué gestiona muchos proyectos? —> Porque no hay más SC en toda la empresa…)

En fin. la teoría del método Scrum es muy sencilla. Pero hacerlo bien es muy difícil.

GESTIÓN DE PROYECTOS EN EL MUNDO REAL

Dejar un comentario

Título original: Your Project Management Coachbiafore

Autores: Bonnie Briafore, Teresa Stover

Editorial: Anaya Multimedia/ Viley, año 2012, 448 páginas

ISBN: 978-84-415-3225-0

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

No hay muchos libros en el mercado que traten el tema de la gestión de proyectos, así que este libro me llamó mucho la atención cuando lo vi. Le eché un  vistazo y decidí comprármelo. Eso si, lo compré a pesar de que se trata de otro caso de cambio del titulo original por otro que no tiene nada que ver.

El libro me lo leí antes de que me examinara para obtener la certificación PMP del PMI. Ahora lo hubiera leído con otra actitud.

Se tata de un libro dirigido a personas con algunos conocimientos previos de gestión de proyectos. Al principiante le va a resultar un poco difícil entender algunos conceptos que se presuponen en ese libro. Lo escribe una persona que es PMP y que tiene

El libro se divide en las mismas partes que los grupos de procesos del PMBOK:

  • La Parte I está compuesta de una introducción de lo que es y lo que no un proyecto, así como qué es gestionar un proyecto.
  • La Parte II se refiere a la planificación y nos habla de qué es un plan de proyectos,cómo identificar los trabajos de un proyecto, cómo estima trabajos y costes, cómo planificar recursos, cómo establecer el cronograma, cómo gestionar la calidad, escribir el Plan de Comunicación, el plan de gestión de cambios, los riesgos
  • imagesLa Parte III está dirigida a los procesos de ejecución
  • La Parte IV habla de la monitorización y control
  • La Parte V  se refiere al cierre. Incluye cómo documentar el proyecto y cómo cerrarlos.

Una de cal, lo mas flojo de todo el libro es el capítulo Nº 13 (Parte II) que habla de la puesta en marcha y que describe la obtención de aprobación, seleccionar el equipo y eventualmente, seleccionar al proveedor.

Y otra de arena, en el capítulo Nº 8 (Parte II) se habla del calendario y de la ruta crítica, y menciona la idea de que el diagrama Gantt no es el proyecto. Esta es una gran verdad que ha hecho mucho daño a muchos proyectos.

Como información extra, también contiene ideas acerca de cómo crear una PMO en una empresa y los motivos por los cuales es una buena decisión.

Destaco que dentro de los capítulos hay excelentes anotaciones que son fruto de la experiencia y que hacen mas valioso el contenido, por ejemplo, el autor destaca que las «Lecciones aprendidas» es una de las partes más importantes de la gestión de los proyectos, pero que hay que ser muy cuidadoso para que los objetivos o incentivos del Project Manager y del equipo no impacten con ellas, pues de otra forma nos encontraríamos con una simple descripción de lo bien que se realizó el proyecto, eludiendo cualquier tipo de análisis o crítica.

Otro detalle a destacar, menciona  lo que son preguntas específicas del examen PMP, por ejemplo, las fases en el desarrollo de un equipo de trabajo de Bruce Tuckman. Pero hay que hacer una advertencia, con este libro no es suficiente para prepararse para el examen PMP . Hace falta bastante más material adicional para poder tener éxito en el examen.

Muy interesantes y aprovechables son las plantillas para obtener soporte a las tareas habituales de gestión del proyecto, que se ofrecen para ser descargadas directamente de la web de Anaya Multimedia.

Es de agradecer que es un libro claro, conciso y escrito con un lenguaje que todo el mundo puede entender.

Como conclusión, un libro muy recomendable para profundizar en el mundo de la gestión de proyectos.

Valoración: 8/10