Etiqueta: Libro

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.