Guías HBR
Gestión de
Proyectos
REVERTÉ MANAGEMENT
Barcelona, México
HARVARD BUSINESS REVIEW PRESS
Boston, Massachusetts
Guías Harvard Business Review
Equípate con los consejos necesarios para tener éxito en tu trabajo de la mano de
la publicación más fiable del mundo de los negocios. En las Guías HBR
encontrarás una gran cantidad de prácticas y consejos básicos de expertos en la
materia que te ofrecen una solución inteligente para enfrentarte a los desafíos
laborales más importantes.
Títulos publicados en esta colección:
Guías HBR: Controla el Estrés en el Trabajo
Guías HBR: Presentaciones Persuasivas
Guías HBR: Céntrate en el Trabajo Importante
Guías HBR: Gestión de Proyectos
Contenidos
Qué aprenderás
Visión de conjunto
1. Las cuatro fases de la gestión de proyectos
En qué consisten la planificación, el desarrollo, la ejecución y la finalización del
proyecto, y cómo se superponen dichos procesos
2. El elenco de personajes
Quién es quién en la gestión de proyectos
Fase 1: PLANIFICACIÓN
3. El acta de constitución
Cómo dar la orden de inicio
4. La gestión de la «confusa fase inicial»
No podemos eliminar la incertidumbre en las primeras etapas de un proyecto
complejo, pero podemos gestionarla
LOREN GARY
5. El examen pre mortem
Aprende de tu proyecto mientras aún esté vivito y coleando
GARY KLEIN
6. ¿La corrupción del alcance encarece tu proyecto o lo revaloriza?
Delinea límites estrictos en el alcance de tu proyecto, pero sé flexible si surgen
grandes oportunidades
LOREN GARY
Fase 2: DESARROLLO
7. Fija las prioridades antes de iniciar el proyecto
Tres pasos para que no te salgas del buen camino
RON ASHKENAS
8. Estimula la productividad mediante las cajas de tiempo
Consejos para mantener el calendario de tu equipo —y el tuyo— bajo control
MELISSA RAFFONI
9. Planifica el trabajo
Pon los bueyes antes del carro
10. Estudio de caso HBR: ¿Lanzarse al fracaso?
¿Cuándo es más importante la velocidad que la calidad?
TOM CROSS
11. Empieza el proyecto sobre una buena base
Dirige tu proyecto hacia el éxito mediante un lanzamiento bien planeado
12. La disciplina de los equipos
La responsabilidad mutua conduce a resultados asombrosos
JON R. KATZENBACH Y DOUGLAS K. SMITH
Fase 3: EJECUCIÓN
13. Reuniones eficaces
Orienta bien las reuniones e infunde energía y sentido a tu proyecto
14. El enfoque adaptativo de la gestión de proyectos
Qué hacer cuando tus herramientas para tomar decisiones dejan de ser útiles
frente a la incertidumbre
15. Un buen proyecto también puede fracasar
Riesgos que conllevan los grandes proyectos y cómo gestionarlos
NADIM F. MATTA Y RONALD N. ASHKENAS
16. Seguimiento y control
No tengas miedo de revisar tu plan
RAY SHEEN
17. Gestiona los problemas humanos de tu equipo
Asegúrate de que los miembros del equipo se concentran en sus tareas, cumplen
su parte del trabajo, trabajan juntos y satisfacen los criterios de calidad
18. Herramientas para la cooperación y el cambio
Qué hacer cuando la gente no se pone de acuerdo en cuáles son los objetivos o
en cómo conseguirlos
CLAYTON M. CHRISTENSEN, MATT MARX, Y HOWARD H.
STEVENSON
No pierdas más dinero —ni tiempo— intentando recuperar el ya perdido
Cómo evitar perseguir costes hundidos
JIMMY GUTERMAN
Fase 4: FINALIZACIÓN
20. Delega autoridad y control
Evalúa tu éxito antes de poner el punto final
RAY SHEEN
21. Recopila las lecciones aprendidas
Cuatro pasos para realizar eficazmente el examen a posteriori
RAY SHEEN
Glosario
Qué aprenderás
Te han propuesto que dirijas un proyecto. Agradeces el voto de confianza que
han depositado en ti, pero ¿te estás estresando porque no tienes ni idea de por
dónde empezar? ¿Te preocupa que las distintas partes implicadas tiren de ti en un
millón de direcciones diferentes y que te impidan definir objetivos claros, por no
hablar de cumplir con los plazos y el presupuesto? ¿Cómo vas a decidir cuándo
has de seguir con tu plan original y cuándo has de ser flexible? Todos los
miembros de tu equipo soportan muchas presiones, ¿cómo vas a mantenerlos
motivados?
Con esta guía obtendrás la confianza y las herramientas necesarias para gestionar
proyectos de forma eficaz.
Elegir al equipo adecuado y a mantenerlo a pleno rendimiento.
Evitar la «corrupción del alcance».
Centrarte en tareas fundamentales y trazar una secuencia lógica.
Entender los diagramas Gantt y PERT.
Conseguir que los miembros del equipo trabajen todos a una.
Mantener informadas a todas las partes interesadas.
Evaluar el éxito de tu proyecto.
Decidir cuándo es momento de retirarse.
Recopilar —y aprovechar— las lecciones aprendidas.
Visión de conjunto
Capítulo 1
Las cuatro fases de la gestión de proyectos
Si estás coordinando el desarrollo de una web, el diseño de un coche, el traslado
de tu departamento a unas nuevas instalaciones, la actualización del sistema
informático o cualquier otro proyecto —grande o pequeño—, siempre pasarás
por estas cuatro etapas: planificación, desarrollo, ejecución y finalización.
Aunque cada una de estas fases tenga características singulares, se superponen.
Por ejemplo, normalmente empezarás a planificar con un presupuesto y una
fecha de finalización aproximados. Una vez estés en las fases de desarrollo y
ejecución, definirás e implementarás los detalles del plan del proyecto. Eso te
aportará nueva información, por lo que revisarás el presupuesto y la fecha de
finalización. Dicho de otro modo, planificarás mejor a partir de tu mejor
conocimiento de la situación general.
La siguiente tabla describe las actividades de cada fase, así como las habilidades
y herramientas necesarias para realizar el trabajo:
Planificación: cómo diseñar un proyecto
Cuando pensamos en la planificación de un proyecto, casi de inmediato nos
viene a la mente su programación temporal, aunque en realidad no llegaremos a
ese punto hasta la fase de desarrollo. El auténtico objetivo de la planificación es
definir los fundamentos: qué problema queremos resolver, quién participará en el
proyecto y qué se hará.
Determinar cuál es exactamente el problema que se ha
de resolver
Antes de empezar, es importante invertir un tiempo en detallar qué asunto en
concreto se abordará en el proyecto. No siempre es obvio.
Pongamos por caso que el director de sistemas informáticos te ha pedido a ti,
que eres el gerente de tecnologías informáticas, que crees una nueva base de
datos y un nuevo sistema para introducir la información. Seguramente, tendrás
muchas ganas de iniciar el proyecto lo antes posible para, así, resolver esos
problemas con los que estás lidiando desde hace algún tiempo. Pero
¿conseguirás de este modo resolver el problema de la empresa? Si quieres que el
proyecto tenga más probabilidad de éxito, primero debes ir más allá de los
síntomas ya observados: «No podemos sacar los datos con la suficiente rapidez»,
y «Tengo que filtrar cuatro informes diferentes para compilar una simple
actualización de la actividad reciente de mis clientes». Tienes que localizar
aquellos problemas subyacentes que la organización está intentando resolver.
Antes de diseñar la base de datos, plantéate unas cuantas cuestiones: qué tipo de
datos son necesarios, qué se hará con ellos, para cuándo es necesaria una
solución, etcétera. Si no lo haces, correrás el riesgo de malgastar tiempo y dinero
creando una solución demasiado simple, o demasiado compleja, tardía o
sencillamente inútil para los usuarios.
Identificar a las partes interesadas
Verás más claramente el auténtico problema cuando determines quiénes son las
partes interesadas. Es decir, cuando te plantees a qué cargos o personas afectarán
las distintas actividades o los resultados del proyecto, quién aportará los recursos
necesarios (personas, espacio, tiempo, herramientas y dinero) y quién utilizará el
producto del proyecto o se beneficiará de él. Las partes interesadas trabajarán
contigo para enunciar qué significa exactamente que el proyecto tenga éxito.
Consigue que definan qué esperan del proyecto y qué están dispuestas a aportar
para conseguirlo. Además, si alguna de las partes interesadas cambia de idea a
mitad de camino, debes estar preparado no solo para dar una respuesta a los
nuevos participantes, sino también para incluir a los otros en cualquier decisión
que implique redirigir el proyecto.
Tanto si estás gestionando el proyecto en una empresa como si trabajas de asesor
independiente, es fundamental que te respalden las personas para las que
trabajas. En algunas ocasiones, puede que lo vean todo color de rosa y que te
exijan una enorme cantidad de trabajo en un plazo imposible; en otras, quizá
esperen que obres milagros con unos recursos de material o personal
insuficientes. Como gestor del proyecto, deberás asegurarte de que los requisitos
y los recursos se correspondan equitativamente... o te verás abocado al fracaso.
Definir los objetivos del proyecto
Una de las tareas de planificación más difíciles es la de combinar las
expectativas de las distintas partes interesadas en un conjunto coherente y
manejable de objetivos. El éxito del proyecto se medirá en función de hasta qué
punto se satisfagan dichos objetivos. Cuanto más explícitos sean desde un
principio, menor desacuerdo encontrarás después respecto a si has cumplido o no
las expectativas. De todos modos, en la fase de planificación aún quedan muchas
cosas en el aire, por lo que cada cierto tiempo tendrás que revisar esos objetivos
marcados, a medida que vayas recabando información sobre lo que debes lograr.
Cuando definas los objetivos, piensa en la palabra METAS. Un objetivo debe
ser:
Medible
Específico
Temporalmente limitado
Alcanzable
Sensato
Supongamos que el actual seguro médico de una empresa no está ofreciendo un
nivel de servicio acorde con las cuotas que pagan los empleados; por ello, el
departamento de recursos humanos ha recibido el encargo de buscar un nuevo
proveedor. Los objetivos METAS del proyecto podrían ser los siguientes:
Evaluar ‹alcanzable› al menos a seis ‹medible› proveedores que cumplan los
criterios mínimos del departamento en cuanto a calidad del servicio.
Recomendar ‹alcanzable›, en el Consejo de Administración de junio
‹temporalmente limitado›, los tres ‹específico› que ofrezcan la mejor y
mayor cobertura a un coste que sea al menos un 10% ‹sensato› más bajo
que la actual contribución de la compañía por empleado.
Cuando definas los objetivos de tu proyecto ten en cuenta los siguientes factores:
Calidad. Identifica los criterios de calidad, y determina cómo cumplirlos y
evaluarlos.
Organización. Calibra los objetivos en función de las personas y los recursos
que tienes a tu disposición.
Comunicación. Determina qué información necesita cada una de las partes
interesadas y cómo facilitársela.
Determinar el alcance, los recursos y las principales
tareas
Muchos proyectos fracasan porque o bien se abarca más de lo debido y, por lo
tanto, se subestima enormemente el tiempo y el dinero necesarios, o bien porque
no se ha tenido en cuenta una importante parte del trabajo. Una herramienta
bastante útil para evitar estos problemas es la estructura de desglose de trabajo
(EDT), que ayuda a determinar el alcance y las tareas del proyecto, así como a
establecer estimaciones (encontrarás un ejemplo más adelante en este capítulo).
El concepto subyacente consiste en subdividir actividades complejas en sus
unidades más manejables.
Para crear una EDT:
Pregúntate: «¿Qué se tiene que hacer para conseguir X?».
Sigue haciéndote la misma pregunta hasta que la respuesta esté desglosada en
tareas que ya no se puedan subdividir más.
Calcula cuánto tiempo será necesario para realizar las tareas y cuánto costarán en
términos de dinero y de horas por persona.
Normalmente, una EDT consta de tres a seis niveles de actividades subdivididas.
Cuanto más complejo sea el proyecto, más niveles contendrá. Como norma
general, no deberías llegar a tener más de veinte: solo un proyecto inmenso
podría abordar tantos.
Ahora, durante la fase de planificación, no te preocupes por la secuencia de
actividades. Ya te encargarás de la programación en la fase de desarrollo. Utiliza
la EDT para crear un marco que irás rellenando a medida que tengas las ideas
más claras sobre las limitaciones de personal, presupuesto y tiempo de ejecución
del proyecto. Abultar las estimaciones es una manera aceptable de reducir
riesgos, pero hazlo abiertamente y explica a las partes interesadas por qué lo
haces.
Una cuidadosa planificación te permitirá hacer una estimación bastante ajustada
de cuántas personas —con qué habilidades— serán necesarias para desarrollar
un proyecto. También podrás hacerte una buena idea de cuánto tiempo llevará su
ejecución.
Prepararse para soluciones intermedias
El tiempo, el coste y la calidad son las tres variables relacionadas que suelen
determinar lo que puedes lograr.
Calidad = tiempo + coste
Modifica cualquiera de estas variables y cambiará el resultado. Por supuesto,
este tipo de modificaciones a menudo se producen en medio del proyecto. Por
ejemplo, si el plazo para crear un nuevo sistema de gestión de la base de datos de
repente se reduce a la mitad, o bien tendrás que contratar al doble de personal, o
bien tendrás que conformarte con un sistema más sencillo que el planeado
originalmente. No dejes que las trivialidades interfieran en las actividades
esenciales del proyecto. La clave es establecer un nivel de calidad que satisfaga
las necesidades de las partes interesadas.
Saber desde el principio cuál es la variable más importante para cada una de las
partes interesadas te ayudará a hacer los cambios adecuados a lo largo del
proyecto. Es tu responsabilidad mantener a todo el mundo informado de
cualquier modificación y de las consecuencias que conlleva en términos de
tiempo, coste y calidad.
ESTRUCTURA DE DESGLOSE DE TRABAJO
Ejemplo de un documento de planificación
Elabora una estructura de desglose de trabajo (EDT) para que no se te pase por
alto ninguna parte importante de una actividad compleja y para no subestimar el
tiempo y el dinero necesarios para realizar el trabajo. Utiliza tantas páginas
como sea necesario.
DESCRIPCIÓN DEL PROYECTO GLOBAL
El «proyecto global» consiste en migrar tres servidores web y las bases de datos
a un nuevo centro de procesamiento de datos (CPD). Es necesario instalar cinco
nuevos servidores en el nuevo centro: estos servidores replicarán los servidores
de producción existentes en el antiguo centro de datos. Los nuevos servidores se
construirán con las mismas especificaciones que los antiguos, ejecutarán la
misma aplicación y tendrán el mismo contenido. Una vez instalado el nuevo
equipamiento, se pondrá a prueba para comprobar su funcionalidad. Los sitios
tendrán una fecha de migración y activación. Por último, se retirará el
equipamiento antiguo y se volverá a incluir en el inventario.
TAREA PRINCIPAL
Obtener el equipamiento.
Subtareas de nivel 1
Comprar tres servidores web y dos bases de datos.
Enviar el equipamiento al nuevo centro de datos.
Subtareas de nivel 2
Preparar el pedido y comprar servidores.
Avisar al centro de datos de la llegada del equipamiento.
Duración de la subtarea
7 días
TAREA PRINCIPAL
Instalar equipamiento.
Subtareas de nivel 1
Instalar físicamente el hardware.
Cargar sistemas operativos.
Cargar aplicaciones.
Replicar el contenido en los nuevos servidores.
Subtareas de nivel 2
Colocar y cablear el nuevo equipamiento en el centro de datos y asegurar
conectividad física y de red.
Cargar sistemas operativos base para los servidores web y de bases de datos.
Cargar el software de aplicaciones, incluido el software del servidor web, las
aplicaciones de la base de datos y cualquier elemento dependiente.
Copiar la configuración de los sitios de producción, transferir los datos a los
nuevos servidores y cargarlos adecuadamente.
Duración de la subtarea
8 días
TAREA PRINCIPAL
Poner a prueba el equipamiento.
Subtareas de nivel 1
Poner a prueba las máquinas.
Subtareas de nivel 2
Asegurar la conectividad de red, así como la funcionalidad y la integridad del
acceso a la base de datos y la web.
Duración de la subtarea
2 días
TAREA PRINCIPAL
Activar el nuevo equipamiento.
Subtareas de nivel 1
Migrar al nuevo sitio de producción.
Comprobar la integridad del contenido y los datos.
TAREA PRINCIPAL
Subtareas de nivel 1
Trasladar el acceso a la web y la base de datos a los nuevos sitios.
Llevar a cabo una serie de test predeterminados para verificar que los datos sean
exactos y que se haya captado y aplicado cualquier actualización realizada desde
la replicación.
Duración de la subtarea
2 días
TAREA PRINCIPAL
Volver a comprobar el equipamiento.
Subtareas de nivel 1
Dejar encendidas las máquinas durante 24 horas y volver a comprobar su
integridad.
Subtareas de nivel 2
Realizar los test una vez más para comprobar el correcto funcionamiento de las
actualizaciones y el registro de datos.
Duración de la subtarea
1 día
TAREA PRINCIPAL
Retirar el equipamiento antiguo.
Subtareas de nivel 1
Retirar el equipamiento del centro de datos.
Volver a incluir el equipamiento en el inventario para futuros usos.
Subtareas de nivel 2
Desinstalar el equipamiento, borrar el software y los contenidos.
Reenviar el equipamiento al inventario.
Duración de la subtarea
2 días
Desarrollo: cómo poner en marcha el proyecto
En la fase de desarrollo reunirás a tu equipo. Las estimaciones de tiempo se
convertirán en calendarios. Las estimaciones de costes se convertirán en
presupuestos. Juntarás todos tus recursos. Recibirás y adquirirás compromisos.
Formar un buen equipo
Tu primera tarea en esta fase es calcular qué habilidades son necesarias para
desarrollar el proyecto; de este modo, podrás fichar a las personas adecuadas.
Para ello deberás examinar directamente la estructura de desglose de trabajo que
realizaste durante la fase de planificación, cuando elaboraste tu mejor estimación
de las tareas y actividades necesarias. Es posible que debas buscar a personas
que tengan algunas habilidades específicas, ya sean trabajadores externos o empleados de otros departamentos de tu organización. No te olvides de
presupuestar tiempo y dinero por si es necesario cubrir huecos con personas
externas o que no estén al día en algunas tareas puntuales y necesiten formación.
Planificar la asignación de tareas
Si ya tienes formado tu propio equipo, seguramente ya habrás decidido de qué se
encarga cada individuo. En el caso de que hayas heredado un equipo con el que
ya has trabajado antes, probablemente tú mismo podrás asignar las tareas. En
cambio, si te han asignado a un grupo nuevo al que no conoces, antes de asignar
tareas, haz una lista de las habilidades necesarias y habla con cada miembro del
equipo sobre sus capacidades personales. Proceder de este modo también te
servirá para comenzar a establecer la comunicación y la cohesión del grupo. Por
ejemplo, si el proyecto requiere una habilidad que ningún miembro del equipo
posee, quizá alguno conozca a alguien que sí la tenga... o tal vez alguien esté
interesado en formarse para adquirirla.
Está claro que, aunque quieras, tú solo no podrás hacerlo todo. Una vez
asignadas las tareas a los miembros de tu equipo, facilítales la información y los
recursos necesarios para que puedan realizarlas con éxito... luego distánciate y
deja que hagan su trabajo. Es posible que, a medida que el proyecto avance,
tengas que delegar más tareas de las que originalmente habías previsto. Sé lo
suficientemente flexible para hacerlo. No te olvides de que tú, como gestor del
proyecto, eres el responsable de los resultados (véase el recuadro «Consejos para
delegar eficazmente»).
Crear el calendario
Sería fantástico poder hacer un recuento de las tareas pendientes y decir: «Con
los recursos que tenemos, necesitaremos tanto tiempo», y luego conseguir
exactamente lo necesario. Pero la realidad es que la mayoría de proyectos tienen
unas fechas de inicio y final fijas, independientemente de los recursos
disponibles.
Para crear un calendario realista dentro de dichas limitaciones, es mejor trabajar
en orden inverso; es decir, a partir de los plazos inamovibles marcados —de las
fechas inmutables—, a fin de averiguar cuándo deberás tener listo el material
que se ha de entregar o presentar. Por ejemplo, si un informe anual se ha de
entregar para una reunión de accionistas y sabes que el impresor necesita dos
semanas, todo el texto del informe, el diseño y la maqueta final deberán estar
listos para enviarlos a imprenta dos semanas antes de la reunión.
CONSEJOS PARA DELEGAR EFICAZMENTE
Reconoce las aptitudes de cada miembro del equipo.
Confía en la capacidad de tu equipo para realizar su trabajo.
Céntrate en los resultados que se van obteniendo y abandona la necesidad de
implicarte en cómo se llevan a cabo las tareas.
Considera que saber delegar es el mejor método para que tu equipo desarrolle
sus habilidades.
Para que el personal trabaje prestando mejor rendimiento, delega hasta el nivel
más bajo.
Explícales las tareas de la forma más clara posible y facilítales los recursos
necesarios para que las realicen con éxito.
Evita la delegación inversa: no resuelvas problemas ni tomes decisiones por los
miembros de tu equipo de forma automática. Céntrate en generar alternativas
conjuntamente.
En función de la complejidad de tu proyecto, hay algunas herramientas que
resultan útiles para secuenciar las tareas, como el método de la ruta crítica y el
diagrama PERT, o el diagrama Gantt, para planificar su orden cronológico y
duración. El diagrama PERT utiliza la técnica de revisión y evaluación de
proyectos (PERT, por sus siglas en inglés). Más adelante, detallamos su
funcionamiento. Por el momento, basta con que tengas presente la regla general
de «trabajar en orden inverso», así como los siguientes pasos básicos a la hora de
crear calendarios:
Utiliza la estructura de desglose de trabajo o un esquema similar para hacer una
lista de actividades o tareas, y delinea su secuenciación determinando cuáles son
esenciales para alcanzar el resultado deseado.
Asigna a cada tarea un entregable: por ejemplo, «elaborar un primer borrador de
las preguntas de la encuesta».
Utiliza entregables para crear un calendario con plazos realistas.
Detecta los cuellos de botella que puedan alterar el calendario.
Busca maneras de eliminar los cuellos de botella o incorpora tiempo extra para
sortearlos.
Establece sistemas de control y comunicación para actualizar y revisar el
calendario.
Mantén implicadas a todas las partes interesadas e infórmales sobre el progreso
del proyecto y cualquier modificación del calendario.
Celebrar la reunión de lanzamiento
Una vez elegidos los miembros del equipo y elaborado el calendario, convoca a
todo el mundo para una reunión de lanzamiento. Repasa detalladamente el plan y
los objetivos del proyecto con todo el grupo, y revisa también la propuesta de
calendario. Asegúrate de dejar claras las distintas funciones y responsabilidades.
Anima a los miembros del equipo a que se planteen y señalen en qué áreas
pueden producirse problemas y dónde podrían introducirse mejoras. Considera
seriamente sus sugerencias —sobre todo, las relacionadas con áreas en las que
los miembros del equipo tengan más experiencia que tú—, y ajusta tus
estimaciones y actividades en consecuencia.
Elaborar un presupuesto
La primera pregunta que nos plantearemos a la hora de elaborar un presupuesto
será: «¿Qué se necesita exactamente para realizar el trabajo?». Para determinar
los costes, desglosa el proyecto en las siguientes categorías:
Personal. ¿Has calculado todos los costes: los corrientes y los extraordinarios,
los de los empleados y los de los trabajadores externos? Esta suele ser la partida
más grande de un presupuesto.
Transporte. ¿Es todo el personal del mismo lugar de trabajo o será necesario
trasladar a algunos empleados?
Formación. ¿Saben todos utilizar el equipamiento y el software necesarios?
¿Tienen los miembros de tu equipo las habilidades necesarias? ¿Será necesario
un medio de transporte para la formación? Una vez terminado el proyecto,
¿tendrás que enseñar a los usuarios cómo ejecutarlo?
Suministros. Además del computador, el software y otras herramientas
habituales, ¿tu equipo necesita algo más?
Espacio. ¿Es necesario reubicar a los empleados? ¿Cuánto espacio será necesario
en el nuevo local y qué precio tendrá? ¿Habrá gastos corrientes de
mantenimiento?
Investigación. ¿Tendrás que comprar información o datos en los que basar el
proyecto? ¿Cuánta investigación tendrá que hacer tu propio equipo? ¿A qué
precio?
Gastos de capital. ¿Qué equipamiento o actualizaciones técnicas de alto
coste serán necesarios para realizar el trabajo? ¿Los gastos de capital se
amortizarán por sí solos? En tal caso, ¿cómo?
Gastos generales. ¿Qué gastos generales prevés para tu proyecto? ¿Son
coherentes con el porcentaje estándar de gastos generales de tu empresa?
Tras introducir las cifras de estas categorías estándares en el presupuesto,
pregunta a un asesor de confianza de qué te has olvidado. ¿Se te han pasado por
alto los seguros, los derechos de licencia o los gastos de asesoramiento legal o
contable?
Un presupuesto, por muy minuciosamente planeado que esté, solo es la mejor
estimación. En absoluto te sorprendas si los números reales se acaban desviando
de tus estimaciones originales; sé lo más flexible posible dentro de tus
limitaciones de tiempo, de exigencias de calidad y de dinero total disponible.
Ejecución: cómo implementar la estrategia
Ha llegado la hora de pasar a la acción. La fase de ejecución suele ser la más
gratificante, pues es cuando el trabajo se lleva a cabo de verdad, pero también
puede ser la más frustrante. Los detalles pueden resultar bastante tediosos y, en
ocasiones, abrumadores.
Monitorizar y controlar el proceso y el presupuesto
Tanto si tienes establecido un sistema de control del proyecto formal como si
realizas tus propias comprobaciones de forma periódica, trata de mantener una
perspectiva global para que los detalles y los problemas insignificantes no te
absorban. Los programas informáticos para el seguimiento de proyectos pueden
ayudarte a valorar tus avances. No existe una única perspectiva válida para todos
los proyectos. Probablemente, un sistema apropiado para un proyecto grande,
con el exceso de papeleo que requiere, saturará un proyecto pequeño; mientras
que un sistema que funciona en proyectos pequeños no será lo suficientemente
potente para uno grande.
Responde con rapidez ante los cambios de datos o información que se vayan
produciendo; busca los primeros indicios de posibles problemas para poder
corregirlos a tiempo. De lo contrario, solo estarás haciendo un seguimiento, no
ejerciendo el control. Deja claro a tu equipo que tus respuestas ante los
problemas que surjan no servirán de nada si no recibes la información en el
momento oportuno —en la mayoría de los casos, basta con una puesta al día
semanal—. Pero tampoco te apresures a resolver las cosas precipitadamente: es
importante que los miembros del equipo solucionen los pequeños problemas por
su cuenta.
Examina los números reales a medida que van llegando, para asegurarte de que
coinciden con las cantidades presupuestadas. De todos modos, siempre hay que
estar preparado para explicar por qué hay gastos extra que son inevitables.
Algunos de los que suelen aparecer en los proyectos son el aumento de las horas
extra para poder cumplir los plazos, los honorarios de consultores para resolver
problemas imprevistos y las fluctuaciones en los tipos de cambio.
Informar sobre el avance del proyecto
En general, las diferentes partes interesadas querrán actualizaciones e informes
de la evolución del proyecto periódicos. Pregúntales qué cantidad de
información quieren recibir y en qué formato. No escondas ni minimices los
problemas que vayan surgiendo, pues fácilmente podrían derivar en una crisis. Si
todas las partes interesadas están bien informadas, podrán ser un recurso muy
positivo en caso de dificultades.
Celebrar reuniones semanales con el equipo
Cuando nos encontramos inmersos en los detalles de un proyecto, resulta fácil
distraerse de las actividades esenciales hacia direcciones que nos hacen perder el
tiempo. Para que tu equipo permanezca concentrado, celebra una reunión
semanal y recuérdales periódicamente qué es lo esencial para el éxito del
proyecto.
CONSEJOS PARA CONTROLAR LOS RETRASOS EN EL PROYECTO
Antes de aceptar como inevitable el retraso para finalizar el proyecto, intenta
aplicar los siguientes métodos:
Renegociar con las partes interesadas. Plantéales la posibilidad de aumentar
el presupuesto o de ampliar el plazo.
Utilizar los pasos subsiguientes para recuperarse. Examina presupuestos y
calendarios para ver si es posible recuperar el tiempo perdido más adelante.
Reducir el alcance del proyecto. ¿Puedes renunciar a elementos no esenciales
del proyecto para reducir costes y ganar tiempo?
Utilizar más recursos. ¿Puedes poner a trabajar a más personas o máquinas?
Sopesa los costes en relación con la importancia del plazo.
Aceptar una sustitución. ¿Puedes utilizar un elemento menos costoso o más
fácilmente disponible?
Buscar fuentes alternativas. ¿Puedes encontrar en otro lugar el elemento que
falta?
Aceptar una entrega parcial. ¿Puedes mantener el proyecto en marcha con las
tareas ya finalizadas aunque recibas el resto más adelante?
Ofrecer incentivos. ¿Puedes dar bonificaciones u otros alicientes para facilitar
que la entrega se realice dentro del plazo?
Exigir que se cumpla lo prometido. Si insistes en que alguien haga lo que
había dicho que haría, ¿conseguirás el resultado deseado? Es posible que para
hacerlo necesites el apoyo de cargos directivos superiores. Sírvete de esta
táctica de forma selectiva: procura no dañar relaciones importantes en busca
de tu objetivo.
Define claramente el orden del día de las reuniones. Trata de estructurarlas
alrededor de números de producción, del objetivo de los ingresos o de cualquier
otra medida que hayas elegido para evaluar el rendimiento. Muchos de los
puntos del orden del día surgirán de forma natural de objetivos que el proyecto
haya incumplido, satisfecho o superado: por ejemplo, quizá haya que debatir en
grupo si es preciso desplazarse en más ocasiones durante la realización del
proyecto, porque has detectado una bajada de la productividad en una oficina
satélite. O tal vez haya que pedir a los diseñadores que sigan reuniéndose cada
dos semanas, porque han conseguido doblar su producción creativa desde que
empezaron a reunirse con esa frecuencia. Mantén el impulso del proyecto
realizando un seguimiento semanal de cualquier tarea en curso y conéctala con
las medidas de evaluación global que hayas establecido. Asimismo, a lo largo
del trayecto, no dejes de celebrar los pequeños éxitos logrados por tu equipo: así
revitalizarás su entusiasmo a medida que progresen hacia mayores objetivos.
Gestionar problemas
Las consecuencias de algunos problemas pueden llegar tan lejos como para
poner en riesgo todo el proyecto. A continuación, enumeramos cuatro de las
dificultades más importantes que deberás afrontar:
Demoras. El problema más común en la gestión de proyectos son los
retrasos en su ejecución. Muchas veces las demoras son inevitables, pero
normalmente es posible, como mínimo, mejorar la situación. El primer paso
es reconocer que existe un retraso. Si has realizado un estrecho seguimiento
de la evolución del proyecto, te darás cuenta rápidamente de cuándo se han
reajustado los horarios para asumir retrasos o cuellos de botella
inesperados.
Corrupción del alcance (scope creep). Las demoras pueden ser fruto de una
presión interna para alterar el alcance del proyecto. Cuando las partes
interesadas piden cambios, es tu responsabilidad comunicarles claramente
cómo dichos cambios afectarán al coste, al tiempo o a la calidad del
proyecto.
En algunos casos, la corrupción del alcance se convierte en una batalla
permanente para el gestor del proyecto. Cuando se han acordado presupuestos e
hitos específicos, es posible que la gente empiece a ver que se pueden hacer más
cosas. Evita verte atrapado en la resolución de problemas que quedan fuera del
alcance predefinido del proyecto, aunque sean cuestiones que tu empresa
necesita abordar urgentemente.
Problemas de calidad. Asegurar la calidad es fundamental para lograr el
éxito de cualquier proyecto. Por desgracia, a veces también cede ante la
presión de las fechas límite. No apresures la realización de controles de
calidad esenciales en aras del cumplimiento del calendario. Y, a la hora de
examinar los entregables, utiliza las herramientas más apropiadas —tales
como inspecciones detalladas, listas de comprobación o muestreos
estadísticos— para aceptarlos o rechazarlos. En función de los costes,
devuelve los entregables rechazados o revísalos.
Problemas humanos. Estos suelen ser los desafíos más difíciles que debe
afrontar un gestor de proyectos. Generalmente, se pueden evitar o gestionar
estableciendo, desde un principio, una comunicación fluida con cada
miembro del equipo. Si las reuniones semanales de grupo no son suficientes,
quizá sea necesaria una interacción diaria —con miembros concretos del
equipo o con todo el grupo—.
Presta atención a pequeñas señales de problemas emergentes: una mayor tensión
e irritabilidad, una pérdida del entusiasmo o una incapacidad para tomar
decisiones por parte de un miembro del equipo... Cuando detectes señales de este
tipo, investiga rápidamente cuál es el meollo de la cuestión, y gestiónalo. No
permitas que una pequeña contrariedad derive en un desastre.
Finalización: es importante cómo se gestiona el final
Algunos proyectos se hacen eternos, pero todos terminan en algún momento.
¿Cómo saber, en calidad de gestor de proyectos, cuándo hay que poner el punto
final? ¿Y cómo llevarlo a cabo en la práctica?
Evaluar la ejecución del proyecto
Antes de finalizar el proyecto, tu equipo debe haber cumplido sus objetivos —o
determinar, junto con las principales partes interesadas, que dichos objetivos ya
no son pertinentes—. Compara la evolución del proyecto con el alcance que todo
el mundo acordó al comienzo. Así, podrás calcular la ejecución del proyecto... y
si aún queda trabajo por hacer. Cuando hables de tus conclusiones con las partes
interesadas del proyecto, llega a un consenso con ellas sobre hasta qué punto está
«terminado» el proyecto. Mantén el alcance del proyecto en el centro de
atención para que todo el mundo utilice la misma vara de medir a la hora de
evaluar su éxito.
INFORME DE EVALUACIÓN POSTERIOR
Ejemplo de análisis y lecciones aprendidas
Nombre del proyecto: Proyecto Phoenix
Fecha: 5/29/200X
Presentes en esta sesión: Rafael, Phil y Carmen
FASE/TAREA DEL PROYECTO
Adquisición del equipamiento
Qué ha funcionado
Obtención de los servidores web a tiempo y dentro de presupuesto.
Qué no ha funcionado
Problemas logísticos con la disponibilidad de servidores de bases de datos:
dieron lugar a un retraso. El envío exprés supuso un gasto adicional.
Formas de mejorar
Tenemos que pedir el equipamiento con más tiempo.
FASE/TAREA DEL PROYECTO
Instalación del equipamiento
Qué ha funcionado
Se recuperaron dos días gracias al esfuerzo realizado por Rafael y Carmen
durante la fase de instalación.
FASE/TAREA DEL PROYECTO
Puesta a prueba del equipamiento
Qué ha funcionado
La fase de pruebas tuvo éxito: se descubrió un error en el contenido de la base de
datos y pudo corregirse antes de la migración.
FASE/TAREA DEL PROYECTO
Activación del nuevo equipamiento
Qué ha funcionado
Migración sin problemas con el mínimo tiempo fuera de servicio.
Qué no ha funcionado
Algunos usuarios no sabían que iba a producirse una breve interrupción.
Formas de mejorar
Dar a conocer el periodo de trabajo de forma más agresiva.
FASE/TAREA DEL PROYECTO
Segunda puesta a prueba del equipamiento
Qué ha funcionado
Las pruebas fueron satisfactorias.
FASE/TAREA DEL PROYECTO
Retirada del equipamiento antiguo
Qué ha funcionado
Se retiraron los sitios y se eliminó el contenido sin problemas; volvió a incluirse
el equipamiento en el inventario.
Qué no ha funcionado
Hubo cierta confusión con algunos números de serie y el inventario, pero acabó
resolviéndose.
Formas de mejorar
Comprobar con antelación los números de serie para minimizar problemas al
final del proyecto.
ANÁLISIS DE OBJETIVOS
¿Cuál fue el desempeño del proyecto/equipo a la hora de…
... alcanzar las metas y cumplir los objetivos del proyecto?
Éxito: se lograron todos los objetivos.
... cumplir los plazos y la fecha de finalización?
Éxito: cumplimos nuestra fecha meta.
... hacer un seguimiento y mantenerse dentro del presupuesto?
Éxito: un pequeño sobrecoste fue inevitable.
¿Cuál fue el desempeño del proyecto/equipo a la hora de…
... comunicarse con las partes interesadas?
Éxito parcial: deberíamos haber comunicado los requisitos antes y mejor a las
personas implicadas en cada fase del proyecto.
EVALUACIÓN DE RECURSOS
¿Los recursos asignados (tiempo, personas, dinero) fueron adecuados,
suficientes y utilizados de forma eficiente?
En términos generales, la asignación de recursos fue apropiada. El proyecto
superó ligeramente el presupuesto previsto, pero no fue incorrecto. Las personas
que participaron en él contaban con la experiencia y los conocimientos
necesarios para llevar a cabo las fases sumamente técnicas del proyecto. El
calendario era el adecuado, pues el proyecto se completó dentro de plazo sin
exceso de tiempo.
LECCIONES APRENDIDAS
¿Qué lecciones clave ha dado el proyecto que puedan resultar útiles en el
futuro?
En cada fase del proyecto, es fundamental tener en cuenta los próximos pasos
que se van a dar y avisar, lo antes posible, a los diferentes grupos o personas de
qué recursos serán necesarios. De este modo, habríamos podido comprar el
equipamiento a su debido tiempo y no habríamos tenido que apresurarnos tanto
en las últimas fases para cumplir los plazos.
Cerrar el proyecto
Los pasos que des para poner el punto final al proyecto dependerán de si es tu
equipo el que se responsabiliza de sus propios entregables, si los transfiere a otro
grupo de la organización o si debe finalizar el proyecto por completo. Más
adelante, en esta guía se explican estos tres tipos de cierre, así como algunas
técnicas muy útiles para ejecutarlos fácilmente. Si tu proyecto ha salido según lo
previsto, ya es hora de celebrarlo. Lo más probable es que, a lo largo del
trayecto, haya habido momentos difíciles —el proyecto ha llevado más tiempo
de lo previsto, el resultado es inferior a lo esperado, los costes superan tus
estimaciones...—, pero, aun así, es importante reconocer los esfuerzos y logros
del equipo.
Recibir informes del equipo
Sea cual sea el resultado, no olvides programar una evaluación posterior: es el
momento de recibir los informes del equipo y de documentar el proceso para
compartir las lecciones aprendidas. La evaluación posterior es una oportunidad
para descubrir, no para criticar ni echar culpas a nadie. Si algún miembro del
equipo teme que le culpabilicen de problemas que han sucedido, seguramente
intentará ocultarlos, en lugar de ayudar a buscar mejores maneras de gestionarlos
en el futuro.
Realizar un informe de evaluación posterior
El informe de evaluación posterior documenta la información que será útil no
solo para el equipo y las partes interesadas del proyecto actual, sino también para
otros gestores de proyectos que puedan utilizarlo para planificar su propio
trabajo (véase el informe de ejemplo en este mismo capítulo). Debe incluir:
Conclusiones del equipo. De los informes de tu equipo, ¿qué lecciones crees
que pueden resultar útiles más adelante?
NOTA SOBRE LAS OFICINAS PARA LA GESTIÓN DE PROYECTOS
Las grandes compañías suelen tener lo que se conoce como oficina de gestión de
proyectos, que ejecuta algunas de las siguientes tareas:
Establecer procesos y patrones que sirvan de guía a los gestores en la
planificación y la ejecución del proyecto.
Orientar y ayudar a los directivos, a los gestores y a los miembros de los equipos
a la hora de implementar los procesos y patrones.
Gestionar proyectos directamente para conseguir los objetivos deseados (en
organizaciones con una estructura matricial fuerte, este tipo de oficina no asume
tal responsabilidad).
Una oficina para la gestión de proyectos bien gestionada ayuda al equipo
encargado de un proyecto a desarrollar un plan adecuado, a realizar una
estimación razonable de los riesgos y a hacer el seguimiento de las distintas
etapas; además, el equipo dispondrá de opciones adecuadas para desviarse del
procedimiento estándar si es necesario.
Estatus futuro. Una vez concluido, ¿qué pasará con el proyecto? ¿Formaba
parte de otro proyecto más grande?, o ¿era un trabajo independiente que ha
cumplido sus objetivos?
Estatus de las tareas críticas en curso. ¿Cuál es el estatus actual de las
actividades en curso que tengan un elevado nivel de riesgo técnico o que
estén siendo realizadas por proveedores externos o subcontratados?
Evaluación de riesgos. ¿Algún riesgo podría causar —o ha causado— una
pérdida financiera, el fracaso del proyecto u otros problemas?
Limitaciones de la inspección. ¿Existe alguna razón para cuestionar la
validez de la evaluación posterior? ¿Falta alguna información? ¿Algún dato
es dudoso? ¿Algún miembro del grupo ha sido reacio a facilitar detalles?
Incluso después de haber finalizado el proyecto, podrás seguir sacando provecho
del conocimiento que hayas adquirido, de las habilidades que hayas aprendido y
de las relaciones que hayas entablado. Dispondrás de valiosos recursos: el truco
radica en seguir utilizándolos cuando inicies nuevos proyectos.
Capítulo 2
El elenco de personajes
Para alcanzar los objetivos de tu proyecto es importante contar con las personas
adecuadas... y estas deben tener muy claro cuál va a ser su función. A
continuación describiremos detalladamente quién hace qué.
Patrocinador
El patrocinador, impulsa el proyecto al máximo nivel de la compañía y elimina
cualquier obstáculo institucional. Debe tener suficiente influencia para establecer
una comunicación eficaz con el director ejecutivo y con las principales partes
interesadas, proporcionar los recursos necesarios y aprobar o rechazar los
resultados. También es importante que «se juegue su propia piel» con el
proyecto, ya que es el máximo responsable de su ejecución.
Gestor del proyecto
El gestor del proyecto, identifica el problema central que debe resolverse y
determina, con aportaciones del patrocinador y de las partes interesadas, cómo
abordarlo: cuáles serán los objetivos y el alcance del proyecto, y qué pasos serán
necesarios para obtener los resultados deseados. Luego, se encarga de planificar
y programar tareas, de supervisar su ejecución en el día a día y de realizar un
seguimiento hasta evaluar el rendimiento obtenido, pone punto final al proyecto
y capta las lecciones aprendidas. Es el patrocinador quien le otorga su autoridad.
En muchos sentidos, es como el clásico director, pues debe:
Proporcionar un marco para las actividades del proyecto.
Identificar los recursos necesarios.
Negociar con cargos superiores.
Fichar a participantes eficaces.
Fijar metas.
Coordinar actividades.
Mantener una visión clara del trabajo y llevarlo por buen camino.
Verificar que todos los miembros del equipo contribuyan en el proyecto y se
beneficien de él.
Mediar si hay conflictos.
Asegurarse de que se cumplan los plazos y el presupuesto para lograr los
objetivos marcados.
Jefe de equipo, o líder
En los grandes proyectos se puede incorporar a un jefe de equipo, o líder, que
directamente rinda cuentas al gestor del proyecto. En proyectos pequeños, el
gestor del proyecto desempeña los dos roles. El jefe de equipo no puede actuar
como jefe y, al mismo tiempo, obtener los beneficios del trabajo en equipo. Al
contrario, debe cumplir las siguientes funciones importantes:
Motivar. En lugar de decirle a la gente qué debe hacer, el líder visualiza
aquellas acciones que deben realizarse para que los objetivos del equipo se
cumplan.
Servir de ejemplo. Con su propio comportamiento influye en la actitud de
los otros: por ejemplo, empieza las reuniones puntualmente y habiendo
cumplido con las tareas que tenía asignadas de la reunión anterior. En
numerosas ocasiones, el jefe de equipo suele recurrir a este tipo de táctica,
pues normalmente no puede utilizar promociones, compensaciones o
amenazas de despido para influir en los otros miembros.
Negociar. Consigue lo que se necesita de los proveedores de recursos
presentando el proyecto como algo mutuamente beneficioso.
Observar. Examina su entorno por si surgen señales de problemas
inminentes, de malestar entre los empleados o de oportunidades de mejora.
Animar. Encuentra maneras de ayudar a los diferentes miembros del equipo
para que maximicen su potencial y alcancen los objetivos acordados. Tendrá
en cuenta las habilidades de cada individuo y motivará el aprendizaje de
nuevas aptitudes todavía no adquiridas, en el caso de que sean necesarias.
Participar activamente. Además de orientar, el líder debe realizar una parte
del trabajo, sobre todo en los ámbitos en los que tenga especial competencia.
También es muy buen ejemplo que asuma alguno de esos trabajos menos
agradables que nadie quiere realizar.
Miembros del equipo
El elemento fundamental de cualquier proyecto, y su auténtico motor, son los
miembros del equipo,. Por eso es extremadamente importante elegir a las
personas adecuadas.
Criterios para la selección de personal
A la hora de seleccionar a los miembros de un equipo, por supuesto, lo primero
que valorarás es que posean las habilidades necesarias para realizar un
determinado trabajo; de todos modos, es poco probable que consigas todos los
conocimientos especializados que precisas sin facilitar algún tipo de formación.
Considera los siguientes ámbitos de conocimiento:
Habilidades técnicas en una disciplina específica, como estudios de mercado,
finanzas o programación.
Habilidades para resolver problemas que permitan analizar situaciones
difíciles, o puntos muertos, y plantear soluciones.
Habilidades interpersonales, en especial la capacidad de colaborar
eficazmente con otros, aspecto fundamental del trabajo en equipo.
Habilidades institucionales, tales como establecer contactos, comunicarse
bien con otros departamentos de la compañía y saber manejar la esfera
política, que ayudan a que el equipo realice su trabajo y evite conflictos con
otras unidades operativas y su personal.
Cuando estamos creando un equipo tendemos a centrarnos demasiado en las
habilidades técnicas y a pasar por alto las habilidades interpersonales e
institucionales, que son igual de importantes. Por ejemplo, una programadora
brillante puede obstaculizar los avances del equipo si no está dispuesta a
colaborar. En cambio, alguien cuyas habilidades técnicas sean regulares pero que
sepa moverse por los recovecos de la organización puede convertirse en el
miembro más valioso gracias a su capacidad para conseguir recursos y ayuda de
otras unidades operativas.
No son abundantes las personas que obtendrían una alta puntuación en los cuatro
tipos de habilidades. Aprovecha al máximo el talento disponible, y toma
medidas para neutralizar los puntos débiles de tu grupo. No busques solo a expertos que muestren valiosas competencias, sino a aquellas personas que
tengan potencial para aprender nuevas habilidades. Cuando vayas a seleccionar a
un candidato para que forme parte de tu equipo, comenta su potencial
contribución con el patrocinador. Consúltalo también con el supervisor, ya que
formar parte de tu equipo le ocupará un tiempo que, de otro modo, podría
dedicar a sus tareas habituales.
Es posible que a lo largo del proyecto tengas que incorporar a nuevos miembros
y despedir a otros, a medida que cambien las tareas y las necesidades. Una
pequeña advertencia: con el tiempo, los miembros de un equipo van ganando
cada vez más eficacia a la hora de trabajar conjuntamente, tomar decisiones y
comunicarse. La cohesión se ve socavada cuando demasiadas personas entran y
salen del equipo.
Contribuciones y beneficios
No es tolerable que algunos miembros vayan por libre, que se beneficien de
formar parte del equipo sin cumplir con sus obligaciones. De todos modos, no es
necesario que todo el mundo dedique la misma cantidad de tiempo al trabajo en
equipo. Por ejemplo, un alto directivo que deba centrar gran parte de su atención
directa a otras funciones puede añadir valor al proyecto obteniendo recursos o
ganando apoyos dentro de la organización.
Del mismo modo que todos los miembros deben contribuir a que el trabajo
conjunto dé unos resultados, también tienen que recibir un claro beneficio por
formar parte del equipo: por ejemplo, una experiencia de aprendizaje que les
ayude a desarrollar su carrera profesional, o bien una mayor remuneración o una
bonificación. De lo contrario, la gente no se implica a un alto nivel... al menos
no a largo plazo. Centrarán más su atención en los beneficios que obtengan de su
trabajo habitual, y para ellos la prioridad de tu proyecto pasará a un segundo
nivel.
EL COMITÉ DIRECTIVO DEL PROYECTO
Algunos proyectos cuentan con un comité directivo, formado por el patrocinador
y por las principales partes interesadas. Las funciones del comité son aprobar el
acta de constitución, conseguir recursos y evaluar todas las peticiones que surjan
para cambiar elementos clave del proyecto: los entregables, el calendario o el
presupuesto, entre otros.
Un comité directivo es una buena idea cuando diferentes compañías,
departamentos o personas tienen una fuerte participación en el proyecto. Puesto
que el comité representa los distintos intereses, goza de una buena posición para
solventar embarazosos problemas entre departamentos o empresas. Del mismo
modo, puede resultar útil si te anticipas a las solicitudes de cambio.
¿Inconvenientes de tener un comité directivo? Conlleva un nivel de supervisión
adicional, y sus reuniones roban tiempo a algunos de los empleados más caros de
la compañía. Así pues, no tengas un comité si no es necesario.
Coordinación
Los objetivos del equipo y los de los de sus miembros deben concordar con los
objetivos de la organización. Por este motivo, los esfuerzos de todos deben
coordinarse a través del sistema de recompensas de la compañía. Este tipo de
refuerzo empieza desde arriba, con el patrocinador: puesto que es el responsable
del éxito del equipo, parte de su compensación estará vinculada a la actuación
del equipo. En rangos inferiores, el gestor del proyecto y los miembros del
equipo también han de percibir que los resultados del grupo influyen en su
compensación. Con este tipo de coordinación del equipo se consigue que todo el
mundo reme en la misma dirección.
Fase 1
Planificación
Capítulo 3
El acta de constitución
Todo proyecto debe contar con un acta de constitución,, en la que se detallen la
naturaleza y el alcance del trabajo y las expectativas de la dirección respecto a
sus resultados. Un acta de constitución es un escrito conciso que contiene
algunos o todos los elementos siguientes:
Nombre del patrocinador del proyecto.
Beneficios del proyecto para la organización.
Breve descripción de los objetivos.
Calendario previsto.
Presupuesto y recursos disponibles.
Autoridad del gestor del proyecto.
Firma del patrocinador.
Elaborar un acta de constitución obliga a los altos directivos a articular
claramente qué debe conseguir el proyecto. Consideremos el siguiente ejemplo:
Phil era el patrocinador del equipo encargado de rediseñar el procesamiento de
pedidos y el servicio de atención al cliente de su compañía. Como él había
criticado abiertamente estas funciones, parecía ser la persona más adecuada
para desempeñar dicha tarea. Hacía mucho tiempo que estaba descontento con
cuánto se tardaba en procesar los pedidos y con la mediocre atención al cliente
que prestaba la compañía. Además, en su opinión, los costes de dichas
operaciones eran demasiado elevados. Así pues, puso a Lila a cargo de un
proyecto para mejorarlas.
¿Qué tipo de reducción de costes esperaba Phil? ¿Cuáles eran exactamente sus
quejas acerca del sistema actual? ¿Qué implicaría exactamente tener éxito? Lila
intentó en vano que Phil concretara dichas cuestiones. Estaba demasiado
ocupado como para pensarlo con detenimiento y tenía demasiadas ganas de
delegar la responsabilidad de los resultados del proyecto. Otros ejecutivos de la
empresa también tenían mucho interés en ver mejoras pero, como Phil, no
tenían las ideas claras sobre qué resultados buscaban. Así pues, cuando Lila
planteó preguntas al respecto a los altos directivos, estos no mencionaron
ningún objetivo concreto. Ante la falta de orientaciones, Lila y su equipo
establecieron sus propios objetivos y criterios de éxito.
El equipo siguió adelante, y Lila fue informando a Phil de sus progresos durante
los diez meses que duró el proyecto. Los recursos eran siempre un problema;
sobre todo, porque Lila nunca sabía cuánto dinero podía gastar ni a cuántas
personas podía seleccionar para las fases clave del proyecto. Tenía que
negociar con Phil cada solicitud de recursos, caso por caso.
Al final, el equipo consiguió llevar a cabo sus tareas, cumpliendo todos los
objetivos que habían fijado. Redujeron en un 33% el tiempo necesario para
procesar los pedidos, y en un 12% los costes globales de procesamiento y
atención al cliente. Además, el 90% de los clientes ahora podían resolver su
situación con una sola llamada de teléfono. El equipo lo celebró con una cena
espléndida, y cada uno de los miembros volvió a ocuparse de sus obligaciones
habituales.
Sin embargo, los altos directivos no estaban demasiado satisfechos con el
resultado:
—Tu trabajo ha sido bastante bueno —le dijo Phil a Lila—. Has hecho mejoras
significativas, pero esperábamos una reorganización de mayor envergadura y un
ahorro más considerable.
Lila se quedó atónita y algo más que enojada: «Si lo que quería era eso —pensó
—, ¿por qué no lo dijo?».
Situaciones como esta son habituales, pero pueden evitarse con un acta de
constitución que deje claros los objetivos, el calendario y el alcance del
proyecto.
Objetivos
Como demuestra el caso de Lila, los gestores de proyecto necesitan algo más que
una mera descripción a grandes rasgos de los objetivos de los que se harán
responsables. Objetivos ambiguos pueden dar lugar a malentendidos, a
decepciones y a costosas revisiones.
Analicemos, por ejemplo, la siguiente afirmación: «Desarrollar un sitio web
capaz de ofrecer de forma rápida y precisa información sobre los productos, así
como procesar los pedidos de nuestros clientes de forma rentable». ¿Qué
significa exactamente? ¿Qué quiere decir «de forma rápida»? ¿Cómo definimos
«de forma precisa»? ¿Es un error cada mil transacciones aceptable? ¿Uno cada
diez mil? ¿Hasta qué punto debe ser rentable el sitio web? Cada una de estas
preguntas debe responderse de forma concertada con el patrocinador y con las
partes interesadas claves del proyecto.
Un acta de constitución bien planteada especifica los fines, pero los medios
deben estar a cargo del gestor del proyecto y de los miembros del equipo.
Decirle al equipo qué tiene que hacer y también cómo tiene que hacerlo
menoscabará las ventajas que supone haber creado un grupo competente. Como
dice J. Richard Hackman en Leading Teams: «Cuando especificamos los fines
pero no los medios, los miembros del equipo pueden —de hecho, implícitamente
se les anima a hacerlo— sacar provecho de la totalidad de sus conocimientos,
sus habilidades y sus experiencias a la hora de concebir y ejecutar una manera de
funcionar bien ajustada al propósito y las circunstancias del equipo».
Calendario
Aparte de fijar objetivos específicos y mesurables, tendrás que establecer un
calendario para conseguirlos. El proyecto no puede quedar abierto. En algunos
casos, la fecha límite debe ser firme, y el alcance pasa a ser variable.
Supongamos que una compañía de software promete lanzar una nueva edición
cada tres meses. El equipo encargado del proyecto debe ajustar su alcance en
función de las nuevas ediciones —añadiendo características o renunciando a
ellas— para cumplir cada plazo.
En cambio, si el alcance del proyecto es fijo, entonces puede establecerse un
plazo razonable una vez que el gestor del proyecto y su equipo hayan desglosado
los objetivos en grupos de tareas y que hayan estimado la duración de cada tarea.
No obstante, el acta de constitución siempre debe incluir una fecha límite
razonable, fecha que puede modificarse a medida que el equipo vaya
averiguando qué debe hacer.
Alcance
Por supuesto, las opciones son siempre abundantes mientras que el tiempo y los
recursos son limitados. Una técnica útil para tomar las decisiones acertadas
consiste en llevar a cabo una lluvia de ideas entre las partes interesadas y los
participantes en el proyecto, para definir qué está a su alcance y qué no.
Se puede pensar en las expectativas del patrocinador —los fines que se buscan—
como la primera parte del acta de constitución y en el plan del proyecto —los
medios— como la segunda parte. Normalmente, el gestor de proyectos crea el
plan, pero es importante que obtenga el visto bueno del patrocinador para no
encontrarse con problemas como los que tuvo Lila con Phil. Idealmente, el acta
de constitución expone las mejores ideas de muchos miembros del equipo, o de
todos. Resulta especialmente valiosa para proyectos grandes y complejos, pues
detalla las diferentes tareas, los entregables, los riesgos y los horarios. El equipo
puede utilizarla como si de un mapa de carreteras se tratara.
Capítulo 4
La gestión de la «confusa fase inicial»
Por Loren Gary
En sus inicios, la gestión de proyectos consistía principalmente en deshacerse de
incertidumbres. Desde un principio, el gestor detallaba todos los entregables y
especificaba al máximo para que la ejecución fuera lo más rutinaria posible. Por
supuesto, siempre surgía alguna sorpresa, pero en general era predecible a qué
atenerse. Sin embargo, en muchos de los complejos proyectos actuales —tanto si
se trata del desarrollo de nuevos productos, como de instalaciones informáticas o
de la mejora de los procesos internos—, la incertidumbre sencillamente no puede
eliminarse al cien por cien.
Si estuvieras reestructurando una fábrica de zapatos, explica David Schmaltz,
consultor en gestión de proyectos de Washington: «Tal vez solo el 10% del
trabajo estará vinculado a la construcción de una nueva cadena de fabricación,
pero el 50% tendrá que ver con la incertidumbre respecto a qué estilo de zapatos
se venderá mejor el próximo trimestre... En consecuencia, en lugar de intentar
reducir el tiempo que tardan los zapatos en llegar al mercado con procesos de
producción más rápidos, la empresa se centrará en construir cadenas de
fabricación que fácilmente puedan adaptarse a nuevos estilos de zapatos».
Los estudios acerca de la gestión de proyectos excepcionales en sectores con
cortos plazos de comercialización indican que los primeros pasos en un proyecto
complejo, a menudo conocidos como la confusa fase inicial, tienen un impacto
desproporcionadamente grande en los resultados finales. Así pues, es importante
proceder con cautela. Resiste las ansias de lanzarte directamente a la puesta en
marcha: «Definiendo primero el problema, tendrás mucha más libertad a la hora
de resolverlo», señala Bob Gill, presidente de la Product Development and
Management Association, organización sin ánimo de lucro de Nueva Jersey. «Si
en lugar de presuponer que tus máquinas de remachado son demasiado lentas,
das un paso atrás y dices: “En realidad, el problema es que el coste de fabricar el
producto es demasiado elevado”, abres la puerta a otras opciones para resolver el
problema, como, por ejemplo, rediseñar el producto para que necesite menos
remaches».
Reúne pronto a tu comunidad
Es necesario que las partes interesadas te den información para tener un
profundo conocimiento de la naturaleza y el alcance de lo que hay que hacer. A
los miembros de los distintos grupos que probablemente se verán afectados por
tu proyecto pídeles que te ayuden a explorar las diferentes oportunidades,
aconseja Peter Koen, profesor del Stevens Institute of Technology, también de
Nueva Jersey: «Cuestionarte, antes de nada, cuáles son las necesidades no
satisfechas y el valor de lo que estás haciendo puede ahorrarte resultados
insatisfactorios más adelante; por ejemplo, lanzar productos en un mercado
maduro y en declive».
Si pides la opinión de otras personas para definir el problema, rápidamente te
percatarás de que afecta a una comunidad mucho más amplia de lo que
esperabas en un principio. Y con el tiempo cambiará, apunta Chuck Kolstad,
director ejecutivo de Antara, empresa de alta tecnología de California: «Es
posible que aquellas partes interesadas que solo pueden aportar información
durante las primeras fases del proyecto esgriman su poder en la toma de
decisiones más adelante». Si desde el inicio dejas claro que valoras sus ideas y
que las incorporas en el proyecto, las partes interesadas estarán más dispuestas a
prestarte el apoyo que necesitas. Es en este punto dónde debes poner en juego
tus habilidades de reclutamiento: cuando comentes cómo ves el desarrollo del
proyecto con una compañera de trabajo cuya ayuda necesitarás, pregúntale si es
interesante para ella. Ayúdale a encontrar su proyecto dentro del tuyo.
Pensando en un proyecto complejo típico que dure menos de un año, Schmaltz
comenta que «a veces, las apariencias engañan: esas interminables
conversaciones que entablas con la gente durante las dos primeras semanas son
todo lo que quieras pensar menos inútiles». Cuando los planes fallan o surgen
nuevas necesidades —continúa—, las relaciones que hayas establecido durante
la fase inicial funcionarán como «una asociación benéfica de gente que se
compromete a encontrar la manera de que el proyecto funcione».
Trabaja en orden inverso
La investigación sobre sesgos cognitivos muestra que a la hora de tomar
decisiones tiene una influencia esencial cómo enfocamos inicialmente nuestros
pensamientos acerca de un tema. Una vez concretado el problema, no te centres
directamente en el proceso o el producto actual que quieres mejorar. En lugar de
eso, dice Jim Goughenhour, vicepresidente de Informática de Sealy, «imagínate
cómo sería idealmente el estado final y luego trabaja en orden inverso para
conseguir lo máximo posible según el tiempo, el presupuesto y las circunstancias
políticas de que dispongas».
El enfoque tradicional a la hora de abordar uno de los proyectos que
Goughenhour supervisa (la creación de un sistema consistente para el registro de
las ventas) se basa en revisar el objetivo de todos los registros utilizados por los
empleados de ventas y marketing de la compañía y en explorar maneras de
combinarlos: «Si hubiéramos hecho eso —señala—, mayor parte del dinero se
nos habría ido en pequeñas mejoras que ni de lejos se habrían acercado a la
situación ideal».
Sé la voz de la razón
Al final de la fase inicial del proyecto, generarás un plan general que marcará las
expectativas dentro de la comunidad del proyecto y de la compañía en su
conjunto. No cabe la menor duda de que no es una tarea fácil, pero puede ser un
desafío aún mayor gestionar las expectativas de tu patrocinador: el impulsor del
proyecto que está tres o cuatro niveles por encima e insiste en que el trabajo esté
finalizado en cuatro semanas.
No olvides que tienes «la sagrada responsabilidad de decepcionar», asegura
Schmaltz. Ahora que las conversaciones de la fase inicial van llegando a su fin,
¿tienes esa inquietante corazonada de que el proyecto llevará mucho más tiempo
de lo esperado y de que también costará mucho más? «Solo si decepcionas desde
el principio al promotor del proyecto con esta noticia podrás deslumbrarlo al
final», explica Schmaltz. «De lo contrario, acabarás atado de pies y manos a
expectativas poco realistas y, en lugar de generar éxitos, presentarás fracasos casi
con total seguridad».
Loren Gary fue editor de Harvard Management Update.
Capítulo 5
El examen pre mortem
Por Gary Klein
Los proyectos fracasan en un porcentaje espectacular. Una de las razones es que
muchas personas son bastante reacias a expresar sus reservas durante la
importantísima fase de planificación. Si consigues que las personas críticas que
conocen el proyecto y que están preocupadas por sus puntos débiles puedan
expresar sus opiniones tranquilamente, aumentarás las probabilidades de que el
proyecto sea un éxito.
En 1989 Deborah J. Mitchell, de la Wharton School, Jay Russo, de Cornell, y
Nancy Pennington, de la Universidad de Colorado, realizaron una investigación
que demostró que la práctica de la retrospectiva probable —imaginar que un
hecho ya se ha producido— aumenta un 30% la capacidad de identificar los
motivos de los resultados futuros. Hemos aplicado esta práctica para concebir un
método llamado «examen pre mortem», con el que el equipo de un proyecto
puede identificar riesgos desde el principio.
Hipotéticamente hablando, el examen pre mortem es el opuesto a una autopsia.
En el ámbito de la medicina, una autopsia permite que los profesionales
sanitarios y la familia sepan qué causó la muerte del paciente. Todo el mundo
sale beneficiado de ello; salvo, por supuesto, el paciente. Un examen pre mortem
en un contexto empresarial se realiza al principio del proyecto, en lugar de
hacerse al final, para poder mejorar el proyecto y para que no sea necesaria una
autopsia. A diferencia de una sesión crítica habitual, en la que se pregunta a los
miembros del equipo «qué podría salir mal», el examen pre mortem parte de la
idea de que el «paciente» ya está muerto y, por lo tanto, se pregunta «qué ha
salido mal». Los miembros del equipo tendrán que encontrar razones plausibles
para el fracaso del proyecto.
Un examen pre mortem típico empieza después de haber explicado al equipo
todo el plan. El líder inicia el ejercicio diciendo que el proyecto ha sido un
espectacular fracaso. Después, los presentes tendrán unos minutos para escribir
por separado todas las razones que se les ocurran para explicar el fracaso; sobre
todo, aquellas cosas que no suelen mencionarse como posibles problemas por
miedo a ser poco diplomáticos.
Por ejemplo, en una sesión organizada en una compañía del tamaño Fortune 500,
un ejecutivo sugirió que un proyecto de sostenibilidad ambiental valorado en
miles de millones de dólares había «fracasado» porque su interés menguó
cuando se jubiló el director ejecutivo de la empresa. Otra persona atribuyó el
fracaso al hecho de que dejó de ser viable porque una agencia gubernamental
cambió sus políticas.
A continuación, el líder pide que cada miembro del equipo, empezando por el
gestor de proyectos, lea una razón de su lista. Cada persona señala un motivo
diferente hasta que se hayan registrado todas las posibles razones. Una vez
terminada la sesión, el gestor del proyecto revisa la lista para buscar maneras de
reforzar la planificación.
En una sesión de un proyecto para poner avanzados algoritmos informáticos a
disposición de coordinadores de campañas aéreas militares, uno de los miembros
del equipo, que durante la larga reunión de lanzamiento del proyecto había
permanecido callado, planteó que uno de los algoritmos no encajaría fácilmente
en determinados computadores portátiles utilizados sobre el terreno. En
consecuencia, el software precisaría horas para funcionar pese a que los usuarios
necesitaban resultados rápidos. Si el equipo no conseguía encontrar un método
alternativo, el proyecto sería irrealizable. Resultó ser que los desarrolladores del
algoritmo ya habían creado un potente atajo para resolverlo, pero se habían
mostrado reacios a mencionarlo. Al final, se utilizó ese atajo y el proyecto acabó
teniendo mucho éxito.
En una sesión para evaluar un proyecto de investigación en otra organización, un
alto ejecutivo sugirió que el «fracaso» del proyecto se debía a la falta de tiempo
para preparar un estudio de viabilidad antes de la revisión corporativa de las
iniciativas de producto. Durante toda la reunión de lanzamiento, que había
durado hora y media, nadie había ni tan solo mencionado ninguna limitación de
tiempo. El gestor del proyecto revisó rápidamente el plan para tener en cuenta el
ciclo corporativo de toma decisiones.
Aunque muchos equipos realizan análisis de riesgos antes de lanzar un proyecto,
un examen pre mortem que incorpore esta técnica retrospectiva presenta ventajas
que otros métodos no tienen. Efectivamente, el examen pre mortem no solo
ayuda a identificar problemas potenciales desde el principio, sino que también
reduce la tendencia a minimizar los riesgos que suelen tener las personas ya muy
implicadas en el proyecto. Además, al describir puntos débiles que nadie más ha
mencionado, los miembros del equipo sienten que se valora su inteligencia y su
experiencia, y los demás aprenderán de ellos. El ejercicio también hace que, una
vez iniciado el proyecto, el equipo esté más pendiente ante los primeros indicios
de problemas. Al fin y al cabo, un examen pre mortem puede ser la mejor
manera de evitar un doloroso examen post mortem.
Gary Klein es científico principal de MacroCognition, en Yellow Springs (Ohio).
Capítulo 6
¿La corrupción del alcance encarece tu proyecto o lo
revaloriza?
Por Loren Gary
Si permites que en tu proyecto se apliquen cambios erróneos, este puede acabar
descarrilando, pasarse de presupuesto o no cumplir los plazos más importantes.
Si rechazas un cambio adecuado, quizá se te escape una gran oportunidad. He
ahí la cuestión: ¿cómo permanecer abierto a las mejoras sin sucumbir a la
corrupción del alcance; es decir, al proceso por el que pequeñas modificaciones
se van acumulando hasta tal punto que ocasionan grandes cambios en el
presupuesto y el calendario? La solución radica en marcar claramente los límites
del proyecto para que el impacto de posibles alteraciones o retrasos pueda
calcularse rápidamente.
La fase de planificación
Un sorprendente número de proyectos se ponen en marcha sin que se haya
realizado el esfuerzo de definir sus parámetros. En estos casos, las prisas son las
principales culpables, en opinión de Dave Moffatt, director sénior de
operaciones con cuarenta años de experiencia en la gestión de proyectos de la
Harvard Business School (HBS). Cuando se planifica un proyecto, deben quedar
claros los siguientes aspectos importantes:
Diferencia entre propósito y alcance
«El propósito de un proyecto es el beneficio general que aportará a la
organización», explica Alex Walton, consultor de proyectos que trabaja desde
Florida. «Su alcance son los elementos (o atributos de producto) concretos que el
equipo del proyecto puede controlar y ha aceptado generar».
Por ejemplo, el propósito de un proyecto puede ser crear un nuevo juego
electrónico que incremente en un 40% las ventas navideñas de una empresa de
juguetes. El equipo que desarrolle el producto debe saber qué características
requiere y cuál es el presupuesto para su fabricación. La declaración de alcance,
facilita este tipo de información: describe, en pocas palabras, cómo se propone el
equipo alcanzar el éxito y, en consecuencia, a partir de qué criterios se evaluará.
Obtén información sobre el alcance del proyecto de las partes interesadas para
que sus expectativas concuerden con la trayectoria real del proyecto.
Planificación agrupada
De todos modos, definir el alcance del proyecto no basta para garantizar que sus
límites queden claros. «Las organizaciones también necesitan agrupar la
planificación de proyectos —afirma el profesor de la HBS Steven Wheelwright
—, de modo que desarrollen una estrategia que establezca un patrón y un ritmo
para cuando se realicen los próximos proyectos». Eso resulta de especial
importancia en el desarrollo de productos. A falta de un calendario para futuros
proyectos, a un ingeniero de productos con una nueva idea puede preocuparle el
hecho de que nunca vaya a implementarse; en consecuencia, puede intentar
introducirla en el producto que esté desarrollándose en ese momento, sin valorar
el impacto que ello pueda tener en su presupuesto y en su calendario.
El análisis de proyectos anteriores es un buen complemento para la planificación
agrupada. Por ejemplo, estudia proyectos anteriores que tu compañía haya
llevado a cabo internamente en cuestión de tecnologías informáticas. ¿Qué
patrones emergen? Tus hallazgos pueden contribuir a identificar posibles
problemas y a que estés más preparado para afrontarlos en futuros proyectos
informáticos que tenga pendientes tu empresa.
Establecer las reglas
Otra manera de minimizar la corrupción del alcance es definir conscientemente
la necesidad de debatir y aprobar los diferentes cambios antes de introducirlos.
Por ejemplo:
Formar un consejo de control de cambios. En los entornos muy
estructurados, un grupo de este tipo se encarga de «recopilar información
sobre el impacto que un cambio propuesto tendrá en términos de
calendario, presupuesto o alcance; votar sobre la propuesta de cambio, y
luego enviar un documento de solicitud de cambio al patrocinador del
proyecto para que lo firme», expone Bob Tarne, consultor sénior
especializado en proyectos informáticos y de telecomunicaciones de la
empresa PM Solutions de Pensilvania.
En un proyecto informático que afecte a los departamentos de ventas, marketing
y logística, el consejo de control de cambios estará formado por los directivos
sénior de dichos departamentos. En la práctica, los proyectos más pequeños —
que cuesten menos de 1 millón de dólares y duren menos de 12 meses— pueden
funcionar sin ningún consejo de este tipo, asegura Tarne. Basta con que el gestor
de proyectos busque el asesoramiento de las partes interesadas cuando lo
necesite.
Establecer umbrales para trabajos adicionales. Michele Reed, un consultor
independiente en gestión de proyectos que ejerce en Washington, dice:
«Cualquier cambio que implique un incremento del 5% del presupuesto o el
tiempo originalmente previstos para ese elemento concreto del proyecto
debe dar lugar a una solicitud formal de cambio de alcance».
Limitar el número de nuevas características. Define directrices para
establecer cuántos detalles nuevos, de mayor o menor envergadura, pueden
incluirse en un proyecto de determinado tamaño. De este modo, el equipo
del proyecto controlará mejor la confusión inherente a la planificación de la
fase inicial, pues se verá obligado a elegir solo aquellas características más
importantes para los clientes en ese momento.
La fase de ejecución
Una vez llegado el momento de ejecutar el proyecto, divídelo en pequeñas partes
con plazos cortos y céntrate primero en aquellas tareas que presenten menor
incertidumbre y variabilidad.
Por ejemplo, un equipo de desarrollo de software que está trabajando en un
producto con cuatro características nuevas, pero nadie sabe con certeza si el
mercado desea realmente la cuarta, puede optar por crear primero las otras tres,
porque con toda seguridad sí que las busca el mercado. Entonces fijarán la fecha
de lanzamiento de la cuarta característica para más tarde, cuando el equipo haya
recopilado suficiente información de los clientes para confirmar que es esencial.
Pero no esperes a que todos los subproyectos estén terminados para verificar si
el proyecto (o producto) será un éxito, asegura Wheelwright. Él recomienda el
enfoque conocido como prototipado periódico del sistema,: «A intervalos
regulares durante la fase de ejecución, vincula todos los subproyectos para
realizar una prueba de sistema. Así te aseguras de que todos los subproyectos
que has creado confluyan según lo previsto».
¿Hay que aprobar este complemento?
Durante la construcción del McArthur Hall, la residencia para estudiantes de los
programas de educación ejecutiva de la HBS —algunos duran hasta ocho
semanas—, se tomó la decisión de cambiar su alcance creando diez habitaciones
para alojar a los invitados de los asistentes durante unos días.
Reducir el número de habitaciones para estudiantes a diez menos habría
perjudicado los ingresos potenciales del programa a largo plazo, pues se
dispondría de menos espacio para los alumnos. Era mejor construir diez
habitaciones adicionales para alojar a sus invitados —argumentó el patrocinador
ejecutivo del proyecto— y pagar el coste adicional en varios años recurriendo al
mayor flujo de ingresos derivado de mantener el número de habitaciones para
estudiantes según lo previsto inicialmente. En otras palabras, gracias a un
minucioso análisis del retorno de inversión o ROI (Return of Investment), los
supervisores del proyecto encontraron la manera óptima de lidiar con el nuevo
complemento.
Siguiendo las recomendaciones aquí descritas en las fases de planificación y
ejecución de un proyecto, eliminarás los cambios de alcance que no merezcan
este tipo de análisis. Si defines límites claros desde el principio, es mucho más
probable que las solicitudes de cambio que vayan surgiendo merezcan ser
seriamente consideradas.
Cuando te estés planteando un cambio de alcance, asegúrate de que las partes
interesadas entiendan perfectamente el objetivo de ese cambio. Por ejemplo, ¿las
condiciones del mercado han hecho que sea importante acelerar el calendario
para que el producto pueda enviarse antes de lo previsto inicialmente? ¿Hay que
ajustarse a nuevas normas del sector introducidas después de la fase de
planificación? O ¿se precisa una nueva solución tecnológica porque la elegida
inicialmente no ha dado resultados?
A continuación explica cómo afecta el cambio propuesto a todo: a la declaración
de alcance y al plan del proyecto, a los recursos disponibles, al presupuesto
general y al calendario. Por último, anima a las partes interesadas a que
consideren qué ocurriría si no se realizara el cambio. En dichas deliberaciones,
dice Moffatt, de la HBS, que las opiniones de las personas que representen a los
usuarios finales han de ser las más valoradas.
Como gestor de proyectos, si estás defendiendo un cambio, debes contar con un
plan para financiarlo. Si los ingresos futuros generados por el cambio propuesto
no van a cubrir sus costes, indaga en qué otros ámbitos del proyecto puedes
ahorrar dinero y céntrate en aquello que puedas controlar directamente en los
próximos 30-90 días del calendario, aconseja Reed.
Loren Gary fue editor de Harvard Management Update.
Fase 2
Desarrollo
Capítulo 7
Fija las prioridades antes de iniciar el proyecto
Por Ron Ashkenas
En su apresuramiento por demostrar iniciativa y pasar a la acción, los nuevos
gestores de proyectos suelen emprender actividades sin haber reflexionado
acerca de cuáles son más esenciales y en qué orden deberían desarrollarse. En
consecuencia, sin querer, acaban retrasando el proyecto.
Consideremos el siguiente ejemplo: los gestores de planta de una multinacional
manufacturera no paran de recibir solicitudes de informaciones innecesarias, a
menudo redundantes, desde la sede principal. Para reducir esta carga, la jefa de
fabricación pide a un ingeniero sénior que lidere un proyecto para optimizar el
intercambio de datos. Cuando se le plantea esta responsabilidad, el ingeniero,
entusiasmado, (1) envía un correo electrónico para solicitar a todos los jefes de
funciones corporativas que nombren a los miembros del equipo y que manden
una lista de los datos que quieren de las fábricas, y (2) envía una nota a una
decena de gestores de planta preguntándoles por su opinión acerca de los
informes que deben eliminarse. En pocas horas, este nuevo gestor de proyectos
se ve abrumado y confuso: algunos de los ejecutivos corporativos se resisten a
sus peticiones porque es la primera vez que oyen hablar del proyecto; otros dicen
que necesitan más detalles sobre el problema para poder responder, y otros han
enviado largas listas con los informes que necesitan. Los gestores de planta
también han respondido con una curiosa mezcla de preguntas y solicitudes. Así
pues, en lugar de despegar con brío, el gestor de proyectos ha generado
resistencias y más trabajo para sí mismo y para otros; además, tiene un montón
de información que no le resultará demasiado útil.
Evitar este tipo de situaciones no es tan difícil como parece. A continuación
presentamos tres sencillos pasos que puedes seguir para definir bien tus
prioridades antes de poner el proyecto en marcha:
1. Aclarar el encargo
No inicies ninguna actividad hasta que las partes interesadas no hayan dado su
visto bueno al acta de constitución del proyecto. Es fácil que acabes perdiendo
tiempo en todo tipo de tareas equivocadas si no dejas claros los objetivos
globales del proyecto y cómo se medirá su éxito (qué), el contexto empresarial
en el que se enmarca (por qué), los recursos disponibles (quién), el calendario
(cuándo) y las limitaciones e interdependencias clave (cómo). Aunque estaría
muy bien que tu jefe o el patrocinador del proyecto aclarasen este tipo de
cuestiones «antes» de encargarte la misión, la realidad es que la mayoría de los
proyectos no se asignan con este nivel de especificidad y claridad, de modo que
hacerlo dependerá de ti. En el ejemplo anterior, si el gestor de proyectos hubiese
dado este paso antes de enviar los correos electrónicos, se habría percatado de
que la jefa de fabricación solo había hablado en términos generales con los jefes
de funciones corporativas acerca del problema de sobrecarga informativa... y no
les había explicado que iba a poner en marcha un proyecto específico con un
objetivo y un calendario definidos.
2. Organizar a las tropas
Una vez hayas establecido qué debes lograr y hayas fichado a los miembros de
tu equipo, debes conseguir que la gente se involucre en el proyecto rápidamente,
para que lo sientan suyo. Pídeles que te den su opinión sobre el acta de
constitución y que te cuenten sus experiencias con respecto al problema, y
trátalos como socios, no como subordinados temporales. Trabaja con ellos para
desarrollar un modus operandi para tu equipo: con qué frecuencia se reunirán,
cómo se comunicarán los distintos miembros entre ellos, cuándo evaluarás sus
progresos con el patrocinador del proyecto, etc. Si no te organizas desde el
principio, luego tendrás que perder tiempo persiguiendo a la gente, coordinando
calendarios y repitiendo mensajes importantes.
Lo mismo ocurre a la hora de identificar y contactar con las partes interesadas.
Haz que tu equipo te ayude a crear un «mapa» de la gente a la que, en mayor o
menor medida, afectará el proyecto. Esboza cómo se relacionan entre sí y con el
proyecto, y luego efectúa un «análisis político» de los principales protagonistas:
¿Qué individuos o grupos prestarán apoyo a tu proyecto con entusiasmo?,
¿cuáles se mostrarán preocupados al respecto o se opondrán?, ¿a quién tienes
que convencer o prestar especial atención? Con un análisis de este tipo, el gestor
de proyectos de nuestro ejemplo sobre las plantas de la multinacional
manufacturera habría averiguado que algunos jefes de funciones corporativas —
que para responder a sus demandas tendrían que cambiar su manera de recopilar
datos— no iban a mostrarse partidarios del proyecto y, además, podían plantearle
obstáculos. Teniendo esta información en sus manos habría podido dirigirse a
ellos de una manera diferente.
EJEMPLO DE UN ACTA DE CONSTITUCIÓN PARA EL PROYECTO
DE OPTIMIZACIÓN DE DATOS
Qué: Reducir las solicitudes corporativas de datos a las fábricas en un 50%
y liberar, como mínimo, cuatro horas semanales para el personal y para los
gestores de planta.
Por qué: Las fábricas tienen que centrarse en incrementar la utilización del
equipamiento y en gestionar una mayor combinación de productos. Eso
significa dedicar más tiempo a planificar y dirigir, y menos tiempo a
comunicar datos. Actualmente, todas las funciones corporativas piden
información a las fábricas: a menudo, son los mismos datos en diferentes
formularios y en distintos momentos.
Quién: El gestor del proyecto reclutará a su equipo entre el personal de las
siguientes secciones: operaciones de fabricación, finanzas corporativas,
aseguramiento de la calidad y los recursos humanos. Podrá incorporar a
otras personas según las necesidades de cada momento. Todos los miembros
se dedicarán al proyecto a tiempo parcial, pero es posible que tengan que
dedicar hasta un 25% de su tiempo a dicha tarea.
Cuándo: El proyecto debe iniciarse de inmediato. Hacer un inventario de los
requisitos de intercambio de información actuales, en 30 días; y las
recomendaciones de consolidación y optimización, en 60 días. Empezar a
eliminar informes redundantes, en un plazo de 90 días. Finalizar la
implementación, en menos de 120 días.
Cómo: Las funciones corporativas deben alcanzar un consenso acerca de
qué necesidades comunes de datos pueden satisfacerse con los sistemas
existentes y con los informes estandarizados. Las solicitudes de información
para fábricas en concreto deben ser la excepción, no la regla, y deben
conllevar una mínima personalización.
3. Ata los cabos de tu plan de proyecto
Ahora ya estás listo para desarrollar un plan de proyecto, o por lo menos un buen
borrador de trabajo, teniendo en cuenta lo que ya sabes sobre tus objetivos y las
partes interesadas. Realiza una lluvia de ideas con tu equipo para identificar
todas las actividades necesarias para ejecutar el proyecto, incluyendo
recopilación de datos, consecución de «triunfos rápidos», reuniones de partes
interesadas y presentaciones. Anima a los miembros de tu equipo a ser creativos
y a no preocuparse por los plazos en este momento. Escribe cada elemento en
una nota adhesiva y pon todas las notas en la pizarra.
Después, organiza las actividades por categorías y ordena los distintos grupos.
Algunas de estas categorías se desarrollarán en paralelo y representarán flujos de
trabajo separados —aunque seguramente relacionados—. Las notas de la pizarra,
consideradas en su conjunto, representan tu plan de proyecto.
Ahora, examina cuidadosamente el panorama completo. Dale a cada miembro
del equipo 100 «puntos» para que los asignen a las distintas actividades —sin
debate—; pídeles que presten especial atención a las que deben llevarse a cabo
con éxito para alcanzar los objetivos del proyecto. A continuación, compara la
asignación de «puntos» y observa qué actividades son consideradas esenciales y
qué acciones simplemente estaría bien hacerlas. Es muy probable que se desate
un intenso debate acerca de qué actividades hay que eliminar o retrasar para que
las prioridades más altas gocen de la atención y los recursos que precisan.
Cuando ya hayas completado este ejercicio, vuelve al plan global del proyecto e
introduce los ajustes necesarios: minimiza los pasos superfluos y desarrolla los
más valorados para lograr el éxito.
Está claro que resulta contraproducente ponerse manos a la obra sin antes haber
priorizado las tareas. Aun así, no basta con controlar ese impulso natural de
empezar cuanto antes solo al principio del proyecto. No pararán de surgir nuevas
oportunidades, dificultades, ideas y amenazas, así como nuevos pasos y flujos de
trabajo... a menudo sin que nadie entienda exactamente cómo estos nuevos
elementos se han introducido en el plan. Constantemente tendrás que establecer
prioridades, y restablecerlas, para asegurarte de que el equipo nunca pierda de
vista sus objetivos. Para ello, reúne al equipo por lo menos una vez al mes para
dar un paso atrás y reevaluar el plan del proyecto. En cada una de estas
reuniones, plantea dos cuestiones clave: la primera, «¿se ha producido algún
cambio que nos obligue a replantearnos las prioridades?»; la segunda, «si nos
encomendaran este proyecto ahora, ¿lo enfocaríamos de forma diferente?». Así,
podrás mantener tus prioridades claras... y tu proyecto en el buen camino.
Ron Ashkenas es socio sénior de Schaffer Consulting en Stamford (Connecticut)
y autor del libro Simply Effective: How to Cut Through Complexity in Your
Organization and Get Things Done, Harvard Business Review Press, 2009.
Colabora regularmente con el blog de hbr.org.
Capítulo 8
Estimula la productividad mediante las cajas de
tiempo
Por Melissa Raffoni
Nota del editor: Para que tu proyecto cumpla los plazos previstos, necesitarás
un equipo que esté centrado y sea productivo. A continuación encontrarás una
serie de consejos para mantener el calendario de tu equipo —y el tuyo— bajo
control.
Todos necesitamos más tiempo pero, puesto que nadie disfruta de más de 24
horas al día, la única opción es emplear esas horas de la forma más eficaz
posible. Una técnica muy útil, que solo consta de tres pasos, es la de las cajas de
tiempo o time-boxing.
En primer lugar, haz una lista de todo lo que tu equipo quiere conseguir durante
un plazo de tiempo determinado: una semana, un mes o un trimestre. Incluye los
objetivos del proyecto y las tareas necesarias para alcanzarlos. Puede resultar
efectivo agrupar las actividades según su función, como estrategia, desarrollo de
negocio, operaciones diarias y gestión de recursos humanos. Con este marco de
trabajo, podrás comprobar si tu equipo está dedicando su tiempo a lo más
importante.
En segundo lugar, calcula cuánto tiempo requerirá cada elemento. Piensa
minuciosamente en los pasos necesarios para realizar las tareas. «Esta es la parte
que me obliga a ser más cauteloso —explica Beran Peter, director ejecutivo de
Instruction Set, una consultoría especializada en educación de Massachusetts—.
Si me doy cuenta de que no voy a cumplir mi estimación, puedo averiguar el
porqué y evaluar cómo puedo introducir algún cambio para recuperar el rumbo».
En tercer lugar, asigna la cantidad de tiempo adecuada para cada elemento. Si
piensas que para redactar un plan de negocio son necesarias unas 32 horas,
intenta reservar para ello cuatro horas cada martes y cada jueves de las próximas
cuatro semanas. El reto, por supuesto, es priorizar y distribuir el tiempo de modo
que tenga sentido. No te olvides de dejar cierto margen. Los cambios son
inevitables, y es posible que debas añadir algunas tareas no previstas a medio
camino.
Cuando empieces a utilizar la técnica de las cajas de tiempo, te darás cuenta de
que tiene varias ventajas:
Obliga a analizar detalladamente los objetivos de un proyecto y a determinar
cuánto tiempo es necesario para hacerlos realidad.
Facilita un marco para establecer expectativas y límites. Si el calendario de un
miembro del equipo está completo, no podrá aceptar otros encargos... o tendrás
que hablar con él sobre cómo replantear cuidadosamente sus prioridades.
Mejora tu capacidad para estimar las necesidades de tiempo.
Ayuda a detectar aquellas iniciativas poco productivas que consumen demasiado
tiempo, y a eliminarlas.
En definitiva, tu equipo se sentirá mejor con el trabajo que está haciendo. Todo
el mundo estará más centrado. Todos conseguirán hacer más cosas. Y, no menos
importante, no sufrirán el agotamiento derivado de asumir más de lo que pueden
hacer.
Capítulo 9
Planifica el trabajo
Ahora que ya sabes utilizar la estructura de desglose de trabajo para identificar y
definir las tareas del proyecto y para estimar cuánto tiempo requieren cada una
de ellas, ha llegado el momento de ordenarlas. Para ello, es necesario dar tres
pasos:
Examinar las relaciones entre las distintas tareas.
Crear un calendario provisional.
Optimizar el calendario.
Examinar las relaciones entre las distintas tareas
En un proyecto, las relaciones entre las distintas tareas determinan el orden de
las actividades. Supongamos que la compañía ABC Auto tiene previsto lanzar un
nuevo automóvil de turismo; para ello ha formado un equipo que lo diseñará y lo
pondrá a prueba. El equipo debe fabricar y testar sus piezas externas e internas
antes de poner a prueba el automóvil entero. Debido a estas dependencias, las
tareas del proyecto se programarán en el orden siguiente: (1) diseñar el vehículo,
(2) fabricar y testar las piezas externas e internas y (3) poner a prueba el
vehículo fabricado con dichas piezas (véase la figura 1).
FIGURA 1
Diagrama de red del proyecto: relaciones entre tareas
Fuente: Harvard ManageMentor® on Project Management, Boston: Harvard
Business Publishing, 2002.
Sin embargo, es posible fabricar y probar las piezas en dos vías paralelas que se
realizan simultáneamente: una para las piezas externas, y la otra para las
internas. ¿Por qué? Porque esos dos conjuntos de actividades dependen del
diseño del vehículo pero no presentan dependencias mutuas. Si detectas
oportunidades para llevar a cabo distintas acciones en paralelo, como en este
ejemplo, podrás reducir la cantidad total de tiempo que requerirá el proyecto.
Una vez que se hayan evaluado las relaciones entre las distintas tareas, haz una
lluvia de ideas con el equipo para determinar un orden aproximado que tenga
sentido según las dependencias identificadas.
Crear un calendario provisional
Llegados a este punto, ya estás listo para crear un calendario provisional, que
implica asignar un entregable a cada tarea —por ejemplo, «fabricar un prototipo
para las pruebas de mercado»—; fijar plazos realistas; identificar cuellos de
botella para eliminarlos; buscar alternativas o añadir tiempo para asumirlas; y
establecer un protocolo para actualizar y revisar el calendario. En tu calendario
provisional, indica las fechas de inicio y final de cada una de las actividades e
identifica las relaciones entre tareas. Recuerda que solo se trata de tu primera
propuesta de calendario: podrás ajustarlo después, cuando el equipo lo haya
revisado.
Un gestor de proyectos se sirve de varias herramientas para elaborar el
calendario de trabajo de su equipo. A continuación, te presentamos unas cuantas
que suelen resultar útiles.
Método de la ruta crítica (CPM)
Como su nombre indica, el método de la ruta crítica, o del camino crítico, es un
sistema de cálculo conocido por sus siglas en inglés, CPM, (Critical Path
Method). Este método ayuda a identificar qué tareas son primordiales —las acciones que deben completarse puntualmente para que el proyecto cumpla los
plazos establecidos— para asignar los recursos de forma eficiente. Los gestores
de proyecto a menudo utilizan el CPM para marcar el orden de las actividades.
Imaginemos un proyecto que implique seis tareas con los siguientes requisitos y
plazos:
Puedes dibujar la ruta crítica siguiendo el ejemplo de la figura 2.
FIGURA 2
Método de la ruta crítica
Con este esquema verás que, como mínimo, son necesarios 12 días para
completar el proyecto. También resulta evidente que las actividades A y E son
primordiales para el plazo global. Teniendo esta información, puedes plantearte
si te interesa redirigir los recursos de que dispones hacia esas tareas.
Volvamos al proyecto de la compañía ABC Auto, analizado anteriormente, y a
su diagrama de red,. El diagrama no solo ilustra dependencias entre tareas, sino
que también revela la ruta crítica: (1) diseño del vehículo, (2) fabricación de
piezas externas, (3) pruebas externas y (4) prueba del vehículo. ¿Por qué esta
secuencia de tareas define la ruta crítica? Porque es la ruta más larga del
diagrama. La otra ruta —que pasa por (1) fabricación de piezas internas y (2)
pruebas internas— lleva dos días menos. Los miembros del equipo que trabajen
en dichas acciones podrían dedicarles dos días extra sin incumplir el plazo fijado
para la prueba del vehículo. Y tampoco acortarán los plazos del proyecto si
finalizan antes de tiempo su trabajo en actividades que no forman parte de la ruta
crítica. ¿Por qué? Las tareas de la ruta crítica determinan la duración total del
proyecto.,
Diagrama Gantt
Si lo único que necesitas es mostrar cuándo debe empezar y finalizar cada
actividad, prueba con un diagrama Gantt,. Puedes crear uno fácilmente con una
hoja de cálculo o con un programa de gestión de proyectos (véase la figura 3).
FIGURA 3
Diagrama Gantt
Fuente: Harvard ManageMentor® on Project Management, Boston: Harvard
Business Publishing, 2002, 26.
Se trata de una popular herramienta de calendarización porque es sencilla y nos
permite ver las acciones del proyecto de un solo vistazo. Sin embargo, no detalla
las relaciones entre tareas, como hace el CPM, por lo que quizá quieras hacer
constar las dependencias dentro de los bloques de tiempo.
Diagrama PERT
Como alternativa al diagrama Gantt, algunos gestores de proyectos se sirven de
la técnica de revisión y evaluación de proyectos, comúnmente abreviada como
PERT (por sus siglas en inglés, Project Evaluation and Review Techniques). Es
una útil herramienta que permite dar una visión general del proyecto, puesto que
ilustra la ruta crítica —en esencia se trata de un diagrama de red— y delinea las
metas del proyecto (véase la figura 4).
FIGURA 4
Diagrama PERT
Fuente: Harvard ManageMentor® on Project Management,Boston: Harvard
Business Publishing, 2002, 25.
Un diagrama PERT puede contar con muchas redes de tareas paralelas o
interconectadas, por lo que en el caso de proyectos complejos es fundamental
revisarlo periódicamente. Cuando realices el seguimiento del proyecto, quizá sea
necesario volver al diagrama y revisarlo. Por ejemplo, si el tiempo entre tareas
dependientes supera tus estimaciones y las tareas en cuestión se hallan en la ruta
crítica, tendrás que compensar el tiempo perdido en otro punto del calendario
para cumplir el plazo general del proyecto.
¿Qué herramienta de programación es mejor para tu objetivo? La que encaje con
tu manera de trabajar y te permita mantener informados a todos los miembros
del equipo y recordarles que forman parte de un esfuerzo más amplio.
Optimizar el calendario
Una vez creado el calendario provisional, se ha de trabajar en equipo para
mejorarlo. Anímales a encontrar:
Errores. ¿Son todas las estimaciones de tiempo realistas? Presta especial
atención a las tareas de la ruta crítica; ya que, si alguna de ellas no puede
completarse puntualmente, todo el calendario será incorrecto. Asimismo,
revisa las relaciones entre tareas. ¿El calendario refleja el hecho de que
algunas tareas no pueden iniciarse hasta que no se hayan terminado otras?
Omisiones. ¿Falta alguna tarea? ¿Has reservado tiempo para la formación?
Excesos. Si revisas el calendario, quizá descubras que hay, por ejemplo,
algún empleado que debería trabajar 10-12 horas al día durante meses para
completar las tareas que tiene asignadas; o que un equipo en concreto
tendría que rendir muy por encima de sus posibilidades. Si encuentras
problemas de este tipo, redistribuye la carga.
Cuellos de botella. Tienes que identificar cualquier tarea que haga que el
trabajo vaya acumulándose y afrontar el problema. Piensa en una cadena
de montaje de automóviles que deba detenerse porque la gente que instala
los asientos no puede seguir el ritmo de la cadena. La manera habitual de
resolver este problema es acelerar el proceso utilizado para realizar la tarea
o añadir más recursos —por ejemplo, más gente o mejores máquinas—.
Desequilibrios en la carga de trabajo. ¿Algunos miembros del equipo tienen
que hacer demasiado y otros tienen que hacer demasiado poco? Si
reequilibras las cargas de trabajo, quizá puedas acortar el calendario
global.
Tiempos de holgura que puedan aprovecharse. Tal vez sea posible acortar el
calendario quitando recursos de actividades que no formen parte de la ruta
crítica. Por ejemplo, si tienes a cuatro personas trabajando en una tarea no
primordial que cuenta con cuatro o cinco días de holgura, durante unos días
deriva a algunas de esas personas —o a todas— a una tarea primordial.
Aunque utilices un software de planificación de proyectos para supervisar las
tareas y los plazos, realiza este tipo de revisión exhaustiva con los miembros del
equipo. Si, para ello, te planteas comprar un programa informático, deberá
facilitarte elaborar y modificar los diagramas, calcular las rutas primordiales,
generar calendarios y presupuestos, tener en cuenta fines de semanas y
vacaciones, crear diferentes escenarios para la planificación de emergencias y
comprobar si alguna persona o algún grupo tienen demasiado trabajo asignado.
Capítulo 10
Estudio de caso HBR: ¿Lanzarse al fracaso?
Por Tom Cross
Nota del editor: Los estudios de caso HBR presentan relatos ficticios de
dilemas reales que algunos líderes han tenido que afrontar, y ofrecen
soluciones de expertos.
—No hay ningún motivo por el que los contratistas no puedan ofrecernos
productos sin defectos que hayan sido desarrollados rápidamente: velocidad y
calidad, ambas cosas —dijo David MacDonagle mientras se encendía un
cigarrillo. El viento cálido, que anunciaba lluvia, no paraba de apagarle los
fósforos. Finalmente se rindió y volvió a meterse el cigarrillo en el bolsillo.
MacDonagle, director de la Administración Aeronáutica de Canadá (CAA),
estaba nervioso. Todo el mundo en la sede de la CAA estaba nervioso. Dentro de
muy poco, el proyecto al que muchos habían dedicado los últimos cuatro años
iba a pasar su primera prueba en el mundo real, a 350 kilómetros de la Tierra.
MacDonagle se sentía enjaulado en las oficinas ejecutivas y la presencia de los
medios de comunicación lo agobiaba, así que había decidido salir a tomar el aire
—o más bien el humo del tabaco— y había propuesto a Samantha Van Sant, la
joven e inteligente directora del programa, que le acompañara.
Van Sant, antigua comandante del Ejército canadiense, también se jugaba mucho
en el proyecto. Desde el año 2006 había estado gestionando las dos empresas
que la CAA había contratado para que fabricaran, por valor de 1200 millones de
dólares, el juego de brazos robóticos gigantes conocido como Retractable
Extended-Arms Compatible Holder (REACH) para la Estación Espacial
Internacional.
—¿Cómo sueles manejar los nervios tú? —le preguntó MacDonagle.
—Normalmente salgo a correr —respondió Van Sant, mirando la carretera que
salía de la sede de la CAA y atravesaba unos maizales, por la que había recorrido
muchos kilómetros.
Se dieron la vuelta para observar las instalaciones de la agencia aeroespacial,
que a pesar de ser enormes parecían pequeñas en el vacío paisaje quebequés. A
Van Sant las vistas le recordaron una de las frases que MacDonagle solía repetir:
«En la exploración espacial somos una pequeña nación...».
Efectivamente, en comparación con Estados Unidos, Rusia, Europa y Japón,
Canadá desempeñaba un papel minúsculo en el espacio. Siempre con el temor de
ser marginados, la CAA había hecho todo lo posible para conseguir que los
contratistas del REACH (Hollenbeck Aircraft y Eskina Software Systems)
completaran la primera fase del proyecto a tiempo para transportar el
equipamiento a la estación espacial ese año, cuando el laboratorio orbital estaría
oficialmente acabado. Asombrosamente, habían cumplido el plazo... y dentro del
presupuesto. El REACH ya estaba amarrado a la estación, pero el proyecto aún
no había finalizado: también incluía un sofisticado juego de «manos» que
instalarían en los extremos de los brazos robóticos para realizar trabajos
extremadamente delicados. Las ampliaciones iban a desarrollarse durante dos
años más.
Los contratistas habían sido fantásticos en cuestión de velocidad; el problema
residía en la calidad: no paraban de aparecer fallos en el software, los motores y
los circuitos. Lo cierto es que, en cuatro años, ninguna de las pruebas realizadas
había conseguido resultados impecables: «Sí, sí, lo podemos resolver», era la
respuesta que siempre daban los representantes de las empresas contratistas,
haciendo caso omiso de las preocupaciones de la CAA.
—La vida está llena de riesgos —le dijo un representante a Van Sant después de
que uno de los brazos del REACH no respondiera a la orden de retraerse—. Ya
les avisamos de que un calendario comprimido aumentaría el riesgo.
El contrato que ella gestionaba exigía un desarrollo paralelo; es decir, las fases
del proyecto (I+D, fabricación del prototipo, ensayos, producción y control de
calidad) se superponían, de modo que cada fase se iniciaba cuando la anterior
aún estaba incompleta en un 50%. En algunos círculos de la industria
aeroespacial, eso era un sacrilegio. Pero, dado el plazo de la construcción de la
estación espacial y la siempre presente amenaza de recortes en la CAA, la
agencia se había fijado como objetivo realizar el trabajo de una década en seis
años. Las simulaciones por ordenador reemplazaban a los ensayos en el mundo
real. El control de calidad de las piezas era menos exhaustivo. Puesto que el
proyecto tenía muchas incógnitas, la CAA había aceptado un contrato de margen
sobre el coste; según el cual, los contratistas recibían una cantidad específica
sobre sus costes por mano de obra, materiales y gastos generales.
La insistencia de MacDonagle en enfocar el desarrollo desde la perspectiva de la
velocidad había sido una de las principales razones por las que habían contratado
a Van Sant como directora del programa. Durante sus años en el Ejército, se
había ganado una reputación a prueba de balas como gestora agresiva y centrada
en los objetivos. Ella y MacDonagle estaban de acuerdo. Van Sant sabía que la
velocidad era primordial.
—Tenemos que volver —dijo MacDonagle—. Nos espera la jauría de la prensa.
Les dije que daría entrevistas rápidas cuando volviera. Ya sé qué me van a
preguntar: «¿Funcionará el REACH esta vez?».
Empezó a llover mientras se dirigían hacia el edificio. MacDonagle miró a Van
Sant:
—¿Funcionará?
Se avecinan problemas
Con un rotulador rojo en la mano, MacDonagle preguntó a un grupo de
reporteros si eran conscientes de que hacía cincuenta años Estados Unidos había
puesto en órbita 500 millones de agujas de cobre de 2,5 centímetros de largo
para reflejar las ondas de radio y facilitar así las comunicaciones. Esas agujas
aún estaban flotando por el espacio y algunas habían rasgado uno de los
colectores solares de la estación espacial.
—Los paneles solares son las grandes alas rojas del gran pájaro —dijo,
volviéndose hacia la pizarra para dibujar los colectores y marcar un corte en uno
de ellos—. Un agujero aquí significa menos electricidad —añadió dando
golpecitos en la pizarra—. Desde que esas agujas voladoras agujerearon el panel
solar, la estación espacial ha estado funcionando con menos electricidad.
Arreglarlo es complicado porque está muy lejos de los módulos en los que
trabajan los astronautas y por el riesgo de electrocución. Una vez que el panel
está en su lugar, no puede apagarse. Sigue generando electricidad de la luz solar.
Por lo tanto, si uno de los astronautas intentara acercarse para arreglarlo, su
cuerpo correría el riesgo de recibir una descarga de 100 voltios. Aquí es donde
entra en juego el REACH.
Se tomó un momento para dibujar la invención canadiense, luego dio un paso
atrás para admirar su boceto. Los dos largos brazos de la máquina se extendían
hacia el panel solar como si lo abrazaran cariñosamente.
—El REACH no fue diseñado para arreglar paneles solares —apuntó
MacDonagle—. Está hecho para realizar trabajos de rutina, como sustituir las
baterías en el exterior de la estación espacial. Pero, puesto que el REACH ya
está allí, lo van a utilizar para realizar esta reparación. Cerrará el agujero del
panel solar mientras los astronautas lo controlan desde la seguridad de su
módulo.
Volvió a tapar el rotulador y empezó a responder a las preguntas. Mientras Van
Sant observaba la escena, alguien le dio una palmadita en el brazo. Era Alfred
Siroy, jefe de un departamento de la CAA cuyo objetivo era averiguar por qué
había tantos problemas de calidad en el equipamiento fabricado por HollenbeckEskina.
—¿Cuánto falta para que empiecen? —le preguntó.
—Poco... Un rato... No estoy segura —le respondió Van Sant.
Siroy siempre conseguía que Van Sant se pusiera a la defensiva. No ocultaba su
disconformidad con la manera en la que estaba gestionándose el programa
REACH, especialmente por la gestión en paralelo. Van Sant sabía que ese punto
de vista figuraría en el informe que Siroy estaba preparando. Por suerte, era muy
meticuloso a la hora de escribir, así que redactarlo le estaba llevando mucho
tiempo. Le preguntó cómo llevaba el informe:
—Es lento —le respondió con un movimiento de la cabeza—. Pero ya tenemos
el título: «Lanzarse al fracaso».
Van Sant se sobresaltó:
—¿Qué fracaso? —le preguntó—. El REACH está a punto de realizar una
reparación esencial.
Siroy le dirigió una mirada escéptica:
—Una producción rápida era un objetivo loable —respondió—, pero el
contratista necesita suficiente tiempo para la fase de aseguramiento de la calidad.
Y el contrato debe poner los incentivos donde corresponde —continuó—.
Hemos realizado un análisis. Tu ajustado calendario obliga a Hollenbeck-Eskina
a buscar atajos, y el resultado es que los prototipos fallan. Utilizar simulaciones
por ordenador en lugar de rigurosas pruebas sobre el terreno es una receta para el
desastre. No existe un sistema de gestión de datos electrónico que permita a los
contratistas y a la CAA acceder a los datos de los ensayos para analizarlos. Los
prototipos no incorporan los instrumentos que podrían suministrar los datos
experimentales adecuados. Y los contratistas no tienen ningún incentivo para
frenarse: el contrato de margen sobre el presupuesto pone todo el riesgo en
manos de la CAA. La agencia y los contratistas tienen diferentes metas y
objetivos.
Van Sant estaba de acuerdo en lo del contrato: sus puntos débiles eran cada vez
más evidentes para ella. Pero, si la velocidad era prioritaria, eran inevitables.
—El lenguaje del contrato es de hace muchos años —respondió con
menosprecio.
—Puedes revisar el pasado —dijo Siroy—. Cualquier contrato se puede
modificar si las dos partes se ponen de acuerdo... ya lo sabes.
De repente, Van Sant vio que uno de los empleados que había estado haciendo el
seguimiento de lo que ocurría en la estación espacial alejaba a MacDonagle de
los periodistas; quienes, oliendo carnaza, intentaron seguirlos. MacDonagle la
miró, y a Van Sant no le gustó la expresión de su rostro: algo malo estaba
pasando.
Consiguió pasar a la sala de comunicaciones, donde los periodistas no podían
entrar, justo antes de que se cerrara la puerta. En los altavoces pudo oír a los
astronautas de la estación espacial hablando de la unidad de conmutación y
empleando la palabra «error». Oyó que alguien decía: «Tenemos que pasar al
plan B».
El REACH probablemente presentaba el mismo problema que había surgido
durante su último ensayo sobre el terreno. Había aparecido una notificación de
error del sistema, pero los contratistas lo desestimaron como un simple «error de
notificación», suponiendo que no se trataba de una auténtica avería mecánica.
Sin embargo, lo cierto era que nadie iba a querer utilizar el REACH si sus luces
rojas estaban parpadeando. El riesgo de que los brazos robóticos fallaran en un
momento crítico era demasiado grande.
—¿Cuál es el plan B? —preguntó Van Sant a MacDonagle.
—No lo sé —le respondió en voz baja—, pero sea lo que sea no será nada
nuestro. El REACH es la única contribución de Canadá a la estación espacial.
Apoyo desde las alturas
—¡Tenemos vídeo! —gritó alguien, y en las pantallas aparecieron múltiples
imágenes de un hombre con traje espacial colgado del extremo de una grúa de
carga.
Ya eran más de las doce de la noche, pero los periodistas aún estaban en la CAA.
Se apiñaron alrededor de las pantallas. Hacía rato que MacDonagle y Van Sant
ya no intentaban evitarlos, y entre ellos estaban mientras observaban cómo se
desarrollaba la reparación en el espacio situado sobre África Occidental.
Todo el mundo miraba en silencio cómo la grúa, adaptada para la ocasión,
transportaba al astronauta hacia el panel solar de la estación espacial. El REACH
ni siquiera aparecía en la imagen, lo habían dejado aparcado en algún otro sitio.
—Harris Webb —dijo MacDonagle con tristeza mientras miraba a la figura con
el traje brillante—. ¡Qué apropiado!
Años atrás, MacDonagle y Webb habían trabajado como pilotos en la misma
misión espacial, y Webb, aunque mucho más joven, fue el elegido para dirigirla.
Webb era médico, alpinista, escritor, piloto y chef, además de astronauta
estadounidense: era el tipo en quien todo el mundo confiaba, brillante e
intrépido... casi hasta el punto de ser temerario.
Los periodistas comentaban animados sus acrobacias. Puesto que el REACH
había fallado, Webb se había colocado en el extremo de la grúa para ir a reparar
manualmente el panel solar. Con una de sus manos enguantadas sostenía lo que
parecía un enorme palo de hockey envuelto con aislante para poder detenerse
antes de chocar contra los paneles. En la otra mano llevaba varios cables de
plástico de unos dos metros de largo que iba a utilizar para «coser» el panel solar
plegable.
—¡Guau! —gritó uno de los periodistas al ver que Webb empezaba a introducir
torpemente uno de los cables a través de las huecos del panel.
—Imprudente —dijo entre dientes MacDonagle. Se puso las manos en la cabeza
y miró al techo.
Van Sant vio a Charlie Truss, uno de los representantes de Hollenbeck, sentado
en una esquina, con la corbata desabrochada. Tenía un aspecto horrible. Pero Van
Sant no sintió lástima, solo enojo. Se dirigió hacia él:
—Pase lo que pase allá arriba esta noche —le dijo—, acá abajo las cosas van a
cambiar. Nuestra única manera de superar este fiasco es demostrar que hemos
dado pasos concretos para mejorar la calidad de nuestros productos y conseguir
resultados positivos.
—Estoy totalmente a favor de eso —respondió Truss—. Pero cualquier medida
que tomes para aumentar la calidad hará que todo vaya más lento. Cuando eso
ocurra, los costes empezarán a aumentar y habrá la posibilidad de que tu agencia
sufra recortes de presupuesto. Si convertimos nuestro contrato en uno de los
contratos tradicionales en la industria aeroespacial, con todos esos pasos
secuenciales y con inevitables retrasos, ya podemos despedirnos de las mejoras
que teníamos preparadas para el REACH.
—Si hay que sacrificar la velocidad en pos de un REACH más fiable, que así sea
—dijo Van Sant—. El contrato tiene grandes deficiencias. Los contratistas son
responsables de la velocidad pero no del desempeño. Tenemos que compartir el
riesgo. Necesitamos un contrato con sanciones e incentivos basados en el
desempeño para equilibrar velocidad, calidad y resultados. Nuestro objetivo son
piezas fiables y sistemas que funcionen... y ese objetivo también debería ser el
suyo. Tenemos que trabajar como un equipo unido cuyos miembros puedan
controlarse mutuamente para conseguir resultados.
Van Sant oyó un grito ahogado de los periodistas. Se dio la vuelta y, aliviada, vio
que Webb, mientras finalizaba la reparación, había soltado sin querer unas
tenazas, que ahora se iban flotando en el espacio.
Pero entonces Webb hizo algo increíble. Se dirigió a su público de la Tierra y se
puso a defender el fracaso del REACH.
—Todo el mundo va a echarle las culpas al REACH, pero no deberían —dijo—.
Es una gran pieza de tecnología. Quiero felicitar a David MacDonagle y a la
CAA por superar un montón de obstáculos técnicos a toda prisa para que el
REACH estuviera acá a tiempo. Va a ser un elemento fundamental de nuestras
operaciones. Un pequeño problema de la unidad de potencia no es nada. Las
máquinas complejas fallan, así son las cosas. Lo arreglaremos, igual que hemos
arreglado este panel solar. Tengo entendido que en un par de meses la CAA va a
tener preparado un nuevo producto: unas manos robóticas tan diestras que
pueden pelar un huevo duro. Yo les digo que nos las envíen cuanto antes. Las
empezaremos a utilizar de inmediato. Necesito pelar unos cuantos huevos duros.
Van Sant se había quedado anonadada y vio que Truss también estaba
estupefacto. Luego, dirigiéndole una pequeña sonrisa, Truss le preguntó:
—¿Qué decías del contrato?
Tom Cross es director sénior de Educación Ejecutiva de la Darden School of
Business de la Universidad de Virginia, donde desarrolla programas de
educación ejecutiva para líderes del Departamento de Defensa. Antes fue
director sénior en empresas como KFC y Office Depot.
¿Debe Van Sant renegociar el contrato del REACH?
Véanse los comentarios que siguen.
Comentario #1
Por Gary L. Moe
Siempre que se oye hablar de grandes, complejas y costosas iniciativas
tecnológicas patrocinadas por el Gobierno que no consiguen cumplir las
expectativas, la culpa siempre acaba recayendo en las prisas del calendario. Si la
agencia pública no hubiera presionado tanto a los contratistas, si los
desarrolladores hubiesen tenido más tiempo para perfeccionar el diseño, si se
hubieran incluido algunos meses o años en el calendario de producción... la
tecnología habría funcionado a la perfección. Pero no es verdad.
Aunque el Gobierno otorgase a los contratistas todo el tiempo y el dinero del
mundo para completar un detallado análisis de requisitos y para perfeccionar el
diseño del proyecto, probablemente el producto final seguiría sin ser intachable.
El llamado «diseño big-bang», en el que los desarrolladores trabajan
vigorosamente para corregir hasta el más mínimo detalle, es incapaz de generar
un producto totalmente funcional y sin errores; porque los seres humanos, por
muy brillantes que sean, no pueden prever todos los problemas que pueden
surgir en una tecnología compleja.
Lo que se necesita, en realidad, es un proceso de desarrollo iterativo, con el que
construimos un prototipo o incluso un producto plenamente desarrollado y lo
ponemos a funcionar, lo ponemos a prueba y aprendemos de sus puntos débiles;
la mayoría de los cuales no son detectables en la mesa de dibujo o en la
simulación en 3D. En la siguiente iteración, mejoramos el producto. Luego
hacemos otra ronda de lo mismo... y otra... y otra... hasta que finalmente
conseguimos que funcione. Cuanto más compleja la tecnología, más iterativo
tiene que ser el desarrollo.
Así es cómo se desarrollan los productos en el sector no gubernamental.
Pongamos, por ejemplo, la industria del automóvil. Los coches son tan
complejos que, para fabricar un modelo, el fabricante lo construirá varias veces y
realizará numerosos test antes de iniciar su plena producción. En los proyectos
de software, este proceso se llama «desarrollo ágil». Los desarrolladores
escriben código durante una semana, lo ponen a prueba para ver cómo mejorarlo,
y luego escriben más código.
Un enfoque interactivo también funciona mejor en lo que a los cambios
organizativos se refiere. Por mucho que trabajemos en el diseño de una
reorganización, no lograremos hacerlo bien en más de un 60%; de modo que
debemos seguir trabajando en ello y al final conseguiremos el 90% —nunca
puede llegarse a un nivel más alto—.
El desarrollo iterativo puede funcionar tanto para grandes proyectos a largo
plazo como para proyectos puntuales; así son muchos de los componentes de la
Estación Espacial Internacional. Se tiene que dividir el desarrollo en distintas
secciones y aplicar el método de «construir-testar» las diferentes partes.
Así pues, ¿por qué las organizaciones gubernamentales, sobre todo las de los
sectores militar y aeroespacial, prefieren adoptar un diseño big-bang? Se explica
por varios motivos, y algunos tienen que ver con la manera en la que se gestiona
la contratación. Pero la raíz del problema está en que el desarrollo iterativo
conlleva experimentación, y la experimentación implica fracasos. Las agencias
gubernamentales temen los fracasos porque echan a perder algunas carreras
políticas. En consecuencia, intentan evitar la experimentación. Pero
normalmente con lo que acaban topándose es con un fracaso aún mayor... y sin
tener ni idea de lo que ha ocurrido.
Por eso, mi consejo para Samantha Van Sant es que reestructure el contrato para
dividir el desarrollo del REACH en pequeñas secciones y que exija a los
contratistas que lo mejoren siguiendo un proceso iterativo, en lugar de intentar
conseguir plena funcionalidad desde el principio. Recortar la funcionalidad que
se entrega en cada fase también puede ser una ayuda, ya que el 80% de los
excesos de coste y tiempo suelen deberse al último 10% o 20% de funcionalidad
requerida.
Gary L. Moe es director de la Oficina de Tecnología Empresarial de
McKinsey y trabaja desde Silicon Valley.
Comentario #2
Por Tom Quinly
En el mundo del desarrollo de productos innovadores, la batalla entre la
velocidad y la calidad ha terminado. La velocidad ha ganado... claramente. En
los competitivos mercados globales de hoy en día, sacar al mercado rápidamente
una innovación puede marcar la diferencia entre el éxito y el fracaso. Pero
también se da por hecho que la calidad debe ser elevada. La calidad se ha
convertido en lo mínimo que debe ofrecerse.
Se han publicado muchos estudios de investigación sobre el Santo Grial del
desarrollo ultrarrápido. Los programas de ingeniería simultáneos, los equipos
ágiles, los programas de mitigación de riesgos, el desarrollo en espiral, la
externalización, los mecanismos de armonización y las herramientas avanzadas
de simulación y modelado... todo ello puede ayudarte a conseguirlo, pero tu
propio equipo humano, los procesos de tu organización y las demandas del
mercado serán lo que determinará la receta adecuada. Lo que mejor nos funciona
a nosotros es formar equipos pequeños, con experiencia y mucho talento; ser
claros acerca de las expectativas respecto a la introducción del producto en el
mercado; verificar que los desarrolladores cuentan con las herramientas
adecuadas, y mantener a nuestros equipos técnicos motivados, contentos y
focalizados en el cliente.
La burocracia, sin embargo, mata la innovación. A medida que una empresa va
creciendo, es inevitable que en los procesos se vayan introduciendo
sigilosamente cosas que no añaden valor. Con cada tropiezo existe la tendencia
de añadir al proceso otra capa de verificación. Por separado, cada verificación
tiene todo el sentido del mundo, pero todas combinadas hacen que la innovación
quede obstruida y que el equipo no pueda avanzar con agilidad.
Recuerdo una experiencia que tuve al principio de mi carrera, cuando un gran
proyecto de desarrollo dio resultados deficientes. En una reunión de revisión
ejecutiva, lo tenía todo preparado para explicar qué había ocurrido, qué
habíamos aprendido y qué habíamos hecho para parar la hemorragia. Nuestro
director ejecutivo miró al resto de los asistentes y dijo que estaba
decepcionado... no con el grupo que había fracasado (el mío), sino con los otros
grupos, porque ellos no habían fracasado. No estaban siendo tan agresivos como
se esperaba de ellos. La anécdota pervive en la tradición oral de la compañía y
dice mucho sobre nuestra cultura.
No se trata de fomentar el fracaso: lo utilizamos como una herramienta. Los
programas de desarrollo complejo raras veces —si es que alguna vez— salen a
la perfección a la primera; a menudo, ocurre algo inesperado. Se aprende mucho
de revisar los fracasos y analizar los procesos, las expectativas, las personas y
los instrumentos. ¿Nuestros requisitos eran demasiado ambiciosos o estaban mal
definidos? ¿No habíamos identificado las zonas de alto riesgo? ¿Habíamos
diseñado buenos planes de reducción de daños? Este eterno esfuerzo por
aprender mejora la predictibilidad, reduce la duración del ciclo y nos ayuda a
sacar al mercado un producto de alta calidad antes que la competencia.
Por eso, recomendaría a Van Sant que abandone la jurásica creencia de que la
velocidad implica sacrificar la calidad. Debería pedirle a todo su equipo que
analicen los errores y que exploren nuevas maneras de conseguir calidad sin
poner en peligro el calendario. Si el REACH tiene pocos socios alternativos con
las cualificaciones necesarias, entonces alterar un contrato de larga duración con
un socio muy experimentado y especializado sería contraproducente. Si
Hollenbeck-Eskina es la mejor opción, yo evitaría la revisión del contrato por el
posible riesgo de perder un socio con un profundo conocimiento del proyecto.
No obstante, si Hollenbeck-Eskina no colabora plenamente en el análisis y la
corrección de los errores, entonces puede que sea hora de implicar a otros socios
potenciales o de mantenerse firmes en la renegociación del contrato.
Tom Quinly es presidente del Departamento de Control del Movimiento de
Curtiss-Wright Controls, empresa con sede en Charlotte (Carolina del
Norte) que desarrolla productos para los mercados industrial, aeroespacial
y militar.
Capítulo 11
Empieza el proyecto sobre una buena base
Una vez formado el equipo, entregada el acta de constitución del proyecto y
programadas las tareas del equipo, aún quedan algunas cuestiones esenciales por
abordar antes de empezar a trabajar. En primer lugar, tu proyecto precisa un
lanzamiento,, un evento especial que marque su comienzo oficial. En segundo
lugar, es necesario organizar las actividades y facilitar las herramientas que
contribuyan a fortalecer el equipo. Y, en tercer lugar, se han de crear normas de
comportamiento que posibiliten el trabajo en colaboración y comunicarlas a
todos los participantes.
Por qué importa el lanzamiento
El lanzamiento constituye el primerísimo hito del proyecto. Si se realiza
correctamente, su valor simbólico es considerable.
La mejor manera de iniciar un proyecto es organizar un encuentro con todo el
equipo, con el grado de solemnidad y pompa que se merezca. Ya habrás
mantenido muchas reuniones de planificación con personas clave del proyecto,
pero esos encuentros informales no pueden sustituir a un encuentro cara a cara
con todos los miembros del equipo, el patrocinador, las partes interesadas y, en
su caso, el responsable de mayor rango de la organización.
La presencia física en esta reunión tiene una gran importancia psicológica; sobre
todo, en el caso de equipos geográficamente dispersos, cuyos miembros tendrán
pocas oportunidades de reunirse como grupo en el futuro. Estar juntos al
principio de su largo viaje y tener la posibilidad de conocerse personalmente
fortalecerá el compromiso de los miembros del equipo y contribuirá a
convencerles de que son un equipo y un proyecto importantes. Si alguien no
puede asistir a la reunión de lanzamiento por su ubicación geográfica,
convendría que participara de forma virtual, a través de una videoconferencia o,
por lo menos, con un altavoz.
La presencia y el comportamiento del patrocinador durante el lanzamiento dicen
mucho de la importancia —o la falta de ella— que se atribuye a la misión del
proyecto. Como Jon Katzenbach y Douglas Smith escriben en «The Discipline
of Teams» (HBR, marzo-abril de 1993):
Cuando un equipo potencial se reúne por primera vez, todo el mundo está
observando las señales que los otros envían para confirmar, posponer o
descartar suposiciones y preocupaciones. Prestan especial atención a quienes
poseen autoridad: el líder del equipo y cualquier ejecutivo que haya conformado
el equipo, lo supervise o influya en él de algún modo. Y, como siempre, lo que
estos líderes hacen es más importante que lo que dicen. Si, diez minutos después
de su comienzo, un director sénior abandona la reunión de lanzamiento para
atender una llamada y ya no vuelve, la gente entiende el mensaje.
Estas son las principales tareas que debes efectuar para el lanzamiento:
Da la bienvenida a todos los miembros del equipo. Saluda y da las gracias a
todos aquellos que colaborarán de algún modo en el proyecto. Menciona a
todo el mundo por su nombre. Muchos de los asistentes serán miembros
centrales del equipo, mientras que otros serán miembros periféricos que
solo participarán temporalmente o de forma limitada. Pero todos serán
miembros.
Pídele a tu patrocinador que diga algunas palabras. Pídele que hable de por
qué el proyecto es importante y de cómo concuerdan sus objetivos con los
objetivos de la organización en general. De lo contrario, los miembros del
equipo no verán qué consecuencias tiene para ellos ni para la compañía y no
se esforzarán al máximo.
Haz las presentaciones pertinentes. A menos que ya se conozcan entre sí, es
probable que no sepan qué cualificaciones tiene cada persona. Si el grupo no
es demasiado grande, pídele a cada participante que se presente y diga algo
sobre su formación y su experiencia, así como sobre cuál será su
contribución en el proyecto y qué espera sacar de él.
Haz una presentación del acta de constitución. Explica los objetivos,
entregables y calendarios que hayas documentado.
Busca consensos. Consigue que todo el mundo se ponga de acuerdo respecto
a lo que significa el acta de constitución.
Describe los recursos disponibles. Aunque sin duda vas a querer avivar el
entusiasmo del equipo durante el lanzamiento del proyecto, también es
importante que des expectativas realistas sobre la cantidad de apoyo —
tanto de personas como de presupuesto— que vas a tener.
Describe los incentivos. ¿Qué recibirán los miembros, además de su
compensación habitual, si el equipo cumple los objetivos o los supera?
Aunque los participantes desarrollarán un sentimiento de pertenencia y objetivos
comunes solo con el tiempo y a través de experiencias compartidas, en este
encuentro de lanzamiento habrás plantado las semillas para que ello suceda. La
idea es que empiecen a sentirse como miembros de un equipo de verdad.
Facilitar actividades y herramientas para trabajar
juntos
Si solo damos a la gente objetivos colectivos y camisetas con el logo del equipo,
de equipo lo único que tendrá es el nombre. El equipo de un proyecto se
consolida mediante el trabajo común, el intercambio de ideas y el tira y afloja
habitual en la toma de decisiones.
Un gestor de proyectos puede facilitar este tipo de colaboración mediante
reuniones periódicas, herramientas de comunicación como boletines y webs del
proyecto, así como con la ubicación física de los miembros del equipo. Los
eventos sociales fuera de la empresa también pueden ser válidos, pues fomentan
la cohesión del grupo. Tu objetivo será animar a la gente a crear los lazos de
confianza y amistad que conviertan el trabajo en equipo en algo estimulante y
productivo.
Establecer normas de comportamiento
Lleva tiempo construir un equipo eficaz. Cada persona se suma al proyecto por
intereses personales. Es posible que algunos miembros vean a sus compañeros
como la competencia para conseguir promociones, reconocimiento y premios. A
lo mejor, algún miembro del equipo guarda rencor a otro. Y siempre hay alguien
con pocas aptitudes sociales.
Este tipo de problemas pueden perjudicar a tu proyecto si no los frenas o
neutralizas. Una de las mejores maneras de gestionarlos es establecer unas claras
normas de comportamiento que todo el mundo deberá seguir por igual. Como
Jon Katzenbach y Douglas Smith observan en The Wisdom of Teams, las reglas
más esenciales tienen que ver con los siguientes aspectos:
Asistencia. El equipo no puede tomar decisiones y realizar su trabajo si los
miembros no asisten a las reuniones o las sesiones de trabajo en común. Si
tú, el líder, siempre llegas tarde o estás ausente, la gente seguirá tu ejemplo.
Interrupciones. Hay que apagar los móviles durante las reuniones y las
sesiones de trabajo. Asimismo, deja claro que nadie puede interrumpir a
nadie. Todo el mundo tiene derecho a hablar.
Vacas sagradas. Haz que sea evidente que no habrá temas tabú. Por
ejemplo, si un equipo cuyo objetivo es rediseñar procesos sabe que un
cambio concreto podría disgustar a uno de los directivos de la empresa, sus
miembros deben tener la seguridad de que pueden debatirlo sin problemas.
Desacuerdos. Es muy probable que distintas personas propongan diferentes
soluciones al abordar los problemas. Anímales a buscar formas
constructivas de resolver los desacuerdos.
Confidencialidad. Es posible que algunos problemas del equipo sean
delicados. Los miembros solo hablarán de ellos con libertad si saben que lo
que digan no va a salir del equipo.
Orientación a los resultados. El propósito de un equipo no es reunirse y
debatir, sino actuar y generar resultados. Déjalo claro desde un buen
principio.
¿Qué normas de comportamiento debe seguir tu equipo? Depende de cuál sea el
objetivo del grupo y la personalidad de sus miembros. Pero las normas básicas
son el respeto mutuo, la escucha activa y saber cómo verbalizar preocupaciones
y gestionar conflictos.
Para que las ideas fluyan libremente, puede que algunos grupos quieran adoptar
directrices específicas para fomentar una toma calculada de riesgos, por ejemplo,
o para establecer procedimientos de reconocimiento y gestión de errores. Sean
cuales sean las normas que siga tu grupo, asegúrate de que todos los miembros
puedan participar en su elaboración... y de que todo el mundo esté de acuerdo en
respetarlas. La participación y la aceptación por parte de los miembros del
equipo evitarán muchos problemas en el futuro.
Capítulo 12
La disciplina de los equipos
Resumen de las principales ideas contenidas en el artículo publicado en la HBR
por Jon R. Katzenbach, y Douglas K. Smith.
LA IDEA, EN RESUMEN
La palabra «equipo» llega a estar tan manida que muchos gestores no son
conscientes de su auténtico significado... ni de su verdadero potencial. Con un
grupo de trabajo común y corriente, el desempeño depende de lo que sus
miembros puedan hacer como individuos. El desempeño de un equipo, en
cambio, requiere responsabilidad individual y también mutua.
Aunque no parezca nada especial, la responsabilidad mutua puede generar
resultados asombrosos. Permite que el equipo alcance niveles de ejecución
mucho mayores que los mejores resultados individuales de sus miembros. Para
conseguir estos beneficios, los miembros del equipo deben hacer algo más que
escuchar: responder constructivamente y prestarse apoyo mutuo. Además de
compartir estos valores que fomentan el espíritu de grupo, deben compartir una
disciplina esencial.
LA IDEA, EN LA PRÁCTICA
La disciplina esencial de un equipo tiene cinco características:
Un reto de rendimiento excepcional tiende a crear un equipo. La mayoría de
los equipos responden a un mandato inicial externo al grupo. Pero para
tener éxito el equipo debe «apropiarse» de este propósito, darle su propio
toque.
Unos objetivos de desempeño específicos que surjan del propósito común.
Por ejemplo, lanzar un nuevo producto al mercado en menos de la mitad del
tiempo normal. El equipo estará inspirado y estimulado por objetivos
imperiosos: infundirán una sensación de urgencia. Dichos objetivos también
tienen un efecto nivelador, pues exigen que los miembros se centren en el
esfuerzo colectivo necesario, en lugar de en sus diferencias de cargo o
estatus.
Una combinación de habilidades complementarias. Entre ellas encontramos
competencias técnicas y funcionales, capacidad para resolver problemas y
tomar decisiones, así como habilidades interpersonales. Los equipos exitosos
raras veces cuentan con las aptitudes necesarias desde el principio: las
desarrollan a medida que van aprendiendo qué exige el desafío al que se
enfrentan.
Un fuerte compromiso con la manera en la que se lleva a cabo el trabajo.
Los equipos deben llegar a acuerdos respecto a quién realiza qué tareas,
cómo se establecen y cumplen los calendarios, y cómo se toman y cambian
las decisiones. En un verdadero equipo, cada miembro realiza una cantidad
equivalente de auténtico trabajo; todos los miembros, incluido el líder,
contribuyen de formas concretas en el trabajo colectivo.
Responsabilidad mutua. La confianza y el compromiso no se obtienen
mediante la fuerza. El proceso para ponerse de acuerdo respecto a los
objetivos del grupo es la prueba que deben superar los miembros para
rendirse cuentas mutuamente... no solo con el líder.
Una vez establecida la disciplina esencial, el equipo podrá concentrarse en los
desafíos fundamentales a los que se enfrenta:
Para un equipo cuyo propósito es dar recomendaciones, el reto es empezar de
forma rápida y constructiva, y dar resultados claros a aquellos que deban poner
en práctica sus recomendaciones.
Para un equipo que crea productos, se trata de no perder nunca de vista sus
objetivos de desempeño específicos.
Para un equipo que se encarga de dirigir, su principal tarea es distinguir los
desafíos que precisan un enfoque de equipo real de los que no lo necesitan.
Si una tarea no requiere productos fruto de un trabajo conjunto, un grupo de
trabajo puede resultar la opción más eficaz. Un equipo es lo más conveniente
cuando la jerarquía o ciertos límites de la organización coartan las competencias
y perspectivas necesarias para conseguir resultados óptimos. No es de extrañar,
pues, que los equipos se hayan convertido en las principales unidades de
productividad de las organizaciones con un elevado desempeño.
Jon R. Katzenbach es socio sénior de Booz & Company y antiguo director
de McKinsey & Company. Douglas K. Smith es consultor organizativo y
antiguo socio de McKinsey & Company.
Fase 3
Ejecución
Capítulo 13
Reuniones eficaces
Dirige bien las reuniones e infunde energía, fuerza y sentido a tu proyecto.
¿Cómo conseguir que sean productivas? Sigue estas sencillas directrices.
Preparar bien la reunión
Asegúrate de que la reunión sea necesaria. Si puedes conseguir el objetivo sin
convocarla —por ejemplo, por correo electrónico—, hazlo... y evita que todo el
mundo pierda el tiempo.
Aclara el objetivo de la reunión. Si se trata de tomar una decisión, explícalo y da
el tiempo y los materiales necesarios para que los participantes se preparen.
Sondea previamente a los principales participantes sobre los puntos importantes
del orden del día. Quizá te des cuenta de que es necesario hacer modificaciones.
Convoca solo a personas que, en la reunión, puedan aportar o aprender algo.
Facilita previamente un orden del día que claramente sirva al objetivo fijado.
Insiste en que todo el mundo se ponga al día de los asuntos por tratar antes de la
reunión, que traigan los materiales pertinentes y que se preparen para contribuir
en el debate.
Gestionar la reunión
Vuelve a definir el propósito de la reunión. Así, el grupo centrará su atención en
ese punto.
Deja que todo el mundo exprese su opinión. Si alguna persona acapara la
conversación o si alguno de los asistentes no se atreve a tomar la palabra, puedes
decir: «Gracias por tus ideas, Phil. ¿Qué piensas tú sobre este problema,
Charlotte?».
Mantén la conversación centrada en las cuestiones fundamentales.
Termina con una confirmación y un plan de actuación que incluya unos plazos
bien definidos: «Muy bien, hemos decidido contratar a DataWhack para instalar
los nuevos servidores. Y, tal como hemos quedado, yo me encargaré de obtener
la orden de compra hoy, Bill llamará al vendedor esta semana y acordará con él
un calendario, y Janet se pondrá a buscar a alguien que pueda llevarse el antiguo
equipo. Nos volveremos a reunir a la hora habitual la próxima semana para ver
cómo está todo».
Llevar un seguimiento
Envía una nota que resuma los principales resultados de la reunión. Poner en
evidencia que se ha dado un paso más hacia el objetivo anima a la gente.
Recuerda a cada persona sus tareas y plazos.
Ofrece ayuda a quien pueda sentirse abrumado por otro trabajo o tenga
dificultades con una tarea. La gente suele ser reacia a pedir ayuda, incluso
cuando son conscientes de que la necesitan.
Capítulo 14
El enfoque adaptativo de la gestión de proyectos
¿Tu proyecto incluye una tecnología o un material desconocidos? ¿Es
sensiblemente mayor que los proyectos que has supervisado hasta ahora? ¿Se
trata de tareas distintas a las que tu equipo ha gestionado anteriormente?
UN NUEVO MODELO PARA EL PATROCINADOR
El modelo adaptativo de la gestión de proyectos crea una nueva función para el
patrocinador del proyecto; función que Robert Austin vincula al capital riesgo en
su artículo «Project Management and Discovery» publicado en Science en 2002.
En lugar de dar al equipo un montón de recursos al principio, presta apoyo al
proyecto por fases, a medida que va dando resultados. Como en el caso del
capital riesgo, el patrocinador avanza recursos para adquirir información y
reducir la incertidumbre... y cada inversión le da la opción de permanecer en el
juego.
Si has respondido afirmativamente a alguna de estas preguntas, es posible que un
enfoque tradicional de la gestión de proyectos no funcione. Ello sucede porque
el enfoque tradicional presupone que puedes identificar qué hay que hacer,
cuánto costará y cuánto tiempo llevará. En situaciones con mayor nivel de
incertidumbre —por ejemplo, si te enfrentas a riesgos no previstos, o si la gama
de posibles resultados es muy amplia—, algunas herramientas para tomar
decisiones como el retorno de la inversión, el valor neto actual y la tasa interna
de desempeño —que presuponen la predictibilidad de los futuros flujos de caja
— dejan de ser útiles. Quizá debas plantearte un enfoque más adaptativo.
Abordan las tareas de forma iterativa. El equipo realiza pequeñas tareas
graduales, evalúa el resultado de dichas tareas y hace ajustes a medida que
va avanzando.
Tienen ciclos rápidos. Los plazos cortos permiten adoptar un enfoque
iterativo.
Ponen el énfasis en una entrega de valor inicial. Pequeñas entregas previstas
a corto plazo fomentan la valoración del trabajo realizado y la
incorporación de lo aprendido en las actividades posteriores.
Reclutan a gente que puede adaptarse. Algunas personas aprenden más
rápido que otras y están más abiertas al cambio.
Cisco se refiere a su enfoque con el nombre de «realización rápida e iterativa de
prototipos». Muchas de las tareas son como sondas; es decir, funcionan como
experiencias de aprendizaje para los pasos subsiguientes. Esta táctica es análoga
al concepto de «cazas fáciles» que las organizaciones de I+D utilizan para
analizar muchas posibilidades rápidamente y a bajo coste. Cuando la solución
adecuada no es aparente, realizan varios experimentos sencillos para distinguir
entre opciones prometedoras y opciones no tan prometedoras. Incluso los
experimentos fallidos son lecciones para averiguar qué funcionará.
TROCEADO Y PLANIFICACIÓN «Y-SI»
Para ampliar su capacidad de adaptarse a condiciones cambiantes, algunas
empresas utilizan las técnicas que Cathleen Benko y F. Warren McFarlan llaman
«troceado y planificación “y-si” (what-if)» en su libro Connecting the Dots:
Aligning Projects with Objectives in Unpredictable Times. La compañía de
software sueca Ellipsus Systems utilizó la planificación “y-si” para decidir qué
estándar de programación —protocolo de aplicación inalámbrica (WAP) o Java
— iba a utilizar en su software. Puesto que no estaba claro qué estándar acabaría
siendo el dominante, el cofundador de la empresa, Rikard Kjellberg, diseñó
distintos proyectos basados en ambos estándares, y luego presentó los primeros
prototipos en ferias comerciales para poner a prueba las preferencias de los
participantes. Su planificación de contingencias lo condujo a una exitosa
colaboración con la compañía creadora de Java: Sun Microsystems.
La empresa de gestión hotelera Carlson Hospitality Worldwide, con sede en
Minnesota, se sirve del troceado para descomponer proyectos grandes y caros en
proyectos más pequeños y manejables, de modo que aumenta
las probabilidades de que sean aprobados y reciban financiación. Después de que
el Consejo de Administración rechazase una petición de 15 millones de dólares
para reparar el sistema central de reservas de la compañía, los gestores
dividieron el proyecto en distintas unidades de trabajo con beneficios
independientes y mínimas dependencias mutuas. Es decir, si se cancelaba un
trozo, el resto podía seguir adelante. El consejo no tardó en aprobar el primer
trozo. Al final, el nuevo sistema de reservas de Carlson fue votado como el
primero del sector; la parte de reservas por voz ya generaba 40 millones de
dólares de ingresos anuales en 2003: «El troceado nos permite aprender y
reevaluar constantemente nuestras prioridades», afirma el director de Sistemas
Informáticos Scott Heintzeman. «También reduce riesgos y hace que la gente
centre sus esfuerzos en cada unidad de trabajo. Y, como cada trozo lleva solo
entre tres y seis meses de trabajo, la gente no pierde energía ni entusiasmo».
Adaptado de «Close the Gap Between Projects and Strategy», Harvard
Management Update (producto n.º U0406A), junio de 2004.
Capítulo 15
Un buen proyecto también puede fracasar
Resumen de las principales ideas contenidas en el artículo publicado en la HBR
por Nadim F. Matta, y Ronald N. Ashkenas,.
LA IDEA, EN RESUMEN
Un asombroso porcentaje de grandes proyectos fracasan: según algunas
estimaciones, más de la mitad. ¿Por qué los esfuerzos que implican a mucha
gente durante largos periodos de tiempo son tan problemáticos? La planificación
de proyectos tradicional conlleva tres serios riesgos:
Espacios en blanco. Los planificadores dejan huecos en el plan del proyecto
porque no pueden prever todas las actividades y los flujos de trabajo que
precisará el proyecto.
Ejecución. Los miembros del equipo no consiguen llevar a cabo las acciones
que les han asignado de forma correcta.
Integración. Los miembros del equipo ejecutan cada una de las tareas a la
perfección —dentro de plazo y presupuesto—, pero al final no ordenan bien
todas las piezas del proyecto. El proyecto no da los resultados esperados.
Es posible gestionar estos riesgos con iniciativas de resultados rápidos,:
pequeños proyectos diseñados para generar rápidamente miniversiones de los
resultados finales del proyecto grande. Gracias a las iniciativas de resultados
rápidos, los miembros del equipo pueden eliminar obstáculos antes y a pequeña
escala. Los equipos de resultados rápidos sirven como modelo para que, después,
los otros equipos desarrollen la iniciativa a mayor escala con más seguridad. El
equipo se siente satisfecho por generar un valor real, y la empresa consigue antes
una recompensa por su inversión.
LA IDEA, EN LA PRÁCTICA
Las iniciativas de resultados rápidos presentan varios rasgos característicos:
Se centran en los resultados. La iniciativa genera recompensas medibles a
pequeña escala.
Ejemplo:El Banco Mundial quería mejorar la productividad de 120.000
pequeños agricultores de Nicaragua en un 30% a 16 años vista. Para conseguirlo,
sus iniciativas de resultados rápidos incluían «aumentar en un 30 % el peso de
los cerdos de 30 granjas en un plazo de 100 días utilizando para ello granos de
maíz mejorado».
Son verticales. Las iniciativas incluyen a personas de distintas ramas de la
organización —a veces, de diferentes organizaciones— que trabajan
simultáneamente en un plazo de tiempo muy corto para realizar fragmentos
de varias actividades horizontales (o paralelas). El énfasis tradicional en
actividades desintegradas, horizontales y a largo plazo deja paso a acciones
integradas, verticales y a corto plazo. El equipo descubre las actividades
ubicadas en el espacio en blanco entre los flujos horizontales del proyecto e
integra correctamente todas las actividades.
Ejemplo:Supongamos que estamos trabajando en un proyecto de gestión de la
relación con el cliente a escala de toda la empresa. Tradicionalmente, un equipo
se ocupa de analizar a los clientes, otro de seleccionar el software, y un tercer
equipo desarrolla los programas de formación. Cuando finalmente se termina el
proyecto, sin embargo, es posible que los comerciales no introduzcan los datos
necesarios porque no entienden qué deben hacer. En cambio, con el concepto de
iniciativas de resultados rápidos, un solo equipo puede encargarse de
incrementar los ingresos de un grupo de ventas de una determinada región en un
plazo de cuatro meses. Para conseguirlo, los miembros del equipo deben tener en
cuenta el trabajo realizado por todos los equipos paralelos: no tardarán en
descubrir la resistencia que oponen los comerciales, así como otros imprevistos.
Son rápidas. La iniciativa quiere obtener resultados y aprendizajes en
menos de 100 días. Está diseñada para conseguir ganancias rápidas y, lo que
es más importante, para cambiar la forma en la que trabajan los equipos.
¿Cómo? El plazo corto de tiempo genera una sensación de urgencia desde el
inicio, plantea desafíos personales y no deja tiempo que perder en riñas
entre distintas partes de la organización. También estimula la creatividad y
anima a los miembros del equipo a experimentar con nuevas ideas para
generar resultados concretos.
Equilibrar las actividades verticales y horizontales
Las iniciativas verticales de resultados rápidos presentan muchas ventajas. Sin
embargo, eso no significa que se deban eliminar todas las actividades
horizontales. Estas acciones ofrecen economías de escala rentables. La clave está
en equilibrar lo vertical con lo horizontal, en difundir los conocimientos
adquiridos entre los equipos y en combinar todas las actividades en una
estrategia global de ejecución.
Ejemplo: La empresa de material de oficina Avery Dennison, insatisfecha con el
incremento de sus ingresos, un 8% en dos años, formó varios equipos de
resultados rápidos en tres divisiones de Norteamérica. Tan solo en tres meses,
los equipos lograron cumplir sus objetivos: conseguir un pedido nuevo de un
gran cliente para un producto mejorado en menos de 100 días. El equipo
directivo de la compañía decidió ampliar el proceso de resultados rápidos a
toda la organización, y lo reforzó con un amplio programa de comunicación
entre los empleados. Sin abandonar las actividades horizontales, decenas de
equipos pusieron en marcha sus iniciativas de resultados rápidos. ¿Cuál fue el
resultado? Ocho millones de dólares en nuevas ventas y cincuenta millones en
previsión de ventas al cierre del ejercicio.
Nadim F. Matta es socio director y Ronald N. Ashkenas es socio sénior de
Schaffer Consulting en Stamford (Connecticut).
Capítulo 16
Seguimiento y control
Por Ray Sheen
A diferencia de los procesos —en los que la misma gente realiza repetidamente
las mismas actividades—, los proyectos suelen acarrear actividades únicas —
como la utilización de nuevas tecnologías, la construcción de nuevos edificios o
la programación de un nuevo software—, realizadas por personas que tal vez sea
la primera vez que trabajan juntas. En consecuencia, como líder del proyecto,
tendrás que hacer un seguimiento activo para comprobar si tu plan realmente
está conduciendo a tu equipo hacia sus objetivos.
Para realizar el seguimiento y el control del proyecto, son imprescindibles cinco
pasos básicos:
1. Hacer un seguimiento de las actividades del
proyecto
Es importante que periódicamente te pongas en contacto con los miembros del
equipo, para comprobar que están realizando sus tareas y cumpliendo con los
estándares de calidad. Para ello, resulta eficaz convocar reuniones de equipo,
siempre y cuando todo el mundo trabaje en la misma ubicación. Sin embargo,
teniendo en cuenta lo dispersos que suelen estar los equipos en los actuales
entornos empresariales, puede resultar difícil reunir a todo el grupo. En ese caso,
yo organizo sesiones de trabajo independientes con los individuos o con los
pequeños grupos necesarios para actividades concretas.
Por ejemplo, hace poco participé en una conferencia telefónica en la que
ingenieros de tres oficinas distintas ayudaron a preparar la propuesta de
desarrollo de producto para un cliente. Si hubiese escrito un borrador, lo hubiese
repartido para recibir comentarios y luego hubiese intentado integrarlo todo,
seguramente habría tardado varias semanas en completar el documento. En lugar
de eso, reuní a los ingenieros pertinentes por teléfono durante tres horas para que
revisaran el documento conjuntamente, hasta que todo el mundo estuvo de
acuerdo con el redactado. Tras una sesión de trabajo de este tipo, pongo al día al
resto del equipo en una reunión de grupo más grande o por correo electrónico.
También realizo «comprobaciones entre compañeros» para verificar que las
tareas se hacen bien. Cuando alguien finaliza una actividad, otro miembro del
equipo analiza los resultados. No es un análisis técnico en profundidad; es una
verificación rápida para confirmar que a la persona que ha hecho el trabajo no se
le haya pasado algo por alto y que haya entendido bien los requisitos. Por
ejemplo, si un miembro del equipo revisa un plan de formación para un nuevo
sistema, se cerciorará de que estén incluidos todos los departamentos que
necesitan la formación. Siempre que sea posible, encarga esta verificación a
alguien que pueda utilizar los resultados de la actividad. Cuando trabajé con una
empresa de dispositivos médicos en el desarrollo de un nuevo producto, le pedí a
su departamento de regulación que analizara la documentación del diseño y que
pusiera a prueba los datos para ver si faltaba alguna información necesaria por
razones regulatorias. Si ninguno de los miembros tiene un interés en el resultado
del equipo, puedes hacer la comprobación tú mismo, pero deja claro que no se
trata de una evaluación profesional. Solo se trata de un miembro del equipo
mirando por uno de sus compañeros.
2. Recopilar datos de progreso
Algunas compañías cuentan con sistemas informáticos de gestión de proyectos
que generan informes de forma automática. Si puedes servirte de uno, utilízalo
sin ninguna duda, pero recopila también datos del progreso del proyecto a través
de cortas reuniones de actualización,, en las que los miembros del equipo
informen del estado de las actividades y evalúen riesgos, sea cara a cara o de
forma virtual. En mi caso, limito este tipo de reuniones a diez minutos, y solo
hablamos de las tareas iniciadas o finalizadas desde la última reunión. El
objetivo es hacerse una idea de cómo progresan las cosas, no es ponerse a
trabajar en equipo. Si el grupo detecta algún problema o riesgo, los resolvemos
en otra sesión, con las personas pertinentes.
Yo suelo convocar reuniones de actualización semanalmente, ya que me
permiten hacer un seguimiento adecuado del proyecto y detectar problemas para
resolverlos a tiempo. No obstante, cuando un proyecto entra en modo crisis, la
«tasa de actualizaciones» se acelera.
Una vez gestioné un proyecto en el que el sistema eléctrico de una nueva
instalación falló tres días antes de que el edificio se pusiera en funcionamiento.
Un importante objetivo empresarial dependía de esa fecha límite. El equipo
trabajó día y noche para detectar la causa del error, para sustituir el componente
averiado y para volver a conectar el edificio a la red eléctrica. Normalmente, tal
proceso habría durado dos o tres meses, pero solo teníamos tres días, así que
pedí actualizaciones cada tres horas.
3. Analizar el desempeño del proyecto para verificar
que el plan aún funciona
Raras veces las actividades salen exactamente como se había previsto. Se puede
tardar más o menos tiempo; los gastos pueden no coincidir con la cantidad
presupuestada, por arriba o por abajo. Una desviación del plan no es un
problema, siempre y cuando no ponga en peligro los objetivos del equipo.
En un proyecto, en una reunión de actualización, un ingeniero me informó de
que un nuevo molde llevaba un retraso de dos semanas. Pero el molde no estaba
en nuestra ruta crítica y contábamos con casi seis semanas de holgura en esa
sección del calendario, por lo que el equipo no tuvo que tomar medidas
especiales. Si el producto con retraso hubiese puesto en peligro algún objetivo
importante, habría convocado una reunión con los miembros del equipo
pertinentes para buscar una solución.
En estos casos es cuando una cuidada planificación del proyecto reporta
beneficios. Saber cuál es tu ruta crítica te ayudará a decidir qué cuestiones
merecen un cambio de calendario. Si desde el principio identificas los riesgos
que puedan perjudicar tus objetivos, reconocerás más fácilmente qué imprevistos
amenazan el éxito del proyecto. Si has estimado la duración y los gastos de cada
actividad y has tomado buena nota de cualquier incertidumbre, podrás distinguir
entre las divergencias de poca importancia y las divergencias que indican
problemas subyacentes de envergadura.
Cuando un plan requiere una revisión, es posible que debas ampliar la fecha de
finalización, servirte de reservas presupuestarias, eliminar entregables del
alcance del proyecto o incluso cancelarlo.
En un proyecto de desarrollo de software que supervisé, nos encontramos con
que la primera versión tenía demasiados errores. Antes de intentar arreglar el
software, comprobé rápidamente el documento de requisitos y me di cuenta de
que los programadores estaban utilizando una versión desactualizada. Tuvimos
que reprogramar el desarrollo del software de ese módulo y la finalización del
proyecto se retrasó un mes, pero el cambio era claramente necesario.
4. Mantener informadas a las partes interesadas de los
avances del proyecto
Algunos gestores de proyectos y miembros del equipo consideran que las
revisiones de gestión por las partes interesadas, —que implican la preparación de
informes y la celebración de reuniones— son un esfuerzo inútil, pues precisan
un tiempo que podrían dedicar a otras actividades. No obstante, si se gestionan
correctamente, estas revisiones favorecerán el éxito del proyecto. Existen tres
tipos de revisión: de gestión, de peaje y de carácter técnico. En cada una de ellas,
debes anotar propuestas de acción y distribuirlas, así como guardar el acta de la
reunión en la carpeta del proyecto para utilizarla como referencia en el futuro.
El objetivo de la revisión de gestión, es solventar riesgos. Es posible que las
partes interesadas examinen varios proyectos a la vez para ver si la cartera de
proyectos generará en su conjunto el desempeño empresarial deseado y para
identificar puntos débiles del sistema. También se fijarán en proyectos
específicos para analizar sus ventajas. Este tipo de revisiones suelen realizarse a
intervalos regulares; por ejemplo, una vez al mes. Cuando las convoques, no
olvides que las partes interesadas quieren información acerca de los objetivos
empresariales, no un seguimiento del día a día del proyecto.
Hace poco asistí a una revisión en la que el líder del proyecto se pasó casi media
hora describiendo unos diseños técnicos que el equipo estaba analizando y
poniendo a prueba, descripción cuyo único resultado fue aburrir y frustrar a las
partes interesadas. Habría sido mucho más útil contarles en cinco minutos que el
proyecto avanzaba según el calendario previsto, que el equipo había hecho
progresos en su análisis técnico y que no habían detectado ningún nuevo riesgo.
Crear un panel de control, es una fantástica manera de resumir tus objetivos y de
enseñar a las partes interesadas si el proyecto, tal como está planificado y
gestionado en estos momentos, podrá conseguirlos —puedes dividirlo en
componentes como calendario, presupuesto y desempeño—. Es lo que se conoce
como gráfico semáforo,, pues suele indicar el estado de las actividades en rojo,
amarillo y verde. La mayoría de empresas emplean un formato estándar para que
los directivos sénior puedan valorar rápida y eficientemente el progreso y los
riesgos de muchos proyectos. Si utilizas colores, verifica que todo el mundo
entiende qué significa exactamente cada color. Por ejemplo, ¿indicas que una
tarea no está terminada en rojo? ¿O algunas están en verde porque el plan para
su finalización ya ha sido aprobado y está en marcha?
Cuando tengas que dar malas noticias en una revisión de gestión, exprésalas
siempre según el riesgo que supongan para los objetivos del proyecto. Explica,
por ejemplo, si el retraso en determinada tarea le impide al equipo llevar a cabo
el proyecto según el calendario; o si la falta de un recurso reducirá la rigurosidad
de una actividad y, en consecuencia, la calidad de su entregable. Cuando
presentes problemas, ofrece también opciones para resolverlos y analiza los
riesgos que cada solución conlleva. Las partes interesadas decidirán qué riesgos
quieren que la empresa asuma.
La revisión de peaje, (también llamada revisión de etapa, o de fase,) es una
reunión para tomar decisiones, no para hablar del estado del proyecto. Se utiliza
cuando un negocio planea y ejecuta proyectos en fases separadas. Durante la
revisión, el equipo sintetiza los resultados de la fase precedente y presenta el
plan de la nueva etapa. Las partes interesadas valoran el plan, las opciones y los
riesgos, y luego deciden si aprueban, redirigen o cancelan el proyecto. Si
deciden pasar a la fase siguiente, entonces también facilitan al equipo los
recursos necesarios, incluida la financiación.
En una revisión técnica, (a veces llamada revisión por pares,), un equipo
independiente de expertos —consultores internos o externos, por ejemplo, o
representantes de una agencia reguladora— efectúa un análisis en profundidad
de los resultados del proyecto. El objetivo es comprobar que los miembros del
equipo hayan realizado el trabajo con precisión, por completo y con el nivel de
calidad adecuado. Es posible que las partes interesadas den su visto bueno en
este punto: si el equipo ha completado con éxito una fase del proyecto, ahora
podrá pasar la revisión de peaje para conseguir la aprobación que le permita
pasar a la siguiente etapa.
5. Gestionar los cambios en el plan
Cuando revises el plan, puedes introducir grandes cambios o solo hacer ajustes
que permitan al equipo alcanzar sus objetivos.
Si propones grandes cambios a las partes interesadas, especifica los costes y
riesgos que implica tanto cambiarlo como quedarse con el plan original. A un
contratista en materia de defensa con el que trabajo, las Fuerzas Aéreas le
pidieron que mejorase el rendimiento de un componente de un sistema de
armamento. Después de que las Fuerzas Aéreas revisaran las opciones
propuestas —que incluían costes, riesgos y calendarios— y seleccionaran una de
ellas, el contratista actualizó la documentación del diseño, los procesos de
fabricación, los contratos de los proveedores, el calendario del proyecto y el
presupuesto para que la transición fuera lo más suave posible. Cuando hagas
revisiones a gran escala, apúntalas —así como los motivos para hacerlas— en
algún tipo de registro de cambios para el proyecto. Para revisar el plan puedes
servirte de tus procesos y técnicas habituales para planificar proyectos. Envía el
nuevo plan a los miembros de tu equipo y explícales cómo les afectarán los
cambios.
Cuando estés implementando un plan para imprevistos o puliendo los detalles de
una parte del proyecto que solo estaba planeada a un nivel elevado, es posible
que surjan pequeños cambios. Normalmente, el equipo del proyecto estará
capacitado para encargarse de ellos, sin precisar la aprobación de las partes
interesadas, a menos que los cambios les afecten a ellas o a sus departamentos.
Mientras realices el seguimiento de tu proyecto, jamás olvides que cumplir tus
objetivos es lo más importante. No te obsesiones con cumplir el plan original.
Según mi experiencia, casi todos los planes de proyecto deben revisarse en algún
momento; sobre todo, cuando desarrollas nuevos productos o sistemas, pues lo
que aprendes en los primeros estadios del proyecto determina la manera de
realizar las tareas de las últimas fases. No temas cambiar de rumbo si hacerlo te
ayuda a acercarte a los objetivos.
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 sectores, y ha dirigido una oficina de gestión de proyectos en el
negocio de distribución eléctrica de General Electric.
Capítulo 17
Gestiona los problemas humanos de tu equipo
Tu principal recurso es tu gente. Una vez hayas realizado el duro trabajo de
seleccionar a los miembros adecuados para el equipo y hayas puesto en marcha
el proyecto, tienes que conseguir que sigan concentrados en la tarea, que hagan
su parte del trabajo, que trabajen de forma conjunta y que alcancen el nivel de
calidad que hayas establecido con las partes interesadas. De lo contrario, es muy
poco probable que consigas los objetivos, y aún menos que cumplas con los
plazos y el presupuesto establecidos. En los siguientes apartados aprenderás a
reconocer y gestionar los distintos problemas humanos que puedes encontrarte
como gestor de proyectos.
Problemas estructurales del equipo
Capítulo 18
Herramientas para la cooperación y el cambio
Resumen de las principales ideas contenidas en el artículo publicado en la HBR
por Clayton M. Christensen, Matt Marx, y Howard H. Stevenson,.
Nota del editor: A veces hay que gestionar el cambio dentro de un proyecto. En
otras ocasiones, los propios proyectos son agentes de cambio para la empresa;
así que deberás vencer las resistencias de la propia organización. Ten a mano
las herramientas adecuadas y conseguirás que cooperen contigo, en vez de
atrincherarse en contra del proyecto.
LA IDEA, EN RESUMEN
¿Por qué a los gestores les cuesta tanto conseguir la cooperación de los
empleados para llevar a cabo iniciativas de cambio? Incluso los líderes
carismáticos tienen un éxito irregular: a veces obtienen un compromiso, pero en
otras ocasiones fracasan estrepitosamente.
Según Christensen, Marx y Stevenson, demasiados líderes se sirven de las
herramientas de cambio equivocadas en el momento equivocado y, en el proceso,
malgastan energías y ponen en riesgo su credibilidad. Por ejemplo, una
declaración de la visión de la empresa contribuye a que la gente se suba al carro
si previamente ya estaban de acuerdo con el destino que debe perseguir la
organización. Sin dicho consenso, este tipo de declaraciones no darán lugar a
cambios de comportamiento, aparte de que todo el mundo pondrá los ojos en
blanco al unísono.
¿Cómo servirse de las herramientas adecuadas en el momento adecuado para
conseguir cambios? Sondea hasta qué punto la gente está de acuerdo con 1)
dónde hay que ir y 2) cómo llegar. A continuación, selecciona las herramientas
según la naturaleza del consenso de los empleados. Por ejemplo, si la gente no
está de acuerdo con los objetivos y con la manera de alcanzarlos —algo común
durante una fusión—, utiliza alguna de las herramientas de poder, como
amenazar con tomar tú las decisiones. Si los empleados tienen objetivos que
difieren de los de la compañía, pero están en de acuerdo en cómo debe hacerse
—por ejemplo, contratistas independientes—, utiliza herramientas de gestión,
como sistemas de medición del desempeño y la formación.
Elige las herramientas adecuadas y conseguirás introducir los cambios que tu
empresa necesita para ir un paso por delante de la competencia.
LA IDEA, EN LA PRÁCTICA
Seleccionar las herramientas de cambio adecuadas
Escenario n.º 1: Si los empleados coinciden en los objetivos pero no están de
acuerdo en cómo conseguirlos, utiliza herramientas de liderazgo: visión,
carisma, arte de vender y modelo de conducta.
Ejemplo: En diciembre de 1995, la Microsoft de Bill Gates publicó su visionario
informe El maremoto de internet. El documento convenció a los empleados de
que la red de redes iba a convertirse en algo esencial para la informática —idea
contraria a las creencias de los empleados—. Los empleados respondieron con
productos que obstaculizaron el progreso de la empresa rival Netscape y
consiguieron que Microsoft siguiera dominando en el sector del software —algo
que deseaban tanto los empleados como la compañía—.
Escenario n.º 2: Si los empleados no están de acuerdo ni con los objetivos ni con
la manera de alcanzarlos, utiliza herramientas de poder: amenazas,
contrataciones y promociones, sistemas de control y coacción.
Ejemplo: Para fusionar JP Morgan con BankOne, el director ejecutivo Jamie
Dimon redujo el salario de centenares de ejecutivos entre un 20% y un 50%.
Amenazó con seleccionar una sola plataforma informática para sustituir los
innumerables sistemas de la empresa si el personal del departamento
informático no elegía una en seis semanas. Y les dijo a los directores de sucursal
que perderían su puesto de trabajo si no cumplían con sus cuotas de ventas.
Escenario n.º 3: Si los empleados están de acuerdo con los objetivos y con la
manera de alcanzarlos, utiliza herramientas de cultura, para contrarrestar
complacencias. En concreto, sírvete de la «separación» —dividir la organización
en entidades con objetivos propios consensuados y planes para conseguirlos—
con la finalidad de evitar un acuerdo de alto nivel en cuanto a objetivos y
métodos que, de otro modo, podría dejar las cosas tal como están.
Ejemplo: Hewlett-Packard se dio cuenta de que su nuevo negocio de impresoras
de inyección de tinta —con una tecnología y economía únicas— solo podría
prosperar si estaba protegido ante las expectativas culturales de su negocio de
impresoras láser tradicional. Separar los dos negocios eliminó la necesidad de
que cooperaran entre sí y posibilitó que los dos grupos trabajaran con modelos
de beneficios muy distintos.
Escenario n.º 4: Si los empleados no coinciden en cuanto a los objetivos, pero sí
están en de acuerdo en cómo debe hacerse, utiliza herramientas de gestión:
sistemas de medición, modalidades estándares de funcionamiento y formación.
Ejemplo: En muchas compañías, las razones por las que los trabajadores
industriales sindicados van a trabajar difieren notablemente de las de los
directivos sénior. Pero siempre y cuando los trabajadores acepten la aseveración
de los directivos de que seguir ciertos procedimientos de fabricación les ayudará
a crear productos con la calidad y el coste deseados, cumplirán dichos
procedimientos.
Clayton M. Christensen es el profesor Kim B. Clark de Administración
Empresarial de la Harvard Business School (HBS) en Boston. Matt Marx
fue estudiante de doctorado de la HBS. Howard H. Stevenson es el profesor
emérito Sarofim-Rock Baker de Administración Empresarial de la HBS, así
como el presidente del Consejo de Harvard Business Publishing.
Capítulo 19
No pierdas más dinero —ni tiempo— intentando
recuperar el ya perdido
Por Jimmy Guterman
Aprobaste el desarrollo de un nuevo producto de gran resonancia para tu
empresa hace un año... pero ahora las cosas no van bien. Pese a aquellas
predicciones que vaticinaban que los clientes necesitaban tu producto, el
mercado ha cambiado y, en el mejor de los casos, la respuesta es incierta. A
pesar de todo, ahora no vas a rendirte y tirar a la basura 10 millones de dólares.
¿Verdad?
En realidad, gastar un centavo más en un producto condenado al fracaso es una
decisión equivocada. Además, intentar aprovechar costes hundidos, —
inversiones que ya no son recuperables— es un error habitual: «Solo doscientos
mil dólares más», te dices, «y recuperaremos nuestra inversión».
No caigas en la trampa de este tipo de razonamiento. La auténtica sabiduría
gerencial radica en una especie de falta de memoria: la capacidad de ignorar
inversiones, costes y beneficios previos para poder centrarte totalmente en la
situación actual. Los directivos, cuando tienen limitaciones de información y
tiempo, suelen utilizar estrategias de simplificación, conocidas con el nombre de
heurísticas de juicio,, como atajos para tomar decisiones. El problema es que la
psicología humana siempre ejerce su influencia y produce algunos sesgos
cognitivos, conclusiones basadas en percepciones equivocadas e inferencias
erróneas. La trampa de los costes hundidos es un sesgo cognitivo. El profesor de
la Harvard Business School Max H. Bazerman, autor de Judgment in Managerial
Decision Making, compara esta «intensificación del compromiso no racional»
con estar en una parada de autobús esperando durante horas. En algún momento,
tendrás que admitir que el autobús no va a venir.
Evitar intensificar el compromiso de tu empresa con un producto, una persona o
una estrategia más allá de lo razonable es posible. Sigue las siguientes directrices
para conseguirlo.
No tomar decisiones simplemente para justificar las
decisiones pasadas
¿Debes quedarte con un proveedor que no da los resultados esperados porque lo
contrataste tú y no quieres que te acusen de andar sin rumbo? ¿Debes seguir
dando créditos a una empresa que, en repetidas ocasiones, no ha cumplido sus
obligaciones porque promete que un solo préstamo más lo cambiará todo? Desde
la distancia, queda muy claro que la respuesta a ambas preguntas es no. Pero es
fácil que el contexto nuble tu buen juicio.
Evita este problema a partir de evidencias externas que respalden tus decisiones:
si te estás planteando si seguir con un proyecto o no, consulta a tantas fuentes
externas y a tantos abogados del diablo como sea posible; así averiguarás qué
opina la gente de tu dilema, más allá de tu supervisor. No tener una amplia
perspectiva del panorama suele conllevar decisiones demasiado cautas; lo que a
su vez puede hacerte caer en la trampa de los costes hundidos.
Centrarse en la calidad de la decisión, no en la calidad
del resultado
Muchas personas caen en esta trampa porque tienen miedo a que se les juzgue
por las desafortunadas consecuencias de la decisión que tomaron cuando parecía
la mejor opción. Cuando las cosas salen mal, explica el profesor emérito de la
HBS Howard Raiffa, los responsables de tomar decisiones «se preocupan más
por sus actos de acción, como cambiar de rumbo, que por sus actos de omisión,
como dejar que la empresa siga por el mal camino. “Si dejo que todo siga su
curso”, piensan, “las cosas podrían cambiar. Si actúo ahora y admito que el
rumbo actual va en la mala dirección, podría provocar que revisen toda la
situación...”. Existen enormes presiones internas y externas para continuar por el
mismo camino, aunque todas las partes se den cuenta de que es un mal camino y
de que continuará siéndolo».
Si tienes a tu cargo a alguien responsable de tomar decisiones, puedes evitar una
intensificación innecesaria del compromiso dejando claro que nadie será
castigado por no poseer una bola de cristal.
Cuanto más se equipara tiempo con dinero, más
susceptible se es a la trampa de los costes hundidos
Es la conclusión a la que llegó el profesor de marketing de la Universidad de
Ciencia y Tecnología de Hong Kong Dilip Soman tras realizar una serie de
experimentos sobre costes hundidos. Tal como apunta en un artículo de 2001
publicado en el Journal of Behavioral Decision Making, los costes hundidos no
suelen confundirnos cuando nuestra principal inversión es tiempo. Pero sí que
representan un problema cuando estamos más versados en convertir la inversión
de tiempo en un equivalente monetario.
Utilizar reglas de decisión para evitar que se nos nuble
el pensamiento
En Judgment in Managerial Decision Making, Bazerman describe una situación
habitual: «Tomaste la decisión personal de contratar a una nueva gestora de nivel
medio para que trabajara para ti. Aunque esperabas que su cumplimiento iba a
ser excelente, los primeros informes indican que no está trabajando según tus
expectativas. ¿Debes despedirla? Tal vez no puedas permitirte su nivel actual de
rendimiento. Pero, por otro lado, has invertido una buena cantidad en su
formación. Además, es posible que solo esté en la fase de aprender los gajes del
oficio. Así pues, decides invertir un poco más en ella y ofrecerle más recursos
para que salga adelante. A pesar de todo, sus resultados siguen sin ser los
esperados. Aunque ahora tengas más razones para “minimizar pérdidas”, has
invertido bastante más en esta empleada».
Objetivos precisos pueden ayudarte a evitar este tipo de racionalizaciones.
Establece por adelantado cuánto tiempo y dinero estás dispuesto a invertir en un
proyecto o en una persona antes de analizar los resultados específicos. Como
dijo una vez el sabio de las inversiones Warren Buffett: «Si te encuentras en un
agujero, lo mejor que puedes hacer es dejar de cavar». Los objetivos te dicen
cuándo debes soltar la pala. Te permiten distinguir, dice Bazerman, «entre
situaciones en las que tu persistencia tendrá recompensa y situaciones en las que
no será así».
Jimmy Guterman fue editor sénior en hbr.org.
Fase 4
Finalización
Capítulo 20
Delega autoridad y control
Por Ray Sheen
Ahora que ya has ejecutado tu proyecto, ha llegado la hora de evaluar tu éxito y
luego poner fin a las actividades: desde transferir el control de los nuevos
sistemas o instalaciones a presentar los entregables a las partes interesadas. ¿Por
qué no finalizar las actividades primero? Porque no sabrás si es hora de cerrar
hasta que no hayas determinado si has alcanzado tus objetivos.
Dicho de otro modo, el éxito significa alcanzar los objetivos de tu acta de
constitución y tu declaración de alcance, no necesariamente terminar todas las
tareas recogidas en tu diagrama Gantt. Tanto si tu equipo ha lanzado un nuevo
producto como si ha implementado un nuevo sistema —o abierto unas nuevas
instalaciones u optimizado un proceso—, tendrás que validar si los objetivos, si
aún son pertinentes, se han alcanzado. Puesto que a las partes interesadas les
importa mucho más generar beneficios empresariales que seguir al pie de la letra
la «ruta crítica» del plan, el equipo debe dejar atrás los detalles del proyecto y
concentrarse en esos beneficios cuando haya terminado el proceso.
Un día me encontré por casualidad con alguien con quien había trabajado hacía
unos años en el desarrollo de un producto, y me comentó que había sido uno de
los mejores proyectos que nuestra organización había hecho. Cuando nos
separamos, intenté recordar qué había sido tan bueno del proyecto, porque sabía
que no estuvo bien planeado ni ejecutado. Me di cuenta de que fue la fase de
finalización la que nos salvó. En nuestro plan, se nos había pasado por alto que
algunos sistemas del negocio debían modificarse para adaptar el nuevo producto;
nos retrasamos con la asignación de personal, por lo que no tardamos en estar
fuera de plazo; además, tuvimos que reorganizar el proyecto varias veces por
culpa de errores de estimación y de problemas técnicos. Para salvar los retrasos,
nos pasamos de presupuesto en un 10%. Al final, sin embargo, compensamos
estos problemas satisfaciendo las necesidades del mercado. Nos aseguramos de
que, cuando lanzáramos el producto, funcionaría bien, sería fácil de comprar
para el cliente y de fabricar para nosotros. Además, nuestros sistemas tendrían
que admitirlo sin ninguna dificultad. Todo se vio recompensado: las ventas
superaron nuestras expectativas. Por eso, las partes interesadas consideraron que
el proyecto había sido un éxito, pese a los tropiezos que hubo durante la
planificación y la ejecución.
Una vez que hayas alcanzado tus objetivos —o determinado que ya no son
pertinentes—, puedes adoptar uno de estos tres enfoques para cerrar el proyecto:
El equipo se entrega a sí mismo el proyecto
En este caso, los miembros del equipo se convierten en quienes utilizan y
mantienen sus propios entregables. Por ejemplo, cuando trabajaba en General
Electric, formamos un equipo para diseñar y supervisar la puesta en marcha de
una nueva instalación de alta tensión. Una vez en funcionamiento, el jefe del
equipo y otros miembros se encargaron del mantenimiento de la instalación. Si
tu equipo hereda sus propios entregables, tendrá que cerrar las cuentas
administrativas o archivos —como contratos con proveedores y órdenes de
compra— vinculados al desarrollo del proyecto, y abrir los correspondientes a su
despliegue operativo.
El equipo finaliza el proyecto
En este caso, todas las actividades se detienen, y la organización libera o reubica
los recursos. Eso puede ocurrir cuando el proyecto tiene problemas como un
sobrecoste enorme, pero a veces se debe a factores que están fuera del control
del equipo.
Por ejemplo, una vez trabajé con varios equipos en la coordinación de procesos
financieros para dos empresas con planes de fusionarse. Los equipos se habían
formado hacía meses y habían hecho grandes progresos, pero de repente el
Gobierno tomó la decisión de vetar la fusión, en el último momento. Los equipos
se disolvieron en 24 horas. Este tipo de cierre es administrativamente muy claro
—que el proyecto se ha terminado es indiscutible, al fin y al cabo—, pero
emocionalmente puede resultar difícil, ya que la gente pierde sus cargos —o
puestos de trabajo— sin previo aviso.
El equipo integra el proyecto
Al adoptar este enfoque —de lejos, el más habitual y el más difícil—, tu equipo
debe asegurarse de que otras personas aprovechen sus entregables y los apliquen
correctamente. En las decenas de iniciativas para crear nuevos productos que he
contribuido a gestionar, se ha tardado lo mismo, o incluso más, en entregar el
diseño del producto a los departamentos de fabricación y calidad, como en
formar al personal de ventas, marketing y servicios, que en diseñar, desarrollar y
validar el propio producto. Durante la integración de un proyecto, es posible que
te enfrentes a una resistencia al cambio de la organización. Si piensas que puede
ocurrir, añade una fase de transición que incluya pruebas piloto, ensayos beta y
cualquier otra actividad que facilite la integración.
Por descontado, el método de finalización dependerá en gran medida de las
condiciones empresariales, igual que de las herramientas y técnicas que deberás
utilizar. A continuación describo algunas que me han resultado útiles para
gestionar expectativas cuando un proyecto se acerca a su fin.
La lista de tareas finales
Se utiliza sobre todo en proyectos de construcción, pero funciona bien en
cualquier otro tipo de proyecto en el que la gente intente pedir extras —por
ejemplo, prestaciones adicionales— en la fase de finalización. El equipo se
reúne con las partes interesadas y analiza los resultados de las actividades del
proyecto. Durante el análisis, entre todo el mundo se identifican las tareas
restantes, que tú incluirás en una lista de acciones finales. Entonces, el equipo se
ocupa de cada elemento de la lista y, cuando en la lista no queden más tareas
pendientes, se habrá terminado el proyecto. Puesto que las partes interesadas ya
habrán dado su visto bueno a la lista final de tareas, será mucho menos probable
que te pidan «solo otra cosa más» a estas alturas. La lista de tareas finales es una
buena opción en la fase final, ya que es posible que al equipo le cueste
desprenderse del proyecto, y así podrá centrarse en cerrarlo de verdad.
Hace unos años, al trabajar con un fabricante de piezas de plástico, ayudé a uno
de los equipos a utilizar esta herramienta para realizar todas las pruebas, las
inspecciones y los ensayos piloto necesarios para certificar un nuevo molde que
estuviese a punto dentro de plazo.
El «apretón de manos» con las partes interesadas
Los proyectos con una declaración de alcance un poco confusa —como suele
ocurrir con iniciativas de investigación o con pequeños proyectos informales—
se benefician de esta técnica, porque impide que el trabajo sobrepase los límites
del plan. Reúnete con las principales partes interesadas para comparar los logros
del proyecto con el contrato o la declaración de alcance, y pregúntales si
consideran que el proyecto efectivamente está terminado. Pídeles que
establezcan un punto de finalización o si prefieren cerrar ya el proyecto y, si es
necesario, abrir uno nuevo. En este tipo de reuniones se suelen plantear un gran
número de opciones, por lo que es conveniente preparar varias propuestas.
Después de la reunión, documenta la decisión que hayan tomado las partes
interesadas y difúndela para evitar confusiones.
Cuando realizo una evaluación de gestión de proyectos en una organización,
suelo terminarla de este modo. Muchas veces me piden que analice «qué
necesitamos mejorar». Una vez concluido mi análisis, me reúno con el ejecutivo
que me contrató. Normalmente nos ponemos de acuerdo en que la evaluación se
ha terminado, comentamos mis conclusiones y luego analizamos si es necesario
que me quede para ayudar a implementar mejoras.
El «aparcamiento de la corrupción del alcance»
Durante la ejecución del proyecto, es posible que algunas partes interesadas
hayan propuesto ideas adicionales o que los miembros del equipo hayan querido
añadir florituras al proyecto. Idealmente, habrás recogido estos puntos en una
lista, a la que algunos gestores de proyectos llaman el «aparcamiento de la
corrupción del alcance», para que no se pierdan, pero tampoco hagan descarrilar
el plan introduciendo nuevas actividades o ampliando sus límites. Ahora que
estás finalizando el proyecto, revisa esta lista para generar propuestas de
seguimiento y presentarlas a las partes interesadas. Esta técnica resulta eficaz
cuando un equipo se prepara para entregarse a sí mismo un proyecto, ya que las
partes interesadas serán más propensas a aceptar los entregables si saben que
podrán modificarlos más tarde. Yo he utilizado el aparcamiento de la corrupción
del alcance en varios proyectos de desarrollo de software. En cada caso, aunque
encontramos problemas menores durante las pruebas de aceptación por parte del
usuario, pudimos cerrar los proyectos porque los mantuvimos dentro del alcance
hasta el siguiente lanzamiento.
Sea cual sea el enfoque y las herramientas de finalización que utilices, no te
olvides de celebrar los logros de tu equipo. El éxito atrae al éxito. Incluso en
proyectos con una planificación o ejecución imperfecta, los miembros del equipo
habrán trabajado duro para alcanzar los objetivos de la empresa, y se les tiene
que recompensar por ello. De este modo, les animarás a volver a hacer un buen
trabajo para ti en el futuro, y un ejemplo positivo hará que otros equipos también
logren sus objetivos. Deja la conversación sobre las cosas que puedan mejorarse
para más adelante. Es mejor hacerlo en una sesión independiente dedicada a
recopilar las lecciones aprendidas y destinada a mejorar tu manera de gestionar
proyectos de cara al futuro. Ahora, por un momento, disfruta del éxito de tu
actual 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 sectores, y ha dirigido una oficina de gestión de proyectos en el
negocio de distribución eléctrica de General Electric.
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 realizan 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 proyecto 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
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
planificació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 ingenierí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 reunió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 proyecto, 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 ocurrido. 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 aprobación del proyecto, así como si
esos objetivos eran realmente alcanzables. Los proyectos se aprueban según los
beneficios 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 capacidad. 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 originalmente? Analizando minuciosamente estas
cuestiones y comunicando las conclusiones al patrocinador del proyecto, un
equipo puede mejorar el proceso que sigue la organizació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 lecciones en el proceso de
iniciación de proyectos.
2. Evaluar el plan del proyecto
A continuación pregunto: «¿Era el plan razonable y adecuado 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 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
establecieron para la comunicación del equipo y las partes interesadas. ¿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 información establecido para comunicar los planes y el estado del
proyecto a todos los agentes implicados.
Las lecciones aprendidas suelen incorporarse a los procedimientos y sistemas
para la gestión de proyectos que tiene la compañía. Cuando trabajé como
consultor para un fabricante subcontratado de tamaño medio, me sorprendió
descubrir 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 ineficiencia 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 contradictorios; 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 procedimientos y sistemas necesarios para planificar y ejecutar proyectos 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 importancia de dar lo mejor y se minimiza la
sensación de que el líder del proyecto pueda estar pecando de favoritismo. Con
las personas 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.
Un proceso para recopilar las lecciones aprendidas fomenta la mejora continua.
No obstante, según mi experiencia, nadie 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, modificar 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 sectores, 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 concisa del trabajo
previsto en un proyecto. El acta de constitució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 Committee]. Grupo de
personas que aprueba el acta de constitución del proyecto, consigue
recursos y juzga todas las peticiones para cambiar elementos clave del
proyecto, como los entregables, el calendario y el presupuesto.
Corrupción del alcance [Scope creep]. Tendencia —a menudo fruto de una
presión ejercida por algunas partes interesadas— 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 programació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 desempeño excepcional.
Estructura de desglose de trabajo (EDT) [Work Breakdown Structure].
Rutina de planificación que desglosa el objetivo 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 proceso con la finalidad de aprender e
intercambiar lecciones e introducir mejoras. También se llama sesión de
lecciones aprendidas, revisión post mortem o examen a posteriori.
Gráfico semáforo [Stoplight chart]. Herramienta de seguimiento de
proyectos que utiliza colores —rojo, amarillo y verde— para indicar el
estado de cada actividad del proyecto, también llamado panel de control.
Lanzamiento [Launch]. Evento o reunión especial que marca el inicio oficial
de un proyecto.
Lista de tareas finales [Punchlist]. Lista de últimas acciones que debe
realizar el equipo de un proyecto, aprobada por las principales partes
interesadas.
Método de la ruta crítica [Critical Path Method]. Técnica de planificación
utilizada para proyectos complejos con varias actividades. Cualquier
actividad que deba estar finalizada antes de que puedan ponerse en marcha
otras acciones se considera «crítica»; es decir, es necesaria para que el
proyecto se complete con éxito en el momento oportuno. La duración final
del proyecto viene definida por la ruta crítica.
Oficina de gestión de proyectos [Project management office. Oficina
corporativa —normalmente en una compañí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 quieran
efectuar dichos procesos y, a veces, gestiona proyectos concretos.
Revisión de la gestión [Management review]. Reunión en la que las partes
interesadas pueden examinar varios proyectos conjunta e individualmente
para ver si la cartera de proyectos generará en su conjunto los resultados
empresariales deseados y para identificar puntos débiles.
Revisión de peaje [Tollgate review]. Reunión en la que el equipo sintetiza los
resultados de la fase precedente y presenta el plan de la nueva etapa para
que las partes interesadas puedan decidir si aprueban el proyecto, lo
redirigen o lo cancelan. También llamada revisión de etapa o de fase.
Revisión técnica [Technical review]. Reunión en la que un equipo de
expertos independientes aporta un análisis en profundidad de los resultados
del proyecto para comprobar que los miembros del equipo hayan realizado
el trabajo con precisión, por completo y con el nivel de calidad adecuado.
También recibe el nombre de revisión por pares.
Técnica de revisión y evaluación de proyectos (PERT, por sus siglas en
inglés) [Performance Evaluation and Review Technique]. Método de
programación que, cuando se pone en forma de diagrama, representa cada
tarea como un nodo conectado con otros nodos necesarios para completar el
proyecto. Un diagrama PERT puede contar con muchas redes de tareas
paralelas o interconectadas, por lo que en el caso de proyectos complejos se
recomienda revisarlo periódicamente. A diferencia del diagrama Gantt,
indica todas las relaciones entre las tareas y los hitos del proyecto.
¹Adaptado de Pocket Mentor: Managing Projects (producto n.º 1878), Harvard
Business Review Press, 2006.
²Adaptado de Harvard Business Essentials: Managing Projects Large and Small
(producto n.º 6198BC), Harvard Business Review Press, 2004.
³Adaptado de Harvard Business Essentials: Managing Projects Large and Small
(producto n.º 6211BC), Harvard Business Review Press, 2004.
⁴Adaptado de Harvard Management Update (producto n.º U0306C), junio de
2003.
⁵Reimpresión n.º F0709A.
Adaptado de Harvard Management Update (producto n.º U0501C), enero de
2005.
⁸Adaptado de Harvard Management Update (producto n.º U99120), diciembre de
1999.
Adaptado de Harvard Business Essentials: Managing Projects Large and Small
(producto n.º 6242BC), Harvard Business Review Press, 2004, y Pocket Mentor:
Managing Projects ( producto n.º 1878), Harvard Business Review Press, 2006.
¹ Reimpresión: n.º R1104N. Reimpresión solo del caso: n.º R1104X.
Reimpresión solo de los comentarios: n.º R1104Z.
¹¹Adaptado de Harvard Business Essentials: Managing Projects Large and Small
(producto n.º 6280BC), Harvard Business Review Press, 2004.
¹²Citado de Harvard Business Review, julio-agosto de 2005 (reeditado de 1993),
reimpresión n.º R0507P.
¹³Adaptado de Harvard Business Essentials: Managing Projects Large and Small
(producto n.º 6198BC), Harvard Business Review Press, 2004, y Harvard
Manage Mentor, un product online de Harvard Business Publishing.
¹⁴Adaptado de «Project Adaptation: Dealing with What You Cannot Anticipate»,
Harvard Business Essentials: Managing Projects Large and Small (producto n.º
6273BC), Harvard Business Review Press, 2004.
¹⁵Citado de Harvard Business Review, septiembre de 2003, reimpresión n.º
R0309H.
¹⁷Adaptado de Pocket Mentor: Managing Projects (producto n.º 1878), Harvard
Business Review Press, 2006.
¹⁸Citado de Harvard Business Review, octubre de 2006, reimpresión n.º R0610D.
¹ Adaptado de Harvard Management Update (producto n.º U0205D), mayo de
2002.
² Adaptado de Harvard Business Essentials: Managing Projects Large and Small
(producto n.º 3213), Harvard Business Review Press, 2004.
Créditos
Guías HBR: Gestión de Proyectos
HBR Guide to Project Management
Original work copyright © 2012 Harvard Business School Publishing
Corporation
Published by arrangement with Harvard Business Review Press
© Harvard Business School Publishing Corporation, 2012
© Editorial Reverté, S. A., 2017
Loreto 13-15, Local B. 08029 Barcelona – España
revertemanagement@reverte.com
ISBN edición impresa: 978-84-945629-4-5
ISBN edición digital: 978-84-291-9377-0
© Agnès González Dalmau, 2017, por la traducción
Digitalización: Reverté-Aguilar, S. L.
Reservados todos los derechos. La reproducción total o parcial de esta obra, por
cualquier medio o procedimiento, comprendidos la reprografía y el tratamiento
informático, queda rigurosamente prohibida, salvo excepción prevista en la ley.
Asimismo queda prohibida la distribución de ejemplares mediante alquiler o
préstamo público, la comunicación pública y la transformación de cualquier
parte de esta publicación sin la previa autorización de los titulares de la
propiedad intelectual y de la Editorial.