Una frase popular reza: “Sueña con la Luna y alcanzarás las estrellas.”

Lo cierto es que la humanidad ha soñado con la Luna desde que el primer hombre —si es que hubo uno— alzó su mirada al cielo. Y ese anhelo, tan movilizador como sugiere la frase,  hoy lo sentimos más cerca gracias al éxito de la misión Artemis II de la NASA.

Sin embargo, soñar con la Luna es sencillo, alcanzarla no. El programa Artemis de la NASA es un esfuerzo mancomunado de las agencias espaciales de más de siete países; una inversión cercana a los cien mil millones de dólares; decenas de miles de personas trabajando entre técnicos, ingenieros, científicos y personal de administración; y un esfuerzo de ingeniería de dos décadas (la tecnología base fue validada en los 2010’s y el primer alunizaje se espera en 2027).

A diferencia del programa Apollo, el programa Artemis no busca sólo alcanzar la Luna, sino hacer de ella un trampolín hacia destinos lejanos, como por ejemplo Marte. En otras palabras, no es sólo pisar la Luna, sino crear allí la infraestructura logística que permita pegar aquél gran salto. Hacer esto posible, probablemente sea una de las integraciones sistémicas más exigentes de la ingeniería moderna. En este contexto, la complejidad técnica puede ser enorme, sin embargo, sin duda no es la única. 

Entendiendo la Complejidad

Los proyectos espaciales, devenidos luego en misiones espaciales, suelen ser terreno fértil para el desarrollo de situaciones complejas.

Para entenderlo, podemos definir una situación compleja como aquella en la que múltiples elementos interactúan de forma interdependiente, generando comportamientos que no pueden explicarse por la suma de sus partes. En este tipo de situaciones emergen la imprevisibilidad, la ambigüedad en la relación causa-efecto y dinámicas difíciles de anticipar.

Bajo estas condiciones, un proyecto complejo no es simplemente difícil: es inherentemente incierto en su planificación, ejecución y gestión. No resulta extraño, entonces, ubicar a iniciativas como el programa Artemis dentro de esta categoría.

Es importante aquí distinguir complejo de complicado: mientras que complicado puede entenderse como algo engorroso, trabajoso o difícil; complejo refiere a sistemas cuyo comportamiento emerge de interacciones que no son lineales ni evidentes.

Entonces, un proyecto complejo se distingue de otro complicado no por cuánto cuesta resolverlo, sino por cómo se comporta: la dificultad se puede reducir; la complejidad, en cambio, sólo puede gestionarse. Lo complicado exige capacidad. Lo complejo exige comprensión.

Sin embargo y a pesar de estas explicaciones, cuando nos encontramos participando en un proyecto complejo, la reacción natural e intuitiva frente a la incertidumbre que genera el estado de desconocimiento, es establecer más controles, sobrecontrolar. Cuando en realidad, el exceso de control no reduce la incertidumbre, sino que la desplaza, la oculta… y muchas veces, hasta la amplifica.

Los proyectos espaciales y sus complejidades

En mi pasaje por la industria del espacio he conocido de cerca aquello de gestionar la complejidad. En el equipo del proyecto SAOCOM (https://es.wikipedia.org/wiki/SAOCOM) trabajamos durante más de diez años desarrollando tecnología de punta para el sector tecnológico argentino. De hecho, los satélites SAOCOM 1A y 1B son - escribo en presente porque aún se encuentran en servicio- de los primeros de su tipo en el mundo. Se trata de un sistema satelital de dos satélites en órbita polar heliosincrónica a 620 km de altura dotados de un radar de apertura sintética (SAR) que permite observar la tierra independientemente de las condiciones meteorológicas, y además, con una composición tridimensional de las imágenes. Vale aquí mencionar que, antes de la irrupción tecnológica producida por este proyecto, Argentina no fabricaba sistemas de radar de ningún tipo.

Este desarrollo de tecnología,  especialmente en esta parte del mundo, dice mucho sobre la complejidad tecnológica asociada al sistema satelital en sí y al desarrollo de cada uno de sus componentes. La tecnológica, claro está, es una complejidad evidente. Pero detrás de ella, otros factores hacían del proyecto mucho más complejo todavía. 

La Complejidad Programática: La planificación y el control de las tareas del proyecto pesaban tanto y más que la gestión de la complejidad tecnológica: Programar la entrada y salida de cada empresa y organización participante del proyecto -de un total cercano a las cien-, en donde muchas de ellas a lo largo del proyecto cambiaban de rol entre cliente y proveedor, fue todo un desafío. De la misma manera, planificar las actividades en un diagrama de Gantt donde se encadenaban más de veinticuatro mil tareas y, además, mantenerlo bajo control a lo largo de diez años en medio de la incertidumbre de los resultados, fue un trabajo maratónico.

Sin embargo, la complejidad tecnológica y la programática no fueron las únicas que entraron en juego. Otras dimensiones de complejidad afectaban también constantemente al proyecto.

Desde una dimensión organizacional, la complejidad operativa jugaba un rol protagónico.  

Este tipo de complejidad refiere a la interdependencia entre los elementos operativos de la propia organización, y resulta que, a mayor grado de burocratización, mayor complejidad. Entonces, en un proyecto donde quien realiza gran parte de la ejecución es un organismo del Estado, este tipo de complejidad requería atención especial. 

Pero también, existía una complejidad desde la dimensión social, esa que encontramos en las interacciones entre las personas que son parte de un proyecto ambicioso, pero a la vez, agotador, en donde mantener la llama del entusiasmo por un periodo tan extenso es más que necesario, una obligación. En un contexto altamente exigente en cuanto a atención, desafíos y dedicación, convivíamos ingenieros de diferentes ramas, científicos, administrativos y burócratas, todos quienes debían mantener su interés por el proyecto y su entusiasmo a pesar de las vicisitudes técnicas, económicas, y del paso del tiempo. Porque sostener un proyecto así no depende solo de la ingeniería, sino de la capacidad de mantener sentido en el tiempo. No sólo se pone a prueba el conocimiento, sino también la cohesión.

Lo cierto es que, existen handbooks y cuerpos normativos que guían el desarrollo de sistemas espaciales, tanto en el área tecnológica como en la organización de sus proyectos. Sin embargo, poco se encuentra en aquellos documentos sobre cómo navegar la complejidad. La alternativa fue aprender de pensadores como Peter Senge, Ralph Stacey y Dave Snowden, entre otros, y por supuesto, el método de prueba y error. 

Más Allá de la Ingeniería

Con el tiempo, aprendí que ninguna organización falla por lo que no sabe, sino por lo que no logra alinear. Que la verdadera misión no era solo tecnológica, sino convivir sin fragmentarnos. Que no alcanza con descomponer sistemas en partes más pequeñas para poder controlarlos, si luego no somos capaces de recomponer el todo con propósito.

En proyectos como SAOCOM, el aprendizaje no estuvo solo en dominar tecnologías que no existían en el país, sino en algo menos visible y más difícil de replicar: aprender a coordinar lo diverso sin anularlo, a sostener el rumbo cuando la incertidumbre se vuelve norma, y a aceptar que el control absoluto es, en el mejor de los casos, una ilusión útil. 

Cuando entendí que la organización del proyecto era un sistema, que no dependía de cada componente por separado, sino de cuánto somos capaces de hacer que todos ellos —personas, procesos y tecnología— converjan en el mismo momento y en la misma dirección, me convencí que más que un logro técnico, la experiencia fue un aprendizaje organizacional.

 

A popular saying goes: “Reach for the Moon and you’ll land you’ll land among the stars”. 

Humanity has dreamed of the Moon ever since the first human being—if there ever was one—lifted their gaze to the sky. And that longing, as inspiring as the phrase suggests, feels closer today thanks to the success of NASA’s Artemis II mission.

However, dreaming of the Moon is easy; reaching it is not. NASA’s Artemis program is a joint effort involving space agencies from more than seven countries; an investment approaching one hundred billion dollars; tens of thousands of people working across technical, engineering, scientific, and administrative roles; and a two-decade engineering endeavor (the foundational technology was validated in the 2010s, and the first lunar landing is expected in 2027).

Unlike the Apollo program, Artemis does not aim merely to reach the Moon, but to turn it into a springboard toward more distant destinations, such as Mars. In other words, it is not just about setting foot on the Moon, but about creating the logistical infrastructure there to enable that next giant leap. Making this possible is likely one of the most demanding systemic integrations in modern engineering. In this context, technical complexity may be enormous, but it is certainly not the only kind.

Understanding Complexity

Space projects, which later become space missions, are often fertile ground for the emergence of complex situations.

To understand this, we can define a complex situation as one in which multiple elements interact interdependently, generating behaviors that cannot be explained simply by the sum of their parts. In these situations, unpredictability emerges, cause-and-effect relationships become ambiguous, and dynamics become difficult to anticipate.

Under these conditions, a complex project is not merely difficult: it is inherently uncertain in its planning, execution, and management. It is therefore no surprise that initiatives such as the Artemis program fall into this category.

It is important here to distinguish complex from complicated: while something complicated may be cumbersome, laborious, or difficult, complexity refers to systems whose behavior emerges from interactions that are neither linear nor obvious.

Thus, what distinguishes a complex project from a complicated one is not how hard it is to solve, but how it behaves: difficulty can be reduced; complexity, by contrast, can only be managed. The complicated demands capability. The complex demands understanding.

Yet despite these explanations, when we find ourselves participating in a complex project, the natural and intuitive reaction to the uncertainty generated by the unknown is to impose more controls—to overcontrol. In reality, excessive control does not reduce uncertainty; it merely displaces it, conceals it, and often even amplifies it.

Space Projects and Their Complexities

During my time in the space industry, I came to understand firsthand what it means to manage complexity. As part of the SAOCOM (https://es.wikipedia.org/wiki/SAOCOM) project team, we spent more than ten years developing cutting-edge technology for Argentina’s technological sector.

In fact, the SAOCOM 1A and 1B satellites are—I write this in the present tense because they are still in operation—among the first of their kind in the world. They form a satellite system composed of two satellites in sun-synchronous polar orbit at an altitude of 620 kilometers, equipped with synthetic aperture radar (SAR), which allows observation of the Earth regardless of weather conditions and providing three-dimensional image composition. It is worth noting that before the technological breakthrough produced by this project, Argentina did not manufacture radar systems of any kind.

This technological development, particularly in this part of the world, says much about the technological complexity associated both with the satellite system itself and with the development of each of its components. Technological complexity is, of course, the most visible kind. But behind it lay other factors that made the project even more complex.

Programmatic Complexity: Project planning and task control weighed as heavily as—if not more heavily than—the management of technological complexity: Scheduling the entry and exit of every participating company and organization—nearly one hundred in total—many of which shifted roles between client and supplier throughout the project, was an enormous challenge. Likewise, planning activities in a Gantt chart containing more than twenty-four thousand interlinked tasks and then keeping it under control over ten years amid uncertain outcomes, was a marathon effort.

Yet technological and programmatic complexity were not the only dimensions at play. Other forms of complexity constantly affected the project as well.

From an organizational perspective, operational complexity played a leading role.

 This type of complexity refers to the interdependence among an organization’s operational elements, and the greater the level of bureaucratization, the greater the complexity. In a project where much of the execution is carried out by a state agency, this kind of complexity required special attention.

There was also a social dimension of complexity—the one found in the interactions among people who are part of a project that is both ambitious and exhausting, where keeping the flame of enthusiasm alive over such an extended period is not just important, but essential. In a context that demanded extraordinary levels of focus, commitment, and resilience, engineers from different disciplines, scientists, administrators, and bureaucrats all had to maintain their engagement and enthusiasm despite technical setbacks, economic difficulties, and the passage of time. Because sustaining a project like this depends not only on engineering, but on the ability to preserve meaning over time. What is tested is not only knowledge, but cohesion.

The truth is that there are handbooks and regulatory frameworks that guide the development of space systems, both technologically and organizationally. Yet those documents offer little guidance on how to navigate complexity itself. The alternative was to learn from thinkers such as Peter Senge, Ralph Stacey, and Dave Snowden, among others—and, of course, through trial and error.

Beyond Engineering

Over time, I learned that no organization fails because of what it does not know, but because of what it fails to align. I learned that the real mission was not merely technological, but learning how to coexist without fragmenting. That it is not enough to break systems down into smaller parts in order to control them, if we are then unable to reassemble the whole with purpose.

In projects like SAOCOM, the greatest learning was not only mastering technologies that did not previously exist in the country, but something less visible and far harder to replicate: learning how to coordinate diversity without suppressing it, how to stay the course when uncertainty becomes the norm, and how to accept that absolute control is, at best, a useful illusion.

When I came to understand that the project organization itself was a system—that it did not depend on each component in isolation, but on our ability to make all of them—people, processes, and technology—converge at the same moment and in the same direction, I became convinced that more than a technical achievement, the experience was a lesson in organizational learning.

Acerca del autor:
Pablo Quintela es un ingeniero industrial argentino. Formó parte del equipo del proyecto SAOCOM de la agencia espacial argentina (CONAE) entre los años 2011 y 2021, a cargo de la Project Management Office (PMO). Actualmente se desempeña como consultor de negocios.

About the author
Pablo Quintela is an Argentine industrial engineer. He was part of the CONAE (Argentine Space Agency) SAOCOM Project team from 2011 to 2021, where he was in charge of the Project Management Office (PMO). He currently works as a business consultant.