Although I don’t watch a lot of TV, one of my “guilty secrets” is that I am fascinated by the “Air Crash Investigation” series. This factual TV series catalogues a range of near misses and miraculous landings, as well as some very unfortunate and tragic air disasters.
Over the years, the commercial aviation industry has become safer and safer—and the fact that every mistake, disaster and near-miss is scrutinised in detail has undoubtedly led to a culture of safety (see the fascinating book ‘Black box thinking *‘ by Matthew Syed for more about this).
I was recently catching up with an old episode of the show, which focused on a case where a skilful pilot successfully landed a plane with almost every automated system failing. Many things fascinated me about this case, but one thing that really stuck with me was when the pilot described the concept of declaring “Pan-Pan“.
Pan-Pan: We’re dealing with an emergency, leave us alone (for now)!
It turns out, that when a pilot is dealing with an emergency situation (which doesn’t yet require a ‘mayday’), they will declare Pan-Pan to Air Traffic Control. According to the pilot on the show, and articles I’ve read elsewhere, this has several useful functions:
1. It prevents Air Traffic Control from communicating or relaying any non-urgent radio traffic. They leave the pilots to focus on resolving the emergency,
2. Air Traffic Control can clear the way and be prepared if a ‘mayday’ call is subsequently made.
When you think about this logically, it makes sense. When the Captain and First Officer are desperately trying to diagnose the problem, referring to the in-flight computer and completing emergency checklist after checklist, the last thing they need is constant interruption. I cannot even begin to imagine the intense focus that must be required on a flight deck in such circumstances, and have the greatest of respect for those that work in the aviation industry.
If a project was a plane…
As I listened to this case study, it struck me that on projects, a very different approach is taken when potentially dangerous news emerges. When bad news emerges on a project, it is all-too-common that the following things will happen:
Ignore: If the project is high stakes and high profile, there is often a tendency to label the person raising the news as a pessimist or trouble maker. The issue is ignored and the organisation hopes it’ll go away. I will never forget the time I was asked to make a risk ‘disappear’ from my status report by a project manager. I refused, and endured a difficult period (but ultimately I had made the right decision).
Interrupt: If a problem occurs, often the spotlight shines on the areas that are suffering the most. The very people that can avert the disaster are constantly interrupted. Demands are made for daily (or, on one project I worked on a long time ago, hourly) updates. The cost of managing the ‘noise’ means that less attention and focus is spent on averting the project disaster. Ironically, this constant meddling means that the very project disaster everyone is trying to avoid becomes more likely.
Blame: Finally, if the project does implode, organisations often look for a convenient scapegoat. Rather than carrying out a root cause analysis, understanding all the components that failed, they blame a single party. Perhaps a vendor gets blamed for non-delivery of a software system (with the organisation conveniently forgetting they did not provide requirements, slashed the budget and refused to collaborate in fact-finding meetings). Then, there is a temptation to move on quickly to the next endeavour without learning from these undiagnosed mistakes.
None of this is inevitable, as BAs, business strategists and business designers, there is a lot we can do to avoid project and business disaster. Perhaps by borrowing the idea of Pan-Pan from aviation—and explaining its importance to our project stakeholders up front—we can ensure that those under pressure are supported (and not demonised), and are (when necessary) left undisturbed to focus on the problem they are trying to solve. Pan-Pan acts as a warning, but also a signal that the person themselves believes they have the situation under control—at least for now. This concept of Pan-Pan allows transparency—it ensures that potential problems are highlighted without the temptation to ‘talk them down’ or label caring and conscientious people as troublemakers. We should clear the way but shouldn’t indulge in knee jerk reactions. If things get worse, and if a project Mayday is declared, then we can be ready to support.
We should also work with our executive stakeholders to insist that project failures–and by this I mean projects that do not deliver benefit or are not ‘on strategy’ (as well as those that run over time and budget) are investigated fully and thoroughly, and that lessons are learned. So often in organisations the ‘lessons learnt’ exercise is really a ‘lessons documented’ exercise: a ritual that ticks a box and is then forgotten about. Over time, as a community, we can help make our projects as robust as the aviation industry has made commercial airliners.
So, next time you hit a project problem, perhaps you’ll consider declaring Pan? And if a colleague declares Pan (even if they don’t use this term) perhaps you’ll clear the way for them?
How do you ensure that project problems are highlighted and dealt with? Do you have any tips? Please add a comment below, and lets keep the conversation flowing!
If you’ve enjoyed this article don’t forget to subscribe.
About the author:
Adrian 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 Business Solutions Ltd is a participant in the Amazon EU Associates Programme, an affiliate advertising programme designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.co.uk
Smart … when I look at some of the troubled projects I’ve worked on they sort of flipped over-night from nobody paying any interest to suddenly everyone wanting status updates and sticking their oar in. So, they move very quickly from ignore to interrupt and blame. Once in the interrupt and blame cycle it’s very difficult to get out of the tail-spin. I’m wondering if pan-pan would help. The challenge is getting everybody to have faith in the PM and team and agreeing to back off for an agreed time. Often by that stage confidence has been lost.
Thanks Tom. I agree that trust and confidence is really important. If that is lost, then there is a much, much, bigger problem. The trick (I suspect) is to highlight the problems–and potential problems–before the tail-spin. To continue with the metaphor.. project “Pan-pan” only works if it’s done early and before the project is crashing and burning. Yet, what often happens is that people report “Green”, “Green, “Green”…. and then a sudden “MAYDAY, MAYDAY!”. This (understandably) takes people by surprise… and then the tailspin and loss of confidence.
So, perhaps it’s all about brutal honesty, and early honesty? Never popular, but often useful. 🙂
Thanks again for the comment, it is very thought provoking!
Adrian.
Yes, brutal, early honesty. How often do you see that in the corporate world?
I agree that projects can go quickly from green to red. Projects can also spend a long time in orange (but I guess pilots and planes shouldn’t!) Orange is a status that is not used very well and there can be a confusion around possible impact and likelihood.
So, when are we getting part 2??
Yes, that is so true! Orange (or amber) often covers a *huge* range. Setting proper (documented) tolerances could help, I suppose. As could setting ‘trip wires’ (i.e. specific conditions that trigger actions…. so that we’ve already ‘decided *how* to decide’ in advance). For example, having a set of criteria that (if met) trigger a contingency plan (or even to ‘pause’ the project all together)
In fact, that might make a nice follow up article…. look out for Part 2 early next week 🙂
Thanks again for the comment Tom!