La ejecución no es el proyecto

Cuando una empresa inicia un proyecto tecnológico, casi siempre lo hace desde la ejecución.

“Necesitamos desarrollar esto.”
“Queremos implantar esta herramienta.”
“Hay que automatizar este proceso.”

Y es lógico.

La ejecución es la parte visible.
La que se puede presupuestar.
La que tiene entregables claros.

Pero la ejecución no es el proyecto.

Es solo una fase.

Y rara vez es la más determinante.

Antes de ejecutar: alineación

Todo proyecto nace de una percepción de problema.

Pero no siempre esa percepción es compartida.

En muchas organizaciones conviven miradas distintas sobre lo que está ocurriendo:

• Para unos, el problema es eficiencia.

• Para otros, es control.

• Para otros, es crecimiento.

• Para otros, es dependencia de personas clave.

Si no se detiene el proceso aquí, el desarrollo empezará sobre una base inestable.

La consecuencia no suele ser un fracaso técnico.

Suele ser algo más sutil:
una solución que funciona… pero no resuelve lo esencial.

Antes de desarrollar: criterio

Una vez que hay alineación sobre el problema, aparece otra pregunta clave:

¿Estamos preparados para sostener la herramienta que queremos implantar?

Desarrollar no es solo definir funcionalidades.

Es asumir que aquello que antes era flexible, implícito o informal, pasará a estar formalizado.

Cuando se implanta un sistema, ya no vale “más o menos”.
Hay que decidir.
Hay que completar.
Hay que validar.

El sistema no admite ambigüedad operativa.

Y cuando esto no se dimensiona correctamente, aparece lo que llamamos el síndrome del software vacío.

No es que el proyecto esté mal hecho.

El alcance se cumple.
La herramienta funciona.
La arquitectura es correcta.

Pero no puede ponerse en marcha.

No porque falle el desarrollo,
sino porque el sistema exige una consistencia operativa que la organización todavía no ha asumido.

La herramienta necesita datos reales.
Necesita criterios definidos.
Necesita responsables claros.

Si esa estructura no existe, el sistema queda ahí.

Correcto.
Terminado.
Pero vacío.

La ejecución: necesaria, pero no suficiente

Solo después de haber trabajado alineación y criterio, la ejecución tiene solidez.

En esta fase se diseñan procesos, se desarrollan herramientas y se integran sistemas.

Es una parte imprescindible.

Pero conviene entender algo importante:

El desarrollo no cuestiona el fondo (salvo que se haya trabajado antes).

La ejecución formaliza lo que ya existe.

Si se adelanta, puede sofisticar la confusión en lugar de resolverla.

Porque cuando se implementa una solución, se fijan decisiones, criterios y prioridades.

Y la ejecución amplifica lo que encuentra.

Si el problema está claro, lo mejora.
Si no lo está, lo consolida.

Después de implantar: impacto operativo

Un proyecto no termina cuando el sistema funciona.

Termina cuando el sistema se integra en la operación real.

Eso significa algo muy concreto:

• Que se utiliza de forma consistente.

• Que sustituye procesos anteriores.

• Que se convierte en fuente de decisión.

• Que reduce fricción operativa.

No todo software cambia la cultura.
Pero todo software que aporta valor modifica, al menos, una parte del funcionamiento.

Si, después de implantarlo, la organización sigue operando exactamente igual y el sistema se convierte en algo accesorio, entonces no se ha integrado.

Se ha instalado.

Y no es lo mismo instalar que integrar.

El proyecto completo

Un proyecto tecnológico completo no empieza con código
ni termina con una implantación.

Tiene, al menos, cuatro dimensiones:

1. Alineación

2. Criterio

3. Ejecución

4. Integración

Reducirlo solo a la tercera es comprensible.

Pero es incompleto.

Y lo incompleto, en decisiones estratégicas, suele salir caro.