IAPs lead to OBEs

In military slang, there is an acronym for what happens when events on the ground move and change faster than the plan: OBE. Overcome by events.

In the United States, our policy and programs prescribe Incident Action Planning in disasters, even though the process was designed for a different kind of problem. We take a tactical planning tool, scale up the organization around it, and then ask it to serve as a strategic coordinating mechanism for an entire disaster.

The result is that the response and recovery systems can move much slower than the disaster itself.

When you try to use an Incident Action Plan, or IAP, this way, cascading impacts don’t just fall through the cracks. We can effectively schedule them into tomorrow’s planning cycle.

Here’s what that actually looks like from the inside.

I frequently worked large-scale disasters at the intersection of several of these IAP processes running at once, often trying to organize Red Cross liaisons across every jurisdiction involved. We’d try to raise concerns or organize action around a cascading impact in mass care, and I often felt like I was operating a pinball machine. You try to bank a problem off one process and into another’s decision-making. Hit it at the wrong point in the 12 or 24-hour cycle, and you lose days. Not to mention the political concerns about the state vs federal vs local. In some areas, we wouldn’t get any action moving if it came from the state to the locality, or the federal to the state, or other places it was the opposite. The work on finding the right person to take action and make the requests became the action, instead of directly working the problem itself.

In the US, we have ICS systems running at nearly every jurisdiction, similar structures in NGOs, and increasingly in the private sector. On a large disaster, you can have hundreds of these cycles running on the same problems, completely siloed from each other. That is an architectural problem: a 24-hour linear batch process trying to manage a borderless, networked crisis. That’s a lot of cracks for the big problems to fall through.

And let’s be honest, or as AI would call it an “uncomfortable truth”. Sometimes we use it like a procrastination tactic, an option to Scarlett O’Hara the sticky problems and say we’ll worry about that tomorrow. React to what feels more urgent today. Because we don’t have an actual coordination system, we get away with it more often than we should. Another EOC is working the same problem. Or a community solves it without waiting for any of us. But that’s not strategy and often doesn’t work out that well. The problem hasn’t gone away. It has gotten worse, changed shape, or created new problems around it. By the time the process catches up, it has been overcome by events.

And let’s talk about the costs. Not only do we have the planning process itself that causes delays and slows down action, but we have the paperwork. I know that I’m starting to talk about this way too much, but I hope we can all see the silliness of how we talk about the coordination elements in the Joint Field Office. We say that this Joint Incident Action Plan is a coordination tool that can somehow hold together the workings of an entire state and the entire federal government in one document (and supposedly be a roll up representing all the IAPs from the local level). Every operational period. I have been on a bit of an informal research quest on this topic for about 5 years, asking people about the Joint IAP. Is it helpful? Is it the right tool? How do you use it? Even when I went around to nearly all the regions and several major operations a couple years ago, I would randomly ask the people I interviewed. In my informal qualitative stats, most people say they use it to find out who’s on the job and what their phone numbers are. Tasking and work came from other places. Which means, in practice, we may be reproducing the nation’s most expensive Rolodex every day, on every disaster, with each state, tribe or territory involved.

I acknowledge that this has become a bit of a personal pet peeve (obsession?), but the point to make is that we really need to look at all these processes and see what the real utility is. We don’t need more bureaucracy or paperwork; we can’t afford to do things just for the ceremony or tradition of it. To make the people on-scene more comfortable or familiar with what we are doing off-scene (I’ve heard this argument a lot, even seen it in old FEMA doctrine). In the FEMA Incident Action Planning doctrine, it says it is a leadership issue to make sure this doesn’t just turn into a paperwork exercise, which doesn’t seem fair. It’s like asking the COO of a construction company to build the project with a hammer and nails instead of running the business with a computer. There’s some relationship to the actual work. You might even feel camaraderie with the crew on site. But it’s genuinely ridiculous to think that tool is going to get the job done at that level no matter how good of a leader you are. And the cost of that mismatch is real labor, from real people, at real cost. Climate change, greater exposure, aging infrastructure, and increasing disaster complexity certainly contribute to rising disaster costs. But we should also be willing to ask how much our own operating architecture costs us unnecessarily.

Especially when those hours could be spent helping people or getting ahead of the next cascading consequence.

So how did we end up here?

We have to remember that the United States did not design its national disaster system from a clean sheet of paper. It accumulated. Similar to the street plans in old cities, there wasn’t an overall planning process that looked at what would work best. The streets were built based on where the old cow paths already went. We were building a national coordination system, and then 9/11 happened. We created NIMS and tried to merge two contradictory approaches. NIMS also reinforced what I think of as the myth of the incident commander when applied at disaster scale: the idea that somewhere above all this activity there can be one person, or a small group of people, with enough authority and information to direct the whole operation through a common planning process.

That logic makes sense within a bounded incident and a defined command structure.

It does not describe a disaster.

There is no single incident commander or even a unified command for a large disaster, and it would be counterproductive to try to designate one.

But that assumption is part of what makes a Joint IAP feel like it should work as strategic coordination.

I sat in a lot of those rooms. Framework revisions, FIOPs, ESF document development. We talked about how little of it made sense even as we were building it. But we did what we could with the situation we were given, and mostly we hoped that someday someone would build something better, something that actually made sense for the scale of problem we were facing. Now is the time. (or 10 years ago was the time, but now is better than later).

An IAP can be extremely useful for aligning organizations working together within a common incident structure under an Incident Commander or Unified Command.

But asking that same tool to serve as the strategic coordination mechanism between the machinery of a state and the machinery of the federal government, much less the many other organizations, businesses, local governments, individuals, and communities involved in a disaster, asks it to do something it was never designed to do.

IAP isn’t the problem. The problem is using an incident planning tool as though it were a disaster coordination system.

Neither command-and-control logic nor coordination logic supports that use.

We need a planning and coordination process designed for the complexity, speed, distributed authority, and scale of disasters.

SHARE YOUR INNOVATION!

In the middle of my pinball years, I also saw real innovation.

Planners and emergency managers built workarounds that ran in parallel to the formal IAP process. I’ve seen so many variations of Incident Strategic Plans, Incident Strategic Action Plans, Incident Support Plans, dependency maps, resource-prioritization tools, shared spreadsheets, informal coordination processes, and probably plenty of things that never had an official name.

I still point people to one built in South Carolina because they made theirs public. But I know there are many more out there.

So here’s my request: if you built one, used one, inherited one, or saw one work well, please share it.

Post it publicly on LinkedIn so other people can learn from it. Tag River Mac or use #DisasterCoordinationLab so I can find it. If you would rather not post it publicly, send it to me directly. And if you cannot share the actual tool, tell me what it did, what problem it solved, and why it worked.

I want to start bringing these examples together and looking for the patterns across them. Not because I think one tool is going to solve disaster coordination, but because practitioners have already been building pieces of what we need under pressure.

That is also exactly the kind of work I am building the Disaster Coordination Lab to support.

The Lab is a paid educational and community space opening in beta next week. We will start with short courses that establish a shared foundation in disaster research and concepts, then use the community space to compare what has worked, challenge assumptions, and develop better tools and practices together.

It is opening in beta because I feel a sense of urgency to start these conversations now, while the Lab is still being built, rather than wait until everything is polished. Even if it starts with only a few of us, that is enough to begin.

Learn the research. Discuss the practice. Build what we need.

If this is the kind of conversation you want to be part of, you can sign up here to hear when the Lab opens.