I was reminded recently of a project I worked on several years ago for a local university. This software was a simple system to be used in emergency situations to help account for students who may have been affected and get them connected to medical services or parents as necessary.
Usually when I write software, I get excited by the idea of people using it and being able to enjoy it or at least have it solve a problem for them. In this case, you hope that no one will ever have to use the software.
As I think about preparedness for an emergency and creating software to be used only in extreme and potentially catastrophic circumstances, it creates some unique design challenges.
One of the trickiest parts of designing software to be used in emergencies is trying to predict what circumstances will be at play and what to account for. If you make the wrong assumptions about what resources will be available (e.g., power, internet), you may create a system that never gets used, even in a disaster! You also have to create an application that solves the key issues while staying flexible enough to handle unforseen problems that the operators may need to adjust to on the fly.
Everyone works for someone, and if you take on a project building emergency software, you will be bound by budget constraints. The system that I worked on all those years ago is apparently still in use, and has had some minor upgrades, but the core system is based on 10 year old technology. Once you have an emergency system in place, it will likely get stale and rusty as people invest in other areas that have a more tangible impact on customers & the bottom line. So you have to think about how to build something that will require minimal maintenance and be as self contained as possible.
For the project I worked on for the university, this meant that we had dedicated laptops and each machine could run independently, without network or anything else. It did not rely on computers being available or having to install anything to get up and running. They also had low-tech ways to get data onto the machines.
Ease of Use
My emergency management software will be used (if ever) by people who I’ve never met and who will have never used it before in real life situations. Ideally the software would be designed in such a way that it would be intuitive to most people without prior training. This is very difficult, especially if you build the software 10 years in advance. The norms of software design change dramatically in that period of time and even something that seems intuitive at the time its built will look outmoded and cumbersome a few years later.
So how do you get people used to using software they will hopefully never have to use? I would say the best answer is to create situations in which they would use it. For example, one way would be to deal with minor crises or situations using the same systems you would use during a bigger crisis. Another approach would be to do regular “fire drills” with key people who are responsible for safety, or likely to be “first responders” in an incident. Coupling this with process & crisis training should create a higher likelihood of better handling during a disaster.
Building software systems and teams that are effective during times of crisis take investment of time & resources. But the payoff should be worth it considering that you will create a capability to deal with problems you can’t have any other way. Sadly, this investment is much easier to justify after a recent problem rather than before, as people become complacent during times between crises. Design for intuitive flexibility in general crisis, find ways to use the software regularly, and be prepared.