Por qué los proyectos fracasan antes de comenzar.
Estrategia7 min de lectura

Por qué los proyectos fracasan antes de comenzar.

Carlos Riveros2026Project Leader Lab

Hay proyectos que no fracasan en la obra. Fracasan mucho antes, en lugares más cómodos y silenciosos.

Hay proyectos que no fracasan en la obra. Fracasan mucho antes, en lugares más cómodos y silenciosos. Fracasan en una sala de juntas con buen café, en una hoja de cálculo que nadie quiso incomodar, en una promesa comercial hecha con demasiada confianza, en una fecha aprobada porque sonaba bien, en un alcance descrito con palabras amplias y responsabilidades pequeñas.

Después, claro, el fracaso se vuelve visible. Aparece en el cronograma, en el presupuesto, en las compras urgentes, en los comités tensos, en los correos con copia a demasiadas personas. La obra recibe el golpe y muchas veces también recibe la culpa. Pero la verdad es que algunos proyectos llegan a ejecución como pacientes que ya venían enfermos. La obra solo hace el diagnóstico imposible de ocultar.

El problema es que nos gusta creer que un proyecto comienza cuando se firma el contrato, cuando se instala el campamento, cuando se hace el acta de inicio o cuando entra la primera máquina. Es una idea práctica, incluso ceremonial. Nos da una fecha, una foto, un hito. Pero los proyectos, en realidad, empiezan antes. Empiezan cuando alguien decide qué se va a prometer, con qué información, bajo qué restricciones y con cuánto margen de honestidad.

Ahí, en esa etapa previa donde todo parece posible, se toman decisiones que después condicionan el destino completo del proyecto. Se define un plazo antes de entender la secuencia. Se defiende un presupuesto antes de reconocer los riesgos. Se vende un alcance antes de madurar el diseño. Se arma un equipo antes de saber qué capacidades se necesitan. Se habla de eficiencia antes de mirar la logística.

Un proyecto no fracasa antes de comenzar por una sola gran decisión equivocada. Casi nunca es tan dramático. Fracasa por acumulación. Por pequeñas decisiones que parecen razonables tomadas por separado y que forman, juntas, una trampa. Y cuando esa trampa se activa —y siempre se activa— la pregunta natural es ¿qué salió mal? La respuesta incómoda es que muchas cosas salieron mal mucho antes de que el proyecto empezara.

Una de las fuentes más comunes de fracaso temprano es la presión de aprobar. En muchos contextos organizacionales, un proyecto que 'no pasa' se percibe como un fracaso. Entonces, inconscientemente, el proceso de aprobación deja de ser un filtro y se convierte en un ejercicio de presentación. Los números se ajustan para que quepan. Los plazos se comprimen para que suenen competitivos. Los riesgos se mencionan brevemente para que parezca que se consideraron. Y el proyecto sale aprobado.

Pero aprobado no es lo mismo que viable. Un proyecto puede cruzar todas las instancias formales de revisión y llegar al campo sin los fundamentos necesarios para ejecutarse bien. Puede tener un acta firmada, un código de proyecto asignado, un presupuesto aprobado y una fecha comprometida, y aun así ser, en su esencia, un proyecto que todavía no ha terminado de diseñarse.

Hay otro patrón que se repite con sorprendente consistencia: la figura del optimismo estructural. Esa tendencia, casi inconsciente, a formular los supuestos del proyecto en su versión más favorable. El diseño estará listo. Los permisos saldrán en el tiempo habitual. El proveedor tendrá el material disponible. El subcontratista cumplirá su cronograma. La interventoría aprobará rápido. El cliente decidirá a tiempo.

Cada uno de esos supuestos, por separado, puede ser razonable. El problema es que un proyecto es un sistema interdependiente. Cuando cinco de esos supuestos se cumplen y dos no, el sistema puede aguantar. Cuando ocho se cumplen y uno falla en el lugar equivocado, el sistema colapsa. Y el optimismo estructural no está preparado para eso: asume condiciones favorables de manera consistente, sin reconocer que la probabilidad de que todo salga bien es matemáticamente pequeña.

Una señal clara de que un proyecto está en problemas desde antes de comenzar es la ausencia de una estrategia de ejecución. Hay una diferencia importante entre tener un cronograma y tener una estrategia. El cronograma dice cuándo. La estrategia dice cómo. Cuál es la lógica de la secuencia, cómo se manejan las interfaces entre especialidades, cómo se organizan los frentes, qué pasa si el proveedor principal falla, cómo se gestiona la curva de aprendizaje, quién decide qué.

Cuando esa estrategia no existe, el proyecto avanza como puede: de hito en hito, de urgencia en urgencia, improvisando en cada bifurcación. Y esa improvisación tiene un costo que no aparece en el presupuesto inicial, pero que se siente en cada semana de retraso, en cada orden de cambio, en cada conversación que debió haberse tenido seis meses antes.

También hay algo profundamente humano en todo esto. Los proyectos los hacen personas, y las personas tienen incentivos, miedos, ambiciones y puntos ciegos. A veces un proyecto nace de una buena idea pero se aprueba por razones que tienen poco que ver con su viabilidad. A veces el promotor tiene urgencia. A veces hay compromisos previos. A veces el contexto presiona hacia adelante aunque la evidencia no acompañe.

El antídoto no es el escepticismo permanente. Es la honestidad estructurada. Es crear espacios en los que sea posible —y seguro— decir que algo no está listo, que los riesgos son mayores de lo que aparece en la presentación, que el plazo requiere condiciones que todavía no se tienen. No para detener el proyecto, sino para formularlo con mayor precisión. Para que cuando llegue a la obra, llegue con los recursos, las definiciones y el tiempo que realmente necesita.

Un proyecto bien concebido llega a la ejecución con una especie de energía reservada. No porque todo esté resuelto —eso no es posible— sino porque los grandes interrogantes han sido formulados, los riesgos han sido reconocidos, las decisiones críticas tienen dueño y el equipo comparte una lectura honesta de lo que viene. Esa energía no se ve en un acta. Se siente en la calidad de las primeras semanas.

Los proyectos que fracasan antes de comenzar, en cambio, llegan a la obra con deudas ocultas. Deudas de diseño, de definición, de planificación, de comunicación. Y esas deudas se cobran. No todas el primer día, pero se cobran. Con retrasos que se acumulan, con costos que crecen, con equipos que se desgastan resolviendo problemas que debieron anticiparse.

La pregunta, entonces, no es solo cómo ejecutar mejor. Es cómo concebir mejor. Cómo crear las condiciones para que cuando un proyecto empiece, empiece de verdad. No como una promesa con fecha, sino como un sistema diseñado para avanzar. Porque los proyectos que se formulan bien no garantizan el éxito. Pero los que se formulan mal casi siempre garantizan el fracaso.

Carlos Riveros

Carlos Riveros

+20 años en proyectos · PMP · MBA · Fundador Project Leader Lab