Delays are one of the biggest issues in aviation. Not only for passengers who experience them, but also for all the stakeholders on the airport and in the network. When major delays do happen (or any other significant incident), we often see two types of reactions in response to them. Either there will be sudden radical new measures to try to prevent them, or the delays are being dealt with on the spot and nothing changes afterwards. Both these types of reactions most likely will not lead to any substantial changes that improve the situation in the future.
Most of the times a delay has more than just one cause. As stakeholders all have to work together to get an airplane to depart on time, the cause of a delay can be at any point in the chain. When a delay occurs, you generally do not have time to analyse what the root cause of the delays is. But if you do not take the time to analyse what went wrong in the first place, it is very likely that similar delays will happen again.
So, first fix the issue at hand but do not wait too long to investigate. Interestingly, when a major incident has taken place, people are much more inclined to accept mitigating measures shortly after the incident, rather then after a couple weeks.
Ask yourself ‘why?’ and ask it several times
In software development, a single fault or mistake may be unpleasant during the first stages of development but may have a significant impact if discovered when the software is already in production with the customer. Resolving an issue in production is 100 times more expensive than tackling it in the requirement discovery phase. Simply repairing the particular bug at an early stage will not prevent similar bugs of reaching production in the future, as it is only the symptom for a problem and not the cause. That is why we always try to find the root cause, by employing the what is known as the ‘5 Whys methodology’.
This principle came from the mind of Sakichi Toyoda, of Toyota motors. The idea is that you keep on asking why something happened, and not just to focus on the initial incident – Why did the system fail? Because there was something wrong with parts of the coding – only to take measures concerning that point (i.e. take action against the individual coder). Instead, you ask a next question: ‘Why was there something wrong with parts of the coding?’ An answer could be ‘because the coding is too complex’. This answer gives us the opportunity to take a second look at the code and the need for its complexity. And so on. The ‘5 Whys methodology says that usually after 5 questions, you will have found a root cause.
It involves every stakeholder
Although the ‘5 Whys’ approach stems from the engineering world, it is also applicable in aviation and at regional airports, where stakeholders work closely together. If you would apply the five whys on the question of a delay for instance, it could look something like this:
Why? Refuelling the airplane started too late
Why? The refuelling truck was too late at the stand
Why? The order for fuel came in too late
Why? It took too long to get the right overall weight calculations for the airplane
Why? The baggage system malfunctioned which delayed the weight information in time
Why? The belt drive of feed 1 broke down due to wear and tear
If, in this example, the question ‘why’ would only be asked once, it could be that there would only be taken measures surrounding the fuel trucks. That probably would not have been enough to prevent these kinds of delays in the future, because the root problem is wear and tear on a belt drive that is also present in other feeds.
Using the ‘5 Whys methodology’ is a good way to come to structural solutions after a crisis, in software development but also at airports. While applying the methodology we learned several things, which we would like to share with you to give you a head start:
