Capítulo 21

Recopila
las lecciones
aprendidas
Por Ray Sheen
Aunque cada proyecto es diferente, siempre puedes —y
debes— aprender de lo que acabas de hacer. Las
compañías
que cuentan con una oficina de gestión de proyectos reali-
zan una sesión de lecciones aprendidas —a veces llamada
«revisión post mortem» o «examen a posteriori»— como
parte integrante de la finalización de cada proyecto. Las
empresas que no cuentan con esta oficina intercambian
ideas de manera informal cuando los miembros del equipo
rememoran lo sucedido. En cualquier caso, es importante
recopilar lo aprendido cuando la experiencia aún está
fresca.
Por ejemplo, hace poco llevé a cabo un pequeño pro-
yecto que solo duró unos meses, y el equipo quedó para
cenar justo después de poner el punto final para hablar de
lo que había salido bien y lo que había salido mal. Fue una
Finalización
conversación fantástica, y el próximo proyecto será aún
mejor gracias a ella. Puesto que el proyecto duró poco y el
equipo fue siempre el mismo, resultó relativamente fácil
hablar de todos los aspectos del proyecto, desde la plani-
ficación hasta la finalización. Cuando volvimos de la cena,
otro miembro del equipo y yo actualizamos la carpeta
del proyecto con notas sobre las lecciones que habíamos
aprendido.
En cambio, cuando gestioné el departamento de ingenie-
ría de una compañía Fortune 500, algunos de los proyectos
duraron tres años e, inevitablemente, algunos miembros de
los equipos iban cambiando con el tiempo. Recuerdo una
sesión de lecciones aprendidas con un equipo de desarrollo
de productos que dirigí justo después de lanzar un nuevo
producto. Por desgracia, solo uno de los asistentes a la reu-
nión había participado en el proyecto desde el principio y,
 además, había cambiado de función. Vistas las cosas desde
nuestra perspectiva, nos resultó más fácil detectar errores
que el equipo original había cometido en el plan del pro-
yecto, pero no pudimos determinar qué sucesos o motivos
causaron dichos errores, puesto que la mayoría de nosotros
no habíamos participado en el proceso. Desde entonces,
adopté un nuevo enfoque para los proyectos a largo plazo:
empecé a recopilar lecciones después de completar cada
fase, en lugar de esperar a la finalización del proyecto; así,
el equipo podía analizar de forma clara y precisa lo ocu-
rrido. Además, eso permite incorporar antes las lecciones
aprendidas.
Cuando dirijo una sesión de lecciones aprendidas, sigo
un proceso de cuatro pasos:

1. Evaluar el estudio de viabilidad

La primera cuestión que formulo es: «¿Ha conseguido el
proyecto generar el resultado esperado?». El objetivo no
es juzgar el trabajo del equipo, sino evaluar si el proyecto
ha satisfecho las expectativas del equipo directivo de la
empresa tal como se definieron en la selección y la
aproba-
ción del proyecto, así como si esos objetivos eran
realmente
alcanzables. Los proyectos se aprueban según los benefi-
cios que puedan reportar a la empresa: un crecimiento de
las ventas, una reducción de costes, la mejora de plazos,
una disminución de defectos o un incremento de la capa-
cidad. Fuese cual fuese el beneficio esperado, ¿se ha
hecho
realidad? De lo contrario, ¿eran erróneos los supuestos y
las justificaciones en los que se basó el proyecto original-
mente? Analizando minuciosamente estas cuestiones y co-
municando las conclusiones al patrocinador del proyecto,
un equipo puede mejorar el proceso que sigue la organi-
zación para seleccionar proyectos y establecer objetivos
realistas en el acta de constitución de un proyecto. Si tu
empresa cuenta con una oficina de gestión de proyectos,
normalmente será la encargada de incorporar dichas lec-
ciones en el proceso de iniciación de proyectos.
2. Evaluar el plan del proyecto
A continuación pregunto: «¿Era el plan razonable y ade-
cuado para el objetivo y las condiciones empresariales del
proyecto?». Analizo si no incluía algunas actividades que
eran necesarias e incluía alguna que fuera innecesaria.
También me fijo en las estimaciones de costes y plazos de
cada actividad. Estas estimaciones tenían que considerar
2. las condiciones empresariales y tecnológicas al comenzar
el
proyecto, así como ofrecer márgenes razonables. Después,
analizo la evaluación de riesgos inicial para determinar
qué
riesgos no se previeron, qué riesgos fueron clasificados de
forma errónea y qué respuestas resultaron inadecuadas.
Por último, presto atención a las prácticas que se estable-
cieron para la comunicación del equipo y las partes inte-
resadas. ¿El plan daba lugar a suficientes ocasiones para
intercambiar información y poner al día a todo el mundo?
¿Las conversaciones se realizaron en el momento
adecuado
y con las personas adecuadas? ¿Las decisiones se tomaron
en el momento oportuno?
3. Evaluar la metodología de gestión
La tercera pregunta que formulo es: «¿Fueron positivos
los sistemas y procedimientos para la gestión de proyectos
con los que cuenta la organización?». Para responder, me
fijo en lo siguiente: si la compañía tiene procedimientos,
plantillas o listas de comprobación; si están actualizados
y son pertinentes —si es que existen—; si las revisiones y
los puntos de control establecidos fueron adecuados para
el
proyecto; y hasta qué punto resultó útil el sistema de infor-
mación establecido para comunicar los planes y el estado
del proyecto a todos los agentes implicados.
Las lecciones aprendidas suelen incorporarse a los proce-
dimientos y sistemas para la gestión de proyectos que
tiene
la compañía. Cuando trabajé como consultor para un fabri-
cante subcontratado de tamaño medio, me sorprendió des-
cubrir que no contaba con procedimientos centralizados
para
la gestión de proyectos, aunque todo su trabajo se basaba
justamente en proyectos. La compañía se limitaba a
contratar a gestores de proyectos con experiencia y les
daba rienda
suelta. Esta manera de proceder provocaba una
«mentalidad
de estrella del rock» entre los gestores de proyectos y a
una
falta de coherencia general. Si a una persona la destinaban
a un nuevo equipo de proyecto, tenía que aprender nuevas
técnicas de programación y elaboración de presupuestos e
informes. La duplicación de sistemas y la consiguiente
inefi-
 ciencia en la ejecución de los proyectos tenía un precio
muy
alto para la organización. Las personas que participaban en
distintos proyectos tenían que saber cómo utilizar
múltiples
formatos de informes y de reuniones, a menudo contradic-
torios; lo que solía provocar que tuvieran que rehacerlo
todo.
La compañía constituyó una oficina de gestión de
proyectos
y, durante los siguientes cuatro meses, creamos los
procedi-
mientos y sistemas necesarios para planificar y ejecutar
pro-
yectos de forma coordinada y simplificada.
4. Evaluar el desempeño de las personas
Por último, pregunto: «¿Qué comentarios puedo dar a los
miembros del equipo acerca de su desempeño —bueno o
malo— y qué debo reportar a sus supervisores?».
Recomiendo
seguir este paso, aunque no sea necesario oficialmente,
con
los principales miembros del equipo. Normalmente, les
pido
a todos los miembros que me señalen a los «superhéroes»
del
equipo. De este modo, se refuerza públicamente la
importan-
cia de dar lo mejor y se minimiza la sensación de que el
líder
del proyecto pueda estar pecando de favoritismo. Con las
per-
sonas cuyo trabajo es deficiente hablo individualmente.
Por
supuesto, cualquier método específico utilizado para llevar
a
cabo evaluaciones de desempeño debe seguir las
directrices
del departamento de recursos humanos.
3. Un proceso para recopilar las lecciones aprendidas
fomenta
la mejora continua. No obstante, según mi experiencia, na-
die lee los informes que resultan de estas sesiones, así que
no pongas todas tus esperanzas en la documentación que
hayas guardado en la carpeta del proyecto. Convierte las
lecciones en una lista de acciones para que la oficina de
gestión de proyectos o los miembros de tu equipo puedan
incorporarlas en el siguiente proyecto. Utiliza las ideas de
inmediato para actualizar las listas de comprobación, mo-
dificar los procesos de revisión e introducir cualquier otro
ajuste necesario antes de que se inicie el próximo
proyecto.
Ray Sheen es profesor y consultor en gestión de proyectos
y
procesos. Tiene más de 25 años de experiencia en
liderazgo
de proyectos en defensa, desarrollo de productos, industria
manufacturera y sistemas informáticos, entre otros secto-
res, y ha dirigido una oficina de gestión de proyectos en el
negocio de distribución eléctrica de General Electric.

Glosario
Acta de constitución [Charter]. Descripción escrita y con-
cisa del trabajo previsto en un proyecto. El acta de cons-
titución suele contener el nombre del patrocinador, los
beneficios que el proyecto tendrá para la organización,
una descripción de sus objetivos, los plazos previstos y un
presupuesto.
Aparcamiento de la corrupción del alcance [Scope creep
parking lot]. Lista de ideas adicionales o florituras que se
han propuesto durante el desarrollo del proyecto. La idea
es «aparcarlas» para poder volver a ellas más adelante, sin
poner en peligro el proyecto actual.
Comité directivo del proyecto [Project Steering Commit-
tee]. Grupo de personas que aprueba el acta de constitu-
ción del proyecto, consigue recursos y juzga todas las peti-
ciones para cambiar elementos clave del proyecto, como
los
entregables, el calendario y el presupuesto.
Corrupción del alcance [Scope creep]. Tendencia —a me-
nudo fruto de una presión ejercida por algunas partes inte-
resadas— de introducir cambios que sobrepasan el alcance
del proyecto y pueden causar estragos en el calendario, la
calidad del trabajo y el presupuesto.
Costes hundidos [Sunk costs]. Inversiones del proyecto
que ya no son recuperables.
Diagrama de red [Network diagram]. Diagrama de progra-
mación que indica todas las relaciones entre tareas y
revela
la ruta crítica. En general es sinónimo de diagrama PERT.
Diagrama Gantt [Gantt chart]. Diagrama de barras que
indica cuándo deben comenzar y acabar las tareas de un
proyecto.
Diagrama PERT [PERT chart]. Véase Técnica de revisión
y
evaluación de proyectos.
Divergencia [Variance]. Diferencia —positiva o negativa
—
entre los resultados reales y los resultados previstos en el
presupuesto. Los gestores utilizan las divergencias para
identificar aspectos problemáticos y ámbitos con un
desem-
peño excepcional.
Estructura de desglose de trabajo (EDT) [Work
Breakdown
Structure]. Rutina de planificación que desglosa el obje-
tivo del proyecto en las numerosas tareas necesarias para
alcanzarlo. También estima el tiempo y el dinero
necesarios
para completar dichas tareas.
Evaluación posterior [Post-evaluation]. Una reunión en
la que el equipo del proyecto explica y documenta su pro-

Oficina de gestión de proyectos [Project management

office. Oficina corporativa —normalmente en una com-
pañía grande— que establece procesos y plantillas para
guiar a los gestores de la organización en la planificación
y ejecución de proyectos, orienta a las personas que quie-
ran efectuar dichos procesos y, a veces, gestiona proyectos
concretos.