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.

 

LIBRO: BAILANDO EL VALS CON OSOS (GESTIONANDO RIESGOS EN PROYECTOS DE SOFTWARE)

Título original: Waltzing with Bears, Managing Risks on Software Projects

Autores: Tom de Marco, Tim Lister

Editorial: Addison-Wesley Professional

Idioma: inglés

ISBN: ‎9780932633606

Páginas: 207

Palabras clave: Proyectos, gestión de riesgos

RESUMEN

Excelente libro y un clásico de la gestión de riesgos. Un poco desactualizado (lógico por la fecha de su publicación en papel, año 2003) pero con un planteamiento valiente que se opone al optimismo de los directivos que no quieren escuchar malas noticias. Si te gusta el tema de la gestión de riesgos en proyectos debes leerlo. Para ser un libro sobre un tema que puede parecer árido, es bastante divertido de leer y las páginas se pasan volando.

¿Por qué molestarse en hacer gestión de riesgos? El riesgo siempre está ahí, así que es necesario administrarlo, en lugar de ignorarlo. El riesgo es un posible evento futuro que conducirá a un resultado no deseado (un problema). Los riesgos no gestionados que se materializan en problemas son muy costosos, tanto para la empresa como para las personas. Pero un buen proceso por sí solo no es suficiente para mitigar los riesgos. La gestión de riesgos proporciona muchos y grandes beneficios en la gestión de proyectos.

Los viejos estilos de gestión son incompatibles con la gestión de riesgos. Es probable que se fracase si el Project mánager lo hace solosin la ayuda del equipo y de la organización. Está reñido con la gestión para el éxito porque no se pueden gestionar los riesgos; siempre están ahí. La gestión de riesgos es incompatible con la cultura si se tolera el fracaso, pero no la incertidumbre. Contar con golpes de suerte no es gestión de riesgos. Se pueden ignorar los riesgos cuando la probabilidad de materialización es lo suficientemente pequeña, cuando no puede hacer nada al respecto si sucede, o si hay consecuencias mínimas o se trata del riesgo de otra persona.

¿Cómo abordarlo? Hay una prescripción de 9 pasos (actualizada a 18 pasos más adelante) para descubrir, administrar y monitorizar el riesgo. Se debe averiguar cuáles se evitarán, aceptarán, mitigarán o se evadirán. Se deben calcular los costos de exposición, contención y mitigación. Se deben cuantificar las incógnitas generando ventanas de incertidumbre basadas en el desempeño anterior (o, en el peor de los casos, usando conjeturas).

 

Existen programas u hojas de Excel para analizar los riesgos causales y agregados. El modelado también puede simular estos riesgos.

Las reservas de riesgo son el tiempo y el dinero que reserva para contener los riesgos. Se debe tratar de pensar en el riesgo como una distribución de probabilidad (gráficos) en lugar de un solo número.

Se deben descubrir los riesgos haciendo una lluvia de ideas sobre catástrofes, retrocediendo hasta los escenarios y luego haciendo un análisis del tipo causa raíz.

Se deben supervisar los indicadores de transición (el riesgo se convierte en un problema), descubriendo siempre los riesgos, recopilando datos y realizando un seguimiento de la finalización del proyecto.

Los riesgos comunes de los proyectos de software suelen ser: errores en el cronograma, inflación de requisitos, rotación, fallos en las especificaciones, bajo rendimiento.

Un mandato: comienza los proyectos temprano, los proyectos que terminarán tarde son casi siempre proyectos que empezaron demasiado tarde, sentencia el autor del libro. Todo el mundo sabe esto, pero esta idea no se lleva a la práctica.

¿Cuánto riesgo debería estar dispuesta a asumir nuestra organización? No puede simplemente orientarse a los beneficios potenciales. Sin precisión aquí, no puede cuantificar el ROI o administrar el riesgo de manera efectiva. En lugar de mirar el costo/beneficio agregado (es decir, todo el proyecto), se debe mirar los componentes para poder clasificarlos en consecuencia. Se debe comparar la incertidumbre de costo/horario con la incertidumbre de beneficio para evitar cortejos fúnebres en el proyecto.

Existe un proceso de 18 pasos para administrar el riesgo y mantener el flujo de información.

¿Cómo sabemos si la gestión de riesgos está funcionando? Si se cumplen al menos 6 de los 9 pasos que se enuncian en la Parte V del libro.

EN DETALLE:

PARTE I: POR QUÉ…

Correr hacia el riesgo.

La declaración de los autores del libro es clara: “Si un proyecto no tiene riesgos, no lo hagas”. Si no hay riesgo, es probable que tampoco haya muchos beneficios. Las empresas que huyen del riesgo y se centran en lo que pueden hacer bien están cediendo el terreno a sus adversarios. Por ejemplo, Merrill Lynch llegó con una década de retraso a las capacidades de negociación en línea creadas por sus competidores.

Una metáfora, la escalera de riesgo de Bob Charette:

  • Tú y tus competidores formáis un conjunto de escaleras mecánicas descendentes
  • Cada empresa tiene que subir (moviéndose contra la corriente)
  • Si te caes, estás fuera del juego
  • Todo el mundo (incluidos los nuevos competidores) comienza a medio camino (es decir, potencialmente por delante de usted)
  • Quien llega a la cima de su escalera mecánica controla una palanca que cambia la velocidad de todas las escaleras mecánicas

La enseñanza de todo esto es que, a veces, adoptamos una actitud de “sí se puede” para ignorar los riesgos; mantenernos positivos significa que nos negamos a mirar el lado negativo. Esto es infantil, por decirlo suavemente.

La gestión de riesgos es la gestión de proyectos para adultos.

A los niños se les puede disculpar de pensar en lo que puede ir mal en el mundo, pero los adultos deben tener en cuenta esas cosas para mantenerse a salvo ellos mismos y a los niños. Es decir, tomar nota explícita de las cosas negativas que pueden ocurrir (riesgos) y planificarlas en consecuencia es una señal de madurez.

Los autores nos recuerdan algunas nociones básicas de gestión de riesgos:

  • Qué es un Riesgo: un posible acontecimiento futuro que conducirá a un resultado indeseable.
  • Qué es un Problema: el riesgo se ha materializado. La gestión de riesgos es el proceso de pensar en acciones correctivas antes de que ocurra un problema, cuando todavía es una abstracción. Lo contrario de la gestión de riesgos es la gestión de una crisis, que consiste en intentar averiguar qué hacer con el problema después de que se produzca.
  • Transición del riesgo: el acontecimiento desencadenante que convierte un riesgo en un problema
  • Indicador de transición: lo que ves que te muestra que la transición está ocurriendo
  • Mitigación: medidas que se toman para mantener las opciones y hacer posible una corrección posterior

Componentes de la gestión de riesgos:

  • Descubrimiento de riesgos: lluvia de ideas y clasificación de lo que podría salir mal
  • Análisis de la exposición: determinar la probabilidad de que se materialice y el impacto potencial
  • Planificación de contingencia: lo que se espera hacer cuando el problema existe
  • Mitigación: pasos a seguir antes de la transición para que los planes de contingencia sean efectivos
  • Supervisión continua de la transición: seguimiento de los riesgos gestionados; búsqueda de su materialización

Reconsideración del aeropuerto internacional de Denver.

Escenario: La inauguración de un nuevo aeropuerto de Denver estaba prevista para octubre de 1993, pero acabó con 500 millones de dólares de presupuesto y 2 años de retraso. La culpa la tuvo el retraso del software del sistema automatizado de gestión de equipajes, ya que el aeropuerto se diseñó de tal manera que, sin este sistema, el aeropuerto no podía funcionar. Ni el proceso de construcción más perfecto puede eliminar la incertidumbre de un proyecto de desarrollo de sistemas complejos. Donde hay incertidumbre, hay riesgo. Donde hay riesgo, hay que hacer un esfuerzo consciente y reflexivo para gestionarlo.

En lugar de preguntar por los fallos del proceso de creación de software, es mejor preguntarse por la gestión de riesgos:

  • ¿Por qué no se puede abrir el aeropuerto sin este software?
  • ¿Por qué este sistema estaba en la ruta crítica?
  • ¿No había alternativas para trasladar el equipaje?
  • Cuando el sistema se retrasó, ¿por qué el aeropuerto no pudo utilizar alternativas? ¿Podría el aeropuerto haber sido diseñado para soportar alternativas (porque no lo fue)?
  • ¿No se podía haber preparado antes los diseños alternativos?
  • ¿No se consideraba la tardanza del sistema como un riesgo?
  • ¿No se han retrasado antes los proyectos de software?
  • ¿Existen antecedentes de sistemas similares implantados en otros aeropuertos?
  • ¿Se estudiaron otros sistemas?
  • ¿Siguió la dirección del aeropuerto los consejos de otros que lo intentaron?
  • El equipo de software le advirtió de la tardanza, ¿por qué no les hizo caso?

La responsabilidad de la gestión de riesgos recae en quien tenga que pagar el precio de los riesgos que se ignoran. Así de claro.

El caso de la gestión de riesgos.

La cultura empresarial suele hacer “promesas imposibles”, como los plazos, y en lugar de oponerse, los Project Managers dicen que si se puede hacer y cruzan los dedos. Los gestores de proyectos suelen decir que sus clientes no harían ningún proyecto si entendieran el lado negativo. Así que se limitan a ocultar el riesgo y a compartir las malas noticias poco a poco, a medida que se producen. Tu disposición a comprometerte con un proyecto arriesgado es una función directa de lo bien que puedes concluir lógicamente que los riesgos han sido evaluados, cuantificados y afrontados.

Prepara los proyectos para el éxito:

  • ¿Se trata de objetivos ambiciosos o de expectativas razonables?
  • La gente tiene poco aguante para el trabajo que les lleva de un fracaso a otro. El coste en moral, agotamiento y poca retención de los empleados es considerable.

Buenas prácticas:

  • Limita la incertidumbre (con una incertidumbre ilimitada, la gente tiene aversión al riesgo o es temeraria; ninguna de las dos cosas es buena)
  • Proporciona una protección a la baja de mínimo coste (reserva de riesgo: tiempo y dinero que puede no necesitar)
  • Protege contra las transferencias invisibles de responsabilidad
  • Maximiza la oportunidad de crecimiento personal (sin nuevas direcciones es equivalente a sin crecimiento)
  • Evita que la dirección se vea sorprendida (normalmente hay algún aviso antes de que se produzca un problema)
  • Centra la atención donde se necesita

PARTE II: POR QUÉ NO…

El caso contra la gestión de riesgos.

La gestión del riesgo va en contra de ciertos estilos de gestión (contraproducentes) que todavía se practican. La mayoría de ellos son mecánicos y los siguen personas que no saben gestionar bien: dirección por objetivos, programación parkinsoniana (el trabajo se expande al tiempo asignado), “cultura del miedo”, etc.

Argumentos típicos contra la gestión de riesgos:

  • Nuestras partes interesadas no pueden afrontar el riesgo:
    • Pero… mentir a la gente no es sostenible
  • Hay demasiada incertidumbre:
    • Pero… ignorar la incertidumbre conduce a la ilusión de control:
  • La incertidumbre excusa los malos resultados:
    • Pero… utiliza los objetivos para que la gente se esfuerce por obtener el mejor rendimiento
  • “Gestionar para el éxito” es mejor:
    • Pero… no puedes gestionar el riesgo de tu proyecto; es inherente
  • No hay suficientes datos para gestionar el riesgo de forma eficaz:
    • Pero… probablemente tenga algunos para riesgos comunes

La gestión de riesgos aislada es peligrosa. Esto es absolutamente cierto. Se necesita el apoyo de los demás, de lo contrario se crea una cultura en la que la gente aprende que es más importante prometer a lo grande que cumplir con lo prometido. Y esta es una dinámica peligrosa.

El peso de la incertidumbre.

Una premisa: “Si tu cultura corporativa no te permite admitir la incertidumbre, no puedes hacer gestión de riesgos”. (También conocida como “Está bien equivocarse, pero no está bien no estar seguro de las cosas”). Por ese motivo se produce la miopía selectiva: sólo se centra en los riesgos que quiere ver (en lugar de los desastres en los que no quiere pensar)

Para ser eficiente en tus proyectos imagina tus peores pesadillas, no tus pequeñas preocupaciones; para descubrir los riesgos que realmente importan a tu proyecto, rastrea hacia atrás desde el efecto hasta la causa. Vigílalo todo.

Suerte.

Cosas que hacen que no merezca la pena gestionar un riesgo (por ejemplo, que nos caiga un asteroide):

  • La probabilidad de materialización es lo suficientemente pequeña como para ignorar si se materializa, lo que estamos construyendo ahora es irrelevante
  • El riesgo tiene unas consecuencias mínimas y no requiere mitigación
  • El riesgo es de otra persona

Si la planificación de su proyecto consiste en tener golpes de suerte, esto no es gestión de riesgos. Los proyectos que empiezan como retos personales rara vez tienen sus riesgos gestionados de forma sensata. Dependen más bien de la suerte.

Cuando aprovechas todas las oportunidades para ganar, puedes elevar las consecuencias de perder, mucho más allá de lo necesario.

PARTE III: CÓMO…

Cuantificación de la incertidumbre.

Si no hay posibilidad de cumplir el plazo previsto, no puedes quedarte ahí. ¿Cuál es la fecha en la que es probable que lo hagas (aunque sea en el futuro) y cuál es la fecha en la que es probable que lo hagas en un 50%?

Los diagramas de riesgo ayudan a cuantificar la incertidumbre.

“La patología de fijar un plazo a la primera fecha articulable garantiza esencialmente el incumplimiento del calendario”. ¿Cuántas veces hemos vivido esto en nuestros proyectos?

La prueba de que una organización es adulta a nivel de riesgos es que los directivos de todos los niveles aprenden a vivir con compromisos que tienen límites de incertidumbre explícitos.

Fecha de nano-porcentaje (N) — la primera fecha con una probabilidad no nula de entrega (cualquier fecha anterior tiene 0% de probabilidad)

Como industria, se nos anima a mantener pequeñas ventanas de incertidumbre. Los resultados anteriores pueden ayudar a calcular la ventana.

Algunos estudios demuestran que el tamaño de la ventana es del 150-200% de N (por ejemplo, ¿se ha programado el parto para el mes 25? Es posible que tenga que llegar hasta el mes 75 para estar totalmente seguro)

Mecánica de la gestión de riesgos.

La mayoría de los gestores de proyectos de software hacen un trabajo razonable de predicción de las tareas que hay que hacer y un mal trabajo de previsión de las tareas que podrían tener que hacerse. Utilizar las retrospectivas de los proyectos/lanzamientos anteriores como punto de partida para el riesgo de los proyectos/lanzamientos futuros es una práctica excelente.

•Lo que se puede hacer con respecto al riesgo, las respuestas al riesgo:

  • Evitar. Implica no hacer un proyecto o parte del proyecto que tenga riesgo
  • Aceptar. Prepararse (tiempo y dinero) para pagar el riesgo en caso de que se materialice
  • Mitigar: Tomar medidas para reducir los costes del impacto
  • Evadir. Esto es básicamente cruzar los dedos y pedir tener suerte

Por regla general, no hay contratos que transfieran con éxito toda la responsabilidad a una sola parte. Si usted es cliente o contratista, espere tener que hacer alguna gestión de riesgos.

La exposición al riesgo es igual al coste por la probabilidad. La evaluación de la exposición no es una ciencia bien definida. La mejor conjetura sobre la materialización probable puede provenir de los datos de la industria, las listas de problemas anteriores, el repositorio de riesgos o simplemente una conjetura. No te excuses de este acto esencial sólo porque cualquier respuesta que se te ocurra nunca será demostrablemente correcta.

El Riesgo de bloqueo es un riesgo que, de materializarse, acabaría con el proyecto o incluso con la empresa; estos riesgos están más arriba en el organigrama que el proyecto, y en el nivel del proyecto debe asumirse que no existen. La Reserva de riesgos son un tiempo y dinero reservados para contener los riesgos.

El Coste de contención: tiempo y dinero necesarios para hacer frente a un riesgo materializado. El coste de mitigación es el tiempo y dinero necesarios para reducir el riesgo; debe compensarse con la reducción del coste de contención, de lo contrario no merece la pena.

Para cada riesgo gestionado, debe haber uno o más indicadores de materialización; vigila de cerca que se produzcan.

Prescripción de la gestión de riesgos.

1. Descubrir los riesgos y anotarlos

2. Asegúrese de que los riesgos típicos de los programas informáticos también se anotan

3. Para cada riesgo…

a. Asignar un nombre y un identificador únicos

b. Encontrar un indicador de transición

c. Estimar el impacto del coste/calendario si se materializa

d. Estimación de la probabilidad

e. Calcular la exposición a los costes y al calendario

f. Definir las acciones de contingencia en caso de que se materialice

g. Añadir acciones de mitigación al plan del proyecto

4. Designar los obstáculos como hipótesis del proyecto (aumentar el riesgo)

5. Determinar la fecha del nano porcentaje (N), suponiendo que no se materialicen los riesgos

6. Construir un diagrama de riesgo que involucre a N

7. Expresar los compromisos mediante diagramas de riesgo con ventanas de incertidumbre

8. Supervisar los riesgos (ejecutar planes de contingencia si es necesario)

9. Seguir descubriendo los riesgos a lo largo del proyecto

• N no es una fecha a la que te comprometes; es sólo una entrada en el proceso de encontrar algo mejor a lo que comprometerse

• N < fecha objetivo < fecha de entrega prevista

• Si se fija la fecha de entrega, la incertidumbre se centra en lo que se va a entregar.

• La implementación incremental (por ejemplo, Agile) ayuda.

• Haga público su registro de riesgos para que otras partes interesadas puedan hacer un seguimiento y para que nadie se sorprenda.

Volver a lo básico.

La gestión de proyectos requiere respuestas a cosas como “cuándo terminará el proyecto “, o “aceptará el usuario nuestro producto”, etc. Si tu respuesta es “no lo sé”, acabas de identificar un área de riesgo. Ya estás tardando en gestionarlo.

Diagrama de incertidumbre: gráfico de barras con los resultados en el eje de las abscisas y la probabilidad de ocurrencia en el eje de las ordenadas; también se puede presentar como un gráfico del acumulado.

Riesgo: patrón ponderado de posibles resultados y sus consecuencias asociadas; esta definición deja de pensar en el riesgo de forma numérica y se asemeja más a una distribución de probabilidad (gráfico).

Riesgo causal: riesgo relativo a un componente

Riesgo agregado: riesgo para el proyecto en su conjunto (alimentado por los riesgos causales) • Puede construir modelos de riesgo para el riesgo causal/componente y utilizarlos para modelar el riesgo del proyecto.

Herramientas y procedimientos.

Si tienes distribuciones de riesgo para determinadas variables, puedes combinarlas con modelos y muestreos. También puedes obtener probabilidades de certeza en un espectro (por ejemplo, ¿Cuánto tiempo me llevará esto en el que puedo estar seguro de acertar en un 75%?)

Riesgos principales de los proyectos de software

Riesgo principal N.º 1 – Fallo de calendario

  • Tendencia a equivocarse en el tamaño del producto a construir
  • La alta dirección no suele culpar al calendario, sino a los creadores del mismo
  • En los proyectos típicos, hay un 50% de posibilidades de que el calendario se sobrepase en un 30%.

Riesgo básico N.º 2 – Inflación de los requisitos

  • “Una cosa de la que puedes estar seguro es que el dominio no va a permanecer estático durante el proceso de construcción”.
  • Para los proyectos típicos, hay un 50% de posibilidades de que su calendario se sobrepase en un 7% debido a esto.

Riesgo principal N.º 3 – Rotación

  • Es necesario conocer el porcentaje medio de rotación anual del personal técnico y el tiempo de preparación de un sustituto (número de meses para reemplazar efectivamente a alguien que se ha ido).
  • Para los proyectos típicos, hay un 50% de posibilidades de que su calendario se sobrepase en un 4% debido a esto.

Riesgo principal N.º 4 – Ruptura del pliego de condiciones

  • Aquí es donde la gente no se pone de acuerdo sobre qué producto construir. “Aunque es posible especificar un producto de forma ambigua, no es posible construir un producto de forma ambigua”.

Riesgo principal N.º 5 – Falta de rendimiento

Dado que hay un espectro en todo el equipo, y que otros riesgos tienen un impacto más fuerte que éste, la probabilidad de que esto afecte al calendario es muy baja.

Un proceso definido para la detección de riesgos.

La cultura corporativa empresarial típica desalienta a las personas que hablan negativamente de un proyecto, sólo quiere oír hablar de los problemas siempre que tengan soluciones a mano, o hace que las personas que hablan de ciertos problemas se conviertan en responsables de estos. Tal cual.

Piense en resultados catastróficos, trabaje hacia atrás para encontrar las situaciones que podrían conducir a esos resultados, y luego trabaje hacia atrás para identificar las causas fundamentales de esas situaciones (que ahora son sus riesgos).

El descubrimiento del riesgo no se produce una sola vez; es un proceso continuo.

Paso 1: Lluvia de ideas sobre la catástrofe

  • Enmarcarlo en términos de una pesadilla
  • ¿Cuáles serían los titulares de las noticias?
  • Cuáles son los mejores sueños, entonces invierte ¿Cómo puede fracasar el proyecto y no ser culpa de nadie ¿Cómo puede fracasar el proyecto y ser culpa nuestra? ¿Qué aspecto tiene el fracaso parcial?

Paso 2: Construcción del escenario

  • Explica los escenarios que conducen a las catástrofes
  • Adjunte también una probabilidad

Paso 3: Análisis de la causa raíz

Del modelo de proceso en espiral Win-Win de Barry Boehm… Haga que todas las partes interesadas definan las condiciones de victoria para el proyecto. Cuando hay dos “victorias” que entran en conflicto, hay riesgo.

Dinámica de la gestión de riesgos.

Actividades básicas:

  • Controlar los indicadores de transición
  • Descubrimiento continuo del riesgo
  • Recoger datos para el depósito de riesgos
  • Seguimiento de las métricas de cierre

Métrica de cierre: qué parte del proyecto se ha realizado (por ejemplo, valor ganado en ejecución (EVR))

Incrementalismo para la mitigación de riesgos.

Se trata básicamente de un desarrollo iterativo en el que se entregan subconjuntos de funcionalidad. Hay que valorar que este libro es de 2003, así que se adelantó a su época, pues el Manifiesto Ágil es de solo dos años antes.

Pero se debe evitar el incrementalismo reactivo: que es dejar que los desarrolladores elijan en qué subconjuntos trabajar sin prioridades ni juicios de la dirección.

Por eso es necesario orientarse al incrementalismo proactivo: plan cuidadoso basado en la entrega de valor y en la confirmación de las hipótesis de riesgo; ordenación de las características para mostrar que (1) no todos los elementos son igual de importantes, y (2) no se permite acumular características más allá de lo que se compromete.

Las partes del sistema que dependen de la realización de maravillas técnicas deben ser empujadas a las primeras versiones.

Plan de entrega incremental: correlación formal entre tres artefactos

  • Plano de diseño (módulos y su relación)
  • Estructura de desglose del trabajo (tareas y dependencias)
  • Pruebas de aceptación

Trayectoria de deslizamiento: cantidad de EVR demostrada que se completa por unidad de tiempo; las desviaciones de esto son un signo seguro de la manifestación del riesgo.

La estrategia definitiva de mitigación de riesgos.

Empezar pronto es una forma muy eficaz de mitigar el riesgo de llegar tarde.

Una gestión con agallas está dispuesta a asumir un poco de riesgo para salir con una posición mejorada si la asunción de riesgos resulta rentable.

Y los proyectos que se inician demasiado tarde son un signo de falta de visión y valor en la cúpula de la de los directivos.

PARTE IV: CUÁNTO…

Cuantificación del valor.

Recordemos lo que es el ROI = (valor – coste) / coste.  Hoy, en lugar de construir sistemas que compensen los costes, nos embarcamos más a menudo en proyectos destinados a mejorar nuestra posición en un mercado. Estos sistemas que mejoran el mercado son mucho más complicados de justificar. (por ejemplo, debemos tenerlo, lo necesitamos para seguir siendo competitivos)

Con un vago análisis de beneficios, no se puede hacer una gestión de riesgos. Hay que cuantificar tanto los costes como los beneficios. Hay varias razones por las que la gente intenta poner excusas para no hacer un análisis de beneficios; una de ellas es que diluye la responsabilidad.

Cinco elementos de las prestaciones:

  • Si los promotores declaran los costes/calendarios, las partes interesadas deben declarar los beneficios
  • Si los desarrolladores declaran la incertidumbre, las partes interesadas deben declarar también
  • Las partes interesadas dividen el sistema en componentes, cada uno debe contar con un análisis de costes y beneficios
  • La dirección utiliza el análisis coste-beneficio para justificar el proyecto
  • La dirección hace una comparación antes/después para ver cómo les fue

El valor también es incierto.

No se limite a un único valor de beneficio (normalmente el más optimista); utilice un diagrama de incertidumbre.

La ventana del mercado es la excusa más común para evitar las proyecciones cuidadosas de las prestaciones: ¡empieza a trabajar ahora o la ventana se cerrará! (De todos modos, esa fecha suele ser difícil de alcanzar).

Análisis de sensibilidad.

La única razón por la que un proyecto debe financiarse es que tenga algún valor y que el producto resultante aporte ese valor. A menudo, el valor sólo se mide para todo el proyecto; sin embargo, es probable que gunas partes del sistema tengan más o menos valor que otras.

Intente calcular una relación valor/coste para cada pieza, y luego muéstrela en un diagrama de árbol/dependencia para que los datos sean más visibles.

Existe una relación no lineal entre el tamaño del proyecto y el esfuerzo necesario para construirlo. Es más barato construir menos.

El valor compensa el riesgo.

Cuando hay mucho en juego, merece la pena correr incluso graves riesgos. Cuando lo que está en juego es poco, no hay que tolerar casi ningún riesgo.

Marchas fúnebres en el proyecto: todo el mundo debe trabajar más duro para entregar el proyecto. Pero si el proyecto lo requiere (porque es muy importante), ¿por qué la empresa no ha dedicado el esfuerzo necesario para hacerlo correctamente? ¿Realmente vale la pena la vida individual de las personas en beneficio de la empresa? La mayoría de estos escenarios no terminan bien, y nadie se siente mejor por ello.

Tu proyecto debe equilibrar la distribución del riesgo con la distribución del valor.

Perfeccionamiento de la receta de gestión de riesgos:

  1. Descubrir los riesgos y anotarlos
  2. Asegúrese de que los riesgos típicos de los programas informáticos también se anotan
  3. Para cada riesgo…
    • Asignar un nombre e identificación únicos
    • Encontrar un indicador de transición
    • Estimar el impacto del coste/calendario si se materializa
    • Estimación de la probabilidad
    • Calcular la exposición a los costes y al calendario
    • Definir las acciones de contingencia en caso de que se materialice
    • Añadir acciones de mitigación al plan del proyecto
  4. Designar los obstáculos como hipótesis del proyecto (aumentar el riesgo)
  5. Determinar la fecha del nano porcentaje (N), suponiendo que no se materialicen los riesgos
  6. Utilizar modelos (como RISKOLOGY) para parametrizar el riesgo (esto implica N)
  7. Expresar los compromisos mediante diagramas de riesgo con ventanas de incertidumbre; convencer a los demás en función del alcance de su modelización
  8. Crear una estructura de desglose del trabajo con pesos relativos de esfuerzo (estos factores en las métricas de funcionamiento del valor ganado)
  9. Conseguir el compromiso de la arquitectura (entrada y salida de datos); tratar esto como un hito y no proceder sin él
  10. Hacer una partición completa del diseño antes de cualquier desarrollo
  11. Revisar la EDT para reestimar en base al diseño
  12. Evaluar el valor igual que se evalúa el coste
  13. Ordene los requisitos en función del valor neto y el riesgo técnico
  14. Crear un plan de entrega incremental
  15. Crear una prueba de aceptación final (es decir, la definición de hecho)
  16. Gráfico de valor ganado en ejecución frente a la fecha de entrega prevista de cada incremento; actualización a medida que se publican las versiones
  17. Supervisar todos los riesgos y ejecutar los planes según sea necesario; supervisar el valor ganado ejecutando la ruta de deslizamiento
  18. Seguir descubriendo riesgos

PARTE V: SI NO…

Prueba de una buena gestión de riesgos.

• La cultura empresarial dice de boquilla que una empresa está haciendo una gestión de riesgos, pero no es así. Por ejemplo:

  • Pensamiento a corto plazo
  • Necesidad de aparentar que se tiene el control
  • Tener una actitud positiva
  • Evitar que parezca que no se está seguro
  • Utilizar el poder político

Si como Project Manager puedes conseguir los 6 primeros puntos de esta lista, probablemente estés haciendo una buena gestión de riesgos en tus proyectos:

  1. Tienes un registro de riesgos con los riesgos comunes de los proyectos de software y hay desencadenantes o triggers.
  2. Tienes un proceso para descubrir continuamente los riesgos, y está abierto a los demás.
  3. Utilizas los diagramas de incertidumbre.
  4. Los proyectos tienen objetivos y estimaciones, y son números diferentes.
  5. Todos los riesgos se vigilan para que se produzcan transiciones.
  6. Cada riesgo tiene un plan de contingencia y mitigación.
  7. Se ha calculado la exposición para cada riesgo.
  8. Los proyectos tienen valores cuantificados y los componentes se clasifican en función de ellos.
  9. Se hacen entregas de forma incremental, caso de proyectos de software.

NOTA FINAL:

En la url http://www.systemsguild.com/riskology encontrarás algunas herramientas y plantillas bastante útiles preparadas por los autores del libro.

OFICINAS DE DIRECCION DE PROYECTOS (PMO)

QUÉ SON:

Aprovechando la publicación del PMBOK en su versión 7, revisamos el Apéndice X3 del citado documento, pues en el mismo se estudian las Oficinas de Dirección de proyectos, también conocidas por su acrónimo PMO (Project Management Office).

Las PMO representan una estructura de gestión que busca estandarizar los procesos de gobernanza relacionados con los proyectos y facilita el intercambio de recursos, herramientas, metodologías y técnicas.

Según el PMBOK V7  las organizaciones establecen una PMO por una variedad de razones, pero con un beneficio principal en mente: mejorar la gestión de proyectos en términos de cronograma, costo, calidad, riesgo y otras facetas. No obstante, las PMO tienen muchos roles potenciales para alinear el trabajo con los objetivos estratégicos: participar y colaborar con grupos de interés, desarrollar el talento y obteniendo valor de las inversiones realizadas en proyectos.

LA PROPUESTA DE VALOR DE LAS PMO:

Las PMO pueden adoptar múltiples formas, no obstante, comprender cómo se utilizar permiten destacar su gama de beneficios:

  • Algunas PMO brindan una guía de gestión de proyectos que respalda la estandarización en la entrega de los proyectos. Estas PMO pueden proporcionar pautas, plantillas y ejemplos de buenas prácticas junto con la formación y el coaching. Suelen ser la puerta de entrada básica de las PMO en las empresas y organizaciones.
  • Una PMO puede ofrecer servicios de apoyo a proyectos para actividades de planificación, gestión de riesgos, seguimiento del desempeño y actividades similares. Este modelo de servicios compartidos de una PMO a menudo existe en organizaciones con unidades de negocio independientes o diversas que desean apoyo con entrega manteniendo un control más directo sobre sus proyectos. Es una forma más avanzada y completa de PMO.
  • Las PMO pueden ser parte de un departamento o unidad de negocio y supervisar un portafolio de proyectos. La supervisión puede incluir actividades tales como requerir un caso de negocios para iniciar un proyecto, asignar recursos financieros y de otro tipo para ejecutar el proyecto, aprobar solicitudes de cambio, alcance o actividades del proyecto, y funciones similares. Este tipo de PMO proporciona gestión de proyectos. Esta estructura existe en organizaciones que tienen departamentos con múltiples proyectos y que entregan resultados estratégicamente importantes, como capacidades de TI o desarrollo de nuevos productos.
  • Una organización puede tener una PMO de nivel empresarial (EPMO) que vincule la implementación de estrategia organizacional con inversiones a nivel de cartera en programas y proyectos que entregar resultados, cambios o productos específicos. Esta estructura existe en organizaciones con capacidades de gestión de proyectos bien establecidas que están directamente relacionadas con el logro estrategia organizacional y amplios objetivos comerciales.
  • Organizaciones con estructuras más planas, iniciativas centradas en el cliente y más adaptables con enfoques de entrega más adaptables pueden adoptar un Agile Center of Excellence (ACoE) u Oficina de Entrega de Valor (VDO). El ACoE / VDO cumple una función habilitadora, en lugar de una gestión o función de supervisión. Se centra en el coaching de equipos, construyendo habilidades y capacidades ágiles a lo largo de la organización, y asesorar a los patrocinadores y propietarios de productos para que sean más eficaz en esos roles. Este tipo de estructura está surgiendo dentro de las organizaciones que adoptan estructuras descentralizadas donde los equipos necesitan responder rápidamente a las necesidades cambiantes de los clientes.

La formación de cualquier tipo de PMO o VDO se basa en las necesidades organizativas. Los influencers clave que ayudan a dar forma a la PMO o VDO incluyen los tipos de proyectos que se entregan, el tamaño de la organización, su (s) estructura (s), el grado de toma de decisiones centralizada / descentralizada, y cultura. A medida que las necesidades organizacionales cambian con el tiempo, las PMO y VDO evolucionan en respuesta. Por ejemplo, una PMO puede transformarse en una VDO o la PMO puede cerrarse después de cumplir con su estatuto

CAPACIDADES CLAVE DE LAS PMO:

El Estándar para la Gestión de Proyectos establece que los proyectos son parte de un sistema de entrega de valor. dentro de las organizaciones. Las PMO pueden respaldar ese sistema y son parte del sistema. Como proyecto Los equipos necesitan capacidades específicas para generar resultados, al igual que las PMO. Las PMO efectivas hacen tres claves contribuciones que apoyan la entrega de valor:

  1. Fomentar la entrega y las capacidades orientadas a resultados. Aseguran que los empleados, contratistas, socios, etc., que están dentro y fuera de la PMO, comprenden, desarrollan, aplican y valoran una gama de habilidades y competencias de gestión de proyectos. Se centran en los procesos de dimensionamiento adecuado y gobernanza, basada en las características únicas de cada proyecto para producir
    resultados de manera eficiente, rápida y eficaz.
  2. Mantener la perspectiva del “panorama general”. Mantenerse fiel a los objetivos de un proyecto sigue siendo un elemento clave del éxito. Vigilan el desplazamiento del alcance y nuevas prioridades que no están alineadas con la estrategia o el negocio. Los objetivos pueden permitir que los proyectos se desvíen de su curso. Las PMO sólidas evalúan el desempeño de proyectos con miras a la mejora continua. Evalúan el trabajo en el contexto del éxito general de la organización en lugar de maximizar los resultados de un proyecto específico. Proporcionan información a los equipos de proyectos, a la alta dirección y a los líderes empresariales y orientación que les ayude a comprender las circunstancias actuales y las opciones de apoyo. de toma de decisiones.
  3. Mejora continua, transferencia de conocimiento y gestión del cambio. Las PMO sólidas comparten regularmente los resultados del proyecto en toda la organización para transferir valiosos conocimientos adquiridos en cada proyecto. Las actividades de aprendizaje e intercambio informan objetivos comerciales mientras se mejoran las actividades que fortalecen la entrega de proyectos futuros. La gestión eficaz del cambio organizacional construye y mantiene la alineación con el proceso actualizaciones, mejoras de capacidad y nuevas habilidades que respaldan la gestión de proyectos.

EVOLUCIONANDO PARA UNA REALIZACIÓN DE BENEFICIOS MÁS FUERTE:

Para muchas empresas, una mayor incertidumbre, un ritmo de cambio acelerado, aumentó competencia, y clientes más empoderados significan que las organizaciones producen valor en un entorno complejo. La capacidad de implementar nuevas iniciativas estratégicas y cambiar rápidamente se está convirtiendo en un diferenciador clave. Estos cambios también están ejerciendo una mayor presión sobre las PMO para demostrar su contribución a la realización de beneficios y creación de valor. Las PMO están evolucionando para enfrentar estos desafíos:

  • Centrándose en iniciativas críticas. Si bien todos los proyectos son importantes, las iniciativas estratégicas pueden tener un impacto significativo en el futuro de la organización, su relación con sus grupos de interés, y sus capacidades. Las PMO están pasando de ser los guardianes del proyecto a orquestar conversaciones entre líderes superiores, jefes de unidades de negocio, propietarios de productos y proyectos equipos. Estas conversaciones brindan información precisa sobre el desempeño del proyecto, las amenazas, y oportunidades que pueden afectar importantes iniciativas estratégicas. Tal enfoque promueve claridad y corrección del rumbo en torno a problemas emergentes y la mayor realización posible de los resultados comerciales.
  • Instituir procesos inteligentes y sencillos. Las PMO están dimensionando correctamente las capacidades mediante el establecimiento de la suficiente disciplina de proceso y práctica para permitir comunicación, colaboración y mejora continua sin agregar desperdicios o anulando los procesos primordiales que están produciendo valor.
  • Fomento del talento y las capacidades. Las PMO están desempeñando un papel más proactivo en la contratación y retener a los miembros del equipo con talento. Están desarrollando y alimentando técnicas, habilidades estratégicas, de gestión y de liderazgo dentro de los equipos de proyecto y en toda la organización.
  • Fomentar y posibilitar una cultura de cambio. Las PMO se están convirtiendo en líderes del cambio mediante la construcción activa de apoyo y compromiso en toda la organización con los resultados y desempeño centrado en los resultados y en la gestión del cambio organizacional como diferenciadores competitivos.

DIFERENCIAS CON EL PMBOK VERSIÓN 6:

Recordemos que en el PMBOK V6 en su punto 2.4.4.3 las PMO se definían como una “estructura de la organización que estandariza los procesos de gobernanza relacionados con el proyecto y que facilita el intercambio de recursos, metodologías, herramientas y técnicas“.

Una oficina de dirección de proyectos (PMO) es una estructura de la organización que estandariza los procesos de gobernanza relacionados con el proyecto y facilita el intercambio de recursos, metodologías, herramientas y técnicas.

Las responsabilidades de una PMO pueden abarcar desde el suministro de funciones de soporte para la dirección de proyectos hasta la propia dirección de uno o más proyectos.

Existen varios tipos de PMOs en las organizaciones. Cada tipo varía en función del grado de control e influencia que ejerce sobre los proyectos en el ámbito de la organización. Este es el ejemplo clásico de clasificación de las PMOs:

  • De apoyo. Las PMOs de apoyo desempeñan un rol consultivo para los proyectos, suministrando plantillas,
    mejores prácticas, capacitación, acceso a la información y lecciones aprendidas de otros proyectos. Este tipo de
    PMO sirve como un repositorio de proyectos. Esta PMO ejerce un grado de control reducido.
  • De control. Las PMOs de control proporcionan soporte y exigen cumplimiento por diferentes medios. Esta PMO
    ejerce un grado de control moderado. Este cumplimiento puede implicar:

    • La adopción de marcos o metodologías de dirección de proyectos;
    • El uso de plantillas, formularios y herramientas específicos; y
    • La conformidad con los marcos de gobernanza.
  • Directiva. Las PMOs directivas ejercen el control de los proyectos asumiendo la propia dirección de los mismos.
    Los directores de proyecto son asignados por la PMO y rinden cuentas a ella. Estas PMOs ejercen un grado de
    control elevado.

La oficina de dirección de proyectos puede tener responsabilidad a nivel de toda la organización. Puede jugar un
papel para apoyar la alineación estratégica y entregar valor organizacional. La PMO integra los datos y la información
de los proyectos estratégicos de la organización y evalúa hasta qué punto se cumplen los objetivos estratégicos de alto
nivel. La PMO constituye el vínculo natural entre los portafolios, programas y proyectos de la organización y los sistemas
de medición de la organización (p.ej., cuadro de mando integral).

Puede que los proyectos que la PMO apoya o dirige no guarden más relación entre sí que la de ser gestionados
conjuntamente. La forma, la función y la estructura específicas de una PMO dependen de las necesidades de la
organización a la que ésta da soporte.

Una PMO puede tener la autoridad para actuar como un interesado integral y tomar decisiones clave a lo largo de la
vida de cada proyecto a fin de mantenerlo alineado con los objetivos de negocio. La PMO puede:

  • Hacer recomendaciones,
  • Liderar la transferencia de conocimientos,
  • Poner fin a proyectos, y
  • Tomar otras medidas, según sea necesario.

Una función fundamental de una PMO es brindar apoyo a los directores del proyecto de diferentes formas, que
pueden incluir, entre otras:

  • Gestionar recursos compartidos a través de todos los proyectos dirigidos por la PMO;
  • Identificar y desarrollar una metodología, mejores prácticas y estándares para la dirección de proyectos;
  • Entrenar, orientar, capacitar y supervisar;
  • Monitorear el cumplimiento de los estándares, políticas, procedimientos y plantillas de la dirección de proyectos
    mediante auditorías de proyectos;
  • Desarrollar y gestionar políticas, procedimientos, plantillas y otra documentación compartida de los proyectos
    (activos de los procesos de la organización); y
  • Coordinar la comunicación entre proyectos.

 

ENLACES DE INTERÉS:

 

CERTIFICACIÓN AGILE HYBRID PROJECT PRO

Consciente de la importancia que está teniendo últimamente en materia de proyectos el movimiento de mezclar elementos de las metodologías predictivas o waterfall, agile, Six Sigma y otras, el PMI ha lanzado una nueva certificación orientada a cubrir esta necesidad formativa.

La micro-credencial ágil / híbrida se alinea con la Guía para el cuerpo de conocimiento de la gestión de proyectos, la Guía del PMBOK, (que ya está en su versión 7) y que es el estándar global preeminente para la gestión de proyectos y que proporciona las prácticas fundamentales de la profesión.

Según el PMI “Los poseedores de la certificación Agile Hybrid Project Pro Micro-Credential han demostrado su amplio conocimiento de conceptos, tareas y técnicas de gestión de proyectos ágiles / híbridos que son aplicables en prácticamente cualquier industria. Los poseedores pueden hablar y comprender el lenguaje global de la gestión de proyectos ágiles / híbridos. Los poseedores han demostrado el conocimiento y las habilidades necesarias para gestionar los planes, el alcance, las partes interesadas, los riesgos, los presupuestos, el cumplimiento, los recursos, la resolución de problemas y la entrega de valor del proyecto.”

La certificación  Project Pro Micro-Credential se está introduciendo para ayudar a los gerentes de proyectos tradicionales, titulares de la certificación PMP existentes, gerentes de proyectos con conocimientos ágiles / híbridos y / o experiencia, para alinearse con los últimos estándares de la industria.

Y es que, como ya vimos en la entrada correspondiente a la certificación Google de Project Management, es ya un hecho que, en lugar de seguir una sola metodología para la gestión de un proyecto, lo más adecuado es estudiar tanto las características del proyecto como las peculiaridades de la empresa y decidir qué es lo más adecuado para lograr el éxito.

Se trata de un movimiento imparable que se ha convertido en tendencia. Mal que le pese a los apóstoles del agilismo o del waterfall puros, muchos responsables de proyectos se han dado cuenta, a través de la experiencia, de que el éxito de un proyecto depende mucho de la cultura de la empresa y que el uso de prácticas o artefactos de las diferentes metodologías puede ayudar enormemente a llevar a buen fin un proyecto.

Ya nadie duda que las daylies que provienen del agilismo ayudan mucho a mejorar la comunicación del equipo y fomentan la transparencia.  Y lo mismo ocurre con las “Retrospectivas“, que proporcionan un feedback excelente acerca de lo que ha sucedido en una fase, iteración o proyecto. Por otra parte, el Business Case de la metodología Prince2 se ha demostrado que proporciona claridad en la definición de los objetivos del proyecto y la búsqueda de rentabilidad o de valor añadido. Es un hecho que muchos proyectos hacen un kickoff para iniciar sus proyectos y completan un Project Charter para definir lo que el proyecto debe cumplir.

A continuación, muestro un resumen de algunos de los enfoques de gestión de proyectos que pueden componer el enfoque híbrido:

  • Predictiva o Waterfall es una metodología tradicional en la que las tareas y fases se completan de manera lineal y secuencial, y cada etapa del proyecto debe completarse antes de que comience la siguiente. El Project Manager es responsable de priorizar y asignar tareas a los miembros del equipo. En el enfoque predictivo, los criterios utilizados para medir la calidad están claramente definidos al inicio del proyecto. Es ideal para proyectos en los que los requisitos están claros desde el principio (lo que no suele ser muy normal).
  • Agile implica fases cortas de trabajo colaborativo e iterativo con pruebas frecuentes y mejoras implementadas regularmente. Algunas fases y tareas ocurren al mismo tiempo que otras. En los proyectos ágiles, los equipos comparten la responsabilidad de gestionar su propio trabajo. Scrum y Kanban son ejemplos de marcos ágiles, que son enfoques de desarrollo específicos basados ​​en la filosofía Agile.
  • Scrum es un marco ágil que se enfoca en desarrollar, entregar y mantener proyectos y productos complejos a través de la colaboración, la responsabilidad y un proceso iterativo. El trabajo lo completan equipos pequeños y multifuncionales dirigidos por un Scrum Master y un Product Owner  y se divide en Sprints cortos con una lista seleccionada de entregables.
  • Kanban es tanto un enfoque ágil como una herramienta que proporciona retroalimentación visual sobre el estado del trabajo en progreso mediante el uso de tablas o gráficos Kanban. Con Kanban, los gerentes de proyecto usan notas adhesivas o tarjetas de notas en un tablero Kanban físico o digital para representar las tareas del equipo con categorías como “Por hacer”, “En progreso” y “Listo”.
  • Prince2 es una metodología de gestión de proyectos que se plantea sean realizados entre otras actividades considerando 7 temas: la Calidad, el Cambio, la estructura de roles del proyecto (Organización), los planes (Cuánto, Cómo, Cuando), el Riesgo y el Progreso del proyecto, justificado por un Business Case (o necesidad del negocio) que es la que evidencia la realización de ese proyecto.
  • Lean utiliza la herramienta de calidad 5S (clasificar, ordenar, limpiar, estandarizar, disciplina) para eliminar ocho áreas de desperdicio, ahorrar dinero, mejorar la calidad y agilizar los procesos. Los principios de Lean establecen que puede hacer más con menos al abordar las disfunciones que generan desperdicio. Lean implementa un sistema de programación Kanban para administrar la producción.
  • Six Sigma implica reducir las variaciones asegurando que los procesos de calidad se sigan en todo momento. El método Six Sigma sigue un enfoque de mejora de procesos llamado DMAIC, que significa definir, medir, analizar, mejorar y controlar.
  • Lean Six Sigma es una combinación de enfoques Lean y Six Sigma. A menudo se utiliza en proyectos que tienen como objetivo ahorrar dinero, mejorar la calidad y avanzar rápidamente en los procesos. Lean Six Sigma también es ideal para resolver problemas complejos o de alto riesgo. La herramienta de calidad 5S, el proceso DMAIC y el uso de tableros Kanban son todos componentes de este enfoque.

El examen de certificación se basa en la aplicación de los siguientes principios y conceptos: 

  • Manejar conflictos y liderar un equipo
  • Apoyar el desempeño del equipo, empoderar a los miembros del equipo y a las partes interesadas
  • Abordar y eliminar impedimentos, obstáculos y bloqueos para el equipo
  • Colaborar con las partes interesadas e involucrar a las partes interesadas
  • Desarrollar un entendimiento compartido, involucrar y apoyar a equipos virtuales
  • Ejecute el proyecto con la urgencia necesaria para ofrecer valor empresarial
  • Gestionar comunicaciones, evaluar y gestionar riesgos
  • Planificar y administrar el presupuesto, el cronograma, la calidad de los productos / entregables, el alcance, los cambios y los problemas del proyecto
  • Planificar y gestionar el cumplimiento del proyecto
  • Evaluar y entregar los beneficios y el valor del proyecto

Los dominios en  los que se basa el examen son los siguientes:

  1. People,
  2. Process
  3. Business Environement.

La siguiente tabla identifica la proporción de preguntas de cada dominio que aparecerán en el examen:

Por último comentar que el examen de certificación se puede realizar “on line” en modo “unproctored” y consta de 60 preguntas, que se deben completar en 75 minutos. Superar el examen proporciona 13 PDUs válidos para el mantenimiento de los poseedores de la certificación PMP.

Más información:

METODOLOGÍA DE GESTIÓN DE PROYECTOS PM²

QUÉ ES PM²

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

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

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

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

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

Qué ofrece esta nueva metodología:

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

Los puntos fuertes de PM² son:

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

Esta metodología se basa en 4 pilares:

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

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

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

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

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

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

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

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

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

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

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

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

 

ENLACES ÚTILES:

 

SLIDESHARE DEL ORIGEN DE PM2

 

GOOGLE PROJECT MANAGEMENT CERTIFICATE

Certificate of completion¿A QUIÉN SE DIRIGE?

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

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

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

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

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

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

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

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

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

CURSOS QUE LO COMPONEN:

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

Curso 1. Foundations of Project Management.

Los objetivos de este curso son:

Google Project Management

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

Curso 2. Project Initiation. Starting a Successful Project:

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

Curso 3. Project Planning. Putting It All Together:

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

Curso 4: Project Execution. Running the Project:

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

Curso 5. Agile Project Management:

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

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

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

CONCLUSIONES

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

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

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

Para quien es este curso:

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

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

 

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

INTRODUCCIÓN

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

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

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

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

 

Sistemas push vs sistemas pull

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

 

Compromiso diferido y políticas

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

Trabajo por lotes

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

 

Descartes

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

Replanificaciones y entregas frecuentes

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

Compromisos de entrega

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

Métricas

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

Tiempo de espera del sistema y del cliente e Histogramas

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

Rendimiento y Run-Chart

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

Conclusiones

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

Próximo post

En el próximo post hablaremos de lo siguiente:

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

 

 

INICIACIÓN A KANBAN (I) – CONCEPTOS PREVIOS

¿Qué significa Kanban?

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

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

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

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

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

Principios directores

Kanban tiene 3 principios directores:

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

 


El método Kanban

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

Valores Kanban

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

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

Principio de entrega de servicios

¿Qué es un servicio?

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

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

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

 

Principio de gestión del cambio

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

El método Kanban usa ….

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

El método Kanban entrega ….

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

Prácticas Generales

Visualizar:

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

Limitar el WIP:

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

Gestionar el flujo de trabajo:

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

Hacer explícitas las políticas:

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

Circuitos de retroalimentación:

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

Mejorar & evolucionar:

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

 

Conclusiones

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

 

Próximos post:

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

 

 

 

 

 

 

 

LEGALTECH

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:

 

 

 

 

 

 

 

 

 

 

 

 

TÉCNICOS “BLACK BOX”

QUÉ ES:

A raíz de una conversación de oficina surgió un tema muy interesante que es el de los llamados técnicos “Black Box”. Un “Black Box”,  es “Una persona que produce ella misma o contribuye a producir un bien o servicio, según unas especificaciones, mediante un proceso que su supervisor entiende sólo en términos generales y que él mismo no domina” *. Para entendernos, es un técnico que desarrolla unas tareas técnicas que su responsable no entiende.  Es una figura muy común dentro del mundo de la informática o de la ingeniería.

Existen diferentes grados en esto, desde el Black Box puro, en el cual su responsable no conoce en absoluto las tareas técnicas que realiza el Black Box a su cargo, pasando por el “White Box” en el cual el trabajo se entiende perfectamente y se puede reproducir también fácilmente, hasta el “Grey Box”, donde su responsable conoce y entiende las tareas que desempeña el técnico, aunque le costaría realizarlas.

Hay que diferenciar la capa técnica y la capa de gestión dentro del trabajo en las empresas y especialmente dentro de los proyectos. El Project Manager debería enfocarse en la gestión del proyecto y los técnicos enfocarse en la parte técnica. Por otra parte, algunos técnicos Back Box no aprecian el valor añadido que proporciona la capa de gestión y solo valoran la capa técnica.

Estos son los problemas que puede generar la gestión de los técnicos Black Box*:

  • De control: no informan porque no lo consideran necesario y porque creen que su responsable tampoco lo entendería. No quieren sentirse controlados. Pero existen proyectos con grandes inversiones o de gran riesgo que requieren reportes de status frecuentes. Esta actitud provoca stress a sus responsables. Tener una necesidad de control relativamente baja es esencial. Un Project Manager, por ejemplo, que no sepa delegar, puede tener un gran problema con la coordinación de los Black Box.
  • De motivación: suelen ser personas auto motivadas y además se molestan si alguien quiere tratar de motivarles. El pensamiento Wishful thinking es contraproducente aquí.
  • De poder: pueden querer convertirse en indispensables en la empresa no compartiendo su conocimiento. La crisis económica y el miedo a ser despedido puede hacer que este punto se convierta en relevante. Además, el jefe depende del tecnioc Black Box para obtener sus objetivos personales, lo que agrava la situación.
  • Otros factores: aquí pueden intervenir otras circunstancias que pueden empeorar la situación, tales como el coste del proyecto, su duración, su complejidad, la escasez de técnicos Black Box en el mercado laboral, etc…

Problemas que puede generar:

  • Depende de la personalidad del supervisor, que puede ver la actitud del técnico Black Box como una amenaza a su autoridad o una oportunidad (no tener que preocuparse de esas tareas)
  • Algunos técnicos Black Box  pueden no respetar a su supervisor como por considerar que no está cualificado técnicamente.  Aquí existe un gran matiz cultural:
    • En los países mediterráneos y en  Latino América la obligación de los gestores de conocer los que saben sus colaboradores es muy fuerte. Se presupone que el supervisor conoce perfectamente el trabajo que realiza el BB. No hace falta decir que esto puede suponer una gran fuente de stress para el supervisor, pues necesita estar actualizandose continuamente para conocer el trabajo técnico, pudiendo dejar del lado la capa de gestión que es precisamente su labor principal.
    • Los países escandinavos y anglosajones no están de acuerdo con la aseveración de que el supervisor debe entender y saber hacer el trabajo de sus colaboradores. En este esquema, está claramente definido que el gestor gestiona y el técnico Black Box ejecuta el trabajo técnico.

Los comportamientos adecuados con los BB serían:

  • Escucharlos
  • Ayudarles
  • Protegerles de interferencias
  • Reducir su stress
  • Controlarles, pero sin ofenderles
  • Mostrarles respeto

EN RELACIÓN A LA GESTIÓN DE PROYECTOS:

Dentro del PMBOK V6 el proceso 9-5 es “Dirigir al Equipo”, que se puede definir como el “proceso que consiste en hacer seguimiento del desempeño de los miembros del equipo, proporcionar retroalimentación, resolver problemas y gestionar cambios en el equipo a fin de optimizar el desempeño del proyecto.”

Implica para el Project Manager del proyecto disponer de una combinación de habilidades, entre ellas la comunicación, gestión de conflictos, liderazgo y la negociación.

Y aquí entramos en un dilema eterno en materia de gestión de proyectos, el Project Manager (PM) ¿Debe conocer técnicamente lo que conocen los técnicos que trabajan en el proyecto? La respuesta oficial  sería que no es necesario (porque un gestor de proyectos debería de poder dirigir proyectos multidisciplinares y transversales en todos los sectores, con independencia de la materia sobre la que verse) pero acto seguido hay que reconocer que el conocimiento técnico del PM de la materia sobre la que trata el proyecto tiene interesantes ventajas (por ejemplo, las estimaciones de las tareas pueden ser más precisas, se podrán controlar mejor los riesgos) y solo un posible inconveniente (que el PM trabaje de técnico y no gestione el proyecto). Pero insistiendo en la idea de que es imposible saber de todo. Un buen jefe de proyectos debe quitarse la “gorra” de técnico y ponerse la de gestor.

Otro factor que agrava este problema es el Efecto “Halo” que es muy común en materia de proyectos. Se refiere de forma genérica a una “Desviación cognitiva por la que la percepción de una característica de una persona está influenciada por la percepción de otras características de esa persona.” Un ejemplo es pensar que una persona que fue un gran jugador de fútbol deba ser un gran entrenador. Específicamente, en materia de gestión de proyectos, se cae frecuentemente en que se elige al mejor técnico, al que más sabe en la materia para que pase a gestionar proyectos, lo que significa pasar de gestionar tareas a gestionar personas, lo que significa gestionar conflictos. Y claro está, resulta evidente que un excelente técnico no tiene por qué ser por sí mismo un buen gestor de proyectos.

El Project Manager debe disponer de habilidades interpersonales y de equipo, que incluyen, entre otras, la resolución de conflictos.

Las técnicas de resolución de conflictos son las siguientes:

  • Apartarse/Eludir: Retirarse de una situación de conflicto real o potencial
  • Suavizar/Reconciliar: Reforzar los puntos de acuerdo más que en las diferencias.
  • Consentir: Buscar soluciones que aporten un cierto grado de satisfacción a todas las partes.
  • Forzar: Imponer su propio punto de vista a costa de los demás; ofrece soluciones únicamente de tipo ganar-perder.
  • Colaborar: Incorporar múltiples puntos de vista y visiones a partir de perspectivas diversas; conduce al consenso y al compromiso.
  • Confrontar/Resolver Problemas: Tratar un conflicto como un problema que debe resolverse mediante el examen de alternativas; requiere una actitud de concesión mutua y un diálogo abierto.

Una mención aparte merece el tema de las Comunicaciones. Es curiosa una regla ya mencionada de que cuantas más capacidades técnicas tiene una persona, menos capacidades “blandas” posee, (liderazgo, el desarrollo del espíritu de equipo, la motivación, comunicación, influencia, la habilidad para resolver conflictos y la negociación). Esto podría ser problema cuando se trata de supervisar a los técnicos Black Box. Este es un punto que debe cuidar el Project Manager, pues el contacto con estos colaboradores podría resultar complejo y frustrante. Y es una obligación del Project Manager desarrollar al equipo del proyecto, y esto implica:

  • Mejorar la motivación, las habilidades y la capacidad de los miembros del equipo, a fin de aumentar su competencia para completar las actividades del proyecto.
  • Mejorar los sentimientos de confianza y cohesión entre los miembros del equipo con el fin de incrementar su productividad a través de un mejor trabajo en equipo.
  • Crear una dinámica de cooperación, trabajo en equipo y capacidad para compartir conocimiento y experiencia.

La necesidad de gestionar adecuadamente las personalidades de tipo Black Box está creciendo, a medida que el mundo laboral se especializa más y más. La globalización de las empresas amplifica este fenomeno. Y su gestión plantea un gran desafío dentro de los proyectos y más con el advenimiento y extensión de las metodologías ágiles. Este tema se relaciona con el cambio de papel de los Project Manager, que pasan de ostentar un liderazgo jerárquico a un liderazgo colaborativo o facilitador, siendo capaces de delegar o empoderar a su equipo.

Y en el mundo de la gestión ágil, se plantea un interesante dilema respecto a la figura del Scrum Master, pues sus funciones son apoyar y tutelar al equipo y ayudar a entender la teoría scrum y sus reglas, valores y prácticas. Esta figura choca frontalmente con la necesidad de autonomía que tienen los técnicos Black Box.

*Fuentes:

  • PMBOK 6 PMI
  • Instituto de Empresa. Informe NT CT13002
  • Manifiesto Ágil.