In my previous posts I have discussed the importance of having access to key baseline information and a place to share it (the Crisis Information Repository). While having access to baseline data is crucial, it is also very important to have information about who is participating in the response, what they are doing, what they are observing, where they are working and how they are serving the beneficiaries.
Withi UN OCHA, part of this has been addressed using what they call 3W (Who What Where), which attempts to track who is involved in the response operation, what they are doing and where they are operating. The big problem with the approach they have taken is that it becomes OCHA’s task to collect and maintain this list. It is therefore very often not up-to-date nor too accurate. With the growing number of organizations involved in humanitarian response (there are 4000 registered foreign NGOs working in Haiti for example) it is time to rethink this whole approach.
Six years ago the humanitarian community was introduced to the concept of Clusters. Today there are 11 clusters (education, early recovery, shelter, WASH, camp coordination and management, protection, emergency telecommunication, logistics, agriculture, nutrition and health). The concept behind clusters is nothing new – you group together those organizations that are working on a particular subject area (like education) and get them to coordinate amongst themselves what they are doing.
The cluster system took off slowly, but now it is used in every emergency and we are starting to see progress in its use. One area though that is still lacking in the clusters is their ability to share information effectively between each other. Three years I ago, while still working for Microsoft, we embarked on a project with UN OCHA on designing a platform for information sharing between the clusters.
The project, which became known as OneResponse was based on the concept that you would have a single platform where clusters would upload documents related to the operations within that cluster. UN OCHA would then be responsible for uploading information related to the overall inter-cluster coordination. Although somewhat successful, the project had its ups and downs. It did show that information sharing between clusters was a key enabler and that having a platform simplified this. What however failed greatly was that it was made too difficult to share information, especially for those operating in limited connectivity environments.
Pushing everyone to use the same platform has its benefits and its drawbacks. Many clusters already have their own sites, while others mainly utilize email for information sharing. At the same time, many NGOs feel they can not easily share information about their work through this kind of platform because of the complex processes involved in uploading the information. Given this and new approaches to sharing information in other fields, I think it is time to rethink this whole information sharing approach.
What we need to do is to learn from the Web 2.0 environment and create a simple, yet effective way of sharing information about who is working where, what they are doing and the more detailed information about the needs of the beneficiaries and the response given.
When you respond to an emergency you should bring with you a profile of who you are and what organization you work for. This profile should also contain information like your email address, phone numbers, etc. When you deploy you should have the ability to check in to that particular emergency. By checking in, you are letting everyone know that you are responding and that if they want to contacts you then you have thereby shared your contact information with them. Once you check in you should be able to see who of your colleagues and friends are also responding to that emergency. It in namely very important to know which people in your “social network” (here I am not referring to any technological solution, but the real life friends and colleagues you have) are responding, because so much is done through those relationships (more on that in a later blog post).
Similarly you should check yourself (or your organization) into the particular clusters that you operate within and into the areas/districts/villages you are doing work in. When you check yourself into an area you should also provide information what work you are doing in that particular area.
This check-in mechanism should be as simple as possible and it should work via SMS, web, email and smart phone clients. That way it becomes easy for people to update their information. And instead of having to pass around a contact list fill-in sheet during every cluster meeting, it becomes enough to say “remember to check in to the cluster by sending the text ‘WASH’ to the number 3242. Just imagine the number of hours saved in entering and editing contact information!
Once you have checked into an emergency, any information you share either through a specific website or client or through Twitter, Digg, Tumblr and similar services becomes flagged as being related to that emergency (one could also tell you which hashtag you should use if one wants to have this very flexible). This means that if you want to share the results of your assessment in the field, then you can simply post that document anywhere on the web (including your organization’s website) and by sharing the link to that document then it gets picked up as being related to this emergency.
One could envision a central site which would provide the user with the ability to see all documents that have been shared in this way. However to make the site more effective, it would make sense to allow users to filter what documents they are interested in. In this way each user would be able to quickly customize the look and feel of the site to only shows things he/she is interested in. Since research shows that in the field few users have the time or even the skills to do customizations, then one could envision a set of templates, for example the ability to say you are only interested in education cluster related documents in the emergency you are checked into.
But that leaves one tricky part out, which is how do we get from a user or organization posting a document and publishing the link into the system to the ability to filter the documents based on various criteria. The key here is to use an effective tagging mechanism. By having the ability to associate with each information link a set of meta data tags, you can then provide users with the ability to filter, group and sort based on these tags.
When documents are first published then they only have those tags associated with them that can be automatically deferred from the posting itself (for example by looking at hashtags in twitter posts). Any user should then be able to add tags (including geo-tags) to any document, because it is through the collective wisdom of the crowd that we can scale this effort up.
At the same time, volunteer technology communities (see previous post on those) can be leveraged to go through documents that have come in, read through them and associate appropriate tags. It is also important to remember that ReliefWeb already does this to a large number of documents that are published by NGOs, governments, media and donor agencies.Their editorial team and content gathering should serve as the backbone of this service. Given their new platform and architecture that is coming out, they could also serve as this central site that everyone would utilize.
The key here is to make this as painless and easy for the organizations on the ground to share information with each other. That information could be in the form of documents, but also in the form of updates on where they are operating and how they are serving the beneficiaries in those locations. If the information is then geo-tagged along the way, it can be surfaced in map based format for easier visualization.
It would also be important to have an occasionally connected client that would be able to surface this information on a computer or mobile device that is not constantly connected to the Internet. Data should be downloaded based on preferences when connectivity is available and it should be easy to share new information even when not connected. Information that then gets uploaded next time you are in reach of a network connection.
Once you have data being tagged and collected in this manner, you can again leverage volunteer technology groups or expert communities outside of the disaster zone to start combing the information from multiple sources into the Crisis Information Repository. There are even tools out there today that allow you to do this, if the data sources for the various information follow a similar format.
Then of course to ensure that the contact information is always up-to-date then you would check out of an emergency when your mission comes to an end. This is just as important as to know you are there.
But how do we go about creating this kind of a 2.0 environment to use. I believe most of the infrastructure already exists in cloud based services that are available today. We should leverage standard protocols such as RSS and Twitter streams instead of trying to create our own. We should aim for simplicity and usage models that are proven. We should make the user experience as simple and as much like the experience they are already used to in social media platforms today.
Want to play a role in making this a reality? Share your comments and enthusiasm and maybe we can have something like this up and running quicker than we expected…
Published January 26th 2011 at DisasterExpert