Cómo Evitar el Fracaso de un Proyecto en 3 Pasos + 4 Estudios de Caso
Hay muchas razones por las que los proyectos fracasan, pero la mayoría se reducen a una de dos cosas (a veces ambas):
- Existía un riesgo que nadie reconoció, y/o
- No respondimos bien cuando surgió un problema
En este artículo, quiero centrarme en la visión general para ayudar a abordar la principal causa del fracaso en los proyectos—y, a menudo, de la gestión de proyectos.
Así es como puedes evitar el fracaso de los proyectos y qué hacer si ocurre ese problema catastrófico que no preveías (¡aún puedes superarlo si actúas rápido y con sensatez!).
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
¿Qué es el fracaso de un proyecto?
Es exactamente lo que parece: cada vez que un proyecto no cumple con los objetivos marcados por el equipo al principio, no responde a las expectativas del cliente o de las partes interesadas clave, o no cumple con los plazos, el presupuesto o el alcance.
¿Por qué fracasan los proyectos?
Como mencioné en la introducción, hay razones comunes por las que los proyectos pueden fracasar. Normalmente esto se debe a un riesgo que no se evaluó adecuadamente, y/o a que el equipo (incluido el gestor de proyectos) no respondió correctamente a ese riesgo.
Otras causas comunes de fracaso pueden incluir una mala comunicación sobre el estado, los problemas o los riesgos; miembros del equipo que no se ajustan (o no entienden bien) el alcance del proyecto, los entregables (es decir, desviación del alcance) o los plazos; falta de recursos, o no seguir los procesos o metodologías designados.
Cómo evitar el fracaso de un proyecto: 3 pasos
La gestión de riesgos es una actividad clave en la gestión de proyectos. Es tan importante que no gestionar el riesgo suele equivaler a fracasar como gestor de proyectos. La gestión de riesgos tiene tres componentes importantes:
- Identificar los riesgos.
- Evaluar lo que has identificado: ¿Qué probabilidad hay de que ocurra y qué tan grave sería si pasa? ¿Cuáles son la probabilidad y el impacto?
- Preparar planes de mitigación y contingencia para aquellos riesgos que podrían arruinar tu proyecto por lo demás exitoso. Los registros de riesgos son útiles para llevar un control de lo que has hecho.
1. Identificar riesgos
Primero, identifica los riesgos. Hacer esto bien aumentará enormemente tus posibilidades de éxito. Y aunque es difícil captarlos todos, si analizas el proyecto de forma sistemática, normalmente puedes descubrir los riesgos más importantes. Esto suele formar parte del proceso de creación de un plan de proyecto.
Mi experiencia está en el desarrollo de software, tanto de producto como de TI, y sus procesos asociados. Los proyectos de software son complejos, frágiles y, salvo en contadas excepciones, no disponen de los sistemas de seguridad e inspección integrados que sí existen, por ejemplo, en la construcción o en la fabricación de dispositivos médicos.
Deberías tener objetivos para cada uno de los cuatro indicadores del proyecto:
- Cronograma
- Contenido
- Costo
- Calidad
Si no sabes cuáles son, empieza por ahí. Suelo ver que dos de los cuatro suelen ser variables, pero cuanto más entiendas hacia dónde te diriges, más fácil será identificar los obstáculos.
Comprender cuál de los cuatro indicadores es prioritario te ayudará a reducir el riesgo realizando pequeños ajustes allí donde corresponda.
Es fácil dejarse llevar por el cronograma del proyecto y pasar por alto riesgos que puedan afectar a los demás indicadores, pero todos están relacionados y es importante identificarlos todos.
Cumplir los plazos con un producto lleno de errores rara vez es una buena opción—aunque lo entregues, acabarás haciendo versiones de corrección sobre la marcha que retrasan más el cronograma de lo que hubiera costado solucionar el problema desde el principio.
Más allá de los 4 indicadores
Además de los cuatro indicadores, tienes tres aspectos de tu proyecto que equilibrar:
- Producto, que por lo general está cubierto por los indicadores
- Proceso
- Personas
Los riesgos de proceso se presentan de dos formas: una insuficiencia en un proceso existente que no responde a las necesidades de tu proyecto, y la ausencia de un proceso para algo clave en lo que tu equipo está trabajando. Los riesgos de proceso pueden mitigarse fácilmente creando o corrigiendo el proceso.
La parte humana a menudo se pasa por alto, pero tu equipo y los equipos con los que interactúan serán clave para el éxito o el fracaso. Partes interesadas difíciles o poco comprometidas dificultarán que obtengas lo necesario para avanzar.
Los miembros del equipo sobrecargados, estresados o infelices no harán el trabajo. Algunos de los posibles problemas con el personal los puedes identificar de manera pública, otros quizás prefieras tratarlos en privado, pero no cometas el error de ignorarlos.
2. Evalúa los Riesgos que Has Identificado
Después de identificar los riesgos, determina cuán probable es que sucedan. Normalmente utilizo un porcentaje: 100% significa que estoy seguro de que ocurrirá. También es importante determinar la gravedad del impacto si el riesgo ocurre. La forma más sencilla de hacer esto es categorizando los riesgos como de alto, medio o bajo riesgo.
Una vez realizado este análisis, es momento de involucrar a tu equipo. Pregunta a cada miembro o colaborador del proyecto qué les preocupa, añade esas inquietudes a la lista de riesgos y ponlas a revisión:
- ¿Puede el equipo pensar en otros riesgos que no hayas cubierto?
- ¿Cómo se sienten respecto al análisis de probabilidad e impacto?
Con base en esta reunión, podrás ajustar tu plan de riesgos. Las partes uno y dos están listas, por ahora. Deberás revisar los riesgos al menos semanalmente para ver si hay nuevos riesgos, si algunos ya no aplican o si ha cambiado la probabilidad o el impacto de alguno.
3. Prepara Planes de Mitigación y Contingencia
Por último, si la combinación de probabilidad e impacto de algún riesgo tiene potencial de descarrilar tu proyecto, trabaja con tu equipo para crear planes documentados de mitigación y contingencia.
La mitigación implica hacer que el riesgo sea menos probable o que tenga un impacto menor si ocurre. El plan de contingencia se centra en los pasos que tomarás si el riesgo es inevitable y sucede.
Asegúrate de que los planes estén documentados y todos los conozcan. También es una buena idea planificar posibles problemas de personal además de los 4 dialers y los procesos, aunque probablemente quieras realizar este análisis tú mismo y mantenerlo confidencial.
Cómo Sobrevivir al Fracaso de un Proyecto
La segunda razón para los fracasos en la gestión de proyectos es una mala respuesta ante la materialización de un riesgo del proyecto, ya sea previsto o no. Esto depende mucho de ti como responsable del proyecto. Antes de completar cualquiera de los siguientes pasos, empieza con estos 2 consejos:
- No entres en pánico. Recuerda respirar.
- No busques culpables y no dejes que nadie más empiece por ese camino.
1. Consulta Tu Plan de Contingencia
Si tienes un plan de contingencia, convoca una reunión inmediatamente, o al menos envía un correo electrónico activando el plan de contingencia. Recuerda a las personas cuál es el plan y diles cuándo y cómo deben informar sobre el estado.
Si omites esto o lo retrasas, verás que personas deseosas de ayudar se habrán lanzado a actuar movidos por el pánico; cuando esto sucede, pierdes el control de lo que se ha hecho y, a menudo, el problema termina agravándose.
Si no tienes un plan de contingencia, reúne de inmediato al equipo con una notificación de reunión e instrucciones estrictas de NO HACER NADA MÁS hasta después de la reunión.
En caso contrario, todos intentarán ayudar y no sabrás qué acciones se han realizado. En la reunión, expón el problema con claridad; siempre sorprende la cantidad de ideas distintas que puede tener la gente sobre cuál es el verdadero problema.
Realiza un análisis consolidado de la causa raíz para llegar al fondo del asunto y elaborad el plan—quién, qué y cómo—para recuperarse. Cuando trabajes en un análisis de causa raíz, debes entender quién hizo qué antes de que surgiera el problema, pero mantén la discusión en ese nivel.
En otras palabras, solo los hechos. No busques culpables, ya que señalar con el dedo solo distraerá. Si tu equipo no logra encontrar la solución, tienes varias opciones.
La primera opción es traer a alguien que tenga conocimientos generales sobre el tema, pero que no forme parte de ese proyecto específico; por ejemplo, si el problema parece estar en la base de datos, invita a un administrador de bases de datos que no esté en el proyecto para conseguir otra perspectiva.
Otra técnica consiste en invitar a alguien que no tenga conocimiento operativo del proyecto. A veces, tener que explicar cada paso de manera explícita expone suposiciones erróneas o aspectos que las personas han pasado por alto.
2. Soluciona el Problema
Haz que todos estén de acuerdo con el curso de acción y asigna tareas. Pide que te informen sobre su progreso y explícales con qué frecuencia deben hacerlo: cada hora, cuando terminen una tarea, al final del día, o lo que tenga sentido según la situación.
Puede que el reporte de avances te parezca obvio, pero para todo el mundo no lo será. Los informes periódicos ayudarán a mantener al equipo centrado. Informa sobre los avances colectivos a todo el equipo de manera regular.
Quienes en el equipo no tengan tareas inmediatas se pondrán inquietos y, finalmente, intentarán ayudar a menos que les suministres actualizaciones de estado y otra información.
También es muy importante mantener informada a la dirección. Usa tu criterio para decidir quién necesita recibir actualizaciones y en qué momento, pero informa sobre los avances a todo el equipo con regularidad.
3. Da el Trabajo por Terminado
Cuando realmente esté terminado, claro. Genera un informe final y sigue con el siguiente paso. Da al equipo algo de tiempo para recuperarse.
4. Realice un análisis post mortem o retrospectiva
Es importante completar una evaluación del proyecto para reunir las lecciones aprendidas. Aquí tienes cómo estructurarlo:
- Exponga el problema para que todos estén en sintonía.
- Comience con lo que salió bien. Incluso en la situación más grave, algo salió bien. Esto da inicio a la reunión con un tono completamente diferente.
- Hable sobre lo que necesita mejorar. Si hay tiempo, haga una lluvia de ideas sobre cómo implementar las mejoras; de lo contrario, asigne tareas y fechas límite y haga seguimiento en esas fechas.
Si en realidad fue culpa de alguien, trate el asunto directamente con esa persona—en privado. Si lo hace en público, todo su equipo se preguntará quién será el próximo en pasar vergüenza ante los demás.
Si lo omites por completo, tu equipo sentirá que alguien se salió con la suya y el problema no se solucionó. Sea objetivo y dé seguimiento a cualquier cambio personal de proceso que alguien deba realizar. Todo se trata de responsabilidad y mejora, no de buscar culpables.
3 Ejemplos reales de fracasos de proyectos
He tenido mi cuota de fracasos en proyectos de TI, aunque afortunadamente—pero dolorosamente—finalmente se recuperaron.
Aquí tienes un par de mis propios proyectos fallidos de TI y de desarrollo, así como un ejemplo de un famoso proyecto fallido.
Estos ejemplos de fracasos de proyectos y estudios de caso de proyectos fallidos también deberían darte una idea concreta de las formas en que los proyectos pueden fracasar y cómo se puede abordar esto.
1. El sistema contable
Al principio de mi carrera, trabajé en IBM. Mi primer trabajo real fue hacerme cargo de un sistema bastante pequeño que alimentaba los sistemas contables corporativos. Alguien dentro de IBM lo había escrito en un lenguaje de programación poco conocido llamado RPG, en un sistema pequeño.
No solo gestioné el proyecto—gestioné todo el sistema (aunque había un administrador), incluyendo la recopilación de requisitos del proyecto, la resolución de problemas y la programación.
Un buen día subí un programa nuevo, lo ejecuté y encontré un error. Corregí el error y volví a ejecutar el programa. A la mañana siguiente recibí una llamada de Contabilidad avisándome que había asientos duplicados (esto es una muy mala noticia en el mundo contable).
Primero, nadie revisó mi trabajo. Segundo, no involucré a las personas de los sistemas posteriores para revisar los asientos antes de que se procesaran. Y tercero, no me tomé el tiempo para analizar algunos de los programas antiguos que seguían ejecutándose y generando asientos duplicados. Tampoco había ningún proceso, más allá de lo que yo iba improvisando sobre la marcha.
Y luego mi reacción—pánico. Por dios, recién salido de la universidad y estoy arruinando el sistema contable de IBM. No incluí a las personas correctas—el administrador no sabía lo que estaba pasando—y él generó aún otro conjunto de asientos sin saberlo. Al final, trabajé 48 horas seguidas para llegar a la raíz del problema, corregirlo, y escribir y ejecutar programas para corregir los errores contables.
Y aprendí la lección—mirar cuidadosamente, conseguir revisiones, pensar en lo que podría salir mal y parar y pensar antes de lanzarte a intentar arreglar las cosas (todo esto lo puede facilitar un software de gestión de proyectos contables). Ahora imagina que yo estuviera gestionando un equipo de 10 personas y todas intentaran hacer lo mismo para solucionar el problema. Realmente hubiera sido irrecuperable sin detener los sistemas contables de IBM para resolverlo.
2. El nuevo producto interno
Como consultor, estaba al mando de un nuevo proyecto grande, con muchas personas opinando sobre los requisitos, lo que generaba cambios constantes en las prioridades funcionales. Estábamos utilizando un proceso de gestión de proyectos ágil, que la empresa no había usado antes. El equipo de QA era muy bueno en pruebas pero aún no comprendía la mentalidad y el flujo de trabajo de los usuarios finales.
Yo era consciente de todo eso y lo manifesté en varias ocasiones, pero no tenía un registro de riesgos, ni evaluaciones de impacto/probabilidad, ni planes de contingencia o mitigación. Tampoco era yo el principal canal de información hacia la patrocinadora del proyecto, aunque sí me reunía con ella ocasionalmente.
Añadimos un sprint. Luego otro. Luego, cuando se hizo evidente que aún no estábamos listos para hacer una prueba beta, agregamos un tercer sprint.
Como no era yo quien informaba a la patrocinadora del proyecto, no tenía idea de que ella no sabía todo esto. La persona a cargo cometió el error crítico de no informar a la patrocinadora, esperando que pudiéramos resolverlo sobre la marcha.
Y para ser justos, aunque yo hablaba de riesgos, no le ofrecí un conjunto concreto de riesgos para presentar y preparar a la patrocinadora ante la posibilidad de un retraso en la planificación.
En medio de todo esto, tuve una reunión con la patrocinadora e hice un comentario casual sobre ese último sprint adicional que íbamos a añadir. Ella me detuvo. No sabía nada sobre eso y no estaba nada contenta.
Resultó que le molestó más la sorpresa que el retraso en la planificación. Hubo repercusiones públicas y, finalmente, la persona a cargo del proyecto fue trasladada a otro departamento de la empresa porque la confianza se había perdido.
Una vez más, aprendí lecciones importantes del fracaso. Conocer los riesgos no es suficiente; necesitas analizarlos en conjunto, evaluarlos, tener planes de mitigación y contingencia, y hacerlos públicos y visibles en todo momento.
Nunca he sido de ocultar riesgos e incidencias, pero la importancia de la transparencia en los proyectos se hizo inconfundiblemente clara.
3. ¿Recuerdas OS2?
No, nadie lo recuerda. Es uno de los muchos proyectos fallidos de desarrollo de sistemas. Yo trabajaba en IBM cuando salió el OS2 original, un competidor de Windows. Ni siquiera probé esa primera versión porque en IBM todos sabíamos que estaba realmente llena de errores. El resto del mundo se dio cuenta enseguida de que tenía tantos fallos que no valía la pena intentarlo.
Tenía tantos problemas que el equipo del proyecto no podía haber pensado realmente que estaba terminado, pero de alguna manera no tomaron la decisión correcta y no retrasaron el lanzamiento. Si no tienes en cuenta el elemento humano, tanto de tu equipo como de tus clientes, un bello plan puede venirse abajo rápidamente.
En software existen varias alternativas ante esta situación: hacer un lanzamiento limitado para personas que toleren los errores a cambio de tener un software de última generación, hacer público que estás esperando alcanzar cierto nivel de confiabilidad antes de lanzar, etc.
Era una etapa lo suficientemente temprana en mi carrera como para extraer valiosas lecciones del hecho de que un producto que me encantaba estaba destinado al fracaso ya en su segunda versión.
Sé claro con tus prioridades: hay pocos casos en los que lanzar en una fecha determinada es más importante que la calidad del producto, pero no son muchos.
Utiliza tus cuatro indicadores y admite tus errores, haz visibles las correcciones para que la gente confíe en que comprendes el problema y no volverás a cometer el mismo error.
Considera el factor humano: es tan crítico como la tecnología. Desde entonces, he incorporado estas lecciones a los proyectos de software y TI, y han sido invaluables.
Conclusión
En general, recuerda que aunque en última instancia la responsabilidad es tuya, no necesitas hacer todo el trabajo. De hecho, no deberías intentar hacerlo solo. Puedes beneficiarte de la amplia experiencia y conocimientos de tu equipo. Eres el líder, pero no tienes que ser todo el equipo.
El software de gestión de proyectos y otras herramientas de gestión de proyectos pueden ayudarte a realizar un seguimiento de los riesgos, los hitos, la asignación de recursos y otros indicadores críticos para saber si vas camino a lograr un proyecto exitoso.
