Wheels up! Even though I’ve logged many more hours in Microsoft’s flight simulator than on anything that flies, I have come to appreciate a pilot’s habits and routines in my own day-to-day project work. Flights in the air and projects on the ground both follow a similar regimen when examined side-by-side. From aviation protocols and procedures, I’ve drafted up five “lessons learned” that I think can be applied to any project management workflow, or at least will be useful when planning and executing project work.

I find that learning to fly is hard, as was learning to   manage projects, however, both are only dangerous   when you crash.

From the Flight Book…

The fundamental tool used by pilots, regardless of the aircraft flown, is the almighty checklist. Checklists are beloved by pilots and PMs alike, and can be used to successfully land any flight or project. Let’s consider a few of these pilot checklists and protocols, and consider how they apply to the field of project management. The following five “lessons learned” are pulled from the aviation industry, and treat a typical project just as a pilot would treat any flight mission…

#1 – The Alertness Assessment Checklist

This one begins with a health assessment of the pilot on flight day. Did he/she get enough sleep before embarking on the mission? Was there any alcohol consumed in the period before work? How much flight time has the pilot logged recently? These assessments go from the simple to the extreme, and in many cases, involve an independent auditor that double checks all the pilot’s criteria.

I recommend making “enough sleep” a memory item in whatever checklist you choose to create.

In pilot parley, a memory item is a specific action (or set of actions), appropriate to the nature of the event, that are required to be performed before making reference to any printed or online checklists. These actions are committed to memory by each pilot as part of their training programs for different aircraft types, and are performed in response to any emergency situation—immediately.

Now as a project manager, one can see how having a few memory items stored up would be critical. For example, if your CEO comes to tell you on the first day of your project that half the workforce is being laid off, you will have no time to dig out your Risk Management Plan; you have to know what to do in real-time! And, in front of a boss that is deciding on the spot in which half of that workforce you belong.

#2 – The Pre-Flight Inspection Checklist

Following a pre-flight inspection checklist is crucial for the safe and successful operation of aircraft. I suggest it’s also crucial when taking off with a new project plan. In the aviation world, there are certain safeguards and checks put into place to make sure, for example, you don’t takeoff with the cargo bay doors open … or with a flat tire.

Most projects have a risk matrix that was drafted up early the planning process (and then filed away somewhere for safekeeping), but research shows that risk rankings formulated by managers are often arbitrary and produce errors.1  For the sake of our analogy, it’s important to note that pilots don’t use them, as any confusion or error can be instantly catastrophic.

I’ve started developing a pre-flight inspection checklist of my own (which I hope to document someday). It consists of a list of must-do’s, that I check before ever pulling a project out on the tarmac.

One common check for me is to have an alternative runway planned in case of engine (or other serious) failure occurs within the course of my project. In short, I like to have a project schedule for the project schedule, or a plan to follow in case a project fails to even get off the ground. Hopefully the alternative plan can provide some pointers on where will we go if left hanging completely in midair.

Another check I make is related to load vs. resource calculations. Pilots do this even before releasing the handbrake. Why start a project on such and such date, when you don’t even have the funds or people to begin takeoff?

Here’s one that bit me on my last project worked, an effort to construct wind sensors before installing wind turbines across remote regions in Nepal. The project charter did mention a bit of rough terrain, but little did I realize that some sites were so remote, it would take a three day hike on foot to get there. Heck, I just assumed one could cruise to these points with all-terrain vehicles! As it turned out, in a few locations, we had to build the road to get us where we needed to go.

Pilots never have that problem; they always know where they are going, what is needed to get there, and what the terrain is going to be like when they do – even before departing the airport!

There are many other comparative checks that can help us manage projects, and I suggest that all project managers browse through a few from the aviation library.

#3 – CRM and the Sterile Cockpit Rule

CRM, or Crew Resource Management, was pioneered in the ‘50s by former RAF pilot, David Beaty, in his seminal book, The Naked Pilot: the Human Factor in Aircraft Accidents. In short, this pilot described a management technique that promotes the use of teamwork and decision making to ensure sound situational awareness and problem solving during every flight. CRM is followed by all major airline crews today. I suggest that every project manager explore this view on successfully handling command and control, and that they apply those lessons within your PMO. In what seems contradictory to proper CRM, pilots also follow the Sterile Cockpit Rule that restricts communication between pilots and crew during certain phases of a flight. It’s interesting to note that, as with proper project plans, flight plans are divided into set phases (for example, planning, design, implementation, post-implementation, etc.)

Of course, I am not suggesting that you forgo communication during certain phases of your project, but I do suggest that you follow some rules to limit the chatter during critical phases. In my experience, flocks of emails, Twitter strikes, and slack sloth during periods of intense activity is not productive, and even worse, can result in an all-engine project flameout.

On a philosophical level, if you can’t quiet your team during critical periods, at least try to quiet your mind when things get rough. Every experienced pilot I know stays calm and collected under pressure. As they say in the Air Force, stay frosty!

#4 – Flying the Beam

“Flying the beam” is an old aviation term used to describe how a pilot lands at airports utilizing technology to guide them home safely, often when they cannot even see the runway on approach.

In order for a project manager to land a project successfully, I recommend doing likewise. Use automation to beep, blink, or yell when your project schedule is going off the rails, or otherwise warn you when things are seriously amiss.

The most common MS Project navigation aids are milestones and the RAG indicator. A RAG indicator is programmed into your project schedule using a simple formula (click here to learn how to install a RED-GREEN-AMBER alert system).

Milestones in MS Project are akin to waypoints on a pilot’s flight plan, and these points within a GPS system not only make up a complete flight plan, but tell the pilot where to turn within the entire series of turns. Project managers should also use milestones, or they are destined to lose their way.

MS Project Add-ins can act like gauges on a flight deck, and keep you from crashing or going off course.

In addition, there are MS Project Add-ins, like the free QCheck-IT from QuantumPM that acts as a gauge on a flight deck alerting you when somethings not right. Go to Project > Get Add-ins to install it (and others). These types of tools build automation into your project schedule, and just as pilots rely on automation to safely operate their aircrafts, today’s project managers need automation to safely operate a project schedule. #5 – The Two Pilot Rule Long ago, aviation authorities determined that some aircrafts needed two pilots instead of one to safely fly. I propose that certain types of projects need two project managers to successfully bring them home, too. While we in the PM world have no such authority to make the rules, if a project is planned to last many months or even years (or is complex and technical in nature), a co-pilot could be needed to navigate across the void.

Having a “backup body” on call (for example, if the lead PM falls sick or is on vacation) may not be sufficient. It’s always better to have a pilot/co-pilot configuration to help with the workload, especially on difficult or risky projects. For pilots in the air, the acting Captain is focused on flying the aircraft, while the 1st Officer is monitoring all details of the flight, including communications. Both the Captain and the 1st Officer can switch it up midflight; however, as both are qualified to fly the plane. As such, a project co-pilot should not be just a name on a list with an email attached.

Just as within the aviation industry, justification for having a double-teamed PM crew may not balance out. In fact, the NY Times recently published an article entitled, Will Robots Take our Children’s Jobs? in which a robotic co-pilot developed by the Defense Advanced Research Projects Agency that had flew and landed a simulated 737 was mentioned. Personally, I’ve always enjoyed working in an environment where there is a matrix of lead PMs and co-leader PMs, all working together on the portfolio, and I dread the day when project work is completely led by artificial intelligence, instead of my own. (But, that’s coming soon as well.)

We hope you enjoyed your flight!

All in all, I’ve found aviation-related checklists (and metaphors) to be useful in my life, no matter if I’m flying an Airbus from my simulator chair, or working on a project from my office chair. Similarities between the industries abound. From Alertness Assessments to Flying the Beam and more, these metaphorical connections can help you navigate your next project safely and successfully home (I swear).

Feel free to add your own aviation / project-planning metaphors in the comment section below, and here’s hoping you always keep the shiny side up—and the greasy side down.

1 Thomas, Philip, Reidar Bratvold, and J. Eric Bickel, ‘The Risk of Using Risk Matrices,’ SPE Economics & Management, Vol. 6, No. 2, pp. 56-66, 2014, doi:10.2118/166269-PA.