As we approach the 50th anniversary of the lunar landing, I wanted to reflect on this landmark event and what we can learn from it. Back when I was about 8-years-old, I used to play a strategy game called Buzz Aldrin’s Race Into Space (“BARIS”). As you may be able to guess from the name, you are placed in the role of the Administrator of NASA or the Soviet space program and the goal is to beat the other side to the moon. It was a great game and it’s what first gave me my passion for engineering (that and my grandfather who was a NASA engineer). To this very day, I look back on the game with fond memories. (If you’re interested in playing the game yourself, it’s available for free on Windows, Mac OS X, and Linux at www.raceintospace.org. It’s even been ported to Android.)

I didn’t realize it at the time, but it turns out that while I was having fun playing this game, it was also teaching an 8-year-old me about project management. As the Administrator of NASA, in order to successfully put a man on the moon you had to come up with a strategy for doing so. From an early age, I learned that the key first step was to clearly identify the end goal. In BARIS, this was obviously to achieve a manned lunar landing (and more importantly return them alive- the game heavily penalizes you for failures). Beginning with the end goal in mind, I learned that the best way to achieve this goal was to split the project up into smaller, more manageable steps. Most importantly, each of these steps (or milestones) had to be real objectives- i.e. not subjective; they have to be tangible. Actionable. Subjective goals are too easily hand-waved; it’s easy to trick yourself with subjective goals that you’ve accomplished something when in reality you haven’t. There’s a reason space missions call these milestones objectives.

In BARIS, this project management strategy plays out something like this:

End goal: Achieve a manned lunar landing.

Break down this goal into smaller objectives:

  1. Get into space in the first place by first launching a satellite which tests out your rocket
  2. Once you have your rocket, make sure you can keep men alive in space. Develop a module program and perform a manned suborbital followed by a manned orbital.
  3. Learn how to keep men alive outside of the spacecraft. Perform an EVA during one of these orbital missions.
  4. Now that you have a rocket and can keep men alive in space, you need a spacecraft that can land on the moon. Begin development of a lunar lander.
  5. You now need a way to connect your lunar lander to your command module. Start testing manned docking missions
  6. Perform a lunar flyby.
  7. Finally, you’re ready to land. Complete the goal and attempt a lunar landing mission.

In addition to making the project manageable, heck achievable at all, each objective incrementally builds on the next and in doing so also helps to test and improve the reliability of those previous objectives. It gives you confidence in your product.

I use this same project management approach I learned from playing BARIS all those years ago when I take on any new project, whether it’s for work or one of my hobby projects. Over the next few weeks, I will be launching a new project. We will start with an overview, breaking the project down into objectives, and we will build out each objective together in subsequent posts. My goal in doing so won’t be to just teach you the technical details for each stage of the project, but most importantly to teach you how to think about engineering projects so that you can design your own without having to follow a cookie-cutter recipe that so many other projects online rely on (example: Instructables.com).

I have attached the project management template board I use on Trello:

Trello engineering project template
Trello board for breaking down project into manageable pieces

Just a rough overview of how I use this board. I first identify all the intermediate stages of the project and place them under the "Stages" list. If one of those stages involves something I don't know how to fully do, I move it to the "Research" list. Once I start active development on that stage, I move it to "In Progress". When I think I have a working prototype of it, I move it to the "Testing" phase. Finally, once it's completed, I move it to the "Complete" list.

Sometimes you run into something you weren't expecting- maybe you found out one of your intermediate stages is more complex than you initially thought. In that case, I will break down the intermediate stage into simpler stages and add them to the list. Other times, you may run into problems that force you to put an objective on hold (for example, receiving the wrong part), for that, I have the "On Hold" list.

Feel free to copy the board and use it for your own projects. I promise it will help make your projects much easier. By forcing you to methodically plan out your design, you'll find that your projects will go much smoother.