Denise Roz Sewell is on the core team of Ushahidi-Haiti @ Tufts and has been instrumental in connecting with our partners at Crisis Camp. Roz is a Pickering Fellow and was a Fulbright scholar in Morocco prior to joining Fletcher. She shares a startling experience with us here.
Capacity. Comparative Advantage. Workflow. Crisis Camp. Ticket Tracking.
Before working with Ushahidi Haiti @ Tufts University (UH@T), all of the above words rarely, if ever, entered into my vocabulary. Well, to be fair, I did say comparative advantage a lot, but that was just because of an economics course I was in. The others, however, were not things I would talk about or even knew about. However, after Crisis Camp Boston came to Fletcher on January 23, I happily altered my vocabulary.
[caption id="attachment_1557" align="alignnone" width="500" caption="CrisisCamp @ Fletcher. Source: Carol Waters"]
[/caption]
This all actually begins on January 18, the first day UH@T began processing and geo-locating text messages arriving from the Haitian short-code 4636. At first, a small team of people could accomplish this task. We received about 100-150 messages a day, and our backlog was only 400 messages. (The short-code had started two days before we had put this team together.) However, the 4636 Haitian media campaign drastically changed all of that. We started receiving over 1,000 messages a day, and the four-person SMS team could no longer handle it.
We had reached our capacity.
UH@T’s comparative advantage is our ability to create a visualization of need with ridiculously accurate GPS coordinates; however, for the SMS team, we were getting stuck on the back-end. Currently, the way the Ushahidi platform is set-up, you need to have administrative access to report SMS messages coming from an outside system. I completely understand that feature. First, the messages contain personal information. Second, only a handful of messages (consistently around 30%) are actionable. This means a message that an aid organization can take action on, i.e. requests for food/water/shelter/medicine. Therefore, we needed to shift through 1000 messages searching for actionable items with a four-person team.
[caption id="attachment_1558" align="alignnone" width="500" caption="Ushahidi Back End"]
[/caption]
Obviously, this is not a productive workflow.
In came the savior of the UH@T operation: Crisis Camp. They had heard of UH@T and wanted to help. This team of developers was ready and willing to work on any project we wanted, and obviously the SMS workflow, or lack there of, became a priority. So I sat down with Ashirul, our Crisis Camp liaison, to develop a better system. A few users sort these messages deciding which are actionable; then, the UH@T team of volunteers geo-locates them, and then the UH@T core team maps them directly to the Ushahidi website. That way, the 300 or so actionable messages we received in a day could be mapped quickly by the 300 or so volunteers we were training without worrying about the stress of creating 300 or so new admin logins for the Haiti-Ushahidi platform. Then, the core team, the new experts on geo-locating, could double-check the coordinates before everything went live on the website. After Ashirul left, I laughed to myself. This was an ideal workflow, and to be honest, I thought it was a pipe dream.
This was when the phrase “ticket tracking system” became my new favorite.
[caption id="attachment_1559" align="alignnone" width="500" caption="SMS Management System"]
[/caption]
RT (Request Tracket) is a web platform that takes items, called ‘tickets,’ and manages them for the users within the system. It is fully customizable, allowing you to specify which users see which tickets and how tickets flow through the system from user to user. Using version three of this system and making source-level modification, the Crisis Camp volunteers started to make the ideal workflow a reality. Ian, pictured below, understood the importance of seeing this through to the end, so that at 1 am, after Crisis Camp had ended, he was down in the SitRoom with the rest of us still plugging away. He was a fast addition to the UH@T Tech Team, and by January 30, RT and our new workflow went live.
Now there have been bugs in the system, the server has crashed more than once, and Ian has received more than one (ok more than 10) crazy emails from me at 1 am. Through it all, though, we have been able to do our job because of this new platform. Let me give you an example, using our old Ushahidi and four-person team system working around the clock, we geo-located and reported about 30 – 40 messages in a day. The first full day of using RT, we put 150 new reports on haiti.ushahidi.com.
Personally, I will change my vocabulary for that kind of improvement any day.
[/caption]
This all actually begins on January 18, the first day UH@T began processing and geo-locating text messages arriving from the Haitian short-code 4636. At first, a small team of people could accomplish this task. We received about 100-150 messages a day, and our backlog was only 400 messages. (The short-code had started two days before we had put this team together.) However, the 4636 Haitian media campaign drastically changed all of that. We started receiving over 1,000 messages a day, and the four-person SMS team could no longer handle it.
We had reached our capacity.
UH@T’s comparative advantage is our ability to create a visualization of need with ridiculously accurate GPS coordinates; however, for the SMS team, we were getting stuck on the back-end. Currently, the way the Ushahidi platform is set-up, you need to have administrative access to report SMS messages coming from an outside system. I completely understand that feature. First, the messages contain personal information. Second, only a handful of messages (consistently around 30%) are actionable. This means a message that an aid organization can take action on, i.e. requests for food/water/shelter/medicine. Therefore, we needed to shift through 1000 messages searching for actionable items with a four-person team.
[caption id="attachment_1558" align="alignnone" width="500" caption="Ushahidi Back End"][/caption]
Obviously, this is not a productive workflow.
In came the savior of the UH@T operation: Crisis Camp. They had heard of UH@T and wanted to help. This team of developers was ready and willing to work on any project we wanted, and obviously the SMS workflow, or lack there of, became a priority. So I sat down with Ashirul, our Crisis Camp liaison, to develop a better system. A few users sort these messages deciding which are actionable; then, the UH@T team of volunteers geo-locates them, and then the UH@T core team maps them directly to the Ushahidi website. That way, the 300 or so actionable messages we received in a day could be mapped quickly by the 300 or so volunteers we were training without worrying about the stress of creating 300 or so new admin logins for the Haiti-Ushahidi platform. Then, the core team, the new experts on geo-locating, could double-check the coordinates before everything went live on the website. After Ashirul left, I laughed to myself. This was an ideal workflow, and to be honest, I thought it was a pipe dream.
This was when the phrase “ticket tracking system” became my new favorite.
[caption id="attachment_1559" align="alignnone" width="500" caption="SMS Management System"][/caption]
RT (Request Tracket) is a web platform that takes items, called ‘tickets,’ and manages them for the users within the system. It is fully customizable, allowing you to specify which users see which tickets and how tickets flow through the system from user to user. Using version three of this system and making source-level modification, the Crisis Camp volunteers started to make the ideal workflow a reality. Ian, pictured below, understood the importance of seeing this through to the end, so that at 1 am, after Crisis Camp had ended, he was down in the SitRoom with the rest of us still plugging away. He was a fast addition to the UH@T Tech Team, and by January 30, RT and our new workflow went live.
Now there have been bugs in the system, the server has crashed more than once, and Ian has received more than one (ok more than 10) crazy emails from me at 1 am. Through it all, though, we have been able to do our job because of this new platform. Let me give you an example, using our old Ushahidi and four-person team system working around the clock, we geo-located and reported about 30 – 40 messages in a day. The first full day of using RT, we put 150 new reports on haiti.ushahidi.com.
Personally, I will change my vocabulary for that kind of improvement any day.