Speed Portal - Final Blog

As the HIF funding for this project has come to an end, a working version of the Speed Portal prototype is available for free to any organisation who is interested in using it, so our overall project goal has been accomplished. That being said, as with any project, there are things that didn’t go according to plan and while we achieved more than we set out to do on the technology front, we learned less than we hoped around the decision making process.

Some of the key stumbling blocks, bottlenecks, and things we learnt in the process of implementing this project include:

;

1. In most organisations, IT is viewed as service delivery hardware, not a strategic enabler

Historically organisational IT departments have provided computers, networks, and a “help desk” focused on assisting users to understand how to use their computer. In most NGOs, this is still the case – they are a service delivery department, not engaged in strategic decisions or discussions about how to enable the organisation to deliver its goals and strategy.

Most aid agencies use social media for marketing and fundraising as well as dabble in using it for communications. This project enabled organisations to use social media, the internet, and digital processes for operations, which was a foreign concept for most and it challenged organisational ways of working. We underestimated the levels of resistance we would face in implementing such a project.

Beyond operations, there also is a massive opportunity for agencies to better engage their “general public” supporter base to help process information and reduce information overload. Again Crisismappers does this well, as does American Red Cross. The Speed Project team experimented with this during Typhoon Haiyan by using a small group of volunteers to plot information on the Portal – we learned this is possible, but to do it on a larger scale we need to create better processes. It is also something that can be done individually or together in a large room creating a type of atmosphere. Small-scale experiments with this type of engagement can continue, but for larger rollout, it needs to be part of organisational disaster preparedness.

;

2. Information management is poorly understood

Similarly to the above, information management is poorly understood in organisations even though almost all lessons learned processes completed over the past decade list information management as one of the key pain points of disaster responses. Information requirements are usually silo-ed in departments with no one having an overall view of the requirements and the inter-relational between information needs. Finance keeps to finance, operations to operations, logistics to logistics, communications to communications, and so on.

Additionally, aid organisations love to consume data, but tend to be reluctant to share data. The Speed Project team learned that we need to better engage with the Digital Humanitarian Network and Crisismappers; ideally this would work out so that in a rapid-onset, Crisismappers would manage public data input streams (social media, RSS, etc.) with World Vision contributing to this, but also accessing it as their main map.

;

3. Technology is a minority part of the solution; People are the majority

A good rule of thumb is that technology is 20% of the solution, while people are 80%.We struggled with this rule as we fought against internal politics and the lack of information management knowledge and positions in organisations.Due to the time we spent in design, we were able to build a prototype quickly when we secured funding.Typhoon Haiyan allowed us a baptism by fire test, which was fine for the “tech” side of the project, but not ideal for the behaviour change aspect of the project. There wasn’t a trained/dedicated Information Manager for the Haiyan Response, therefore, the Speed Platform deployment was limited to testing the functionally of the MVP and not whether the Speed Platform aided information management and decision-making.

Looking back, increasing the number of locations and tests we did would have been helpful, even sharing the prototype with the wider humanitarian community while it was still in development could have provided us with more options to test, which would have be beneficial.

;

4. Communication is never finished and is never enough

As with any project, there is a constant need for communication and should be done using multiple channels and styles – we used one pagers, demos, presentations, &; blogs – directed at various audiences.Some people understood the project immediately, while others took vast number of conversations and still struggle to understand.We learned that people, especially senior leaders, make significant assumptions about what they hear based on their worldview and what they are engaged in – breaking through those assumptions is incredibly difficult.Looking back, we would have benefited from engaging marketers/communication specialists early on as this may have assisted with the behaviour change and communicating the features of the Portal.

We wrote a project blog, which proved to be valuable for partner engagement. Interestingly, it proved to be more popular with people outside World Vision than internal staff.

;

5. Third party validation helps credibility

We did this at least twice – once at the beginning engaging Accenture Development Partners (ADP) to do a market review and short-listing of potential options for the various Speed Portal components and once near the end engaging Thoughtworks to do a similar market review to understand how the market had changed. While both market reviews did not lead to insights the Speed Project team was not already aware of, it assisted significant in communicating internally and externally.

;

6. Time spent in Design is valuable

• People often struggle to differentiate between what is mission critical and a nice to have, however defining and prioritising them is critical in the design stage as it helps define the overall fundamental building blocks of the project and identify the components of a Minimum Viable Product
• Start with paper and pen, then as quickly as possible build a working basic prototype and get it in the hands of users
• Hiring a User Interface (UX) designer was hugely valuable for the project to begin to visualise the Portal and to test assumptions
• The design phase included significant interaction and two-way communication resulting in buy-in and support from the frontline responders as they felt engaged.

;

The Speed Project has ended up being viewed in multiple different phases with lots of ups and downs throughout its life as the image below shows. We anticipate this roller coaster to continue as some organisations incorporate aspects of the Speed Portal into their daily use, and while others use the working prototype as is and continue to development. The team behind the Speed Portal will continue to develop it and work with organisations interested in improving their information management and decision making in disaster responses.

The ability to scale this project is enormous, especially if key partnerships with the Digital Humanitarian Network for the initial 14 days could be increased. However, what we have found while implementing the project is that it is important to start from the needs of the organisation rather than trying to push a particular product.

We’d love to hear from you about how you can use the Speed Portal and/or how we can help you use it. Please get in touch!

Amos Doornbos, co-led the development of the Speed Portal for World Vision, is Director at Faces of Another World