Process discovery is the first major step toward developing or adapting software that addresses specific needs within your organization. Unfortunately, emergency managers have several liabilities that often prevent them from following these standard best practices for process discovery. In general, this means working with a core group of process owners to define current processes and process goals to figure out how the software should be adapted. Liabilities include identifying:
- Reliable Stakeholders. It is always challenging to identify and sustain the engagement of key stakeholders. In emergency management, primary stakeholders may not even work for the same agency as the project owner, let alone agree on a process and who owns it. This makes it very difficult to maintain a team of dedicated stakeholders.
- Realistic Goals. Process discovery can easily turn into wish list documentation. During an emergency response, every second counts so anything you can automate or plan for helps save lives. Working with poorly defined processes and unreliable stakeholders makes it even harder to take outlying possibilities off the table and keep discussions focused on realistic goals.
- Well-defined Processes. In emergency management, processes have to be adapted to the type of response. Processes that work well for a small response may be too loose and chaotic for a large response. Meanwhile, processes that work well for a large-scale emergency may cause bottlenecks or other problems in a smaller scenario. This means that many processes are vaguely defined and infrequently documented.
These liabilities may not be a factor in every process you are trying to identify, document and build out, but if they do become an issue, here are some tips to help you get through them.
Reliable Stakeholders
The experts you need input and feedback from may simply be out of reach during normal operations, when you are building or improving processes. Ideally, you would not move forward without full buy-in from these experts. However, if that isn’t possible, you have to make do. One way to do this is to become as familiar as possible with the process and find a single, reliable stakeholder who will take some level of process ownership.
Without proper stakeholder engagement, you may have to document the process yourself. Identifying a starting place, even if it is just a list of the positions and steps you think are involved, gives potential stakeholders something to work with. Starting from scratch can be daunting, but if you take this on yourself, people who don’t have time to create documentation or even attend meetings are more likely to respond and provide feedback on your effort to document the process.
Realistic Goals
Process discovery can easily devolve into an opportunity to vent about processes and daydream about unrealistic solutions. War stories about once in a lifetime events that you cannot plan around or build a solution for are not going to add to the conversation.
Regardless of whether you have a robust, well-established Situation Unit that seems to have a straightforward collection and analysis process or a new, understaffed Damage Assessment team that has an overly complex process full of redundancy, you need to keep the focus on their primary goals. Similarly, trying to “over-automate” processes to make someone’s job easier can lead to the elimination of annoying, but critical, steps that might comprise the entire process.
It can be hard to steer the conversation back on track, especially with stakeholders you feel lucky to have participating at all. Create a wish list of things the ideal technology would do, but then focus on the first step – identifying the essential goals and getting a process down that can serve as a starting point.
Well-Defined Processes
One rule of thumb for process discovery is that technology should take a back seat. If you don’t understand the process, you cannot build or customize software to meet the need. Whenever possible, processes should be agreed upon and fully documented before technology enters the picture.
However, there are exceptions to this rule. For example, if there is an information gap that needs to be filled before hurricane season, you will need to get started whether you have the process down or not.
It is not ideal, but if you build a functional prototype that correctly recreates part of a process, you will have a very effective way to engage stakeholders. This is never a good place to start with process discovery, but if you are struggling with engagement it can be a great way to remove a roadblock or force some forward motion on stalled discovery.
If you have the luxury of starting with a well-defined process and fleshing it out with dedicated stakeholders, you are likely to end up with a much more robust and fully-realized software solution. However, if you do not have this luxury, do not give up. Take small, incremental steps to begin defining the process and build trust among stakeholders.
