Pink Elephant Blog
Change Management and Air Traffic Control
Before I launch into the tale I would like to provide the context that many organizations struggle with the concept of a business case for creating a single process for Change Management where we see all changes recorded in a single forward schedule of change which is reviewed and approved by a change advisory board. Traditional objectors to this policy are usually the ERP group who in their opinion have being doing change the right way before the rest of IT could even spell the process. Or perhaps it is the application development group who don't actually see themselves as part of IT and they have their own special process for promoting changes into the production environment. The common thread that runs through their arguments of justification is that they have more than enough controls and very mature processes so they don't need to submit themselves to the bureaucracy of the overall IT change process. Now to be fair the first part of their claim is more than likely true. The SAP group has been doing Change Management according to a best practice for years. However, even the most mature change in isolation may still cause a service outage if it is implemented in ignorance of all the other changes happening in the datacenter that day. Now for the airline analogy:Consider that the shared datacenter is like the primary and only runway for a busy airport. Landing changes safely in the production environment is exactly like lining up aircraft for a landing while they are still miles out and ensuring they land safely with no casualties for those people who are in the plane or to those who are living their busy lives on the ground. Many different types of planes of varying sizes need to land at this airport all the time and the runway is called on to meet the needs of a private two person planes (standard changes) all the way up to big commercial Boeing 747s (big projects) Remember that the goal of Change Management in layman's terms is to efficiently and effectively handle lots of changes while minimizing the impact to the people that work and live around the airport. Now that you have this picture firmly fixed in your mind consider that having multiple change processes that do not talk to each other is the same thing as having multiple air traffic control towers on the single runway working blind of each other activities. Sooner or later we are going to have casualties to deal with.How would you like to fly into an airport under these management practices. George's and my thoughts what are yours? ”The system of life on this planet is so astoundingly complex that it was a long time before man even realized that it was a system at all and that it wasn't something that was just there.” ~Douglas Adams
Like this article? 
Comments
Interesting post. Airport and airline analogies are remarkably appropriate for discussions involving change management. I’ve used the analogy of aircraft as an exercise in both change and configuration management. In reality, what ITIL is telling us we should do with our IT environment has been going on in aviation for years.
My favorite example is aircraft maintenance. For certified aircraft from Cessnas to Boeing 737s, every change that’s made to the aircraft must be performed by a properly trained and licensed person in accordance with the documentation provided by the manufacturer, plus any service bulletins (known errors). All changes are logged in detail according to strict rules, and all parts must be certified to not detract from the normal operation of the aircraft in any way and must have a paper trail pedigree.
There are pre-approved changes that any licensed pilot can do, such as oil changes and wheel bearing repack, and there are changes that require approval from a licensed mechanic, followed by an inspection by a mechanic with additional credientials (change verifiaction).
Problem Management is done after an accident or Incident (there are other times as well). If an underlying root cause is discovered, a known error is produced that can take the form of a service bulletin or airworthiness directive which requires mandatory compliance before an aircraft of the same configuration is flown again. The end result of all of the work is a known good aircraft configuration that endures for years.
An aircraft with a correct, auditable change log is worth more than one without, and is deserving of the trust placed in it by its passengers. As importantly, this process has resulted in the safest, most efficient airline industry in the world.
Dave
Dave Johnson | December 13, 2006 at 2:38am
Thank you for your comment Dave
This reminds us that the processes that ITIL describes are not unique to IT. Perhaps they would be better viewed as simply management processes that are constant regardless of what is being managed. For example: Anything worthy of management would require a process such as Change, Incident, Problem, Configuration Management, etc.. The list goes on. Perhaps the only thing about ITIL that is unique to IT are the examples used.
Troy
Troy DuMoulin, VP Research & Development | December 13, 2006 at 8:24am
As a trainer and consultant I too found air traffic analogy effective while discussing Change Managmeent. Especially the importance of an accurate and up-to-date CMDB in Change Management decisions. You might want to check out my post at http://eyetil.blogspot.com/2006/12/change-and-configuration-management-air.html#links
Cheers!
Ravi Putcha
Ravi Putcha | December 23, 2006 at 10:37pm
Air Traffic Flow Management. It’s an activity that is done before flights take place. Any aircraft using air traffic control, from a business aeroplane to an airliner, files a flight plan and sends it to a central repository. All flight plans for flight into, out of and around Europe are analysed and computed
For more details:- http://bit.ly/2N7HxOG
Margaret Negron | September 28, 2018 at 8:17am