The Playbook They Already Wrote: Artemis, Apollo, and the Art of Not Reinventing Everything

I have spent thirty years watching large, complex, expensive projects unfold, and I have noticed a pattern. The pattern is this: at some point in the planning phase, someone in the room decides that the most important thing they can do is make everything different from whatever was done before. Not better, specifically. Different. New. Unencumbered by the timid conservatism of prior approaches, which were, after all, designed by people who didn't have the benefit of knowing what they now know, which is that everything should be different.

This instinct is understandable. It is also, in my experience, approximately as reliable a predictor of project outcomes as reading the entrails of a particularly confused goat.

I have been reading about the Artemis programme. Not casually, in the way one reads about space missions between emails, but with the specific attention of someone who has spent a career delivering large technology programmes and keeps noticing familiar patterns in unfamiliar places. Three things have emerged from this reading that I think every IT leader should know about, not because they work in aerospace, but because the mistakes are perfectly general and the lessons are freely available, in writing, from people who learned them by going to the Moon.

Problem One: The Rocket That Requires Eight Rockets

The Artemis Human Landing System is a modified version of SpaceX's Starship. It uses cryogenic propellants: liquid oxygen and liquid methane, kept at temperatures that would make a sensible material reconsider its decision to remain liquid. Getting enough of this propellant from Earth's surface to the point where Starship can actually depart for the Moon requires, due to the constraints of physics and the limitations of what any single launch can carry, fuelling the vehicle in Low Earth Orbit using propellant delivered by separate launches.

How many separate launches? The honest answer, once you account for propellant boil-off (cryogenic fluids in space have an unfortunate tendency to stop being liquid if you look at them wrong), schedule uncertainties, and the general enthusiasm of reality for exceeding estimates, is somewhere between eight and twelve. Possibly more. The exact number depends on whom you ask and whether they have recently revised their figures. The important thing is that it is not one. The current plan to land humans on the Moon requires launching between eight and twelve rockets to fuel one rocket, which then goes to the Moon. This is, architecturally, the sort of solution that causes experienced engineers to develop a very specific expression.

The reason this matters is the word "cryogenic." Transferring cryogenic propellants in the microgravity environment of Low Earth Orbit is an unsolved problem. The propellant does not behave predictably in the absence of gravity; the fluid dynamics are complex; the boil-off management is genuinely hard. China has demonstrated in-orbit propellant transfer, which is impressive and worth noting, but with storable (non-cryogenic) propellants, where the fluids behave themselves and do not require heroic engineering to keep from boiling away before they can be used. Cryogenic in-orbit transfer, the specific capability the Artemis architecture requires as a precondition for landing humans on the Moon, has not been demonstrated by anyone. It is on the critical path. It has not been tested in the environment where it needs to work.

I want to be fair: there are plans to demonstrate this technology before it is needed. Plans are good. Demonstrated capability is better. The architecture proceeds on the assumption that the demonstration will succeed. If you have spent any time in programme management, you will recognise this assumption as one that deserves a specific line in the risk register, not a footnote.

 

Problem Two: The Orbit Nobody Actually Wanted

Apollo parked in Low Lunar Orbit. This is an orbit close to the Moon, reachable from the lunar surface in a short time, with an orbital period measured in hours. If something went wrong on the surface and you needed to leave urgently, the spacecraft came around with reassuring regularity. It was, from a mission-planning perspective, the sensible place to be.

Artemis uses Near Rectilinear Halo Orbit, or NRHO. This is a highly elongated orbit that ranges from relatively close to the Moon at its nearest point to a considerable distance at its farthest, with an orbital period of approximately six and a half days. The official reasons for selecting NRHO include line-of-sight communication with Earth and its suitability as the location for the Gateway space station. These are genuine advantages and I do not dismiss them.

They are not, however, the primary reason NRHO was selected. The primary reason is that the Orion spacecraft does not have sufficient delta-V (the propulsion budget required to change orbits) to reach Low Lunar Orbit. Orion cannot get there. It is physically unable to make the journey from translunar space into a close lunar orbit. NRHO is not the orbit mission planners chose from a menu of attractive options. It is the orbit Orion can actually reach.

The consequences of this are worth sitting with for a moment. If an astronaut on the surface of the Moon experiences a medical emergency, or a system fails in a way that requires immediate evacuation, the answer to "how quickly can we get them to the spacecraft?" depends critically on where in its six-and-a-half-day orbit the spacecraft happens to be. In the favourable case, a half-day burn gets them there. In the unfavourable case, which is not a rounding error but a predictable consequence of orbital mechanics, the answer is "wait several days." Apollo's Low Lunar Orbit had the spacecraft overhead multiple times per day. The bus ran frequently. In NRHO, the bus may not come around again for most of a week.

This is not a reason not to go. The astronauts understand orbital mechanics and are not under the impression that space is a forgiving environment. But there is a meaningful difference between an orbit selected because it is the best available option and an orbit selected because it is the only available option. That difference should be visible in the mission architecture documentation, the risk assessments, and the emergency procedures, labelled accurately rather than described in the language of communication geometry.

 

Problem Three: The Playbook on the Shelf

After Apollo 1 burned on the launch pad in January 1967 and killed three astronauts during a routine test, NASA changed in ways that went deep into its engineering culture. The programme that emerged from that change successfully landed humans on the Moon six times. Every one of those missions came home. The one that did not land still came home, which given the circumstances was a considerable achievement in itself.

When it was over, the engineers who had done it sat down and wrote a document. They called it, with characteristic directness, What Made Apollo a Success. NASA document SP-287. It covers everything: spacecraft design philosophy, mission sequencing strategy, testing methodology, management culture, communication norms, the specific decisions that turned out to matter and why. It is freely available. You can download the PDF directly from NASA's technical reports server. It is not long. It is not technical in a way that requires an aerospace engineering degree to follow. It is, in the most literal possible sense, a gift from the people who did the hardest thing humans have ever done in engineering, to the people who would come after them.

One passage in particular, from George Low, who had oversight of the spacecraft programme, has stayed with me. He describes how the Apollo teams thought about mission sequencing, and his formulation is so precise it deserves to be quoted: too small a step involves the risk of spaceflight without real progress toward the goal; too large a step stretches the system beyond what engineers can learn and practice and perfect in available time. The correct increment is challenging enough to be meaningful and bounded enough to be learnable. Not timid shuffling. Not heroic leaps that exceed the team's capacity to absorb the lessons before the next leap begins.

The Artemis programme, read through this lens, has taken a very large step. Novel orbit, never-before-demonstrated refuelling technology, new spacecraft with different capability constraints, new launch vehicle, new lander. Each element is individually justifiable. The aggregate is a programme where a very large number of unknowns are simultaneously on the critical path, and where the failure of any one of them interacts with the others in ways that are genuinely difficult to predict. George Low's principle suggests that this is precisely the configuration that exceeds the team's capacity to learn and perfect in available time.

Why This Is Your Problem Too

I am aware that most people reading this are not managing lunar programmes. The Artemis budget is, in a practical sense, not available for your ERP migration or your cloud transformation or your organisation-wide platform consolidation. I raise Artemis not because it is typical, but because it is the clearest large-scale illustration I have encountered recently of three failure modes that appear at every scale of project, in every industry, with depressing regularity.

The first failure mode is the accumulation of unproven dependencies. Every large technology project has a list of things that need to work. The healthy version of this list contains things that have been demonstrated to work in roughly similar conditions, with genuinely novel elements isolated and validated before they become load-bearing. The unhealthy version contains multiple unproven elements that are simultaneously on the critical path, such that the failure of any one of them cascades into the others and the project's ability to diagnose what actually went wrong is severely compromised.

I have seen this in enterprise software programmes where the vendor product, the integration layer, the data migration approach, and the organisational change process were all simultaneously untested in the specific combination being deployed. When something went wrong, and it always went wrong, working out whether the problem was the product, the integration, the data, or the people was an exercise in expensive archaeological investigation rather than straightforward diagnosis. The solution is not cowardice. It is sequencing. Prove the critical unknowns before you depend on them.

The second failure mode is architectural constraint dressed as architectural choice. Artemis uses NRHO because Orion cannot reach Low Lunar Orbit. This is a constraint, not a preference, and the mission planning should reflect it as such. The equivalent in IT programmes is the project that is actually constrained by a previous procurement decision, a contractual commitment, or a political requirement, but whose documentation describes those constraints as deliberate design choices. The effect is that the team optimises around a limitation they are not allowed to name, and the downstream consequences of that limitation are not properly tracked through the risk register because the limitation has been reclassified as a feature.

If your architecture is shaped by constraints, name the constraints. Put them in the design documentation with the word "constraint" next to them. Plan around them explicitly. The alternative is a programme full of decisions that can only be understood if you know the history behind them, and the history is the sort of thing that lives in people's heads rather than in documents and therefore evaporates when people leave.

The third failure mode is the most consistent, the most avoidable, and the most reliably repeated across organisations of every kind. Someone, somewhere, has done something like what you are trying to do. If they were thoughtful, they wrote it down. If the organisation they worked for was sensible, those notes are accessible. The failure mode is that nobody on the current programme has read them, because reading them is not required, because the current programme is new and exciting and the previous ones are old and over, and because there is a pervasive human tendency to treat prior work as background context rather than as directly applicable operational intelligence.

SP-287 is a free PDF. It was written by the people who successfully navigated the most complex engineering programme in human history. It has been sitting on a publicly accessible server for decades. It is apparently not on anyone's required reading list for the programme it was written to inform. This is not a criticism of any individual. It is an observation about how institutional knowledge moves, or fails to, between generations of practitioners.

Your organisation has an SP-287. It may be a lessons-learned document from a previous programme. It may be a post-implementation review, a project retrospective, or an after-action report from something that went wrong years ago. It is almost certainly not on the reading list for your current programme, and the people who wrote it have probably moved on. Find it. Read it. Make reading it a prerequisite for anyone with a significant role in the current programme. This is not nostalgia. It is the most efficient form of risk management available, because the cost of the lessons it contains has already been paid, by someone else, and the only question is whether you will read about them or repeat them.

 

A Final Word on Reinvention

I want to be clear that I am in favour of Artemis. The goal of returning humans to the Moon and, eventually, going beyond it, is one of the very few large collective human endeavours that seems entirely proportionate to the scale of the species undertaking it. We live on a small rock in an unremarkable region of an average galaxy, which is itself one of an estimated two trillion galaxies in the observable universe, and our response to this situation has included going to a nearby smaller rock to look at it from the surface and bring some of it home. This is magnificent and we should do more of it.

But magnificence does not suspend the laws of project management. Large steps that exceed teams' capacity to learn in available time fail. Unproven technologies simultaneously on the critical path cascade. Constraints dressed as choices generate decisions nobody can explain. And documents written by people who already solved the problem, if unread, might as well not exist.

The Apollo engineers handed the next generation a playbook. The next generation is building on a somewhat different architecture than the playbook describes, for reasons that are largely political and contractual rather than purely engineering. This is, in the grand tradition of large institutional programmes, perfectly normal. What would be less normal, and considerably more useful, is if everyone involved read the playbook anyway. Not because it specifies the answers to today's questions, but because it describes how the people who last did this thought about the kind of questions that are being asked now.

The playbook is fifty-five years old. The physics has not changed. It is a free PDF download. There is genuinely no excuse.

All Posts