Emergency response is a critical function in modern societies. One would expect such organizations to have deployment processes emphasizing highest priority action first based on event conditions.
In some cases, you would be incorrect. Sometime, organizations where process compliance and “org charts” hold sway can become stagnant and “miss the point” of what they are supposed to do. This is the story of one such organization and how a new approach, coupled with some technology, presented an opportunity to be best in class. Let's not assume however, any of the people in this organization had ill intent. They were simply creatures built to operate in the culture of the organization.
A good place to start is to understand the mindset of the organization. They were not looking for an improvement. The “tried and true” status was quite good enough for most purposes. Generally, the response structure required was adequate, when exercises occurred key metrics were met. The personnel situation was often fluid, with turnover and reassignments occurring frequently. Training was frequent and resources plentiful.
Why then, seek to change? The piece of the puzzle leadership just didn’t seem to understand was the sos-so result which was received nearly every exercise had the potential to be better. The price was not something the organization would typically consider. This price was to abandon some of their beloved structure and embrace fluidity.
To illustrate my point, let’s walk through a simple scenario. Say an event this organization needed to respond to occurs. There are some environmental factors which are distributed with the deployment notification for the exercise, notably, wind speed and direction and source of the event. The notifier messages go out and personnel would begin traveling to a designated meeting location to acquire their team supplies and go to their designated response areas based on the event data. Any personnel onsite near would do some specific activities until they were replaced by a specific team. Usually the exercises would begin at maybe 4AM, so you had a trickle-in of personal as they respond. The result to deployment was a mishmash of teams available. Often, a critical location would not be filled for up to an hour because those team members were waylaid or traffic was an issue or even the occasional no-show. At the post-mortem review, missed assignments were always a hot topic. The effectiveness of this response system is a key component to the risk management structure for the organization. If it could be postulated the response system was not effective, this could have serious repercussions to the ability of the organization to operate.
Though my point isn’t about gear, I will highlight some “also ran” contributing elements to build inefficiency within the team response plan. Each team had a case of gear to take and do their work at wherever they needed to go. The gear itself was just fine. The communication and direction elements were key detractors from their ability to go where they needed and be directed to other locations by the response team leadership. Radios were included, yet they were complicated secure models. Without lots of familiarity with these tools it was very simple to change parameters and be carrying a brick with you, not a radio. Directions to the locale of interest for your team was done with a large book of paper maps for the local region. If you were not skilled in using this rather specific type of map, it was very easy to not end up where you needed to be. Many review meetings after exercises included data from several teams not being in the correct location.
When you wrap all this into a bow, there are a host of issues to consider. One stands out to me, and was the driver for a system improvement I designed and pitched and found acceptance for. BUT. This improvement is one of my more important achievements yet, it is technically a failure. I’ll get to why.
The highest priority action this response system needed to achieve was perimeter data for the organization boundary. The hodgepodge of teams who arrived during exercises meant this priority data was often not prioritized. Due to the commitment to defined structures, the perimeter team would be filled when they showed up, no sooner. Occasionally, someone would get reassigned if it was taking too long. Rarely, in my observations.
The system I designed, defined, and pitched included cellular tablets with a custom application to handle team deployment, communications, directions, and reassignment. Critically, the system would send the first arriving team member to the all-important perimeter location no matter what. The deployment structure following this included a priority matrix to define the next levels of importance and direct arrivals accordingly. The command center would have a dedicated display of all these devices. The team location, and the ability to redirect them if needed and otherwise interact and share data with the teams.
So why did this fail and why does this mean it was still something worth calling a “success story”? This organization is highly risk averse. It is very much acceptable for their risk aversion to be part of the culture. Just getting the requisite people to talk to about having a better way to run these deployments in a room took a year of presentations, concept art and walk throughs. In the end, the success was having leadership at the highest levels of the organization admit there should be a change and green light additional work on the system, or similar solutions.
My personal lessons learned from this effort are finding common ground and having enough understanding of a system where you can see the problems and articulate them. Start. Somewhere. Is built on this type of structural understanding of systems and the people inside those systems. We cannot help each other without understanding. Even the most amazing solutions are worth nothing if they are not communicated effectively and their potential is not understood.
If you have found this interesting and would like to consider how to fix some of your organizational problems, reach out. Learning about new systems and meeting new people are the best types of things to do.
