<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=749646578535459&amp;ev=PageView&amp;noscript=1">

KaiNexus Blog

Everything Continuous Improvement

Subscribe

How a Checklist Almost Thwarted the First Moon Landing

Posted by Becca Millard

Jun 11, 2015, 9:39:00 AM

full-moon-415501_1280

Checklists are a great way to ensure standard work - especially in a process that has many steps, or for doing work that’s mission critical. The checklist should be developed and tested, of course, but the responsibility for improving the process doesn’t end there. There’s a fine line between “Always follow the checklist” and “Be a critical thinker,” and it’s crucial to train your employees to strike a balance between the two. After all - checklists aren’t perfect, and who better to find errors or opportunities for improvement than the people using them?

It’s widely known that the first moon landing almost ended in disaster, with the landing module nearly running out of fuel. Less well known is that, minutes before touching down, the landing module’s navigation software suddenly triggered multiple alerts. With all the flashing lights, warning beeps, the NASA team panicked, and nearly aborted the mission completely.

So what went wrong?

Buzz Aldrin had a checklist of mission-critical tasks that he had to accomplish in a precise order. But that checklist included a mistake. Placed early on the list was that the rendezvous radar system needed to be turned on. In actuality, that system was not needed in order to land. But, Aldrin followed protocol and continued down the checklist, so he activated the system.

When that system was turned on, it flooded the computer with far too much information and extra work, triggering overflow errors – and if you know anything about programming, you know how nasty that is. Even with today’s modern technology, computers that encounter this kind of error will have major problems.

With disaster (or at least an aborted mission) looming, what saved the day?

Margaret Hamilton – a software engineering pioneer – and her team at the Software Engineering Division of the MIT instrumentation Laboratory were given the task to work on the on board guidance software that helped us land on the moon.

Fortunately, Hamilton and her team had had the foresight to design the software to be so robust, that it was able to ignore the extra information and focus on the top priority tasks at hand – landing the craft.

The panicking NASA team quickly realized that, thanks to these safety nets, they could ignore all those warnings, because the software would just discard the unnecessary data and keep its attention solely on landing the module.

Did Buzz Aldrin know that something was wrong with his checklist? Probably not. After all, it’s not every day that a man lands on the moon (though I’m sure that NASA would have encouraged him to speak up and trusted him to make the necessary change, had he known). The work that your people do every day probably isn’t (literal) rocket science, though - so chances are, they’ll know when their checklist needs to be adjusted. You don’t have Margaret Hamilton’s software to override a faulty process in your checklist like Buzz did… but you do have smart, capable people who can serve the same function.

For more information on Margaret Hamilton’s work to save the moon landing, check out the Forgotten Superheroes of Science segment of the Skeptics Guide to the Universe, podcast #517.

New Call-to-action

 

Topics: Daily Improvement

Recent Posts