Enlaces relacionados:
- 12 estrategias de gestión de riesgos en proyectos aprendidas a la fuerza
- Descripción del puesto de gestor de proyectos digitales
- Webinar: Consejos y herramientas de gestión de riesgos para gestionarlo como un profesional
- Vídeo: ¿Qué herramientas de gestión ágil de proyectos debería usar?
- ¿Por qué es importante la gestión de proyectos?
- Aprenda las ceremonias de Scrum con esta guía increíblemente simple
- Podcast de The Digital Project Manager – Apple Podcasts
- Formación en gestión de proyectos
- Únete a nuestro equipo de Slack para gestores de proyectos
- Únete a la Comunidad de Digital Project Manager
Lee la transcripción:
Estamos probando la transcripción de nuestros pódcast mediante un programa de software. Por favor, perdona cualquier error ya que el bot no es 100% preciso.
Ben Aston:
Entonces, el 15% de los proyectos de TI tienen sobrecostes del 200% y un desfase en el calendario del 70%. Da miedo, ¿verdad? Y quizás te suene familiar. La verdad es que los proyectos asustan. Los proyectos son intrínsecamente arriesgados y eso es porque hacemos que ocurra un cambio. Los proyectos salen mal todo el tiempo. Y como gestores de proyectos, somos el blanco fácil cuando salen mal. Así que deberías tener miedo. Deberías temer que tus proyectos fracasen porque cuando tienes miedo, es mucho más probable que hagas lo que sea necesario para evitar que tus proyectos resulten tan aterradores. Así que sigue escuchando el pódcast de hoy para descubrir cómo puedes usar la gestión de riesgos para que tus proyectos sean menos aterradores y puedas dormir mejor por la noche.
Gracias por sintonizarnos. Soy Ben Aston, fundador de Digital Project Manager. Bienvenidos al pódcast de DPM. Tenemos la misión de ayudar a los gestores de proyectos a tener éxito, y a quienes gestionan proyectos a entregar cada vez mejor. Estamos aquí para ayudarte a llevar tu nivel de gestión de proyectos al siguiente nivel. Visita thedigitalprojectmanager.com para conocer nuestra formación y los recursos que ofrecemos a través de la membresía. Este pódcast está patrocinado por Clarizen, el líder en software de gestión de carteras y proyectos empresariales. Visita clarizen.com para saber más.
Hoy me acompaña Kiron Bondale. Kiron es consultor senior en World Class Productivity. Ofrecen servicios de formación y asesoría. Ha gestionado cientos de proyectos diferentes. Tiene mucha experiencia en gestión de riesgos, ha sido publicado y también en diferentes revistas, y además habla mucho de Ágil. Así que vamos a tocar ese tema en el pódcast de hoy. Pero muchas gracias, Kiron, por unirte hoy a nosotros.
Kiron Bondale:
Gracias Ben. Encantado de estar aquí.
Ben Aston:
Estamos en 2020. Es un año nuevo. Y tengo curiosidad por saber para ti Kiron, si eso significa que va a haber cosas nuevas para ti en lo que haces en World Class Productivity, en tus formaciones y consultorías. ¿Qué hay de nuevo para ti?
Kiron Bondale:
Claro. Lo nuevo para nosotros es que a finales del año pasado, como seguro tú y tus miembros saben, PMI adquirió el Consorcio Disciplined Agile o su propiedad intelectual. Y PMI está mostrando bastante interés en integrar sus ofertas, incluyendo algunas de sus certificaciones. Así que, como organización, vamos a empezar a impartir cursos alineados con Disciplined Agile. Diría que es un kit de herramientas que creemos es una gran respuesta para empresas que buscan una transformación ágil. Así que ese será el foco, al menos en el primer y segundo trimestre del año, tanto para mí como para nuestra organización.
Ben Aston:
Genial. Y en cuanto a esa formación, ¿puedes darnos una idea sobre cómo es tu formación?
Kiron Bondale:
Por supuesto. Hay una oferta estándar de PMI llamada Disciplined Agile Lean Scrum Master. Es un taller de dos a cuatro días, depende del perfil y experiencia de los asistentes; nosotros lo ofrecemos en formato de tres días, cubriendo Lean y Disciplined Agile. Lo bueno de esta formación es que ofrece la oportunidad de hacer un intento gratuito al examen de Certified Disciplined Agilist. Así que participas en el curso y tienes la oportunidad de obtener la certificación.
Ben Aston:
Tengo curiosidad por tu opinión sobre este tipo de certificaciones Ágiles. Tengo mi Scrum Master, que fue un curso de dos días y, en mi opinión, es divertido e interesante. Pero certificar a alguien después de dos días me parece un poco prematuro quizá. Así que me entra curiosidad; tú impartes la formación, pero cuéntanos, ¿en qué será diferente esta formación respecto al Scrum Master y cuál es tu opinión sobre las certificaciones, sobre todo en el mundo Ágil?
Kiron Bondale:
Excelente pregunta, Ben. De hecho, un colega mío y yo, uno de mis amigos virtuales en el mundo de Agile y Project Management, hablábamos de esto justo hoy... Con PMI entrando en la certificación Ágil con Discipline Agile, están entrando en un ecosistema muy saturado.
Ben Aston:
Sí.
Kiron Bondale:
Hay más de 300 certificaciones en el mundo Ágil. Lo que me gusta de lo que está haciendo PMI es que está posicionando bien sus certificaciones, ofreciendo opciones para cada nivel de experiencia. Por ejemplo, la de Certified Discipline Agilist está orientada a aquellos con solo formación académica, sin experiencia práctica todavía.
Ben Aston:
Entiendo.
Kiron Bondale:
Pero si tienes un par de años de experiencia en Agile, puedes optar por la certificación de Practitioner o seguir con la certificación original de PMI y elegir la PMI ACP si tienes experiencia suficiente para igualar la formación.
Y a medida que subes de nivel, hay ofertas Disciplined Agile para ellos también. Así que, al igual que otras empresas de certificación consolidadas, suelen tener un enfoque por niveles.
Ben Aston:
Sí.
Kiron Bondale:
Eso mismo está haciendo PMI, ofreciendo opciones según tu nivel. Ahora bien, nadie va a decir que solo por tener tu CSM o CDA o cualquier credencial básica ya tienes la experiencia para trabajar plenamente en un equipo ágil. Pero al menos podrás hablar el idioma. El siguiente paso es la experiencia práctica, y ahí puedes mirar otras credenciales más avanzadas.
Ben Aston:
Perfecto. Entonces las credenciales están cambiando y la entrada de PMI en el mundo Ágil también es una tendencia emergente. ¿Hay otras tendencias destacadas a las que vas a responder en 2020 en el mundo de la gestión de proyectos?
Kiron Bondale:
Creo que la otra gran tendencia es el cambio que PMI está haciendo respecto a la certificación PMP. Como probablemente sabes, el examen PMP cambia a finales de junio de 2020 y, con ese cambio, pasan a un nuevo modelo de cursos certificados. Antes, los proveedores podían crear sus propios materiales; diferenciaban por la calidad de los mismos.
Ahora, PMI será el único proveedor del material del curso. Todos los instructores deberán formarse con PMI y la diferencia será por el precio y el valor añadido sobre lo que PMI ofrece.
Eso creará más igualdad y acabará con algunos jugadores pequeños de calidad baja. Para los grandes, que llevan décadas y tienen materiales de alta calidad, ha sido duro. Nosotros, por ejemplo, tomamos la decisión de asociarnos con uno de los mejores proveedores de materiales PMI y solo utilizamos los suyos. Así que ahora tenemos que decidir si seguimos así o trabajamos con PMI directamente. Al menos, no hemos “tirado” nuestra inversión.
Ben Aston:
Muy bien, y mirando hacia 2021 una de las tendencias que escucho más es sobre herramientas de gestión de proyectos basadas en inteligencia artificial y la propia IA, haciendo que el gestor de proyectos quede obsoleto. Recuerdo un artículo de Gartner diciendo algo así. ¿Cuál es tu opinión sobre la aparición de más herramientas inteligentes y su papel en la gestión de proyectos, y cómo cambia el rol del gestor de proyectos?
Kiron Bondale:
Gran pregunta, Ben. Y soy bastante optimista respecto al valor de la IA para nuestra profesión. Algunos piensan que pronto nos quedaremos sin trabajo.
Ben Aston:
Sí.
Kiron Bondale:
Pero yo creo que hará a los PM más efectivos. Si miramos lo que hace un gestor de proyectos, hay una clara diferencia entre la parte administrativa y la parte estratégica del rol.
Ben Aston:
Exacto.
Kiron Bondale:
Y la parte estratégica es sobre interacción con personas, gestión de interesados, etc. Pero para enfocarse en eso, hay que liberarse de la carga administrativa.
Ya sea informes, reportes, pronósticos... ahí la IA puede ayudar mucho. Hago un paralelismo con Star Trek: la computadora era muy inteligente, pero nunca se delegaba toda la toma de decisiones; estaba como recurso de apoyo. Eso veo con la IA: puede analizarnos una gran base de datos de proyectos y devolvernos estadísticas y probabilidades útiles.
Así que creo que será una gran ayuda para tomar decisiones.
Ben Aston:
Sí.
Kiron Bondale:
Liberará a los PM de la carga administrativa aburrida y les permitirá centrarse en la parte estratégica, lo que supone más valor y satisfacción profesional para los gestores.
Ben Aston:
Hablemos entonces de las partes más estratégicas de la gestión de proyectos. ¿Qué parte del rol ves como más estratégica y cómo diferenciarla de lo más administrativo, como los informes de estado que mencionaste? ¿Cómo evoluciona eso con la adopción de nuevas herramientas?
Kiron Bondale:
Lo dividiría en cuatro niveles. El primero: relación con los stakeholders. En cualquier proyecto medianamente grande, hay diversidad de interesados y el PM debe mantener contacto regularmente con ellos.
Comprender cambios de actitud, interés, influencia. Hacerlo bien aumenta las posibilidades de éxito. Segundo: el caso de negocio inicial del proyecto. A menudo el PM participa en su redacción, pero luego puede perder de vista el porqué del proyecto, lo que a veces genera riesgos: el alcance se entrega a tiempo y presupuesto, pero la propuesta de negocio ya no existe. Ahí el buen PM señala si hay que cancelar un proyecto que ya no aporta valor.
Tercero: el propio equipo, ayudando a formar equipos de alto rendimiento. Se habla mucho de seguridad psicológica y franqueza radical. El PM como líder servidor necesita tiempo para desarrollarlo, y la IA puede ayudarle a dedicar más tiempo al equipo.
Cuarto y último, y de lo que trataba nuestro artículo: gestión de riesgos. Muchos stakeholders piensan que el riesgo es incertidumbre y si “no va a pasar” mejor no pensar en ello. Los PM a menudo van por el mismo camino porque tienen muchas tareas. Si pudiéramos liberarles de esa carga, podrían invertir más en comprender y gestionar los riesgos; en grandes proyectos, esto puede marcar la diferencia entre el éxito y el fracaso.
Ben Aston:
Sí, totalmente. Y eso lleva al tema de hoy: cómo gestionamos el riesgo y diferentes formas de abordarlo para lograr más éxito en nuestros proyectos. Me gustaría recapitular por qué la gestión de riesgos es importante. Kiron, puedes añadir; como mencionaste, los problemas surgen por no gestionar bien los riesgos. Al gestionar el riesgo puedes evitar cosas negativas; también mantienes al equipo alerta, conscientes de posibles problemas, mitigando impactos negativos. Genera transparencia y confianza. Si gestionas bien, vas dejando un historial, y cuando surge un problema hay una referencia clara que puede sacar al PM de la línea de fuego.
En tu artículo hablabas de tipos de respuestas ante riesgos: evitación, transferencia, escalada, mitigación y aceptación. ¿Cómo saber cuándo utilizar cual? ¿Algún principio a seguir?
Kiron Bondale:
Sí, claro, Ben. El riesgo siempre comienza por conocer el apetito al riesgo de tu organización y de los interesados clave alrededor del proyecto. Si la organización es muy adversa al riesgo, tenderán a la evitación; si está en entornos dinámicos y competitivos, será menos resistente y optarán por mitigar o aceptar riesgos. Cuando evitas cierto riesgo, también puedes estar renunciando a oportunidades y beneficios. Hay que entender todo eso.
Entonces, una vez lo conoces, hay que analizar cada riesgo y utilizar herramientas de análisis cualitativo y cuantitativo. ¿Qué probabilidad hay de que ocurra? ¿Qué impacto tiene sobre el éxito del proyecto? ¿Lo podremos detectar a tiempo? ¿Qué coste-beneficio tiene gestionarlo? Como con la calidad, siempre hay que hacer un análisis coste-beneficio.
Si solo hay un 1% de perder 1.000 dólares, no gastarías 1.000 para prevenirlo, pero si la probabilidad es 50%, sí tiene sentido invertir algo. He visto empresas muy adversas, donde el exceso de mitigación paraliza los proyectos, y otras que ignoran el riesgo y asumen cualquier cosa. ¿Dónde me perdiste?
Ben Aston:
Me perdí en la explicación sobre cuándo usar cada técnica de respuesta al riesgo.
Kiron Bondale:
Bien, lo repito. Cuando analizamos respuestas ante riesgos negativos o amenazas, hay que partir del perfil y apetito de riesgo organizacional y también del patrocinador y otros interesados clave. Si tu organización es muy adversa, evitarán todo riesgo preocupante.
Ben Aston:
Correcto.
Kiron Bondale:
Pero si compites en sectores dinámicos y debes asumir riesgos, evitarás tomar sólo el enfoque de evitación, porque renunciarías a partes arriesgadas pero valiosas del proyecto.
Empieza entendiendo el apetito de riesgo de la organización y de los interesados clave, porque el riesgo es incertidumbre relevante. Si la estrategia de respuesta no coincide con la tolerancia de tus stakeholders, no te prestarán atención, así que es vital que tu comunicación de riesgos sea relevante.
Una vez tienes claro esto, ya puedes buscar la mejor estrategia de respuesta según el riesgo: impacto, probabilidad, detectabilidad, etc. Y por supuesto, aplicar el análisis coste-beneficio.
Ben Aston:
Ajá.
Kiron Bondale:
Hay que asegurarse de que invertimos adecuadamente en la respuesta al riesgo. Para mostrar la utilidad de la gestión de riesgos a quienes no lo ven importante, siempre uso la analogía del seguro. Si compras un coche de $40,000, te parecerá lógico gastar unos cientos al año para protegerlo.
Ben Aston:
Exactamente.
Kiron Bondale:
Pero si la aseguradora te pide $10,000 anuales, probablemente dejarías de asegurar, porque no compensa. Hay que analizar el coste-beneficio, igual que hacemos con la calidad.
Ben Aston:
Hablamos de evitación (no hacer lo arriesgado), transferencia (comprar un seguro), escalada (decir a los stakeholders que la probabilidad e impacto son altos y hay que actuar), mitigación (evitar que pase) y aceptación (si cuesta más prevenirlo de lo que perderías, aceptar el riesgo).
Kiron Bondale:
Exacto. Pero, ojo, hay riesgos que nunca quisieras realizar. Por ejemplo, si el CEO del banco acaba en la cárcel, convendría gastar mucho para evitarlo; o si malas noticias salen en la portada de un periódico nacional. Son riesgos “showstopper”. Pero fuera de eso, siempre hay que analizar el coste-beneficio, porque tanto sobre-invertir como infra-invertir está mal.
Ben Aston:
De acuerdo. ¿Y sobre la documentación para la gestión de riesgos? El clásico es la RAID log (registro de riesgos, suposiciones, problemas y dependencias). A veces son muy complejos y lleva mucho registrar cada riesgo. ¿Cuál es tu opinión sobre la complejidad y cómo documentar?
Kiron Bondale:
Todo debe escalarse y adaptarse al tamaño del proyecto. Un proyecto pequeño no necesita tanta documentación como uno con cientos de personas, proveedores y reguladores externos durante años. No hay una plantilla única. Los documentos y plantillas deben escalar y adaptarse y, para empresas con plantillas empresariales, estas deberían ser flexibles. Si das una plantilla única para todo, solo conseguirás obtener “zombies de plantillas”.
Segundo, hay información en el RAID log o registro de riesgos que solo interesa al PM y al equipo, y otra que deberías compartir con más stakeholders.
Ben Aston:
Cierto.
Kiron Bondale:
Si saturamos a los stakeholders con detalles y listas enormes de riesgos, perderán el interés enseguida. Los equipos exitosos mantienen un registro con todos los detalles para el equipo, pero para los stakeholders extraen solamente la información relevante, lo más significativo y en el lenguaje adecuado, útil para tomar decisiones difíciles. Además, siempre debe estar actualizado y preciso: si ven información desactualizada, desconfiarán de toda la gestión de riesgos. Así pasa con cualquier información compartida: si merece la pena capturarse, merece la pena mantenerse al día.
Ben Aston:
Totalmente cierto. Y en cuanto al RAID log, ¿cómo lo completamos? Muchos saben que hay plantillas, y como miembros de Digital Project Manager tienen una con ejemplos y plantilla. El nuestro tiene IDs, estado, fechas, nombre, descripción, probabilidad, impacto, plan de mitigación, acción, estado, responsable y registro de decisiones con fecha.
Así tenemos toda la trazabilidad. Pero cuéntanos cómo lo usarías con tu equipo. Porque por un lado, como PM, intentas registrar todos tus peores miedos, todo lo que podría salir mal. Pero también hay que involucrar a los stakeholders y al equipo, que también son interesados. ¿Cómo los involucras en la gestión de riesgos durante el ciclo de vida del proyecto?
Kiron Bondale:
Lo normal es gestionar el riesgo a lo largo del ciclo de vida, como decías. Al principio, con el patrocinador, cliente y líderes clave, hacer una identificación y análisis inicial. Luego, conforme avanzas y tienes más planificación, revisarlo de nuevo. Yo recomiendo dos disparadores: uno es por periodicidad (por ejemplo, cada dos semanas revisar riesgos con el equipo, añadir cambios, evaluar qué ha cambiado, qué es nuevo, dedicar 10-15 minutos en la reunión). El otro disparador es por eventos: cada vez que un riesgo se materializa en un problema importante o hay un cambio de alcance, revisamos el registro. Si algo ya no aplica, cerramos el riesgo, pero quizá haya nuevos riesgos que añadir. Así que hay dos momentos: por tiempo y por evento importante (hito, fase, problemas graves...).
Ben Aston:
Excelente consejo. Y ¿qué ocurre cuando la gestión de riesgos sale mal? ¿Dónde falla? Hablaste de contar la historia y contextualizar para los stakeholders, pero ¿dónde ves los mayores fallos?
Kiron Bondale:
Diría que hay dos ejemplos comunes. Uno, verlo como algo puntual, solo por cumplir con la gobernanza. Rellenan el registro con algunos riesgos genéricos y respuestas poco específicas, solo para marcar la casilla de que se ha pensado en ello, pero no actúan. Para mí es como no hacer nada.
Otro: el equipo principal sí hace bien la identificación, análisis y estrategias de respuesta, pero los responsables de ejecutar dichas respuestas no actúan. Quizá porque no se lo presentan de forma relevante o porque tienen demasiadas otras prioridades. Entonces, toda la gestión queda como ejercicio académico.
Ben Aston:
Sí.
Kiron Bondale:
Un tercer motivo puede ser que las organizaciones no aprenden de experiencias previas.
Ben Aston:
Cierto.
Kiron Bondale:
Al identificar riesgos, podrías usar juicio experto, consultores, casos de estudio, pero una fuente ideal es revisar los logs de problemas de proyectos anteriores parecidos, sacando lecciones sobre probabilidad, soluciones, impacto, etc. A menudo no se hace. Así que los fallos típicos son: solo hacer gestión de riesgos por cumplir; no ejecutar las respuestas; o no ampliar la visión y aprender de otros proyectos.
Ben Aston:
De acuerdo. Quiero profundizar en el tema de responsables de riesgos que no actúan ni se sienten comprometidos. Muchas veces la gente no quiere ser responsable porque eso implica hacer algo con el riesgo. Por defecto, la responsabilidad recae en el PM. ¿Cómo logras que los stakeholders asuman la propiedad del riesgo y evitas que sea siempre el PM el responsable?
Kiron Bondale:
Buena pregunta. Podrías poner al PM como responsable de todos los riesgos, pero quien gana o pierde más con el proyecto es la organización. Lo importante es si el proyecto es valioso, entonces pensar en los riesgos como un seguro. Y para que la gente asuma riesgos, no hay que saturarlos con detalles, sino solo lo relevante. Además, hay que definir bien los riesgos, causas, señales de materialización, etc. Haz tu tarea.
Si además las respuestas a riesgos impactan en los objetivos anuales de éxito de estas personas, tienen “skin in the game”. El fallo muchas veces es que a la persona asignada el éxito o fracaso del proyecto le da igual. Así que todo va asociado a tu capacidad de influir y persuadir como PM.
Ben Aston:
Eso es clave. De todas las recomendaciones, lo que más me llega es lo de contextualizar y contar la historia del riesgo al interesado, implicándole realmente. Muchos fallos vienen por hacer la gestión de forma mecánica, copiando y pegando riesgos pasados sin analizar ni sacar lecciones de los errores. Lo importante es comprometerse a gestionar riesgos durante todo el ciclo de vida, no solo al principio.
Kiron, para quien está empezando como gestor de proyectos y no sabe qué es una RAID log, ¿qué debe priorizar para que la gestión de riesgos funcione?
Kiron Bondale:
Que importe. Eso es. Puedes capturar mil riesgos y datos, pero si no importa, no sirve. Prefiero un PM que registre uno o dos riesgos cruciales y logre que los stakeholders actúen, a uno que apunte mil datos irrelevantes. Haz retrospectivas periódicas para medir si el esfuerzo en gestión de riesgos da resultados, si se implementan respuestas, si se reducen riesgos realmente. Si no sucede, habrá que cambiar el enfoque.
Ben Aston:
Genial. Kiron, muchísimas gracias por acompañarnos hoy.
Kiron Bondale:
Gracias, Ben.
Ben Aston:
¿Y tú qué opinas? ¿Cuáles son tus trucos y consejos para gestionar riesgos? Cuéntanos en los comentarios abajo qué te funciona y qué te ha fallado. Comparte cómo gestionas los riesgos. Si quieres aprender más y avanzar en tu trabajo, únete a la comunidad DPM en thedigitalprojectmanager.com/membership para acceder a nuestro equipo de Slack, plantillas, talleres (incluidos sobre gestión de riesgos), consultorías, eBooks y más. Si te gustó el episodio, suscríbete y deja una reseña honesta sobre el pódcast de DPM en Apple Podcasts. Amamos a nuestros oyentes. Recibimos pocas reseñas y sabemos que hay miles; ¡déjanos tu valoración! Hasta la próxima, gracias por escucharnos.
