Project Lessons from Aviation (Part 4): Aviate, Navigate, Communicate

Cockpit of airplane
Image Credit © bennymarty, Fotolia.com #93453181

In aviation, I gather, the mantra ‘Aviate, Navigate, Communicate’ has been a staple for pilots for many years.    I first heard this expression a few years ago, speaking to a fellow BA at a conference who also happened to hold a private pilots licence.  According to the FAA website, the mantra provides a useful aid-memoir for the pilot-in-command, particularly in emergency situations:

 

Aviate: Keep the aircraft in the sky, and keep it under control

Navigate: Monitor location, and navigate to the intended location

Communicate:  Speak to others (presumably this would include those outside the cockpit, e.g. air traffic control and also the passengers on board).

 

When I first heard this mantra, I was struck by its succinctness but also its usefulness—it is a concise shortcut that helps prioritise activities, especially when time is short and when the pressure is on.  It also struck me that it is an interesting model through which we could consider a project.  But perhaps, for a business and project environment it might need some adaptation…

 

Communicate, Communicate, Communicate?

Interestingly, many projects do seem to be managed and run as if the ‘Aviate, Navigate, Communicate’ were being sub-consciously followed.  Imagine a crisis situation in your project—I would imagine in most situations the stated priorities will be:

 

Aviate: Keep the project ‘in flight’/ensure we don’t run out of resources or funding

Navigate: Make sure the project is on track and will deliver on-scope, on-time, on-budget, (and, if you’re in a mature organisation ‘on-benefit’ and ‘on-strategy’ and other relevant factors will also be considered)

Communicate: Issue a communication to a wider audience regarding any changes, problems and how they have been overcome, and try to ensure that they don’t recur

 

At first site, this might seem to make perfect sense.  After all, surely the priority should be to keep the project ‘in flight’? Shouldn’t it…. And communication should happen only after key decisions have been made?

 

Well, possibly—but it depends on the reason for the crisis.  In fact, the instruments that a project is ‘flown’ with are often rather blunt, and finding the underlying reason for a delay or difficulty is likely to require communication with others. Indeed, in our project environment, communication is likely to be very much two-way; listening to disparate stakeholders with differing viewpoints, synthesising those views and assessing possible courses of action.

 

In fact, any kind of meaningful activity, analysis or project activity will require regular communication and engagement, and as practitioners of change it will require us to be engaging.  When the stress is piled on it is very tempted to think that we exist to simply ‘keep the plates spinning’ and ‘keep the project in flight’.   The temptation is to focus on aviation but not focus on navigation or communication.  Yet to do so creates a gap between us and those who are actually most affected or interested in the change we are implemented.  We risk (metaphorically) landing the plane exactly where we thought we were asked to, but we find out that our passengers needs have changed along the way, so they are disappointed.  Or worse, we have colleagues who are stressed because they don’t know what’s happening (or they fear that nothing is happening because they don’t see and haven’t heard from us).

 

On top of this, there is always a bigger strategic context.   A bigger focus on communication, engagement and ensuring alignment with benefits and strategy will help avoid project disaster.  If we find ourselves caught in a loop where we are purely ‘aviating’, it will pay to think about communicating and navigating also. Shortening feedback loops, and creating the opportunity for experimentation and iteration can be beneficial and can create space for dialogue and minor tweaks of direction.   The sooner we make a course correction, the cheaper for the project.  Formal communication and engagement planning is part of this, but having a bias towards informal, concise, meaningful conversations can help us along the way.

 


What are your views, do you have anything to add?  I’d love to hear your experiences and tips.   Please add a comment below, and let’s keep the conversation flowing! 

If you’ve enjoyed this article don’t forget to subscribe.

Subscribe to Adrian Reed's Business Analysis Blog


About the author:

Adrian ReedAdrian Reed is Principal Consultant at Blackmetric Business Solutions, an organisation that offers Business Analysis consulting and training solutions. Adrian is a keen advocate of the analysis profession, and is constantly looking for ways of promoting the value that good analysis can bring.

To find out more about the training and consulting services offered at Blackmetric, please visit www.blackmetric.com

Blackmetric Logo

Julie

Maybe a business analysis mantra could be “engage”, “navigate”, “monitor”, I think that would fit nicely along the lines with your observance :). Good topic, i like your thoughts on it

Leave a Reply