Documenting the main activities led or supported by the SIMS Remote Coordinator for the Sudan Response.
I was confirmed as the SIMS Remote Coordinator on 2023-05-05, by which point I was already supporting the SMCC processes and attending technical IM working group meetings.
The Slack channel is where we will coordinate on tasks that come in from the field and assign them to the relevant SIMS member. The naming convention is to use the year of the event, the iso3 code for the primary country, and the emergency type. That makes this channel: 2023_sdn_conflict - See the channel here.
Access to the Trello board can get unwieldy when too many people pile in. As a result, we've stopped letting anyone who wants to join do so, unless they are directly supporting on a task. When you create a new board, go to Menu > More > Settings > Add/remove permissions and toggle to Admins only.
I created a new board called SIMS - Sudan Complex Emergency 2023. The naming convention isn't as important here, but that is the general pattern I like to follow.
Dropbox is another process that can seem confusing to users. The key thing to keep in mind is that ownership of a folder can be migrated to others, so we aren't locking ourselves into a single user's account as the host. However, it is important to use an account that has a Business-level license, as we will inevitably use more space than is available to free tiers.
Like Trello, we try to prevent too many people from having access to it unless they specifically need it. To do so, click on the elipsis on the far right of the folder in Dropbox's web interface, then select Manage Permissions
Inside the folder for the emergency, look to the top right of the screen and click on the Share button. Enter the email address of each remote supporter that you're granting access. Whenever possible, always use the supporter's work email address.
Back in the top level of the folder, click on the ellipsis. The window that pops up will have a gear icon at the top right.
Click on Link for viewing, then leave all the settings as their default.
Unlike many SIMS responses, this was an operation where the SIMS Remote Coordinator did not have a deployed IM Coordinator at first. The first week was spent dealing directly with stakeholders in the field in order to either directly triage their requests, or intuit based on conversations what products should be proactively produced before being formally requested. There will be an IM Coordinator deploying the week of May 15, and when they arrive, the coordination process will revert back to standard practice where the IM Co manages the process of identifying the requests and communicating them to the SIMS Co, who in turn facilitates the tasking out to the network.
We have set up a joint IM Technical Working Group with the ICRC to facilitate the sharing of resources and ensure we aren't duplicating each others' efforts. This group is currently meeting twice a week, but the cadence will likely increase as the operation staffs up.
There is an operations manager for Sudan that is currently based in Nairobi, but is planning on traveling to Sudan at some point soon once security issues are fully analyzed. He has been our main focal point and person requesting these products.
- Support Profiles: This was the first time we tried to align and categorize requests directly with the support profiles: geospatial, web visualization, information design, data transformation and analysis, and data collection and survey design. Having tasks organized (and correspondingly tagged in Trello) helps focus people's attention by the sort of specializations they possess.
- Dropbox Confusion: We continue to get people confused by Dropbox. We've heard complaints that people don't have more than the free 2GB tier can't sync the folders, but they shouldn't be syncing the whole thing anyway. You can choose to leave data in the cloud and only pull what you need, and since people tend to work on only a small subset of all the data in our top-level folder, they shouldn't even be invited to have access to the whole thing anyway (only relevant D- and P- folders).
- Translations: We need to establish better guidance and SOPs around translations. It's a chronic issue where info products need to be translated into languages that SIMS doesn't have much capacity with. And when it is for a language that we do have capacity—like Spanish—it can be a tough task to get traction on, as translations can be boring and thankless. The two options we tend to talk about include Translators Without Borders (which can be slow) or a paid solution (which we don't have budget for), so we need to figure out how to balance speed with cost.
- Kick-Off: Do we need a better way of launching channels? I just went to the General channel and let folks know, but a week later people are trickling in that I realize should have been there day one. What's a better way of socializing and engaging for those that aren't daily SIMS Slack users?
- Reinforce Dedicated Inbox: Teams struggle sometimes with initial rollout of surge-specific emails. The SIMS Co needs to be proactive about redirecting emails sent to their work address to the field.
- Logistics Data Collection: It's almost inevitable in larger organizations for the initial phase of the response to include a round of data collection about the National Society's warehouses' stock, the branch locations, and more. It feels a bit like we have to reinvent the wheel each time. A single, global round of data collection on branches has proven over the years to be unfeasible, as few National Society's are interested in what they see as a low return on the investment of their time in collecting all of this (and keeping it up to date). We should, then, have better preparedness in this area: more pre-defined workflows and products for capturing this information in order to speed up data collection.
- Expanding Design Asset Toolbox: We make the IFRC icon sets available in operations, but not all of those icons work for certain elements like maps. I recommend we decide on a common set of icons specifically for maps (e.g. pin, border crossing, hospital, etc.)
- Rethink How to Reference Datasets in Dropbox: We typically use two types of folders at the top level of the Dropbox structure: one for data files, and one for products. It makes sense keeping this separate, as it helps people find the data they need and to keep products' assets bundled together. But I've seen in this operation that when people reference data in a data folder inside their product folder, two issues arise. First, is that people might only be granted access to a product folder, and so if someone else comes in to make an update, they might not have the underlying data. And second, datasets change over time, which can lead to products that reference these data folders running into issues. I think we should treat data folders the same way programmers treat libraries that their projects reference. When you're working on a project, you install a specific version of that library in order to freeze any changes and maintain a local version. From a process perspective, this means when you create a new product, you should copy over the data files you're referencing, whether that's a shapefile, a CSV, or whatever else into your product's folder (and label that folder as 'data' or similar). If a product like Photoshop uses relative paths, that means anyone granted access to the product's top-level folder will avoid data access issues, and it freezes the data in place.