A few weeks ago, I received an interesting email from an old friend. He had received an emergency notification email about a threat to his prior place of work. They were going to close the local federal building due to an unspecified threat. He was not supposed to show up to work that day. This was during a time when federal buildings across the country were the scene of real violence between police forces and protestors. Buildings in San Diego, Los Angeles, Portland, and Minneapolis all had been the scene of violence prior to the message. He was not to report to work the next day. The email did look generic, like a system produced it. There was only one small problem with the email. He had retired from that place of work two years prior. Their emergency notification system had not been updated to show his retirement. I thought if that occurred for sure new hires in the same period were probably not in the database.
The email did not surprise me. It mirrored what I have seen myself in organizations. Few people want to update databases for emergencies or anything else. The work is tedious, painful, and usually forgotten until people must pay attention to it. It also reflects the low priority disasters or emergencies rank when there is no emergency knocking at the front door. I could image the scramble when real emergencies occur. Data screwups for sure would rise to notice then. Management walks the cube farm quoting Shakespeare, “A horse, a horse, my kingdom for a horse!" (The famous line from William Shakespeare's historical play “Richard III,” Act 5, Scene 4. King Richard III roams the battlefield shouting those words to try to get a horse to escape on.) They desperately seek the magic key to fix a problem and move on to the next thing.
The blind eye on updating databases reflects a larger problem. Organizations produce plans, but after it gets published the plan moves to its secondary purpose, as a doorstop for the front door. A study by PR News Service found 62% of businesses have crisis plans but few update them. Data shows only 49% of the plans have been updated and 40% of organizations have never conducted crisis exercises. At best, if the updates do occur, bosses treat the work not as critical but as a penalty duty for people they don’t like.
As I dug a little into this problem — online from my friend’s email — things pointed to a larger national problem of bad data cutting across all kinds of industries. IBM research from almost 10 years ago found at the macro level bad data costs the US almost $3 trillion per year. Gartner Research has found the average cost of poor data quality for individual businesses amounts to anywhere between $9.7 million and $14.2 million annually. The nature of these errors come from multiple things like typos during data input, the transposing of numbers, incorrect data from source documents and missing data.
This data problem for organizations grows to cause real world problems. Fake numbers caused by inattention creates a fake picture of capabilities for management. Where one office might know the truth on data but the next office down the hall (which uses the same data) won’t know the truth. For example, large organizations use an average of 367 different software tools to process their data. The multitude of system creates data silos. Organizational silos often create communication issues internally to those teams. That in turn creates a false picture for operations. In 2021, Zillow posted a $569 million loss and a reduction of 25% staff layoff due to problems which came from bad data and their market programs.
The data problem extends to the emergency/contingency field too. The first place where data rules is where you think it might, the emergency notification systems. The same habit of ignoring data accuracy will bleed over to other parts of the program like checks on the accuracy of other critical information. Problems with that data won’t come out until the emergency or the reviewed exercise.
This extends to finding the right data at the right time. An EF5 tornado hit Joplin, Mo., back on May 22, 2011. It resulted in 161 deaths, 1,150 injuries and $2.8 billion in damage. The tornado tore a 22-mile-long hole straight across the city. The local school district, like the rest of the city suffered. Several buildings within the district were damaged or destroyed during the storm. The school district missed a $67 million aid package in disaster aide because they missed a 60-day appeal window. The school district said they were unaware of the timeline. The Associated Press ran a story on the same problem. They found tardiness is one of the most common reasons FEMA headquarters has denied appeals from cities, school districts, and other public entities, accounting for well over $100 million in lost aid. The loss was attributed to FEMA strict adherence to submission deadlines. Poor data management results in missed deadlines by just losing control of requirements.
Often these problems in emergency data problems come from the same source of problems in business. The problems come from lost data during input, communication breakdowns, software management problems, and other data mishandling problems.
The impact of all this has multiple layers. A plan that just sits on the shelf becomes a plan no one believes in, a plan no one has confidence in it. Response entities will suffer from delayed response times. Failure to update an organization’s emergency notification systems inevitably means people won’t get the message. Entities could face regulatory fines and compliance risks from data problems.
Ultimately, this leads to the lack of accountability for the work force at the worst time, during an emergency. People won’t know where their work force is during these emergencies. Management in horrible events will waste time chasing status reports for people who have retired and missing new hires, which leads to hours and days of chaos. That chaos will lead to unnecessary risk for first responders and/or people within an organization. I have a story to prove the point.
Back on May 22, 2010, the Shawnee (Kansas) Fire Department had a firefighter die during a response to a house fire. Firefighter John Glasser went into a burning house looking for two supposed occupants. The neighbor saw two people were in the burning house. Those people were not in the house. Firefighter Glasser died during his search for people who were not there.
I hope everyone will update their data in places like the emergency notification systems to avoid any repeat cases like which led to the death of Glasser. Fix the data today and you have a clean plate to deal with the real problems that come during an emergency.
