A Course on Emergency Management and Technology - Goals and a Starting on Structure

How can or maybe how should we differentiate between ICS and Emergency Management (EM) in order to grow EM?

In the previous articles:

• A Course on Emergency Management and Technology: Getting Started
• A Course on Emergency Management and Technology: Foundations to Consider

I started to consider how to create a course that centers on emergency management (EM). Specifically, I am concerns about creating incompatible students trying to do things in EM that it just does not want. The push to create students who are both conforming and non-conforming is delicate but important given existing issues in EM.

This piece is the first attempt to actually consider where the goals are AND how to get there.

As a starting position, the goals for this course are as such that they meet current needs, push on future needs, and reflect current needs.

The goals again are (subject to change but fine for now):

• Demonstrate an understanding of designing technologies to be used in low-tech or no-tech environments.
• Investigate the current technological capabilities of emergency management in comparison with the technological capabilities of the everyday citizen.
• Identify problems in emergency management through that investigation that could be solved.
• Formulate potential solutions using appropriate theories, data sources, and methods.
• Apply an understanding of low-tech / no-tech environments to your solution.
• Justify those solutions using appropriate theories, data sources, and methods.
• Demonstrate professional and ethical responsibility by including intended and unintended consequences of that solution.
• Synthesize knowledge and insight gained by speaking to practitioners to better understand and improve those solutions.
• Work in teams to overcome problems that arise in multi-disciplinary work.
• Translate complex terminologies, technologies, and solutions in order to communicate effectively across practice and academic domains through written reports, oral presentations and discussion.

And so, how do we even get there? The finish line seems easy but getting there is more than just racing there. We need to build structures along the way that can keep as permanent structures to build further on.

When I originally proposed this course, the outline was:

1. History of Preparation, Response, Business Continuity, and Technology
2. The impact of 9/11 on preparation, planning, and continuity and how those things are further influenced by COVID-19
3. Fires
4. Floods
5. Earthquakes
6. Civil Disturbances
7. Death and IT
8. Technology deprecation
9. Training, Simulation, and Knowledge Building
10. Upstream Thinking

But this is slightly backward in its thinking. It also has a lot of discussion about the shift from civil defense to homeland security that I don’t know is useful context for the type of work this course wants folks to do. It is a useful piece of context to understand current tensions in the field but not necessarily useful.

With Upstream Thinking at the end, this is sort of like pushing ethics in a computer science course to just 1 week that is easily glossed over. This is not useful, nor should be practiced by anyone. Upstream thinking is important for the next generation of EM professionals because it represents the current shift we see happening across the board. The response mindset is finding itself outdated. No longer are we “responding to threats and disasters as they occur” but “are thinking about where issues will arise given the probability of a disaster.”

Schedule

And this is where upstream thinking really helps to situate where that new mindset should consider itself. It is not without its issues and it certainly is not without barriers, roadblocks, or opaque spaces, but this is to be expected. Change in an industry like EM is not going to be any easier than that of change elsewhere. Change is hard, uncomfortable, and often chaotic.

And so, we need to reconsider where and when certain concepts are going to be introduced and how to distribute them. The obvious starting place is sort of the same:

1. The state of things — 2 weeks of onboarding.

Here, we can talk about the response mindset. We can also discuss how technology is not an answer, but something that can augment and enhance existing capabilities without complicating them. And this is also a good space to think about Upstream Thinking. After all, this is the concept I have embraced for this course and for future courses related to this one.

But where to go next?

1. Introduction to potential projects — 1 week

Here, I think after talking about where things are, introducing stakeholders from around Nebraska, Iowa, and the surrounding rural areas, tribal areas, public, and private agencies is a good next step. This will also allow the students to select projects they are interested in and get into teams.

1. Technology deprecation and the determinist mindset — 1 week

Fear of the old, the Shock of the Old. One thing that makes EM so hard to work in as an information scientist is a complete lack of so-called, “modern infrastructure.” We cannot expect things like i9’s as personal workstations, clusters, and other high capacity computing to exist. As a result, we need to temper expectations with a hammer called reality. Again, this is an upstream thinking exercise centered on the question, “How do I design to augment or help rather than replace?”

By placing this after the teams are set up, I can have the students do a rapid prototyping exercise and present those prototypes for discussion in class. While this should include stakeholders, I think a week for prototyping will allow for the groups to manifest product ideas that have been considered through multiple lenses and some of that tech-oriented, “chasing the shiny” would be fantastic. Next, we do need to present these with stakeholders.

1. Stakeholder discussions — 1–2 weeks.

So we have had 2 weeks of onboarding, a week to meet stakeholders, a week to develop some ideas. At this point, presenting concepts and ideas to stakeholders seems like a good idea. At this point, we now have some deliverables to think about.

Deliverables (homework assignments or tests)

Deliverables in class are typically things that serve faculty needs more than student needs. Shifting that balance while also meeting the needs of things like accreditation is important to me. Again, much like the philosophies surrounding this course, balance between policy requirements and useful exercises is important.

• Interests and personality quiz — “how do you work?
• Project selection quiz — “what do you want to work on?”
• Team collaboration environment checkin — “how are you organizing?”
• End-of-class prototype slide deck — “what do you want to do?”
• Report from stakeholders

So at this point, we have got a slow ramp up where students can self-select. I would imagine that the initial quiz about “how do you work?” will consist of my trying to figure out who is a procrastinator and who is not so I can balance teams. I also need to balance students with EM background and with tech backgrounds. A tension for this course, like all courses, will be the balance between learning and metrics.

Additional measures on quizzes for questions that get at the super important differentiator between learning and performing, “Do you only care about getting an A?” While that will not be the question I ask specifically, the concept will be useful to help arrange students into teams. Too much of a mixture of metric-driven students with procrastinators and learners is a recipe for spending an entire semester triaging teams rather than pushing their success.

Past that, I think check-ins with lectures and discussions of disparate hazards would be super useful. For example:

• The Verification Pause — the pause to wait and verify disasters are indeed heading your way before taking action.
• Race, gender, ethnicity, and other things we do not notice and why.
• Current models, expectations, consequences, and problems around resilience, risk, and equity.
• The gap between practice and research and its impact on seeing your work realized.
• Funding gaps among and between private, public, NGO, local, state, federal, and tribal EM spaces and its impact on tech integration.

And more. Basically, if we meet once or twice a week, half of the 3 hours of meeting a week would be devoted to discussion with references taken from the current work the teams are doing. I wonder here about additional readings because course metrics need to be something that I can access without issue. Additionally, those metrics should allow me to see how the course is reacting to the concepts that we are engaging.

These metrics should be useful in that I should be able to report them to the class as a means through which to talk about the opinions of the folks in the course and what those opinions might mean for their projects but also their ability to construct a project that will actually be embraced and used.

So I think here I might design some quizzes, brief assignments as user-testing, or perhaps some thought exercises around complex political arguments that their products will have to encounter.

The final deliverable for this course will be a design document paired with a slide deck. I like these two deliverables as it allows me to see how well the team works with 2 different methods of presenting their work.

The format of those documents will need some careful thought and additionally, I might ask the students to create a github account for the project to add an additional layer of permanence / physicality to them. Making them open-source and considering that world of licensing will be super interesting to do as so much of the “tech” in EM is not only closed source, but not even configurable or customizable.

In the next write-up, i’m going to concentrate on shortcomings, problems, hurdles, and everything negative.