What Joe Shea, program manager of NASA’s Apollo program, taught me

Who was Joe Shea?

Joe Shea was the original Program Manager of NASA’s Apollo Program. Kevin Pollack portrayed him on HBO’s excellent series, “From the Earth to the Moon.” Contrary to what that series depicted, it was Joe who came up with concept of splitting the Apollo Program into missions that achieved never-before-achieved technology marvels.

He is also considered by some a founder of the Systems Engineering profession (many consider him the greatest systems engineer who ever lived). He was also an Adjunct Professor at MIT who taught those of us in Course XVI Systems Engineering. Every year, he would get a project from NASA and have us develop the Preliminary Design, Critical Design, Program Plan and Critical Path and present them to the Administrator of NASA.

Under Joe, I got to work on something called “Project Phoenix,” returning to the moon—but now with a re-usable capsule and landing four astronauts at the pole and keeping there for 30 days (a much harder prospect). In this project I learned about everything from active risk management to critical path costing to lifting bodies to Class-E solar flares. (How cool was that for a 20-year-old?)

Talk about the “Ultimate Definition of Scope Creep”

Yes, we have all seen “Scope Creep” our projects. We all tell “war stories” of the times scope doubled and time was cut in half. However, imagine this scenario:

You are listening to the radio and the President announces that the country is going to put a man on the Moon by the end of the decade. Keep in mind that no one is ever even escaped low earth orbit (let alone escaped Earth’s gravity, executed Holman transfers and navigated to another body). Now you have to implement the largest engineering project in history, while inventing not only technologies, but also whole fields of study. All under the watch of the press—and completed within one decade.

This is inconceivable to most of us. It hammers home how much the men and women of Apollo achieved. It is inspirational.

It also taught me that any “Scope Creep” I deal with is likely to be much easier than this!

What I learned from Joe

The technical things I learned from Joe got me my first job at Lockheed Martin (then GE Aerospace). It was great to be able to say that I had worked on a NASA program, helped create both a PDR (Preliminary Design Review) and CDR (Critical Design Review) and present elements of them to the Administrator of NASA in Washington.

However, I learned five much more important lessons — independent of aerospace or any other technology – that I have used in the eighteen years since:

  1. Break Big Challenges into Small Parts. Any obstacle can be achieved if you break it down to smaller items. If these are too large, break them down again. Eventually you will get to things that have clear, straightforward paths for success. Essentially this is the engineer’s version of “a journey of a thousand miles begins with a single step”
  2. Know Your System (or Program) Inside and Out. You cannot be a technology leader who only manages from above. You must understand how the components work. This is the only way you will see problems before they happen. Remember, you are the leader who is the only one positioned to connect the “Big Picture” to the execution details.
  3. Stuff Happens. Things break. Schedules are late. People leave the project. Plan for this. Ask yourself every week what can go wrong. Put contingency plans together to address the biggest or most likely of these. Today, this is called Risk-based Project Management (now all of the PMs who have worked for me understand my Risk Registers and Weekly Register Reviews)
  4. There is No Such Thing as Partial Credit. Yes, unlike a rocket, you can “back out” (essentially un-launch) software. However, the costs of this type of failure are enormous: not only does it cost 3-5x more to back-out, fix and regression test changes, it also frequently results in lost revenue and customers. Get things right in development – then certify them in testing (not the other way around). Don’t count on being able to “back-out” after a failed launch. Joe hammered a lesson into our heads with a chilling story: when people forgot this and rushed three astronauts died during a basic systems test on the Apollo 1.
  5. Take Ownership. If you are the leader, you are responsible for the team’s or program’s success. If you are the module or work stream leader, you are not only responsible for your area but are being relied upon by your peers for success. If you are a hands-on analyst or engineer you are actually delivering the work that leads to success. In all cases, ensure you do your job right, ask for help when you need it and never lie or hide anything.

Five really important lessons. I am grateful I had the opportunity to learn them before I entered the full-time career work force. I try to “pay this back” by teaching these lessons and concepts everywhere I go.

Before I forget…

Thank you to the men and women of Apollo. You achieved miracles on a daily basis and inspired whole generations of scientists and engineers.

PS – I am writing this on Wi-Fi at 35,000-ft. What a great coincidence given the anniversary.

Post Topics:
, , , , , , , ,

Share your thoughts