La investigación sobre fracasos en proyectos tecnológicos es consistente desde hace décadas: la mayoría de los problemas no son de origen técnico. El Chaos Report del Standish Group, que lleva más de 30 años estudiando proyectos de software, reporta que las causas principales de fracaso son gestión de requisitos, falta de involucramiento de usuarios y cambios en el alcance — no errores de código ni limitaciones tecnológicas.
Estas son las cinco causas que aparecen con más frecuencia.
Causa 1: Definición del problema insuficiente
"Necesitamos implementar AI." "Queremos un sistema de BI." "Hay que digitalizar el proceso de facturación."
Todas esas frases describen una solución. Ninguna describe un problema.
Cuando el proyecto comienza desde la solución, el equipo construye algo técnicamente correcto que puede no resolver nada relevante. La validación llega al final, cuando el costo de corregir el rumbo es máximo.
El punto de partida correcto es siempre el problema: qué duele, cuánto cuesta ese dolor, qué resultado concreto se espera después del proyecto.
Causa 2: Usuarios finales excluidos del diseño
Los proyectos tecnológicos los decide la gerencia. Los usa el equipo operativo. Cuando esos dos grupos no están alineados desde el inicio, el resultado casi siempre es el mismo: un sistema que nadie adopta.
Las personas que ejecutan el proceso conocen detalles que ningún analista externo va a descubrir en un taller de requisitos. Saben cuáles son los casos especiales, las excepciones no documentadas, los pasos informales que hacen que el proceso funcione en la práctica. Ignorar ese conocimiento produce sistemas que funcionan en papel y fallan en la realidad.
Causa 3: Scope creep no gestionado
Un proyecto empieza con un objetivo claro. A mitad de camino, aparecen nuevos requerimientos. Cada uno parece razonable de forma aislada. El efecto acumulado duplica el esfuerzo y la complejidad sin que nadie lo haya decidido explícitamente.
El scope creep es inevitable en proyectos de cierta duración. El problema no es que ocurra — es que no se gestione. Cada cambio de alcance es una decisión que tiene impacto en tiempo, costo y calidad. Tratarlo como si no lo tuviera es uno de los mecanismos más comunes de fracaso.
Causa 4: Ciclos de feedback demasiado largos
El modelo clásico: el equipo trabaja durante meses, y el resultado se muestra al cliente o a los usuarios cuando está "terminado". Si algo no cuadra con lo que se esperaba, el costo de corrección es alto.
Los proyectos con ciclos cortos de entrega — dos o tres semanas entre cada versión funcional — detectan los desajustes temprano, cuando corregirlos es relativamente barato. Los proyectos con ciclos largos detectan los problemas tarde, cuando las opciones son costosas.
Causa 5: Adopción no planificada
Un sistema puede estar técnicamente bien implementado y aun así fracasar si el equipo no lo usa. La adopción no ocurre sola — requiere planificación, comunicación del cambio, capacitación y métricas de uso.
Tratar la adopción como algo que ocurre "después de que termine el proyecto" es un error de diseño. La adopción es parte del proyecto, con la misma importancia que el desarrollo técnico.
El patrón común
Nótese que ninguna de estas causas es técnica. Son causas de proceso, comunicación y gestión. Eso es relevante por una razón práctica: son prevenibles con buenas prácticas de gestión, sin necesidad de cambiar la tecnología ni el proveedor.
Los proyectos bien ejecutados no son más difíciles técnicamente. Son más disciplinados en estos cinco aspectos.
