La queja persistente sobre los proyectos de TI no es que fracasen por completo, aunque algunos lo hagan. Es que no logran ser predecibles. Un programa que termina con seis meses de retraso y un cuarenta por ciento por encima del presupuesto es perjudicial, pero una cartera en la que cualquier proyecto podría terminar a tiempo o podría retrasarse un año, sin una forma fiable de saber cuál de las dos cosas por anticipado, resulta corrosiva de una manera distinta. Hace imposible la planificación a escala de negocio. Enseña a los directivos a inflar cada estimación y a descontar cada compromiso, lo que a su vez enseña a los equipos de entrega que las estimaciones son puro teatro. El sistema entero se desliza hacia un equilibrio de baja confianza en el que nadie cree en el plan y todos se protegen a sí mismos.

Esto importa más ahora que hace una década por una razón concreta. El cambio en TI ya no es un acontecimiento aislado que la empresa absorbe de forma ocasional. Es continuo, y está entrelazado con los ingresos, la regulación y la experiencia del cliente de maneras que dejan poco margen. Cuando se retrasa la migración de un sistema bancario central, o se estanca una consolidación de ERP, las consecuencias no se limitan a una partida del presupuesto de TI. Se propagan hacia los compromisos comerciales, los plazos de cumplimiento y la credibilidad del liderazgo que patrocinó el trabajo. El coste de la imprevisibilidad ha aumentado incluso allí donde no lo ha hecho el coste de un fracaso individual.

La verdad incómoda es que buena parte de la imprevisibilidad se fabrica desde el principio, antes de que se escriba una línea de código o se aprovisione un servidor. Se fabrica al tratar la estimación como una negociación, al comprometerse con un alcance que nunca se entendió de verdad y al adoptar un enfoque de entrega elegido por comodidad cultural en lugar de por la naturaleza real del trabajo. La predecibilidad viene determinada en gran medida por decisiones tomadas cuando el proyecto todavía es barato de moldear. Ahí es donde tiene que empezar la disciplina.

La decisión fundamental en cualquier proyecto de TI no es qué marco de trabajo adoptar. Es un diagnóstico de dónde reside la incertidumbre. A grandes rasgos, la incertidumbre en la entrega adopta dos formas, y exigen respuestas opuestas. La primera es la incertidumbre de ejecución: sabemos con precisión qué necesitamos construir, pero construirlo es una tarea grande, compleja o arriesgada. La segunda es la incertidumbre de requisitos: podríamos construirlo con competencia si tan solo supiéramos qué es, pero la respuesta correcta solo se aclarará a través de la retroalimentación del uso real. Confundir ambas es el origen de la mayor parte de los fracasos relacionados con el método.

Cuando la incertidumbre dominante es de ejecución y el requisito es genuinamente estable, la entrega dirigida por planes no es una reliquia por la que haya que disculparse. Es la herramienta correcta. La migración de un centro de datos, un cambio en la elaboración de informes regulatorios con una especificación legal fija, o el despliegue de un paquete bien conocido en nuevos emplazamientos tienen todos un alcance conocible y se benefician enormemente de una secuenciación previa detallada, del mapeo de dependencias y de la gestión de la ruta crítica. Fingir que ese trabajo es un viaje de descubrimiento desperdicia la única ventaja que ofrece, que es la capacidad de planificarlo como es debido.

Cuando la incertidumbre dominante es de requisitos, el enfoque dirigido por planes se vuelve activamente perjudicial, porque fuerza un compromiso prematuro con decisiones que deberían permanecer abiertas. Aquí la entrega adaptativa se gana su lugar: ciclos cortos, incrementos operativos y un contacto frecuente con usuarios reales convierten las incógnitas en certezas al ritmo sostenible más rápido posible. El objetivo de la iteración no es la velocidad por sí misma. Es la retirada sistemática del riesgo de requisitos. Un equipo que itera pero que nunca confronta sus incrementos con una retroalimentación genuina de los usuarios ha adoptado la ceremonia sin el mecanismo, y no gana nada.

La posición honesta, y la que este artículo defiende, es que la mayoría de los programas de envergadura contienen ambos tipos de incertidumbre en distintas proporciones a lo largo de sus componentes. El juicio maduro no consiste en declarar que todo el conjunto es ágil o waterfall, sino en descomponerlo, aplicar el rigor dirigido por planes allí donde el alcance es estable y el descubrimiento adaptativo allí donde no lo es, y gestionar deliberadamente la costura entre ambos. Esa costura es donde reside la verdadera habilidad.

Varios desarrollos han reconfigurado la gestión de proyectos de TI en los últimos años, y conviene separar lo sustancial de lo pasajero. Lo más sustancial es el paso del pensamiento de proyecto al pensamiento de producto en las partes del panorama de TI que son de larga vida. Una plataforma de pagos o un portal de clientes no es un proyecto que termina; es un producto que perdura, financiado de forma continua y con la propiedad de un equipo estable. Para esa clase de trabajo, la construcción de proyecto, con su fecha de finalización fija y la dispersión del equipo al completarse, se ha convertido en un lastre activo, porque optimiza para la entrega de resultados en lugar de para la propiedad sostenida que mantiene sano el software.

Al mismo tiempo, y en cierta tensión con el movimiento de producto, se ha formalizado la disciplina de gestionar dependencias a escala. A medida que las organizaciones ejecutan decenas de equipos sobre una arquitectura compartida, la restricción determinante para la entrega rara vez es la productividad de un único equipo. Es el coste de coordinación entre ellos: los servicios compartidos, la secuenciación de las integraciones, las capacidades de plataforma de las que dependen múltiples flujos. Los marcos de entrega a escala son, en su núcleo útil, un intento de hacer visibles estas dependencias entre equipos y de programarlas antes de que se conviertan en la razón por la que todos están bloqueados.

Un tercer cambio es la maduración de la entrega continua y la automatización del camino hacia producción. Cuando desplegar un cambio es un acontecimiento raro, manual y de alto riesgo, la economía empuja hacia lotes grandes y ciclos de publicación largos, lo que a su vez empuja hacia una planificación previa pesada. Cuando el despliegue está automatizado, probado y es rutinario, los pequeños incrementos se vuelven baratos de publicar, y todo el ritmo de la entrega puede desplazarse hacia la retroalimentación frecuente de la que depende el trabajo adaptativo. Buena parte de lo que se atribuye a la metodología es en realidad una consecuencia de esta capacidad de ingeniería. Un equipo no puede iterar de forma significativa hacia el valor si solo puede publicar dos veces al año, con independencia del marco que esté escrito en la pared.

La entrega predecible es tanto una propiedad de cómo se estructura el trabajo como de cómo se gestiona. La palanca más poderosa es la descomposición en incrementos que entreguen cada uno algo demostrable y, idealmente, algo utilizable. Esto no es una fineza de administración de proyectos. Un incremento que produce software operativo obliga a responder las preguntas de integración y prueba de forma temprana y repetida, en lugar de aplazarlas a una fase final donde detonan todas a la vez. El fracaso clásico de la integración big-bang, en la que se combinan al final meses de componentes construidos por separado y se descubre que no encajan, es un fracaso de diseño de incrementos antes que un fracaso de gestión.

La arquitectura de dependencias es el segundo principio. Cada dependencia entre equipos, sistemas o proveedores es una restricción de planificación y un riesgo. Un buen diseño de entrega trabaja para minimizarlas y secuenciarlas deliberadamente: identificando qué componentes están en la ruta crítica, qué capacidades compartidas deben existir antes de que pueda empezar el trabajo dependiente, y qué compromisos externos, como un entregable de un proveedor o una aprobación regulatoria, quedan fuera del control del equipo y por tanto necesitan la atención más temprana y el margen más conservador. Las dependencias que se descubren tarde son las más caras, porque para cuando afloran las opciones para resolverlas se han estrechado.

El tercer principio es diseñar para la reversibilidad allí donde el requisito es incierto y para la robustez allí donde está asentado. Las decisiones que son baratas de revertir pueden tomarse con rapidez y revisarse a la luz de la retroalimentación; las decisiones que son caras de revertir, como un modelo de datos en el corazón del sistema o la elección de una plataforma de la que todo lo demás dependerá, merecen un escrutinio desproporcionado antes de fijarse. Un proyecto bien gestionado invierte su análisis cuidadoso allí donde la reversión es costosa y avanza rápido allí donde no lo es, en lugar de aplicar una ceremonia uniforme a cada elección. Confundir ambas, angustiarse por lo trivial mientras se precipita lo irreversible, es una causa común y silenciosa de problemas.

Expansión del alcance disfrazada de flexibilidad. La entrega adaptativa se usa mal con frecuencia como una licencia para no fijar nunca el alcance. La iteración genuina afina la solución hacia una meta estable; el cambio indisciplinado sustituye una meta por otra cada pocas semanas y lo llama capacidad de respuesta. La distinción está en si los cambios convergen. Un proyecto en el que cada ciclo acerca el resultado a un objetivo coherente está aprendiendo. Un proyecto en el que cada ciclo añade un nuevo objetivo no está gestionando el alcance, lo está abandonando, y no terminará.

El informe de estado sandía. Verde por fuera, rojo por dentro. Es el producto natural de juzgar los proyectos por los hitos superados en lugar de por el software operativo y el valor materializado. Cuando la métrica es el porcentaje de tareas completadas, un equipo puede informar de un noventa por ciento durante meses mientras el diez por ciento difícil, integrador y portador de valor permanece intacto. El remedio no es una mejor disciplina de reporte. Es cambiar lo que se mide, de modo que el progreso signifique incrementos demostrables, probados y utilizables en lugar de actividad frente a un plan.

Negación de las dependencias. Los equipos planifican su propio trabajo con esmero y tratan todo lo que queda fuera de su frontera como un problema ajeno que se resolverá solo a tiempo. Rara vez lo hace. Las dependencias que un proyecto no posee son precisamente las que más probablemente se retrasarán, y las que un equipo está menos capacitado para acelerar cuando lo hacen. Hacer explícitas las dependencias externas, asignarles responsables y dotarlas de un margen realista es un trabajo poco vistoso que separa los programas que respetan sus fechas de los que no.

Ambigüedad de las partes interesadas. Muchos proyectos funcionan durante meses sin una respuesta clara a quién decide realmente. Cuando el patrocinador, los usuarios y quienes financian quieren cosas sutilmente distintas y ningún responsable único los reconcilia, el proyecto absorbe el conflicto como agitación, relitigando decisiones ya cerradas y sin contentar a nadie. La claridad sobre quién posee el resultado, a quién hay que consultar y a quién simplemente informar no es burocracia. Es el mecanismo por el cual un proyecto puede realmente tomar decisiones y mantenerlas.

La estimación como compromiso. Una estimación es una afirmación probabilística sobre un futuro incierto. En el momento en que se trata como una promesa, deja de ser honesta, porque la estimación más segura de prometer es la inflada, y el inflado destruye la información que la estimación estaba destinada a transportar. Una entrega saludable mantiene separadas la estimación y el compromiso: las estimaciones informan la planificación con franqueza, y los compromisos se adquieren de forma deliberada, reconociendo la incertidumbre en lugar de negociarla hasta hacerla desaparecer.

El enfoque de Nashua respecto a la gestión de proyectos de TI comienza por el diagnóstico y no por el método. Antes de recomendar cualquier modelo de entrega, trabajamos para establecer dónde reside realmente la incertidumbre de un programa dado, componente a componente, porque esa lectura determina todo lo que viene después. Es un trabajo deliberadamente poco de moda. Resiste el impulso de declarar una única metodología para todo el panorama y en su lugar acepta que un programa puede necesitar rigor dirigido por planes para su núcleo estable y cargado de dependencias, y descubrimiento adaptativo para las partes en las que aún se están aprendiendo los requisitos. Gestionamos la costura entre esos modos como una preocupación de primer orden y no como una idea de última hora.

En la ejecución nos atenemos a un pequeño número de disciplinas innegociables. Los incrementos se diseñan para producir software operativo y probado de forma temprana y frecuente, de modo que el riesgo de integración se afronte de manera continua en lugar de aplazarse. Las dependencias, especialmente las que quedan fuera del control del equipo, se hacen explícitas, se les asigna responsable y se dotan de margen desde el principio. El alcance se gestiona frente a un objetivo coherente, dando la bienvenida al cambio cuando converge hacia ese objetivo y cuestionándolo cuando simplemente lo agranda. Y mantenemos la estimación honesta separándola del compromiso, de modo que los planes transporten información real en lugar de un margen defensivo. Por encima de todo, juzgamos el progreso por el software operativo demostrable y la evidencia del valor materializado, no por el recuento de hitos superados, porque lo segundo es fácil de fingir y lo primero no lo es.

También nos tomamos en serio la arquitectura humana de un proyecto: establecer quién posee el resultado, quién decide y cómo se mantienen esas decisiones. Buena parte de lo que parece un fracaso de entrega es en realidad una ambigüedad no resuelta de las partes interesadas expresada como agitación, y tratamos la clarificación de la responsabilidad como un trabajo de entrega de primer orden y no como una carga de gobernanza que haya que minimizar.

La diferencia que aporta Nashua no es un método propietario que prometa hacer desaparecer la incertidumbre. No existe tal método, y las firmas que afirman lo contrario venden tranquilidad en lugar de entrega. La diferencia es el juicio aplicado de forma consistente: la disposición a diagnosticar con honestidad, a elegir la entrega dirigida por planes y la adaptativa por sus méritos y no por la moda, a hacer visibles las dependencias y la responsabilidad antes de que se conviertan en excusas, e insistir en todo momento en que un proyecto vale lo que pone en manos de los usuarios y lo que materializa en valor, no lo que reporta frente a un plan. Ese juicio es fruto de haber entregado suficientes programas como para saber dónde salen realmente mal.

Hay además un corolario práctico que cambia lo que el trabajo tiene permitido dar por supuesto. Cuando un encargo exige una capacidad que aún no existe, no tiene por qué esperar a un ciclo de compras ni a la hoja de ruta de un proveedor. La Nashua 360 Enterprise Platform está construida para acomodar casi cualquier funcionalidad a buen ritmo, mediante extreme vibe coding: lo que se necesita se describe en lenguaje llano y se genera con rapidez, pero siempre dentro de principios de arquitectura firmes y bajo un aseguramiento de calidad estricto, de modo que la velocidad nunca se logre a costa de la coherencia, la seguridad o el control. El efecto es estratégico y no meramente cómodo. Desplaza la frontera entre hacer y comprar, mantiene barata la opcionalidad y deja que la arquitectura siga a la estrategia en lugar de que la estrategia se pliegue a lo que hubiera disponible en la estantería.

Lo que une todo esto es la negativa a permitir que la entrega se convierta en teatro. Es sencillo ejecutar un proyecto que parece bien gestionado, genera informes confiados y satisface cada punto de control de gobernanza mientras fracasa en silencio a la hora de producir algo de valor. Es mucho más difícil, y mucho más raro, ejecutar uno que se mantenga honesto sobre su incertidumbre, afronte sus riesgos de forma temprana, mantenga su alcance convergiendo y se mida frente a resultados operativos. Ese camino más difícil es el que Nashua se compromete a recorrer, porque es el único que hace el cambio de TI genuinamente predecible y no simplemente bien documentado. Las organizaciones con las que trabajamos aprenden a confiar no en la promesa de que nada saldrá mal, sino en la certeza de que, cuando algo salga mal, se verá pronto, se nombrará con claridad y se abordará mientras todavía sea barato de arreglar.