¿Por qué fallan los proyectos de TI? (No es por la tecnología)

Si tu empresa alguna vez implementó un sistema o una solución que terminó generando frustración, si algún proyecto estratégico se comió el presupuesto del año y entregó la mitad de lo comprometido, o si todavía tienes pesadillas con una fecha de Go Live que se movió tres veces, este post es para ti. Aquí te comparto algunos de los principales motivos que veo constantemente detrás de las fallas en la planeación y ejecución de proyectos. Créeme, esto les pasa a muchas organizaciones serias, con gente capaz y con presupuestos que otros envidiarían.

La tecnología casi nunca es la culpable

Los números hablan por sí solos

El Standish Group lleva midiendo el éxito de proyectos de software desde 1994, con una base que hoy supera los 50.000 proyectos analizados. El resultado más reciente que siempre se repite es claro: solo el 31% de los proyectos se considera exitoso. La mitad termina «desafiada» (con sobrecostos, atrasos o funcionalidades recortadas) y casi uno de cada cinco simplemente fracasa.

Lo increíble no es el número. Es que hace treinta años, cuando apenas existía internet como la conocemos, el porcentaje de éxito era prácticamente el mismo: apenas el 16% de los proyectos se entregaba a tiempo y dentro del presupuesto.

Piénsalo, hemos pasado de servidores físicos a la nube, de Waterfall a Agile, de equipos de 40 personas a squads de 6. La tecnología cambió por completo. La tasa de fracaso, no. Eso, por sí solo, ya debería hacerte sospechar lo que siempre he sostenido: el problema nunca estuvo en el código.

Las principales razones que dañan o rompen un proyecto

Cuando le pregunto directamente a los equipos de tecnología por qué fracasan sus proyectos, las respuestas casi nunca son el lenguaje de programación, un mal framework o un mal proveedor. Casi siempre mencionan esto:

• Nadie del negocio estuvo involucrado en el proyecto. No hablo de una reunión de kick-off con el gerente general sonriendo para la foto. Hablamos de usuarios reales (Key Users) sentados con el equipo semana a semana, validando que lo que estamos construyendo sirva de verdad para el trabajo del día a día. Cuando eso no pasa, el sistema puede estar terminado y aun así ser completamente inútil.
• Los requisitos nunca estuvieron claros o cambiaron sin control. Esto suena a detalle técnico, pero no lo es: es un problema de disciplina organizacional. Si nadie se sienta a definir con precisión qué se necesita y a defender esa definición frente a la presión de «agregar una cosita más», el proyecto se convierte en un blanco móvil que ningún equipo puede alcanzar.
• El patrocinio ejecutivo fue de nombre, no de hechos. Un sponsor que aparece en el kick-off y desaparece hasta que llega la crisis final no es un sponsor, es solo una firma en un documento. Los proyectos que sobreviven tienen a alguien con poder de decisión, disponible para destrabar conflictos y sostener al equipo cuando la presión política aprieta.
• La comunicación entre negocio y tecnología se rompió en algún punto del camino. Y cuando eso pasa, cada área empieza a construir su propia versión de la realidad: TI cree que está cumpliendo el alcance acordado, y el negocio cree que le están entregando otra cosa. Ambos tienen razón según su propia información, pero dejaron de compartir el mismo objetivo.
• Nadie puso un límite al alcance. Cada «solo una cosa más» pareció razonable en su momento. Sumadas, esas pequeñas concesiones son las que terminan descarrilando cronogramas y presupuestos sin que nadie sienta que tomó una mala decisión.

Cuando el proyecto funciona, pero la gestión lo apaga

Te cuento un caso de mi propia experiencia. Hace un tiempo, en Azurian trabajamos con una importante empresa del rubro de materiales de construcción. Partimos con algo pequeño y terminamos resolviendo el sistema core y el seguimiento logístico de la compañía, uno de los softwares más importantes para su operación.

Hicimos un sistema a su medida, con un prototipo sólido que cumplía a la perfección y superaba las limitaciones de su sistema anterior. El proyecto fue sumamente rentable, operó impecable y evolucionó junto a ellos. Sin embargo, en el proceso llegaron nuevas cabezas y gerencias que no tenían la visibilidad de lo que se había construido ni de dónde venían, y terminaron cerrando el proyecto por una decisión gerencial sin lógica de entendimiento técnico ni de negocio.

Ahí te das cuenta de que la ejecución técnica puede ser perfecta y el proyecto muy rentable, pero si la gobernanza y la continuidad de la visión de negocio fallan, el esfuerzo se cae.

Cómo prevenir problemas

En la mayoría de los casos, el negocio ya tiene un discurso preestablecido cuando un proyecto tecnológico no llega a buen término: «Casi siempre la culpa es del software que no funcionaba como esperábamos». Si bien esto pudiese parecer lógico en un sentido técnico puro, lo que realmente falla son las dinámicas humanas y estructurales mucho más profundas y difíciles de resolver. Por este motivo, lo primero que siempre pido es sentarse a conversar directamente con los usuarios que van a usar la herramienta, entender su operación y capturar el verdadero dolor.

Para mitigar el fracaso de proyectos, aquí te comparto los puntos que considero más relevantes:

1. Designa a una persona con verdadera autoridad que responda por el proyecto completo, no por un pedazo.
2. No establezcas compromisos de fecha y presupuesto sin antes entender bien el problema que se quiere resolver y cuál es el esfuerzo necesario.
3. Exige a los usuarios finales involucrados desde el primer día, no invitados únicamente a validar al final.
4. Genera una cultura de alertas tempranas en el equipo, para que los problemas se traten de forma rápida y colaborativa.
5. Pon foco y defiende las decisiones tomadas por la necesidad genuina del negocio, y no por presiones jerárquicas o calendarios irreales.

Si tu empresa ha vivido algo parecido, te aseguro que no fue mala suerte, y probablemente tampoco fue culpa del equipo técnico. Fue un problema de cómo se planificó, se acompañó y se gobernó el proyecto desde el negocio.

La buena noticia es que, a diferencia de un problema técnico, este tipo de falla es completamente prevenible: no depende de salir a comprar mejor tecnología, depende de acompañar bien al negocio y ayudar a tomar mejores decisiones organizacionales antes de escribir la primera línea de código.