Efectuar el pre-mortem

de un proyecto
por Gary Klein

Septiembre 2007
Reimpresión f0709a-e
 pa r a p r o c e s a r
Efectuar el pre-mortem de un proyecto
por Gary Klein
Los proyectos fracasan a una tasa espectacu-
lar. Una razón es que demasiadas personas son
reticentes a expresar sus dudas durante la fase
clave de la planificación. Al crear un ambiente
seguro para que expresen su desacuerdo
quienes conocen bien el emprendimiento y
están preocupados respecto de sus debilidades,
usted podrá mejorar las posibilidades de éxito
de un proyecto.
Un estudio realizado en 1989 por Deborah
J. Mitchell, de Wharton School; Jay Russo,
de Cornell; y Nancy Pennington, de University
of Colorado, descubrió que la retrospección
prospectiva –imaginar que un evento ya ha
ocurrido– aumenta en 30% la capacidad para
identificar correctamente las razones detrás
de los resultados futuros. Hemos utilizado la
retrospección prospectiva para crear un método
denominado pre-mortem que ayuda a los equi-
pos de proyecto a identificar riesgos desde un
comienzo.
Un pre-mortem es el opuesto hipotético de
un post-mortem. Un post-mortem en un en-
torno médico permite que los profesionales de
la salud y la familia sepan qué causó la muerte
del paciente. Todos se benefician con este pro-
cedimiento, menos, por supuesto, el paciente.
Un pre-mortem en un entorno de negocios se
efectúa al comienzo de un proyecto en lugar de
al final, de modo que el proyecto pueda mejo-
Copyright 2007 Harvard Business School Publishing Corporation. All rights reserved. Todos los derechos reservados.
rarse en lugar de ser sometido a una autopsia. A
diferencia de una típica sesión de crítica donde
se les pregunta a los miembros de un equipo
de proyecto qué podría fallar, el pre-mortem
opera bajo el supuesto de que el “paciente”
ha muerto, por lo cual se pregunta qué fue lo
que de hecho falló. La tarea de los miembros
del equipo es generar razones plausibles que
expliquen el fracaso del proyecto.
Un típico pre-mortem comienza después de
que se ha explicado el plan al equipo. El líder
comienza el ejercicio informando a todos que
el proyecto ha fracasado estrepitosamente.
Luego, durante unos minutos, todos los parti-
cipantes anotan de forma independiente todas
las razones que según ellos podrían explicar
el fracaso, especialmente el tipo de cosas que
normalmente no mencionarían como proble-
mas potenciales por temor a ser impolíticos.
Por ejemplo, en una sesión realizada en una
empresa de tamaño equivalente a una Fortune
50, un ejecutivo sugirió que la razón por la cual
“fracasó” un proyecto de desarrollo sustentable
de un costo de miles de millones de dólares
fue porque el interés declinó cuando se jubiló el
CEO. Otro atribuyó el fracaso a que el caso de
negocios se diluyó después de que un orga-
nismo gubernamental modificó sus políticas.
El líder luego pide a cada miembro del equipo,
comenzando con el jefe del proyecto, que lea en
3
voz alta una de las razones de su listado. Todos
enuncian una razón distinta hasta que todas
han sido registradas. Una vez que la sesión ha
terminado, el jefe de proyecto revisa el listado,
buscando maneras de fortalecer el plan.
En una sesión que analizaba un proyecto para
proporcionar a planificadores de campañas
militares aéreas algunos algoritmos computa-
cionales de última generación, un miembro del
equipo, que no se había pronunciado durante
la larga reunión de lanzamiento efectuada
anteriormente, señaló que uno de los algorit-
mos no encajaría fácilmente en algunas de las
computadoras portátiles usadas en terreno.
En consecuencia, el software tardaría horas
en ejecutarse mientras los usuarios requerían
resultados rápidos. Si el equipo no encontraba
una solución al problema, arguyó, el proyecto
era poco viable. Resulta que los desarrolladores
del algoritmo ya habían creado un poderoso
atajo, el cual no habían querido mencionar. Se
utilizó el atajo y el proyecto fue un gran éxito.
En una sesión para evaluar un proyecto de
investigación en una organización distinta, un
alto ejecutivo sugirió que el proyecto había
“fracasado” debido a que no hubo suficiente
tiempo para preparar un caso de negocios
antes de una inminente evaluación corporativa
de iniciativas de producto. Sin embargo, en los
90 minutos que duró la reunión de lanzamiento,
4 harvard business review
nadie mencionó las restricciones de tiempo.
El jefe de proyecto rápidamente modificó el
plan, tomando en cuenta el ciclo de decisiones
corporativas.
Aunque muchos equipos de proyectos efec-
túan un análisis de riesgo antes del lanzamiento,
el método de retrospección prospectiva usada
por el pre-mortem ofrece beneficios que otros
métodos no proporcionan. De hecho, el pre-
mortem no sólo ayuda a los equipos a identi-
ficar tempranamente problemas potenciales.
También reduce el tipo de actitud temeraria
que a menudo adoptan las personas que han
invertido demasiado en un proyecto. Además, al
describir debilidades que nadie más ha mencio-
nado, los miembros de un equipo se sienten va-
lorados por su inteligencia y experiencia, y otros
aprenden de ellos. El ejercicio también sensibi-
liza al equipo para que detecte tempranamente
señales de problemas una vez que se inicia el
proyecto. Al final del día, un pre-mortem podría
ser la mejor manera de evitar la obligación de
efectuar un doloroso post-mortem.
Gary Klein (gary@decisionmaking.com) es el
científico jefe de Klein Associates, una división de
Applied Research Associates, en Fairborn, Ohio.
Es autor de Sources of Power: How People Make
Decisions (MIT Press, 1998) y de The Power of
Intuition (Doubleday, 2004).
Reimpresión F0709A-E