¿Por qué fracasan los proyectos? Ejemplos y cómo evitar el fracaso

Este artículo es un extracto de la guía del libro de Shortform "The Mythical Man-Month" de Frederick Brooks. Shortform tiene los mejores resúmenes y análisis del mundo de los libros que deberías leer.

¿Le gusta este artículo? Suscríbase a una prueba gratuita aquí.

¿Por qué fracasan los proyectos en la gestión empresarial? ¿Cuál es la razón más común? ¿Cómo se puede evitar el fracaso?

En The Mythical Man-Month, Frederick P. Brooks ofrece una guía para completar proyectos complicados a tiempo. El libro abarca estrategias para agilizar el proceso, de modo que pueda mantener a su personal trabajando sin problemas y terminar a tiempo sus proyectos más abrumadores.

Siga leyendo para conocer algunos ejemplos de Brooks de por qué fracasan los proyectos y sus soluciones para evitar el fracaso.

¿Por qué fracasan los proyectos? Respuesta de Brooks

Frederick P. Brooks, autor de The Mythical Man-Month, dirigió la división de IBM que programaba sistemas operativos informáticos en los años sesenta. Dirigía a más de 100 empleados para crear programas punteros que requerían un intenso grado de coordinación: La alta complejidad, y los errores que conllevaba, provocaban que sus proyectos fracasaran y se retrasaran. Brooks trató de responder a la pregunta: "¿por qué fracasan los proyectos?". Como respuesta, desarrolló una serie de estrategias para reducir la complejidad al tiempo que coordinaba grandes equipos, mantenía los proyectos largos dentro de los plazos previstos y gestionaba los errores que inevitablemente se producen en el trabajo orientado al detalle.

Uno de los retos más desalentadores para Brooks a la hora de supervisar proyectos complejos es completarlos en el plazo previsto. Incluso con equipos optimizados para reducir la falta de comunicación, cualquier proyecto a largo plazo puede retrasarse e inevitablemente fracasar.

Por qué los directivos hacen estimaciones inexactas

A veces, los proyectos fracasan y se salen del calendario porque el propio calendario es una mala estimación de su duración. Brooks identifica dos razones por las que los gestores crean estimaciones inexactas.

Razón nº 1: Deseo de complacer al cliente 

Cuando los clientes piden un plazo concreto, los directivos pueden tener la tentación de ajustar las estimaciones de tiempo a los objetivos de sus clientes en lugar de a las capacidades de su equipo. Los directivos pueden sentirse aún más tentados a prometer más de la cuenta cuando se ven presionados por un competidor que les promete un plazo aún más rápido, tanto si puede cumplir sus promesas como si no.

Brooks ofrece dos soluciones a la tentación de prometer más de la cuenta. En primer lugar, los directivos deben ser honestos con sus clientes y estimar los proyectos con integridad. Como directivo, tienes que mantener tu opinión profesional, aunque decepcione a un cliente. En segundo lugar, sostiene que las empresas deben hacer públicos los datos sobre su productividad, incluidos aspectos como los plazos de finalización de proyectos anteriores. De este modo, los clientes conocerán con exactitud los plazos de los proyectos y, por tanto, plantearán menos exigencias poco realistas. Esto, a su vez, reducirá la tentación de los directivos de hacer promesas poco realistas. 

(Nota breve: Aunque prometer demasiado para complacer a un cliente puede ofrecer beneficios a corto plazo, los estudios demuestran que esto puede llevar a la decepción, el conflicto y la pérdida de beneficios a largo plazo. Las investigaciones sobre los conflictos de los clientes con las empresas demuestran que las empresas que prometen más de lo que pueden cumplir se enfrentan a mayores reacciones negativas y tienen que dedicar más tiempo a gestionar los conflictos con los clientes que las empresas que hacen promesas realistas. Además, las empresas que fomentan las relaciones personalizadas con sus clientes se enfrentan a una reacción aún mayor que las que mantienen las cosas estrictamente comerciales, ya que esto aumenta las expectativas de los clientes, incrementando su sensación de traición en respuesta a las promesas incumplidas).

Razón nº 2: Subestimar el tiempo de reparación de errores

Brooks sostiene que los proyectos pueden fracasar cuando los gestores hacen estimaciones de programación deficientes por ser demasiado optimistas. Considera que los programadores informáticos son especialmente optimistas por naturaleza, ya que, como señala, a las personas que se sienten atraídas por la vanguardia de la tecnología les suele gustar imaginar un futuro mejor. Este optimismo les lleva a menudo a subestimar el tiempo que pasarán probando, reparando y corrigiendo errores.

Brooks aconseja a los programadores que adopten una visión más realista y prevean los errores. Ofrece sus propias estimaciones como guía para asignar tiempo a cada fase del proceso.

• 1/3 para el diseño
• 1/6 para programación
• 1/4 para probar y reparar componentes individualmente
• 1/4 para probar y reparar el sistema en su conjunto

Observe que las pruebas y reparaciones ocupan la mitad del horario, mientras que la programación en sí es lo que menos tiempo ocupa.

Consecuencias de una mala estimación de la programación

Brooks identifica tres formas en las que un calendario mal calculado puede hacer fracasar un proyecto:

1. Una programación imprecisa hace que el proyecto llegue tarde.

(Nota breve: aunque Brooks no lo explica explícitamente, terminar un proyecto fuera de plazo perjudica las relaciones de tu empresa con tus clientes. Si contaban con tu proyecto para una fecha determinada, el retraso interrumpe también sus operaciones, lo que garantiza la tensión en vuestra relación).

2. El incumplimiento de los plazos desmoraliza a los empleados, que se sienten fracasados incluso cuando trabajan de forma productiva.

(Nota breve: los expertos en empresa señalan que el incumplimiento crónico de los plazos también puede reducir la productividad al dar a sus empleados la impresión de que sus plazos no importan realmente. Como resultado, aunque empieces a crear plazos realistas, puede que no estén motivados para cumplirlos).

3. Una programación imprecisa reduce la eficacia. Dado que muchos proyectos requieren que los equipos completen los pasos de forma secuencial, una programación imprecisa puede crear cuellos de botella en el flujo de trabajo.

(Nota breve: los expertos en gestión de proyectos aclaran cómo una programación imprecisa crea cuellos de botella. Un cuello de botella se produce cuando las entradas superan la capacidad. En otras palabras, las tareas se asignan a un trabajador, equipo o máquina a un ritmo superior al que pueden completarse. Aquí es donde entra en juego la programación imprecisa. Si subestima la cantidad de tiempo que tardará un paso, entonces sobreestimará la cantidad de trabajo que puede enviar a su trabajador, equipo o máquina, dando lugar al desequilibrio entre capacidad y entrada que produce los cuellos de botella).

Cómo cumplir sus previsiones

Los proyectos pueden fracasar a pesar de una buena programación. Ni siquiera el mejor calendario garantiza que el proyecto se termine a tiempo. En esta sección analizaremos las ideas de Brooks sobre los factores que retrasan los proyectos y sus estrategias para mantenerlos en marcha.

Por qué se retrasan los proyectos

Antes de saber cómo mantener los proyectos dentro de los plazos previstos, hay que entender por qué se retrasan. Brooks descubrió que los proyectos suelen retrasarse debido a la acumulación de pequeños retrasos y no a crisis o catástrofes inesperadas. En una crisis grave, la mayoría de los empleados reconocen la gravedad de la situación y aumentan sus esfuerzos en consecuencia. Sin embargo, a menudo se pasan por alto los pequeños retrasos y se deja que se acumulen sin abordarlos. 

Este problema se agrava porque los directivos inferiores no suelen comunicar los pequeños retrasos. Brooks sugiere que esto no significa necesariamente que haya directivos inferiores engañosos. Puede que ellos mismos se consideren responsables de solucionar el problema en lugar de molestar a los supervisores con pequeños detalles. No obstante, esto hace que los altos directivos no sepan cuándo un proyecto empieza a retrasarse.

Cómo evitar retrasos

Al hablar de por qué fracasan los proyectos, Brooks ofrece dos consejos para reducir los pequeños retrasos del proyecto:

1. Establezca puntos de referencia mensurables y binarios. Puede hacer un seguimiento mucho más preciso de sus progresos estableciendo puntos de referencia mensurables y binarios. Un punto de referencia medible es aquel cuyo progreso puede seguirse y cuantificarse fácilmente. Un punto de referencia binario es un punto de referencia que sólo tiene dos estados: completo o incompleto. Lo contrario de un punto de referencia mensurable y binario es aquel que está abierto a la interpretación en cuanto a si se ha alcanzado o no. Por ejemplo, si estás construyendo una casa y tu punto de referencia es que "la mayor parte del tejado" estará terminado el martes, "la mayor parte del tejado" puede significar muchas cosas. Por el contrario, el objetivo de "clavar 250 tejas antes de las 5 de la tarde" no está abierto a interpretaciones: o se cumple o no se cumple. 

2. Realice un seguimiento de la finalización de todos estos puntos de referencia específicos. Cuanto más consciente sea de los pequeños retrasos, más podrá evitar que se acumulen de forma inadvertida. Una vez que tenga objetivos mensurables y binarios, registre cuándo se ha completado cada uno de ellos. Brooks tenía todo un equipo cuyo trabajo consistía en registrar cuándo se cumplía cada objetivo.

(Nota breve: el seguimiento detallado de los progresos puede resultar agobiante o invasivo para algunos de sus empleados. Sin embargo, no tiene por qué serlo, siempre que se centre en los pequeños logros junto con los pequeños retrasos. Algunos expertos en gestión afirman que reconocer y celebrar las pequeñas victorias aumentará incluso la moral y la productividad de los empleados. Dado que los grandes logros son poco frecuentes, centrarse en los pequeños logros puede mantener la motivación diaria que los empleados necesitan para que su proyecto siga por buen camino).

La ley de Brooks: No añada más empleados a un proyecto atrasado

Brooks sostiene que, una vez que un proyecto se retrasa, es un error añadir más empleados con la esperanza de acelerarlo. Muchos directivos caen en esta trampa, con la esperanza de que la mano de obra adicional acelere el proyecto y evite que fracase. Brooks afirma que esto sólo añadirá más retrasos. De hecho, llama a este principio "Ley de Brooks": Añadir más trabajadores a un proyecto retrasado hará que se retrase aún más. Brooks explica por qué. 

Razón nº 1: Los nuevos trabajadores añaden complejidad y oportunidades para una coordinación deficiente

Todos esos nuevos empleados tienen que incorporarse al flujo de trabajo existente, lo que añadirá tiempo y esfuerzo. Además, los empleados adicionales añadirán más complejidad. Recuerde que a medida que aumenta el número de empleados que trabajan juntos, las posibilidades de que se produzcan errores de comunicación aumentan exponencialmente. Esta complejidad aumenta la probabilidad de que se produzcan errores, lo que significa más tiempo dedicado a probar, depurar y corregir.

(Nota breve: Brooks se centra en cómo los nuevos empleados requerirán formación y añadirán complejidad a un proyecto. Sin embargo, añadir un número significativo de nuevos empleados también puede ralentizar un proyecto porque el equipo tendrá que dedicar tiempo a establecer relaciones. Los expertos en gestión han descubierto que los equipos hacen su mejor trabajo cuando sus miembros confían y se apoyan mutuamente. Cultivar estas relaciones lleva tiempo. Por lo tanto, un equipo con un número significativo de nuevos trabajadores necesita tiempo -y quizás algo de creación intencionada de equipo- antes de funcionar con eficacia).

Razón nº 2: La programación suele requerir pasos secuenciales

A veces, no puede pasar de una fase del proyecto a otra sin completar un paso importante. Si estás atascado en un paso, puedes tener la tentación de añadir más trabajadores a los pasos siguientes para acelerar el avance del proceso. Esto simplemente reducirá su eficiencia porque no tendrán nada que hacer hasta que ese paso anterior esté completo. Por ejemplo, si está construyendo una casa y espera a que se sequen los cimientos de cemento, no puede acelerar el proceso añadiendo más techadores. Se quedarán parados, costando dinero y sin aportar nada.

(Nota breve: los expertos en gestión de proyectos distinguen entre flujos de trabajo secuenciales y paralelos . En un flujo de trabajo secuencial, cada paso se completa antes de pasar al siguiente. Mientras que en un flujo de trabajo paralelo, algunos pasos se completan simultáneamente para reducir el tiempo de trabajo. Por ejemplo, supongamos que está preparando un sofrito. Si trabajara secuencialmente, cortaría todos los ingredientes antes de empezar a cocinar. En un flujo de trabajo paralelo, identificaría los ingredientes que requieren más tiempo de cocción, los cortaría primero y los dejaría cocer mientras corta el resto de los ingredientes, ahorrando tiempo. Sin embargo, los flujos de trabajo paralelos suelen requerir más planificación y gestión, y sólo funcionan en determinados proyectos).

---Fin de la vista previa.

¿Te gusta lo que acabas de leer? Lee el resto del resumen y el análisis del libro "El mítico hombre-mes" de Frederick Brooks en Shortform.

Esto es lo que encontrará en nuestro resumen completo de El Mítico Hombre-Mes:

• Una guía para gestionar grandes equipos y completar proyectos complicados
• Cómo mantener una buena colaboración entre el personal
• Estrategias para que los proyectos a largo plazo se ajusten al calendario

Consiga ya los mejores resúmenes de libros del mundo