Cómo realizar una retrospectiva efectiva y aplicar las lecciones aprendidas a futuros proyectos

Lee la transcripción:

 

Estamos probando la transcripción de nuestros pódcast usando un programa de software. Por favor, disculpa cualquier error ya que el bot no es 100% preciso.

Galen Low: Hola a todos, gracias por sintonizar. Mi nombre es Galen Low y soy parte de The Digital Project Manager. Somos una comunidad de profesionales digitales con la misión de ayudarnos mutuamente a mejorar habilidades, ganar confianza y conectarnos para maximizar el valor de la gestión de proyectos en el mundo digital. Si quieres saber más sobre esto, visita thedigitalprojectmanager.com.

Bien, hoy vamos a hablar sobre las retrospectivas de proyectos: cómo llevarlas a cabo de manera efectiva y cómo asegurar que las lecciones aprendidas realmente se traduzcan en mejoras para proyectos futuros.

Hoy me acompaña Payson Hall, fundador y consultor principal en Catalysis Group, quien ha ayudado a organizaciones a aprender de sus errores en proyectos por más de 30 años.

Payson, es un placer tenerte en el programa.

Payson Hall: Encantado de participar y de conocer a la audiencia.

Galen Low: Sí, en realidad me alegra que lo menciones porque hoy hacemos algo diferente. Estamos en vivo con nuestros miembros como audiencia en el estudio, y vamos a recibir preguntas en directo a través de nuestra comunidad de Slack. Michael también está en el estudio conmigo, así que él responderá algunas preguntas. Vamos a integrarlas en la conversación y puede pasar cualquier cosa. Así que será animado.

Muy bien, vamos a empezar. Pensé en comenzar con una pregunta interesante porque, según hemos estado hablando del tema y llevas décadas haciendo retrospectivas de proyectos como consultor en todo tipo de proyectos, incluidos proyectos de software e integración de sistemas a gran escala. Y quería preguntarte: cuando llegas como consultor externo a descubrir todos los pequeños secretos de un proyecto, ¿el equipo te ve como un amigo o un adversario? ¿Se sienten orientados, o más bien como si los estuvieran auditando?

Payson Hall: Normalmente es un intercambio amistoso. Quiero hacer una distinción importante porque una parte de mi trabajo como consultor consiste en hacer autopsias de proyectos. Si un proyecto se descarrila seriamente y hay preocupación de que alguien sabía lo que pasaba y no lo dijo, se parece mucho más a una auditoría.

De hecho, he trabajado con un auditor estatal en California y he revisado proyectos de TI de mil millones de dólares. Y en esos casos normalmente buscan construir un caso legal para que los abogados persigan al integrador de sistemas. Sin embargo, la retrospectiva más común y amistosa es la de equipos que simplemente terminan un proyecto.

Traigamos a alguien que facilite la mirada hacia atrás, ¿verdad? Eso es una retrospectiva: mirar atrás y preguntarse, ¿qué aprendimos? ¿Qué hicimos bien y quizá ni nos dimos cuenta en su momento? ¿Qué hicimos que, en retrospectiva, habría sido mejor hacer de otra forma? Es realmente una sesión de gestión de riesgos mirando por el retrovisor. ¿Qué puedo hacer mejor la próxima vez? ¿Qué hice brillante y quiero asegurarme de repetir?

Galen Low: Me gusta esa distinción, porque creo que algunos de los oyentes pueden sentir que toda retrospectiva es una autopsia, que parece que serán usados como evidencia en un juicio, que hay una búsqueda de culpables, en vez de, como dices, mirar atrás y aprender.

Payson Hall: Una de las únicas y grandes reglas sobre las retrospectivas—hay muchas formas de hacerlas—pero una regla importante que sugiero es que un gerente de proyecto nunca debe conducir su propia retrospectiva, porque algunas de las cosas que no salieron bien son directamente responsabilidad de quien la dirige. Y un buen facilitador logra evitar la búsqueda de culpables, hace que la conversación sea sobre qué pasó, cuándo pasó, qué podemos aprender. No es, "Galen, lo arruinaste".

Eso no es constructivo. La gente se pone a la defensiva y la charla se va por mal camino. Así que, tanto si traes a alguien de fuera como si es alguien de confianza del equipo con buenas habilidades de facilitación, necesitas un agente externo, sin interés en el proyecto, para guiar la conversación y que nadie salga "ensangrentado" al final.

Galen Low: Exacto, y ese es un buen punto de vista. Sé que muchos que escuchan intentan aprender cómo realizar su propia retrospectiva.

Y está bien; sé que es una realidad para muchos equipos de proyectos y mencionaremos algunos consejos que has aprendido. Pero me encanta tu consejo de que puede (o debería) ser alguien más quien lidere, para que no se convierta en una caza de brujas ni salga sangre tras la sesión, como dices.

Payson Hall: Y que llegue alguien con un conjunto distinto de supuestos. Piensa en los proyectos en los que has estado. Durante el proyecto, haces suposiciones de por qué algo no salió bien. Puede que tengas razón o no. Alguien sin esos prejuicios puede estar abierto a nueva información o maneras diferentes de interpretar los hechos.

Galen Low: Me encanta. Me gusta esa perspectiva de que alguien externo no está tan involucrado, ni tan apegado a un proyecto de 12-18 meses, y puede ver el bosque más allá de los árboles.

Tal vez podamos empezar por lo general. Para orientar a los oyentes, ¿puedes explicar qué es una retrospectiva de proyecto y por qué vale la pena hacer una?

Payson Hall: Gran pregunta. Bien, “retrospectiva” significa mirar atrás. La idea es llegar a un momento clave en el proyecto, o a su final, y parar un poco para reflexionar. ¿Qué aprendimos en este segmento? ¿Qué lecciones queremos aplicar al siguiente segmento o proyecto?

¿Qué hicimos bien casi por accidente? ¿Qué haríamos diferente si pudiéramos volver atrás, si pudiéramos enviarnos un mensaje en el tiempo? La idea es tomarse un respiro, ver los hechos del proyecto en contexto.

Como decías, ampliar la perspectiva para saber qué es importante y qué no. Hay cosas que simplemente son cisnes negros, eventos inesperados como el COVID, por ejemplo. No planeo para pandemias en futuros proyectos, pero si ocurrió, fue un golpe. Puede que haya alguna lección, pero algunas cosas simplemente pasan. Otras, puedes prever: necesitar 12 laptops, pedir 14 por si acaso; una vino dañada, eso fue muy inteligente porque había prisa.

Eso puede compararse: el costo de dos laptops extra contra la demora evitada es una lección valiosa. Quizás el extra pueda devolverse, o incluir en el contrato el derecho a devolverla si no se abrió.

Puede que esos mil dólares estén bien invertidos si evitan un retraso de tres semanas. Si en estos tres años trabajaste con hardware y cadenas de suministros, sabes de lo que hablo.

Galen Low: Exacto, ese ejemplo es muy bueno. Y recalca algo importante: las retrospectivas pueden ser momentos para reflexionar sobre cosas que salieron muy bien, ese detalle ingenioso que funcionó perfecto.

A veces, mirando atrás dices: "¿qué salió bien?", y la respuesta es algo genérico, como la buena comunicación. Pero en cuanto a lecciones claras, como cuando alguien reservó una sala alternativa y luego la principal se canceló y teníamos un respaldo listo: eso es algo excelente, que deberíamos aprender y aplicar la próxima vez. Y asegurarnos de poner en el contrato que si pedimos una laptop extra, podamos devolverla si no se usa, cubriéndonos y usando ese aprendizaje en proyectos futuros.

Y otra cosa importante que mencionaste es que las retrospectivas suceden al final de un proyecto o en momentos clave. Muchos piensan que sólo se hacen al final, como si ya fuera tarde, mirando atrás con resignación, cuando en realidad hay otros momentos durante el proyecto para reflexionar. Me gustaría volver a eso más adelante.

Payson Hall: Sí, es algo que tomamos de los enfoques ágiles, donde normalmente se hace una pequeña retrospectiva al final de cada sprint. He trabajado en proyectos donde las hacíamos en cada hito. En ágil dijeron: ¿Por qué no hacerlas periódicamente?

Al ser más frecuentes, son más pequeñas, el equipo entiende mejor el proceso. Creo que fue una gran innovación que cristalizaron los chicos de Ágil cuando hablaron de retrospectivas en cada sprint.

Galen Low: Ese cambio de mentalidad es importante: se puede hacer con regularidad y entonces es algo más pequeño. Porque, siendo abogado del diablo, muchas organizaciones dicen que quieren aprender de los errores, fracasar rápido, etc. Pero, a la hora de invertir tiempo en mirar atrás, prefieren pasar al siguiente proyecto. Sin embargo, al traer a alguien de fuera como facilitador, ¿en qué consiste? ¿Qué implica hacer una retrospectiva bien hecha? ¿Vale la pena? Si yo fuera la organización y digo: "Ya sufrimos durante el proyecto, mejor sigamos adelante, no hagamos retrospectiva, sigamos", ¿qué responderías?

Payson Hall: Muy buena pregunta. Cuando hablamos de mejora de procesos, hay que asegurarse de que el costo de aprender la lección no sea mayor que el valor de la mejora. ¿Qué implica una retrospectiva? Voy a darte un ejemplo. El contexto importa.

Si hablamos de proyectos multimillonarios, la retrospectiva requerirá más esfuerzo que en proyectos pequeños. Si es un proyecto conflictivo, será más demandante que uno que fue bien. Si el proyecto terminó mal y hay abogados involucrados, no estás haciendo una retrospectiva, sino una autopsia, y son muy costosas.

Por ejemplo, recientemente dirigí una retrospectiva con un equipo de unas 12 personas en un proyecto interno de 18 meses. Cumplió los requisitos, se atrasó un poco pero fue aceptable, no hubo abogados.

La pregunta fue: "¿Qué aprendimos? ¿Qué podemos hacer diferente?" Cada miembro dedicó entre 4 y 6 horas en preparación y reunión. Yo, como facilitador, dediqué unas 12 horas a preparar, facilitar y redactar el informe final.

El gerente de proyecto dedicó de 8 a 12 horas en reunir información y repasar. Así que en total, esta retrospectiva consumió unas dos semanas/persona.

Si vemos que el equipo trabajó 18 meses (mil semanas/persona), destinamos sólo 0,2% de ese tiempo a mirar atrás.

Sólo basta que la retrospectiva te ahorre dos semanas en el próximo proyecto para que justifique el costo.

Esto puede ser estructural, como una recomendación al PMO que ahorre tiempo y problemas, u orgánico, cuando el equipo aprendió algo como hacer revisión de código, que funcionó muy bien y pueden aplicar en siguientes proyectos. Al final, siempre hay hallazgos y recomendaciones que justifican esa inversión de dos semanas/persona.

Galen Low: Y en proyectos más pequeños, ¿hay un límite inferior? Si tu proyecto duró solo cuatro semanas, dedicar dos semanas a la retro parece poco rentable. ¿No la haces? ¿Las agrupas por pequeños proyectos?

Payson Hall: Ese error yo lo cometí al principio.

En una retrospectiva solo debe participar el equipo involucrado en el proyecto. Suponiendo que el equipo no esté en conflicto, es más fácil que haya sinceridad y autocrítica entre quienes compartieron el trabajo. Jamás la haría con extraños; después podrías juntar a los PM para analizar patrones comunes, pero la retro debe ser solo el equipo. Sobre el escalado a pequeños proyectos, totalmente posible. El proceso formal que mencionaré sirve incluso en ese caso. En proyectos largos, es fácil perder el contexto, así que dedicar algo de tiempo a repasar eventos significativos puede ser muy útil. Y en un proyecto corto, una hora juntos podría bastar, con algo de preparación del facilitador para entender el proyecto. Así que sí, se puede hacer de forma informal en una o dos horas.

Galen Low: Como dijiste antes, en ágil, por ejemplo, se hace una retro en cada sprint y eso ya implica ir recogiendo aprendizajes en todo el ciclo, no sólo al final. Y la suma de esas retrospectivas pequeñas puede requerir menos inversión al final. Así que, sí, me interesa saber cómo es el proceso cuando lleguemos a ese momento.

Payson Hall: Imagínate un equipo de ocho personas juntas durante una hora: ya son ocho horas/persona. Un par de horas de preparación, hablando con el PM, y podríamos tener todo el ejercicio completo en 12 horas, incluyendo una lista de puntos clave que aprendimos.

Galen Low: Y está el costo de oportunidad, ¿verdad? Si esa hora te permite encontrar una lección que te ahorre medio millón de dólares la próxima vez, la inversión se paga sola muchas veces. Así que el costo de no hacer una retro también debe considerarse.

Mencionaste antes que trabajabas con equipos internos en tu ejemplo. Muchos de los oyentes trabajan en agencias y suele suceder que el cliente no quiere pagar la retrospectiva porque es para que la agencia mejore. Los líderes de la propia agencia tampoco quieren invertir en ello porque no es tiempo facturable. He estado ahí, con un CEO entrando a decir “Todos fuera, esto es pérdida de tiempo”. Me abrió los ojos. Pero para los líderes de proyectos que ven el valor de una retro, ¿cómo pueden defender ese aprendizaje y convencer a los dueños de agencias y líderes de su utilidad, aunque no sea tiempo facturable?

Payson Hall: Quiero ser diplomático, pero si trabajara donde el CEO dice: “No necesitamos mejorar el próximo proyecto, no hay nada que aprender”, yo buscaría otro trabajo. Eso me preocuparía mucho. Antes de fundar Catalysis Group, trabajé en IBM servicios profesionales en proyectos multimillonarios. Normalmente el cliente no paga la retro; la organización asume el costo.

La organización lo asume porque puede mejorar la satisfacción del cliente, la eficiencia, y corregir procesos. En consultoría, simplemente calcula: ¿cuántas horas necesitas ahorrar para que valga? Un día de consultoría puede costar $2000, pero las horas administrativas no cuestan lo mismo. Si un grupo de seis personas dedica una hora y encuentra cómo ahorrar cuatro días en el siguiente proyecto, ya cubriste el costo de varias retros. Quizá esa organización que mencionas estaba en crisis y el CEO quería producir facturación, pero por lo general no es difícil de justificar. Y puedes empezar en pequeño, con proyectos cortos: juntar al equipo a la hora de comer, por ejemplo. Cuando yo era junior en Price Waterhouse, los socios nos invitaban a desayunos mensuales a las 7 am y nos creíamos “top” porque nos daban desayuno en un lugar elegante. Pero para los socios era que todos fuéramos dos horas antes al trabajo por una reunión de equipo, y encima felices porque nos alimentaban.

Así que en servicios profesionales, intentan optimizar. Puede haber excepciones si hay una urgencia, pero lo ideal es empezar pequeño y que la retro demuestre su valor. Y si en una retro o sesión de gestión de riesgos surge un aprendizaje que ahorra tiempo, ¡cuéntalo! Así convences a los ejecutivos de que es una buena inversión de tiempo. Empieza pequeño para que no suponga una gran inversión.

Galen Low: Empezar de a poco y recoger pruebas, ¿no? Mostrar que aporta valor y luego pedir perdón en vez de permiso. Conseguir evidencias es clave, porque quizá los líderes no ven claro que una retroaporta dinero, y hay oportunidades en juego. Mientras ocurre el proyecto hay horas facturables, podrían estar produciendo en vez de reunidos, y no perciben la prueba de que una retro evoluciona y optimiza el negocio.

Payson Hall: Uno de los resultados frecuentes de una retro es un documento o presentación con los puntos clave. Puede editarse para los directivos; quizá haya una versión interna y otra para compartir arriba. Si es un informe bien hecho, ayuda a que los directivos entiendan que, a veces, ellos mismos causan problemas, por ejemplo, reasignando recursos sin aviso o ahorrando en lo incorrecto. “No queremos pagar otra noche de hotel, así que te haremos volar toda la noche de costa a costa”. Sí, pero cuando llegues estarás hecho polvo. Hay formas sutiles de transmitir esas lecciones hacia la dirección ejecutiva para guiar su pensamiento hacia interacciones más productivas.

Galen Low: Me gusta esa visión estratégica, especialmente lo de que tengan una versión distinta, la de la dirección, con los aprendizajes, y que no toda la "ropa sucia" necesariamente esté en la versión de equipo.

Payson Hall: Exacto. En realidad, no me gusta tanto la metáfora de "ropa sucia". Una de las cosas más inteligentes que me han dicho es que la mayoría de las personas intenta hacer lo mejor posible con la información que tiene, y es fácil llegar a una retro y decir "no hicieron esto, fallaron aquí". Pero de eso no se trata. Hay que asumir que la gente actuó lo mejor que supo con la información que tenía. La clave es: ¿qué información tenías? ¿Cómo conseguirla antes la próxima vez? Si la gente siente que buscas a quién culpar, no conseguirás nada valioso.

Galen Low: Es cierto. Quiero adentrarme ahí: asumamos que todos aceptaron hacer una retrospectiva. ¿Cuál es tu proceso? ¿Puedes guiarme como si yo fuera el PM del proyecto?

Payson Hall: Supongamos que acabamos de terminar un proyecto de un año, con un equipo de 10 a 12 personas. Lo primero es reunirme contigo, el gerente de proyecto. El objetivo es generar buen clima. Si tú me invitaste, es fácil. Si me impusieron a ti desde arriba, tengo que ganarme tu confianza. Te explico el proceso, para que sepas qué esperar.

Te prometo: no habrá sorpresas. Todos los hallazgos los verás antes que nadie y podrás debatirlos, aportar datos o matices. Así ganamos confianza y no tienes miedo de que te vaya a “exponer”. Si el PM oculta cosas comienza el problema. Es como actuar sospechoso ante un policía: levanta sospechas. Mejor charlar abiertamente.

Tras establecer confianza y explicar el proceso, lo primero que busco es entender qué se pretendía hacer. ¿Hay documentos de definición, informes, memorandos? ¿Cuál era el objetivo? Las buenas prácticas dicen que debería existir un acta, una definición escrita de lo que pretendías.

Después, ¿cómo cambió durante el proceso? Busco documentación: requisitos, actas, ordenes de cambio. ¿Cómo fue la evolución? Todos los proyectos evolucionan. Si, por ejemplo, durante un proyecto de un año alguien actualizó PeopleSoft y eso retrasó todo un mes, puedo destacarlo: “esto no es culpa tuya, es un evento independiente, y en el futuro deberías prever y planificar por si ocurre”. Yo ayudo a poner en contexto eso, de modo que no parezca que te estás excusando.

Charlo contigo, reviso toda la documentación que consiga: definición, órdenes de cambio, gestión de riesgos, informes de avance. Consejo: una buena forma de aprender gestión de proyectos es leer un año de informes de estado. A veces hay pequeños eventos que escalan: el primer mes es algo menor, luego en un par de meses se vuelve problema. No es que el PM oculte el problema, sino que no percibió la magnitud. Me ha pasado revisando proyectos en hospitales, con mudanzas a nuevas instalaciones pospuestas mes tras mes y sin que el PM activara una alerta.

Revisaré reportes, buscaré anomalías, haré mi propia línea de tiempo para poder orientarme sobre los eventos principales. Luego converso contigo, relleno huecos y pido información extra si hace falta.

Ya con esto y tu confianza ganada, le pido al equipo que dedique 60–90 minutos de preparación. Que piensen en tres cosas: sucesos interesantes (personas que se casan, hijos), momentos brillantes (algo que salió bien por error o por creatividad), y baches/obstáculos (problemas técnicos, cambios de personal clave por enfermedad, etc.). Cada uno aporta dos o tres eventos significativos desde su punto de vista (efecto Rashomon).

En la sesión, preparo una línea de tiempo con los hitos clave del proyecto. Entrego post-its al equipo: ¿qué eventos recuerdan? “Cuando Susana se casó, fue divertido”. Esos eventos ubican el tiempo: cosas antes y después de algo memorable. Los ponemos en la línea, y luego: ¿qué salió bien? "Contratamos a Juan y superó nuestras expectativas". ¿Y baches? “Tuvimos tormenta y se cortó la luz”. Así construimos una línea de tiempo visual e integradora, que a su vez dispara recuerdos e historias.

Un ejemplo concreto: al construir la línea, el PM comenta que se atascaron en cierto momento porque cambiaron un stakeholder y no lo integraron bien. En la dinámica diaria, es fácil no verlo. Pero ahí es donde se detecta que ese cambio causó meses de turbulencias. Así, visualizando, surgen los patrones.

Luego viene gestión de riesgos retrospectiva: ¿cómo podríamos haber detectado a tiempo el suceso? ¿Podríamos haber aumentado la probabilidad de lo bueno o reducido lo malo? ¿Podríamos haber disminuido el impacto negativo o amplificado el positivo? Por ejemplo, si fue bueno comprar 14 laptops, quizás debería estipular el derecho de devolución en próximos contratos.

Todo esto se convierte en borrador del informe final: qué se planeó, qué se logró, coste y plazos, aciertos y tropiezos. El informe debe ser breve, no una “guía telefónica” que nadie leerá: una o dos páginas, o un resumen ejecutivo de las mejoras propuestas.

Galen Low: Hablemos de profundidad: con tantos hitos, algunos traerán 10, 15 cosas. ¿Se discuten a fondo o solo se identifican y luego se hace el análisis en las preguntas finales?

Payson Hall: Es un juicio del facilitador. Quieres dar espacio para el “ajá”, pero evitar irse por la tangente. Si la discusión es productiva unos 3-5 minutos, genial; luego puede derivarse fuera de la reunión y traer feedback después.

Galen Low: Por eso es clave la habilidad de facilitación. Se habla mucho en la comunidad: ¿debe un PM saber facilitar? Yo creo que sí, porque aunque no facilites, entiendes que no vas a resolver todos los problemas en esa sesión. Lo importante es encauzar a mejorar y aprovechar ideas y aprendizajes.

Payson Hall: Exacto. Esa es la ventaja de alguien externo con buenas habilidades de facilitación. Como ingeniero “en recuperación”, me resulta tentador adentrarme en los problemas técnicos, pero no es útil irse por las ramas. Hay que preguntar: ¿esto ayuda a avanzar? ¿Aporta al objetivo mayor?

Galen Low: Me gusta tu enfoque de que la sesión es un borrador de informe para compartir y que pueda ser útil a otros equipos o al propio equipo en el futuro. No hace falta quedarse en un solo problema si eso absorbe todo el tiempo.

Y es muy importante lo que decías: “esto es gestión de riesgos en retrospectiva”. Muchos ven la gestión de riesgos solo hacia el futuro y no conectan la retro con el riesgo, pero las lecciones se aplican tanto post como pre, y sirven de mensaje en una botella para avisar a otros cómo evitar o aprovechar sucesos.

Payson Hall: Totalmente. La clave es centrarse en qué funcionó y qué no, no en quién fue responsable.

Ese es el valor del facilitador. Esto no es una caza de brujas. He visto retrospectivas llevadas por pésimos facilitadores, obsesionados en “¿quién tuvo la culpa de esto?”. Y el equipo, admirablemente, se negaba a señalar, contestando: “No importa quién, lo importante es lo que ocurrió”. Descubrí después que el verdadero responsable tenía un problema personal, pero el equipo supo no exponerlo, y eso es admirable. No deberías depender de que el equipo sea tan disciplinado; mejor asegurar que sólo el equipo participe y que el facilitador sepa orientar la charla hacia el proceso, no el culpable. Como regla: siempre suponer que todos hicieron lo mejor que pudieron con la información y recursos disponibles. Si no tenían suficientes habilidades, es un tema de liderazgo y planificación, no personal, y puede mencionarse: “nos faltaban competencias en X, deberíamos reforzarlas en el futuro”.

Galen Low: Todo esto está en la base del proceso y preparación. Muchos me preguntan cómo crear seguridad psicológica en la sesión, y gran parte es antes: hablar con los posibles renuentes, explicar el proceso, dejar claro que se va a preguntar "qué", no "quién". Y si durante la sesión surge la búsqueda de culpables, ¿cómo lo rediriges?

Payson Hall: Lo paro de inmediato: amarilla. “Esto no va de culpar. Asumiremos que todos hicieron lo que pudieron. Hablemos de qué y no de quién”. Si pasa otra vez, vuelvo a pararlo e incluso haría una pausa para hablarlo aparte. “Esta no es la reunión para buscar responsables. Si quieres conversarlo, lo hacemos luego, pero aquí buscamos aprender qué funcionó y qué no”.

Galen Low: Y si el reporte dice, “faltaron habilidades en el equipo”, pero luego algún directivo lee entre líneas “esto fue culpa de Brad”, ¿se puede evitar esa lectura?

Payson Hall: Si la falta de habilidades es un tema personal, no debe ir al informe; eso lo gestiona el PM aparte. Lo que sí puede mencionarse: “El proyecto tuvo retos porque algunos recursos fueron reasignados”. No es culpa de nadie. Hay hallazgos y recomendaciones: “Aumentar flexibilidad de recursos” o “avisar con más antelación al PM si se reasignan”. Lo importante es destacar qué sucedió y cómo evitarlo en el futuro, sin personalizar.

Galen Low: Esa es la diferencia entre problemas del proyecto, de los que podemos aprender, y cuestiones de personal que no tienen cabida en el informe. El informe debe ser diplomático, transmitir mejoras de forma constructiva.

Payson Hall: Cierto. El informe debe ser diplomático. Como consultor, puedo decir que “el bebé es feo”, pero con tacto, sin inflamar el ambiente. Hay que presentar las recomendaciones de forma positiva: “En el futuro, sugerimos hacer X”, no “esto fue un desastre”. La gente hizo lo mejor posible con la información del momento.

Galen Low: Tras repasar el proceso, documentación, hitos, análisis, discusión de riesgos y aprendizaje, todo termina en el informe. Pero mucha gente dice: “¿Para qué hacer retrospectiva si luego el informe nadie lo lee o lo malinterpretan, y vemos los mismos errores una y otra vez?” ¿Cómo aseguramos que las recomendaciones conducen realmente al cambio y no quedan archivadas?

Payson Hall: Uno de los mayores problemas es que si entrego un informe de 30 páginas, nadie lo va a leer. Hay que ser breve y priorizar. Si tienes seis sugerencias, selecciona dos o tres para dirigir a los ejecutivos. El resto lo tendrás documentado y el equipo lo recordará para su siguiente proyecto. Hay hallazgos formales e informales. Y el componente informal es el que realmente transforma la organización desde dentro; es lo orgánico. La idea de juntar todos los informes en una gran base de datos es una utopía; ni una sola vez lo he visto funcionar en la práctica: es demasiado específico, nadie lo puede digerir todo. Así que mejor ir por pocos consejos clave y dejar que el resto cale en el equipo.

Por ejemplo, reservar un war room en proyectos grandes suele ser una lección recurrente. Si tras varias retros se sigue recomendando y nadie lo implementa, eventualmente los ejecutivos lo notarán después de escucharlo varias veces.

Galen Low: Y esa distinción es fundamental. Hay que distinguir entre comunicación estratégica (para la dirección) y el aprendizaje informal que se da en el equipo, que sin duda es enorme e incalculable. Cada participante en la retro llevará una “semilla” y la esparcirá en su próximo proyecto; eso es invaluable.

Payson Hall: Además, en las reuniones de planificación muchas veces el equipo recuerda riesgos recientes gracias a retros anteriores, y eso mejora la gestión y genera aprendizaje orgánico en toda la organización.

Galen Low: Y eso es fundamental, porque son las historias que nos contamos y transmitimos. El aprendizaje vive en nuestra memoria y cada situación es una nueva historia que compartir.

Ahora, abro espacio a preguntas del público. Una trataba sobre el "prespective" o “pre-mortem”. Ya respondiste que sí, forma parte de la gestión de riesgos y se puede hacer tanto antes como después. Al trabajar en ágil y tras cada retro de sprint, ¿haces además gestión de riesgos hacia adelante, o ambas se fusionan?

Payson Hall: Normalmente todo se fusiona. En una retro ágil se habla de barreras y de qué mejorar, lo que genera tareas para mitigar ese riesgo en el próximo sprint. Así que es la misma conversación, muy sano en realidad.

Galen Low: Completamente, porque ayuda a que esos aprendizajes se trasladen al futuro inmediato. Otra pregunta relevante era: a veces, los problemas del proyecto vienen de fuera (por ejemplo, recursos clave reasignados a otro proyecto). ¿Cómo informes de tal manera que puedas influir en cambios a nivel organizacional?

Payson Hall: Lo planteo como hallazgo: “El proyecto experimentó dificultades al reasignarse equipo a proyectos de mayor prioridad.” Lo importante es la redacción neutral. La recomendación sería aumentar la flexibilidad del staff, o avisar con mayor antelación sobre futuras reasignaciones. Así señalas la causa y cómo evitarla, sin personalizar.

Galen Low: Me gusta ese concepto de hallazgos. Una última pregunta: “¿Cuáles son los temas clave en los que enfocarse en una retro, dado el tiempo limitado?”

Payson Hall: Depende del contexto, pero lo más importante es: ¿existe una definición clara y compartida con los stakeholders y el cliente? Y, ¿tenemos un proceso de gestión de cambios efectivo? Eso suele ser origen de muchos problemas. Muchas veces no se trata de fallos en la estimación, sino de que el alcance creció sin ajustar recursos ni costes.

Galen Low: De acuerdo. Todo está relacionado y hay que elegir el enfoque más valioso según el contexto y stakeholders. Muy buena reflexión.

Creo que aquí se nos termina el tiempo, pero Payson, muchas gracias por tu tiempo. Ha sido un verdadero honor tenerte en el programa. Antes de despedir, ¿cómo pueden encontrarte para saber más sobre tu trabajo en Catalysis Group?

Payson Hall: Si vas a catalysisgroup.com, encontrarás información sobre formación y consultoría. En la sección de recursos hay algunos artículos descargables sobre gestión de riesgos, que te servirán mucho también para retrospectivas.

Galen Low: Genial. Doy fe de que Payson escribe de manera muy entretenida. Cada artículo suyo me ha hecho reír y además he aprendido algo valioso. Así que, si pensabas que las retrospectivas o la gestión de riesgos son temas aburridos, échale un vistazo a lo que escribe Payson. Pondré el enlace en las notas.

A los oyentes: espero que hayan extraído mucho valor. Si alguna pregunta quedó pendiente, la compartiremos en la comunidad y conversaremos sobre ella.

Payson Hall: Y si quieren escribirme con preguntas, estoy disponible y encantado de responder lo que surja después de colgar.

Galen Low: Listo, ya lo tenéis. Como siempre, si quieres unirte a la conversación con más de mil campeones de la gestión de proyectos digitales, ¡únete a nuestro colectivo! Entra a thedigitalprojectmanager.com/membership para saber más. Si te gustó lo que escuchaste hoy, suscríbete y mantente en contacto en thedigitalprojectmanager.com.

Hasta la próxima, gracias por escuchar.