So for those who don’t know, this past Sunday I designed a simulation and training day for the Digital Humanitarian Network that we ran as part of ICCM. It was probably one of the most challenging simulations I’ve worked on for a number of reasons, but also probably one of the most important. I’ll walk through a few of the challenges and values-added, since there are broader lessons for response communities in regard to training and preparedness that come from good simulation design.
The biggest challenge was trying to conceptualize how the DHNetwork worked. I had participated in planning discussions and lunch meetings for a few months and as the designer I was perpetually unsure of the operational procedures the DHNetwork employed during an activation. I also didn’t know the individual groups that make up the network, so I was trying to think about what they could and couldn’t do in a simulated space. A good simulation is challenging, not impossible, so designing tasks was a challenge. In the end I had to make this work for me instead of against me.
I knew the DHNetwork was a network of volunteer technical experts who could backstop a disaster response operation, supporting mapping, data collection and logistics. I used my ignorance of their experiences and skills to create the tasks; if I wasn’t entirely sure what the individual members did, then a traditional response organization probably wouldn’t be entirely sure either. My experience has generally been as a civilian working in the orbit of military operators, so I tapped into my long-ago experience in defense contracting and training of military officers at USIP to imagine what a military actor would want from the DHNetwork during a disaster response.
This approach led to tasks that were focused on the process of discerning what the client really wanted, instead of completing discrete tasks. If a tsunami hit Samoa, what would the Australian military ask for? How would they ask for it? What is the implicit knowledge on the military side that a civilian volunteer would lack, and how would the DHNetwork pass requests for clarification back to the client? Teasing out this process, with an observer from the Department of Defense on hand to offer his insights to the group was a huge learning opportunity.
Along with dealing with external actors, the process of designating who deals with which request within the DHNetwork was a challenge we needed to address. Peeling back the layers of a brief, unclear request and finding out where the statistics, the mapping and the logistics of the request exist is a challenge, and this challenge is doubled when people are not interacting face to face. This simulation was a chance to get some face to face time between all the group members and see how everyone interpreted unclear or brief requests that were complex in practice.
These were the two areas I focused on when designing the simulation that would be good take aways for others facing similar tasks. First, when doing simulation design the most important thing is to work with what you know. I have a background in quantitative modeling, political economy, and working with the military. I didn’t create mapping exercises since I’m not a GIS expert; instead I created exercises that encouraged process creation among a mix of technical experts, which proved more valuable. The simulation focused on the ‘what’ [are we doing], not the ‘how’ [are we doing it]. More often then not in my experience participants will be experts on ‘how’; what makes a better learning experience is the ‘what’ [are we doing] question.
Was it a (sometimes stressful) challenge to design this particular event? Absolutely, but it was a lot of fun and there are few things more satisfying than seeing valuable learning and information exchange come out of a well-designed exercise.