La NASA diseña una misión completa en semanas. ¿Por qué nuestros proyectos tardan semanas solo en tomar una decisión?

Sandro Paredes SchmidtDirector de Metodologías Colaborativas y VDC · 28 de septiembre de 2026

Detectamos una incompatibilidad en obra. La reportamos. Esperamos tres semanas. Y cuando llega la respuesta, no resuelve el problema.

Mientras tanto, en la obra tenemos: un frente de trabajo sin atender, trabajo en proceso detenido, una cuadrilla esperando para volver a producir.

Eso tiene un nombre: latencia, el tiempo que pasa entre que surge una pregunta y llega una respuesta que permite avanzar. Y el costo de no tratarla se traslada al plazo, al presupuesto y a la motivación del equipo.

Ahora pensemos en otro tipo de proyecto, mucho más complejo: una misión espacial.

En el Jet Propulsion Laboratory (JPL) de la NASA existe un equipo llamado "Team X", dedicado a diseñar propuestas de misiones espaciales. Investigadores de Stanford que lo estudiaron a inicios de los 2000 reportaron que Team X había reducido tareas que tomaban entre tres y nueve meses a solo unos pocos días.

En el proyecto que observaron, el plan era completar el diseño en cuatro semanas. La primera, un grupo de ingenieros definió los requisitos y el diseño de la misión con un representante del cliente. En la segunda, todo el equipo se reunió en solo tres sesiones de tres horas. Las dos últimas se dedicaron a completar la documentación.

Nueve horas de sesión en un plan de cuatro semanas. La sesión no era un espacio en el que se juntaban a discutir y "revisar" información solamente, era el momento en que todo lo preparado con antelación generaba decisiones de impacto para el rumbo del proyecto.

¿Cómo hubieran podido lograr esa meta con los tiempos de respuesta que manejamos en la industria de la construcción?

En Team X, una pregunta se respondía en menos de un minuto; en un equipo tradicional, la misma respuesta podía tardar varios días. Con una meta de diseñar la misión en menos de 500 horas-hombre, una demora como la que vivimos en nuestros proyectos habría hecho ese objetivo prácticamente imposible.

Team X no era más eficiente porque trabajaba más, sino porque esperaba menos.

En construcción solemos decir que ya aplicamos ICE (Integrated Concurrent Engineering) porque tenemos reuniones periódicas para abordar distintas problemáticas. Reuniones que, muchas veces, no logran resultados.

Ahí está el problema: no hacemos ICE. Intentamos hacer sesiones ICE. Y digo "intentamos" porque, por moda, hemos empezado a llamar sesión ICE a cualquier reunión en la que participan varios especialistas.

Esa confusión explica buena parte del rechazo que las sesiones ICE todavía generan en muchos profesionales del sector: se perciben como "una reunión más" en una agenda que ya está "bastante cargada".

Y no caemos en cuenta de lo esencial: ICE va más allá de la sesión.

Si volvemos a Team X, la sesión ocupaba apenas nueve horas de un plan de cuatro semanas. El resto del tiempo se dedicaba a preparar lo que se iba a decidir y a completar lo que se había decidido.

Ese es el criterio propuesto en el framework a continuación. Tres de ellas recogen lo que hacía el equipo del JPL: preparar, sesionar y dar seguimiento; junto con la identificación del reto, para que la sesión tenga foco, y la medición, para que cada ciclo produzca una mejora:

1. Identificación: definir el reto y los actores

En la fase de Identificación se elige un reto concreto, se convoca a quienes tienen la información y la autoridad técnica para resolverlo, y se distingue qué tipo de trabajo implica.

James Thompson distinguía tres tipos de interdependencia: compartida, cuando las áreas solo comparten recursos; secuencial, cuando el trabajo de una alimenta al de la siguiente; y recíproca, cuando las decisiones de cada área cambian las de la otra en ambas direcciones.

Las dos primeras se coordinan con procedimientos y un buen plan, y pueden resolverse antes o después de la sesión, en las fases de Pre-sesión ICE y Seguimiento. La tercera no: exige que las partes se ajusten entre sí, al mismo tiempo. Ese es el trabajo que se lleva a la sesión.

2. Pre-sesión ICE: construir la información antes de la sesión

Es el equivalente a la semana de preparación de Team X. Cada participante debe llegar con su parte resuelta; si no, cada pregunta en la sala vuelve a tener días de latencia.

Quizás esta sea la fase más importante para lograr una verdadera ingeniería concurrente integrada, porque aparece una nueva pregunta: ¿cómo construimos la información de manera más eficiente?

Para responderla, podemos recurrir a la co-ubicación (co-location) o a rutinas de reuniones ajustadas al nivel de desarrollo que se requiera. En general, se trata de cuidar todos los factores del contexto que permiten que las personas correctas se conecten de la manera adecuada para producir el resultado esperado.

Aquí también entran los objetivos de producción y los factores controlables de VDC. Son los que nos permiten medir el avance y ajustar la dirección del velero a tiempo, para que todos lleguen a la sesión con la información construida o, si se trata de trabajo secuencial o compartido, con la solución ya decidida.

3. Sesión ICE: integrar y decidir en tiempo real

La sesión no es para revisar información, sino para integrarla y convertirla en decisiones. Por eso se reserva para el trabajo recíprocamente interdependiente: aquello que necesita a varias disciplinas ajustándose al mismo tiempo.

Para que la sesión sea eficiente, necesita condiciones mínimas: una agenda clara, definida en la fase anterior; un espacio físico, virtual o híbrido que favorezca el trabajo concurrente, con la información visible para todos; y métricas de desempeño de la propia sesión, como el número de decisiones tomadas o el tiempo de respuesta a las consultas.

Para lograrlo sin saturar agendas, podemos trabajar con un modelo acordeón: un núcleo de participantes permanece durante toda la sesión, mientras que otros especialistas se incorporan solo en el bloque que requiere su conocimiento y luego se retiran. La sesión se expande cuando el problema lo exige y se contrae cuando ya no.

Así evitamos tener a personas sentadas horas esperando su tema, que es otra forma de latencia, o no tener a la persona clave en el momento en que se necesita su decisión.

4. Seguimiento: cumplir acuerdos y cerrar pendientes

Una decisión sin responsable ni fecha no es una decisión. Aquí se asegura que lo acordado se ejecute.

El facilitador, o la persona encargada de la integración, debe velar por el seguimiento, porque una decisión que no se concreta puede ser incluso más perjudicial que una pregunta que nunca se respondió.

Por ejemplo, si en la sesión se acuerda un cambio de trazo y Oficina Técnica lo incorpora al plan de trabajo, pero ingeniería nunca emite el plano actualizado, la cuadrilla termina ejecutando con información vieja o esperando otra vez.

Hay además un costo menos visible: la credibilidad. Cada acuerdo incumplido le da la razón a quien piensa que la sesión ICE es "una reunión más".

Por eso, al cierre de cada sesión, cada acuerdo debe quedar registrado con un responsable, una fecha y un entregable concreto, y compartirse ese mismo día. La siguiente sesión puede empezar revisando qué se cumplió y qué no, y por qué. Ese porcentaje de acuerdos cumplidos se convierte, además, en una de las métricas de la siguiente fase.

5. Medición: evaluar el impacto y corregir

¿Se redujo la latencia? ¿Se resolvió el reto? Lo aprendido alimenta la identificación del siguiente ciclo.

Es normal tener sesiones poco exitosas. Como en toda implementación, en la sesión participan y deciden personas (por ahora), y el error siempre es una posibilidad. El problema no es equivocarse, sino tropezar dos veces con la misma piedra.

Por eso el ciclo debe cerrar midiendo. No basta con preguntar si la sesión "salió bien"; hay que responder con datos, que podemos obtener al responder una serie de preguntas como: ¿Cuánto tardamos en responder las consultas críticas, antes y después de la sesión? ¿Cuántas decisiones se tomaron y cuántas se reabrieron después? ¿Qué porcentaje de los acuerdos se cumplió en la fecha comprometida?

Con esas respuestas, el equipo puede identificar qué generó latencia: ¿faltó información en Pre-sesión ICE?, ¿no estaba la persona con la autoridad técnica?, ¿el reto no era realmente recíproco?

El ciclo es iterativo, cada vuelta debe terminar con un ajuste concreto en los factores que nos permiten reducir la latencia. Así, la siguiente sesión no empieza de cero, sino un paso más adelante.

Volvamos a la incompatibilidad del inicio. Tres semanas de espera y una respuesta que no resolvía el problema. Con ICE, esa consulta se habría preparado con la información de todas las áreas, se habría resuelto en una sesión con quienes debían decidir juntos y se habría seguido hasta que el plano llegara a la cuadrilla. No en tres semanas, sino en días.

ICE va más allá de la sesión.

Publicado originalmente en LinkedIn.