La trampa de la experiencia

Si estuviera buscando un director con experiencia para dirigir un equipo de desarrollo de software, Alex estaría en lo más alto de su lista de finalistas. Como directivo sénior, Alex ha dedicado la mayor parte de su carrera a dirigir proyectos de software. Su primera responsabilidad fue desarrollar software científico para la NASA y, desde entonces, ha supervisado proyectos cada vez más complejos para empresas comerciales y agencias gubernamentales.

Alex era el típico de los varios cientos de directores de proyectos que participaron en nuestra iniciativa de investigación sobre el aprendizaje basado en la experiencia en entornos complejos. Lo invitamos a poner a prueba sus habilidades jugando a un juego de ordenador que consistía en gestionar un proyecto de software simulado de principio a fin, hacer los planes, supervisar y guiar el progreso y observar las consecuencias. Le marcamos objetivos: terminar a tiempo y dentro del presupuesto y obtener la mayor calidad posible (medida por el número de defectos pendientes).

Las decisiones y los resultados de Alex fueron representativos del grupo en su conjunto. Comenzó con un equipo pequeño de cuatro ingenieros y se centró principalmente en las tareas de desarrollo. Esa táctica dio sus frutos a corto plazo. La productividad del equipo era alta y el desarrollo progresaba rápidamente. Sin embargo, cuando el tamaño del proyecto superó las estimaciones iniciales, surgieron problemas. Como Alex siguió optando por mantener el equipo pequeño, los ingenieros tuvieron que esforzarse más para mantenerse en el buen camino. En consecuencia, cometieron muchos errores y sufrieron agotamiento y desgaste. Luego, Alex intentó contratar a más personas, pero llevó tiempo, al igual que asimilar a las nuevas contrataciones. El proyecto pronto se retrasó y, en ese momento, la falta de atención de Alex al control de calidad en las primeras fases comenzó a reflejarse en un número creciente de errores de software. Arreglarlos requirió más tiempo y atención. Cuando el proyecto finalmente se completó, ya era tarde, estaba por encima del presupuesto y estaba plagado de defectos.

Tras el partido, le pedimos a Alex que reflexionara sobre la simulación. ¿El crecimiento del proyecto lo tomó por sorpresa? ¿Le sorprendió que el número de defectos fuera tan alto o que la contratación se hiciera difícil de gestionar? Alex, como la mayoría de sus compañeros participantes, respondió que, lamentablemente, esas sorpresas y choques se han convertido en algo habitual en la mayoría de los proyectos en los que ha participado.

Los quebraderos de cabeza de calidad y personal no son lo que la mayoría de las empresas esperan cuando ponen a veteranos experimentados como Alex a cargo de proyectos importantes. En esta etapa de sus carreras, deberían saber cómo abordar los problemas de manera eficiente, si no prevenirlos por completo. Sin embargo, lo que descubrimos en nuestros experimentos fue que los directivos con experiencia no obtenían resultados de gran calidad. En nuestra investigación, utilizamos el juego de simulación para examinar los procesos de decisión de los directivos en una variedad de contextos. Nuestros resultados sugieren claramente que había algo malo en la forma en que Alex y los demás directores de proyectos aprendido de sus experiencias durante el juego. No parecían tener en cuenta las consecuencias de sus decisiones anteriores al tomar nuevas decisiones y no cambiaban su enfoque cuando sus acciones producían malos resultados.

Los quebraderos de cabeza de calidad y personal no son lo que la mayoría de las empresas esperan cuando ponen a veteranos experimentados a cargo de proyectos importantes.

Nuestras sesiones informativas indicaron que los participantes conocían los desafíos presentados en el juego. Les pedimos que valoraran hasta qué punto el juego replicaba sus experiencias en proyectos de la vida real en una escala del 1 al 5, donde 5 significaba «por completo». La puntuación media fue de 4,32, lo que sugiere que nuestros experimentos reflejaron con precisión la realidad de los proyectos de software. Así que, aunque los directivos se habían encontrado con situaciones similares en sus trabajos en el pasado, todavía tenían problemas con ellas en las simulaciones. Llegamos a la conclusión de que tampoco habían aprendido realmente de su trabajo de proyectos en la vida real.

En las páginas siguientes identificaremos tres causas probables de esta aparente interrupción del aprendizaje y propondremos una serie de medidas que las organizaciones pueden tomar para que el aprendizaje vuelva a funcionar.

Por qué el aprendizaje fracasa

Cuando alguien toma una decisión, se basa en un acervo de conocimientos preexistente llamado modelo mental. Se compone principalmente de suposiciones sobre las relaciones de causa y efecto en el entorno. A medida que las personas observan lo que ocurre como resultado de sus decisiones, aprenden nuevos datos y hacen nuevos descubrimientos sobre las relaciones ambientales. Los descubrimientos que las personas consideran que pueden generalizarse a otras situaciones se retroalimentan o «se apropian» de sus modelos mentales. A primera vista, el proceso parece bastante científico: las personas forman una hipótesis sobre la relación entre una causa y un efecto, actúan en consecuencia y, a continuación, interpretan los resultados de sus acciones para confirmar o revisar la hipótesis. El problema es que el enfoque solo parece ser eficaz en entornos relativamente simples, en los que las relaciones de causa y efecto son sencillas y se descubren fácilmente. En entornos más complejos, como los proyectos de software, el ciclo de aprendizaje se interrumpe con frecuencia. En los experimentos que realizamos con los participantes del estudio, identificamos tres tipos de complicaciones en el mundo real que estaban asociadas a la ruptura del ciclo.

Desfase entre las causas y los efectos.

En el mundo real, hay retrasos entre las causas y los efectos y puede resultar difícil vincularlos, y mucho menos especificar la relación entre ellos. Para ver cómo los directores de proyectos abordan este problema, pedimos a los participantes de nuestra investigación que jugaran a un juego simulado en el que gestionaban un proyecto de desarrollo de software satelital de tamaño mediano que crecía significativamente a medida que se añadían más requisitos de producto. Cada participante tenía que supervisar el proyecto en uno de los cuatro entornos operativos que habíamos creado, que variaban en función del tiempo transcurrido entre la decisión de contratar y la llegada de nuevos miembros del equipo, y entre la llegada de los miembros del equipo y su asimilación. Los participantes tenían que tomar una decisión sobre la plantilla del equipo cada dos meses en un proyecto que tardó unos 18 meses en completarse. A continuación, evaluamos la capacidad de los directivos para gestionar los retrasos, comparando sus decisiones de contratación con las decisiones que tomaba un gerente teóricamente ingenuo que nunca tenía en cuenta los retrasos y con las decisiones que tomaba un gerente teóricamente perfecto que siempre lo hacía.

Independientemente de los retrasos en la contratación y la asimilación en sus respectivos entornos de proyectos, todos los participantes tomaron más o menos las mismas decisiones que nuestro ingenuo punto de referencia. Eso demuestra que no pudieron incorporar los efectos de los retrasos temporales en sus decisiones de planificación y sugiere que sus modelos mentales se basaban en un entorno simple en el que había poco o ningún retraso entre una decisión y su resultado. La duración del retraso importaba: los participantes en entornos con retrasos más prolongados en la contratación y la asimilación tenían más dificultades para salir adelante que los participantes que sufrían retrasos más cortos. El tipo de retraso también era importante: los sujetos tenían más dificultades para gestionar los retrasos de asimilación, que son mucho menos visibles que los retrasos en la contratación. La capacidad de gestionar los retrasos se deterioró bruscamente (y de manera desproporcionada) cuando los sujetos tuvieron que gestionar los largos retrasos en la contratación seguidos de largos retrasos en la asimilación. Los sujetos que trabajaban en esas condiciones hacían un 83% más de esfuerzo (en tiempo de personal) y tardaban un 40% más en completar el proyecto que los que tomaban decisiones en entornos con poco retraso en la contratación y la asimilación.

Curiosamente, en muchos casos los participantes decidieron contratar más personal al final del proyecto, lo que iba en contra de lo que dijeron más tarde que debían hacer los directores. En las reuniones informativas posteriores al juego, pedimos a los sujetos que describieran las políticas de contratación adecuadas que se adoptarían cuando los proyectos se retrasaran. La mayoría de los directivos con experiencia declararon que se abstendrían de contratar y buscarían otras opciones, como reformular el proyecto, centrarse en algunas prioridades clave o ampliar el plazo de finalización. Sin embargo, está claro que eso no fue lo que hicieron en realidad. En un experimento de seguimiento en el que los participantes gestionaron un segundo proyecto después de la sesión informativa, se mantuvo el mismo comportamiento: los que gestionaban proyectos con grandes retrasos seguían contratando más personal al final del proyecto. Esto sugiere que, incluso cuando las personas tenían o adquirían conocimientos, no necesariamente aprendían a actuar en consecuencia.

Estimaciones falibles.

En el desarrollo de software, las estimaciones iniciales de un proyecto dan forma a la trayectoria de las decisiones que el gerente toma a lo largo de su vida. Por ejemplo, las estimaciones de la productividad de los miembros del equipo influyen en las decisiones sobre el tamaño del equipo, lo que a su vez afecta a la producción real del equipo. El problema es que las estimaciones iniciales suelen resultar erróneas.

Para ver cómo los directivos gestionan las estimaciones falibles, realizamos otro experimento. En él, examinamos un ciclo de decisiones en el que los directores recibían estimaciones iniciales de la productividad del equipo de proyecto y, a continuación, se les pedía periódicamente que evaluaran la productividad real del equipo, en función del progreso realizado. Cada gerente obtuvo una de las tres estimaciones iniciales del número de tareas que el equipo realizaría por persona y día. Una estimación era baja, media y otra alta, lo que refleja la amplia gama de valores que las diferentes herramientas de estimación pueden generar para el mismo proyecto. Los entrenadores tuvieron que proporcionar estimaciones actualizadas de la productividad del equipo en tres momentos del juego: al final de la fase de diseño (quinto mes), a mitad de la fase de codificación (décimo mes) y al final de la fase de codificación (decimoquinto mes). En cada momento, los directores recibían informes de progreso sobre el estado del proyecto con nuevas estimaciones de productividad y se les aconsejaba que los revisaran antes de proporcionar sus propias estimaciones de la productividad del equipo.

Se les dijo a los participantes que sus estimaciones de productividad se utilizarían para hacer los ajustes en los niveles de personal y los cronogramas del proyecto. Sin embargo, en realidad, el juego hizo caso omiso de las estimaciones. La idea era ofrecer a todos los sujetos informes de estado idénticos para poder comparar la evolución de las estimaciones de productividad de las personas a lo largo del tiempo. Nuestra hipótesis era que las estimaciones de la productividad de las personas convergerían (las personas que comenzaran con estimaciones bajas las aumentarían con el tiempo y las que tuvieran estimaciones altas las reducirían).

Entonces, ¿qué pasó? Las estimaciones de productividad de los directivos no convergieron con el tiempo. Es más, había un claro sesgo hacia el conservadurismo: todas sus estimaciones se inclinaron a la baja. Eso era cierto no solo para los gerentes que tenían estimaciones de productividad iniciales altas, sino también para aquellos cuyas estimaciones iniciales eran bajas. Y cuando se enfrentaron a dos estimaciones de productividad (su estimación anterior y la nueva cifra proporcionada en los informes de estado), dieron más peso a la más abajo de las dos cifras al revisar sus estimaciones. Sospechamos que este conservadurismo puede explicarse por los intentos de los directivos de jugar con el sistema para conseguir más recursos.

Sesgo de gol inicial.

Los directores de proyectos suelen empezar con un conjunto de objetivos relacionados con el coste, el tiempo y otros factores. Sin embargo, la mayoría de los proyectos cambian de alcance o se topan con lo inesperado, lo que con frecuencia hace que los objetivos iniciales queden obsoletos. Cuando eso ocurre, los directivos tienen que revisar sus objetivos en consecuencia.

Para comprobar si los directores modificaron sus objetivos en respuesta a los cambios en el alcance, pedimos a dos grupos diferentes de sujetos que gestionaran un proyecto que aumentaba sustancialmente sus requisitos. Cada grupo recibió un conjunto inicial de dos objetivos. A los sujetos del «grupo de costes» se les pidió que se mantuvieran dentro del presupuesto (944 días/persona de esfuerzo) y entregaran el producto según lo previsto (en un plazo de 272 días hábiles). A los sujetos del «grupo de calidad» se les pidió que entregaran el producto según lo previsto y con el menor número de defectos. Se indicó claramente que se trataba únicamente de objetivos iniciales, según la información disponible en ese momento, y que el éxito de los participantes se evaluaría en función del resultado general. El aumento de alcance se produjo un cuarto del juego. En ese momento, los directivos podrían haber optado por revisar sus objetivos iniciales proyectando sobrecostos presupuestarios o temporales y, al mismo tiempo, ceñirse a los objetivos de calidad iniciales. Aunque no pedimos a los jugadores que reevaluaran sus objetivos de forma explícita, tuvimos cuidado de dejarles abierta la posibilidad.

Ninguno de los dos grupos reajustó los objetivos a la luz de la nueva información. En cambio, los jugadores de ambos grupos mantuvieron sus objetivos originales y, como resultado, no lograron un resultado óptimo. En un esfuerzo por mantener los costes por debajo del objetivo inicial, el equipo de costes hizo muchas menos contrataciones de las ideales y sacrificó el tiempo de finalización. Aunque estos jugadores mantuvieron el sobrecoste en un 59%, tardaron un 17% más en completar el proyecto y su número de defectos se disparó a 1950. El equipo de calidad, por otro lado, empleaba a demasiadas personas. Los jugadores de este grupo alcanzaron su objetivo de defectos, pero aun así terminaron un 9% por encima del tiempo previsto y superaron con creces el presupuesto un 107%. En algunos casos, cumplir los objetivos iniciales creó resultados contraproducentes. Al tratar de cumplir con los presupuestos, los sujetos del «grupo de costes» solían prestar poca o ninguna atención al control de calidad. En el proceso, crearon tantos errores que el esfuerzo necesario para solucionarlos aumentó sustancialmente el coste del proyecto.

Estos resultados sugieren que, si no se les exige explícitamente que reevalúen los objetivos, los directores seguirán persiguiendo los objetivos establecidos al principio del proyecto, incluso cuando los acontecimientos hagan que los objetivos sean inapropiados. No es difícil entender de dónde viene ese sesgo. Al principio de sus carreras, las personas incorporan en sus modelos mentales la idea de que es importante cumplir los objetivos establecidos externamente. Este sesgo se refuerza a menudo en la vida directiva. Revisar los objetivos se considera una admisión del fracaso en muchas empresas, y los directivos se dan cuenta rápidamente de que sus carreras tendrán mejores resultados si cumplen y alcanzan los objetivos iniciales, incluso si eso lleva a un peor resultado general. Con el sesgo tan arraigado en el modelo mental, no es de extrañar que afectara a la toma de decisiones en nuestra simulación, a pesar de que los participantes entendieron que el éxito se mediría por los resultados del proyecto.• • •

Llegamos a la conclusión de que a los directivos les resulta difícil ir más allá de los modelos mentales que han desarrollado a partir de sus experiencias en entornos relativamente simples o que les han transmitido otras personas. Cuando se presentan complicaciones, las ignoran o tratan de aplicar reglas generales sencillas que solo funcionan en situaciones no complejas. Lo que no hacen es mejorar sustancialmente la calidad de sus modelos mentales para tener en cuenta la realidad de los proyectos complejos. Esta conclusión tiene dos implicaciones importantes para las empresas que siguen haciendo hincapié en el aprendizaje en el trabajo:

En primer lugar, los impresionantes antecedentes de personas como Alex influirán poco en su capacidad para gestionar proyectos complejos. Muchas empresas descubren habitualmente que sustituir a un director de proyectos veterano por otro no tiene ningún impacto. A pesar de su experiencia con proyectos complejos, ambos directores no cambian de manera significativa los modelos mentales que ya han creado en contextos más simples y, por lo general, similares. De hecho, en algunos casos, sería mejor que las empresas contrataran a alguien que no tuviera experiencia. Eso no quiere decir que los diferentes directores no tomen decisiones diferentes o que las circunstancias no conspiren para que un proyecto en particular salga bien, o incluso que algunos directores no tengan un éxito constante con el tiempo. El punto es que la mayoría de los directivos, incluso aquellos con currículums impecables, no obtienen resultados consistentemente buenos, y mucho menos mejoran, el desempeño en los proyectos que dirigen. Incluso cuando los directivos mejoran su desempeño de manera constante, la mejora probablemente se deba a alguna experiencia pasada sutilmente diferente, más que al aprendizaje sistemático e incremental de proyectos complejos.

A pesar de sus experiencias con proyectos complejos, los directivos veteranos no mejoran de manera significativa los modelos mentales que han creado en contextos más simples.

La segunda implicación es un corolario de la primera. Si no importa a quién ponga al mando, los directivos acabarán atribuyendo la responsabilidad de los fracasos no a sus propias decisiones, sino a algún otro factor: una planificación demasiado ambiciosa o las exigencias del departamento de finanzas (o, como suele ocurrir, a un vendedor que promete demasiado al cliente y, por lo tanto, se fija objetivos poco realistas para el proyecto). Cuando ese tipo de creencia se afianza, los directivos comienzan a buscar soluciones a sus problemas de rendimiento en los lugares equivocados. Esa puede ser una receta para el desastre.

Arreglar el ciclo de aprendizaje por experiencia

Aunque nuestras investigaciones indican que el ciclo de aprendizaje por experiencia se ha interrumpido para la mayoría de los directores de proyectos complejos, se puede arreglar. Hay una serie de medidas prácticas que las organizaciones pueden tomar para que los directivos comiencen a aprender en situaciones complejas. Algunas de nuestras recomendaciones aceptar las deficiencias del ciclo de aprendizaje por experiencia e implican ayudar a los gerentes a solucionarlas mediante otros tipos de aprendizaje. Otros enfoques aspiran a reducir las deficiencias del ciclo mediante la mejora del descubrimiento y la apropiación. Las empresas que adopten estas recomendaciones descubrirán rápidamente que su capacidad para mejorar el rendimiento de la gestión de proyectos aumenta continuamente.

Proporcione más comentarios cognitivos.

Los entornos de los proyectos están repletos de información, especialmente de comentarios sobre los resultados, que se obtienen a través de informes de estado. Sin embargo, en entornos en los que las relaciones de causa y efecto son ambiguas, la retroalimentación sobre los resultados no es un mecanismo eficaz para el descubrimiento o para identificar las razones que subyacen a un problema específico. Lo que los directores necesitan son comentarios que proporcionen información sobre las relaciones entre las variables importantes del entorno del proyecto, especialmente a medida que el proyecto evoluciona. Esto se llama retroalimentación cognitiva. Para ver un ejemplo, consulte la exposición «La retroalimentación cognitiva en proyectos complejos», que describe la relación entre el nivel de garantía de calidad y el ritmo al que se detectan los defectos en los primeros 80 días de un proyecto. En este caso, el director ha optado por empezar el proyecto con un nivel de garantía de calidad relativamente bajo y lo ha ido aumentando con el tiempo. El ritmo al que se detectan los defectos aumenta en consecuencia, pero con un retraso y de manera desproporcionada, ya que ahora se dedica más esfuerzo a la detección. Luego, la tasa disminuye, lo que indica que la mayoría de los defectos se están detectando, y el gerente ahora puede mantener el control de calidad a este nivel o incluso reducirlo. Si bien estos comentarios no están exentos de errores, permiten a los directivos aprender sobre relaciones dinámicas complejas. Nuestra investigación ha demostrado los beneficios claros de ello: los directivos a los que se les proporcionó retroalimentación cognitiva en nuestras simulaciones demostraron una comprensión más profunda de sus entornos y tomaron decisiones que se tradujeron en mejores resultados. Recomendamos que las empresas inviertan en incluir la retroalimentación cognitiva en los informes periódicos sobre el estado de los proyectos. Es más, hemos descubierto que estos comentarios son aún más eficaces cuando se combinan los datos de diferentes proyectos, de modo que se puede examinar el impacto de las acciones en varios proyectos.

Retroalimentación cognitiva en proyectos complejos

Este gráfico muestra a los gerentes que hay un gran desfase entre un efecto, el número de defectos detectados en un proyecto de desarrollo de software y su causa, la contratación

…

Un proveedor líder de software corporativo que sabemos emplea la retroalimentación cognitiva en sus proyectos de desarrollo. El consenso entre los ejecutivos es que esto ha ayudado a los directores de proyectos a desarrollar una mejor visión. Sus decisiones también parecen haber mejorado: la empresa calcula que la proporción de proyectos problemáticos se ha reducido un 56% en tres años.

Aplique directrices y herramientas de decisión basadas en modelos.

Nuestras investigaciones demuestran constantemente que los directores no pueden llevar una contabilidad mental adecuada en los aspectos dinámicos de la gestión de proyectos de software. La pura intuición no basta: los directivos que se enfrentan a las decisiones necesitan la ayuda de herramientas que combinen modelos formales y heurística. Tenga en cuenta las decisiones de personal. Cuando un gerente hace varias contrataciones, hay un retraso en la contratación y un retraso en la asimilación con cada una. Con el tiempo, el director tiene dificultades para evaluar la productividad actual y futura del equipo, especialmente si el personal sufre una deserción. Pero si el director dispone de herramientas que puedan calcular los efectos de las incorporaciones y la rotación durante varios períodos, tendrá una idea más clara del impacto acumulado esperado en la productividad del equipo a medio plazo. Además de los modelos formales, estas herramientas pueden contener mecanismos como cables trampa para proyectos con problemas (indicar cuándo un gerente debería considerar la posibilidad de reducir el alcance, por ejemplo) o reglas sobre el equilibrio adecuado entre el trabajo de desarrollo y el control de calidad en varias etapas. Nuestras investigaciones muestran que estas herramientas mejoran la toma de decisiones y ayudan a los nuevos directivos a ponerse al día más rápido.

Uno de los principales proveedores de software con el que trabajamos tiene una amplia cartera de sistemas de apoyo a la toma de decisiones para este mismo propósito. Los directivos de la empresa pueden utilizar los sistemas para evaluar la posible deserción, analizar los efectos de las nuevas contrataciones en la productividad del equipo y obtener orientación sobre cuestiones como si es útil contratar en las últimas etapas del proyecto. Los directores que utilizan las herramientas de apoyo a la toma de decisiones afirman que tienen un control significativamente mayor de sus proyectos y demuestran un rendimiento mucho mejor de los proyectos. La empresa también tiene una de las mejores reputaciones de calidad del sector.

Calibre sus herramientas de previsión para el proyecto.

Las herramientas en las que se basan las organizaciones para generar estimaciones de proyectos deben calibrarse según el contexto específico del proyecto: el sector, el entorno local y las habilidades del personal disponible. Sin embargo, muchas organizaciones se limitan a importar herramientas de previsión de gestión de proyectos de otros contextos y otras empresas. Una empresa de software que estudiamos acababa de adoptar una herramienta de una empresa aeroespacial. Las organizaciones agravan los problemas de estimación al basar las suposiciones de sus modelos en datos de proyectos anteriores sin depurar primero los datos (es decir, sin tener en cuenta las circunstancias inusuales a las que se enfrenten esos proyectos). No es sorprendente que las estimaciones resultantes tiendan a no ser fiables y tengan poca credibilidad entre los directores de proyectos. Cuando no tienen fe en las estimaciones, los directores de proyectos se basan en sus propias percepciones y vuelven a aplicar las reglas que han desarrollado para situaciones simples. Para evitarlo, las empresas deben hacer todo lo posible para inculcar la fe de los directivos en las proyecciones, y eso significa personalizar los modelos de previsión según las necesidades del proyecto y limpiar los datos que se utilizan para generar suposiciones e inferir relaciones. Además, cuanto más inviertan los directivos en recopilar y procesar sus propios datos, mejores serán sus previsiones. Este es un área en la que la evaluación comparativa simplista de las «mejores prácticas» por parte de los directores de proyectos exitosos puede resultar muy peligrosa.

Cuanto más inviertan los directivos en la recopilación y el procesamiento de datos, mejores serán sus previsiones.

El centro de investigación y desarrollo de uno de los principales productores de semiconductores ha desarrollado una forma de reducir la falibilidad de las estimaciones. Por cada proyecto completado, el centro «normaliza» los resultados en un proceso de tres pasos que identifica los eventos inusuales, calcula aproximadamente su impacto y, a continuación, deduce el impacto de los resultados. Los valores depurados pasan luego a los modelos de estimación.

Fije objetivos de comportamiento, no objetivos de rendimiento.

Otro punto débil de las herramientas de estimación es que sus proyecciones se basan normalmente en el tamaño del producto (por ejemplo, el número de líneas de código o puntos de función), lo que es extremadamente difícil de predecir en las etapas de planificación. Además, las entregas de los productos pueden cambiar con el tiempo de formas difíciles de anticipar. Por lo tanto, las estimaciones iniciales no son buenas metas. De hecho, cuando se usan así, promueven respuestas inapropiadas, como compensaciones ad hoc entre coste y calidad, y conducen a malos resultados.

Sin embargo, los proyectos de software utilizan de forma universal objetivos de costes y cronogramas basados en las primeras predicciones. Y cuando los directivos saben que se compararán con los objetivos basándose en estimaciones poco fiables, buscan más holgura optando por estimaciones «seguras» y, luego, proceden a desperdiciar la holgura haciendo trabajos y embelleciendo el proyecto con funciones innecesarias. Por lo tanto, hay argumentos sólidos a favor de repensar la forma en que se fijan los objetivos.

En particular, las empresas deben entender que las estimaciones funcionan mejor como dispositivos de planificación y control, y las metas como mecanismos para promover el comportamiento deseado. Recomendamos que, al establecer objetivos, las organizaciones sigan un proceso de dos pasos: primero deben decidir el comportamiento que desean fomentar y, después, fijar objetivos que fomenten ese comportamiento. En un solo proyecto, una organización podría decidir que quiere que sus directores minimicen la rotación del equipo del proyecto (esto puede aumentar la productividad y el aprendizaje y reducir los errores). Entonces, esto puede ser una parte explícita del objetivo establecido. Para cumplir ese objetivo, los directivos tendrían que formular formas de proteger a sus equipos de las presiones de los horarios y del impacto de la deserción normal.

Hemos descubierto que cuando los directores son responsables de varios proyectos, sus objetivos deberían promover un comportamiento que maximice el éxito de la cartera (en lugar de proyectos individuales). Al fijar esos objetivos, la organización debe dar a los directivos cierto grado de libertad, lo que les permitirá, por ejemplo, negociar las compensaciones entre el alcance y los cronogramas para preservar la estabilidad del equipo o evitar que los problemas afecten a otros proyectos. Además, para garantizar un mayor compromiso, las organizaciones deben dar a los directivos la posibilidad de opinar a la hora de elaborar los objetivos.

Desarrolle el proyecto «simuladores de vuelo».

Está claro que los proyectos en directo no ofrecen un buen entorno de aprendizaje. Sin embargo, es posible construir entornos artificiales que se puedan gestionar de forma que la complejidad no abrume el aprendizaje. Como analogía, considere el uso de simuladores de vuelo en la aviación. Las habilidades para volar aviones son muy específicas para cada modelo: los pilotos necesitan recibir una formación exhaustiva cada vez que cambian de modelo (o incluso pasan de, por ejemplo, una versión de carga de un Boeing 747 a una versión de pasajeros). Los simuladores de vuelo son una parte esencial de ese proceso. Los «simuladores de vuelo» construidos adecuadamente pueden desempeñar una función similar en la gestión de proyectos, a la de los mundos virtuales para el entrenamiento y la inmersión. La necesidad de ellos es especialmente pronunciada porque los directores de proyectos ahora se mueven de una organización a otra con más frecuencia que en el pasado. Dado que el conocimiento tiene un aspecto específico de la situación (o de la empresa), cada vez que los directores cambian de empresa o contexto de trabajo tienen que aprender sobre las relaciones en el nuevo entorno, por ejemplo, qué factores impulsan la productividad o la calidad. Le sugerimos un programa de formación gradual, en el que los directivos puedan empezar con entornos indulgentes, en los que las relaciones que se descubran sean sencillas. Los alumnos pasarían entonces por entornos cada vez más exigentes, en los que las relaciones se hacen más complejas y los comentarios son menos fiables. (Eso se puede diseñar aumentando continuamente los desfases entre las causas y los efectos). A medida que los alumnos progresen, sugerimos que los programas se centren cada vez más en las relaciones dinámicas (como la conexión entre las decisiones de contratación y los resultados de la garantía de calidad), ya que son las que más cuesta entender a los directivos.

Sería mejor que las empresas dejaran que sus empleados más jóvenes se las arreglaran solas y centraran sus presupuestos de formación en las personas que están más arriba en la jerarquía empresarial.

Este enfoque de simulador de vuelo funcionó bien para un fabricante de software satelital con el que trabajábamos. La empresa ha desarrollado un juego de gestión de proyectos que incorpora las realidades de su propio entorno (como los factores que más influyen en la calidad y la productividad de su negocio) e imita con éxito los procesos y los resultados de los proyectos reales realizados por la empresa. Los nuevos directores utilizan el juego para aprender los aspectos básicos de la gestión de proyectos antes de asumir las responsabilidades del proyecto. Los resultados iniciales son prometedores: los directores han mostrado una visión considerablemente mejor de las relaciones dinámicas en el trabajo en sus proyectos y el rendimiento de los proyectos también ha mejorado.• • •

Los problemas del ciclo de aprendizaje que hemos descrito no son ciertamente las únicas interrupciones que se producen en el aprendizaje. Tampoco pretendemos que nuestras recomendaciones solucionen todos los problemas. Sin embargo, los estudios que hemos realizado proporcionan pruebas convincentes de que aprender en el trabajo simplemente no funciona en ningún entorno excepto en los más básicos y que los directivos solo pueden seguir aprendiendo si reciben una formación formal y un apoyo a la toma de decisiones específicamente adaptados a los desafíos a los que se enfrentarán. Resulta que las empresas suelen gastar más dinero en formación en contrataciones de primer nivel y, por lo general, importan herramientas de planificación de proyectos al por mayor de otras empresas. Se espera que los reclutas sénior comiencen de inmediato y se supone que las mejores prácticas son precisamente eso. Estas expectativas son precisamente la razón por la que tantos directivos con experiencia fracasan cuando asumen nuevas responsabilidades. Sería mejor que las empresas dejaran que sus empleados más jóvenes se las arreglaran solas, que centraran sus presupuestos de formación en las personas que están más arriba en la jerarquía empresarial y que dejaran de buscar soluciones rápidas en otros lugares.