You are here:  Home  >  Data Blogs | Information From Enterprise Leaders  >  Current Article

The Difference in One Word

By   /  September 26, 2011  /  No Comments

by Glenn J. Thomas

One of my favorite data stories goes back a few years ago when the Federal Aviation Administration (FAA) released its ‘Bird Strike’ database in 2009. This was just months after Captain Chesley “Sully” Sullenberger safely landed a US Airways Airbus A320 in New York’s Hudson River after it suffered multiple canada geese strikes within 30 seconds of takeoff from LaGuardia. (While many may not realize it, damage to aircraft by birds results in hundreds of millions of dollars of damage each year, and infrequently in the loss of life). The database included a vast compilation of data from airports across the United States and was searchable by a variety of options (state, airport, airplane type, etc.) to see a wealth of data related to each incident.  The release of this data in a growing age of transparency received wide news coverage. Unfortunately, some of the coverage was not exactly what they expected.

It seems that according to the database the ‘bird’ that caused the most damage to aircraft on a consistent basis was … a deer. Deer frequently wander on to runways because of the expanse of grass usually found in close proximity. Their presence can cause significant problems during takeoff and landings.  While the issue was not funny – the inclusion of deer in a database for birds was to some.

Today, if you do a search for the FAA bird strike database, you’ll notice that it is now called the ‘Wildlife Strike’ database.

All too often, even the best intentions can run aground on the rocky shores of reality. When releasing data for reporting purposes, internally within an organization or to the world wide masses, it is not enough to ensure that the data is correct. You must also ensure that the context of the data is clearly and correctly understood as well. In the above example, the FAA learned that a single word made a large difference in the perception of the millions of rows of data and the countless hours spent designing the data models and the physical database.

No doubt everyone can think of their own story of how a seemingly well thought out plan, carefully reviewed and successfully executed, still resulted in less-than-stellar results when all was said and done. Mistakes happen. Seemingly obvious things can get overlooked early on, and, when possibly noticed later, many team members can become fearful of mentioning an item that could result in rework, additional costs or even delay a planned release date. Of course the reality is that eventually the oversight will be discovered by someone somewhere. Any cost overrun or delay could be minor in comparison to the publicity received afterwards.

This would be the perfect place to write about how product name translations from one language to another makes the FAA faux pas look inconsequential, but I’ll save that for a future posting.

About the author

Glenn has more than 20 years of experience as a programmer, analyst, and project manager on systems development projects and research missions around the globe. The past 10 years have been spent serving in a variety of leadership roles in the application development, data and enterprise policy and standards arenas. His background includes time spent in the US military, private industry, and the public sector. Glenn is a Certified Data Management Professional (CDMP – DIQ), a Certified Public Manager (CPM), and a Project Management Professional (PMP). Glenn was the recipient of the 2009 DAMA International Government Achievement Award and is a former President and VP of Communications for the Project Management Institute’s Kentucky Bluegrass Chapter.

You might also like...

A Brief History of Non-Relational Databases

Read More →