Purchasing technology for disaster management is sometimes a costly and drawn out process for a variety of reasons. From procurement to training to incorporating into plans and procedures, implementing new solutions is not always easy or cheap. And in recent years, there has been an explosion of disaster-specific and non-specific applications that can be used by disaster management organizations. Open source technologies have gotten better and new market-based solutions have been developed. The market is really starting to grow and mature.
As it does though, we must prepare ourselves to see technology as dynamic and evolving rather than static and stale. The socially adept world in which we are now living is causing a cultural shift in our approach to technology adoption. And this is even more true now to social media and other social technologies are changing the way we operate from solely a formal response to also enabling an informal response. Consequently, this change in mindset affects many things in our organization including: IT & response policies, how we plan, training, purchasing, operations, etc.
Here are a five considerations as you look at new solutions to help you do your job better. You should consider applying them in this order as well.
1) Does it really meet my core needs?
First, can a change in process or people be more effective? Sometimes solutions are as simple as a few personnel or process changes and can be more effective in the long run. If not, you should conduct an environmental scan to identify the tools that address this problem. Touch base with your network and put the word out on social media that you are looking for a new solution to address this problem. You will be amazed at how many leads you will get from your friends and your network. After that, compare and contrast the tools against usability, scalability and support. Ask, what will meet my organization's and community's needs best now and in the future? Ultimately, you want a solution that will evolve as your needs evolve.
I am seeing amazing solutions being developed everyday. Many of them have whiz-bang features that are awesome. But at the end of the day, the solution still needs to help you solve a core problem whether it be efficiency, information management, communications, etc. The ability of the solution to address your core problem should be of paramount importance with the rest of the features as bonuses. Careful thought should be applied to defining your current challenges.
2) Is it usable?
I like to use the rule of thumb that the solution should be intuitive for someone who knows his or her job well. If it is not intuitive, red flags should be raised immediately. If the person who has primary responsibility of using the solution can't figure it out easily, how do you think someone thrown into the position last-minute will react? We often pride ourselves on our dynamic capabilities during a disaster. Usability is a central component to remaining dynamic and to scaling effectively.
But usability also has some added benefits. Better usability leads to lower training costs and easier adoption. No longer are full classes required just to learn how to use a system. The ubiquity of online tutorials and quick tips can help someone learn a system faster and become highly proficient without much training. If the vendor doesn't provide easy access to support material, creating your own is easy as well. Some simple software can do the trick.
As you adopt a more adaptive technology adoption strategy, your organizational and community culture will adapt to the point where the digital divide becomes less and less of an issue and just in time training can be more effective. In fact, there will be less skills degradation over time as people take it upon themselves to learn new technologies rather than waiting to be taught.
3) Can it scale?
During non-disasters times, we only have a core group of people using a platform. But disasters are never a solitary response. We call upon many people to help coordinate, manage, and execute a response. They come from various organizations and backgrounds to help support. Solutions should support this scaling of people with easy additions of members and the ability to work across organizational boundaries using the solution.
In addition to easily added and managing members, the solution should effectively manage the massive amounts of data and information to provide meaningful decision supporting information. After all, a giant feed of unstructured information is rather unhelpful when deciding to deploy resources. You have specific questions about road conditions, prior decisions, decisions from neighboring communities. You also want to know the latest information and updates and see them in both their aggregated and non-aggregated forms. Solutions should understand this and be developed in such a way that functionally specific questions can be answered easily. Robust search and dynamic charts are key things to look for
But people are not the only consideration. As more people use the system and data is inputted from a variety of sources, you need to know that the solution can scale from a technical perspective. Is the server going to get overloaded? Is there failover in place? Is there enough bandwidth? Many hosted solutions address the first two concerns very well since they are on the internet in a well protected environment outside the impact area. They have the resources to build in scaling architecture into their systems. As a result, you don't have to worry about the software crashing on you as your main priorities become only maintaining the power and Internet infrastructure. Some solutions even have offline applications that cache data until the Internet connection is back up.
4) Can it integrate?
Integration is the future of any disaster or non-disaster related application. It is highly unlikely that we will ever see one solution that meets all of our needs. In fact, it is bad for innovation as the economic incentives for the vendor to constantly improve the system are mal-aligned. If you are locked in to their proprietary solution, why should they devote resources to improve the system? Needless to say, I am not a fan of vendor lock-in. The more competition that is out there, the more innovation and improvement we will see as vendors and open source projects compete to be the best solution for you.
Because of a recent focus on big data and integration, a technology ecosystem for disasters is developing that will enable tools to talk to other tools. The more data that can be mashed together, the more we will achieve better process efficiency, better insights, and ultimately a better operating environment. But integration from a solution should not be a custom add-on. This should be part of the core offering of the solution. In some cases, these are integrated applications (app stores), data standards (HXL, EDXL, etc.) or application programming interfaces (APIs). Whatever it is, integrating the solution with other modern technology should not be a cost intensive process. Of course, if you are dealing with antiquated internal systems, this is a different story. But your choice of technology today should account for the ability to easily integrate. This will pay off dividends in the future.
5) Does it have support?
Support is a relative term and does not always mean vendor support. Having a technologist on staff or an application guru that can troubleshoot may be all that is required. Whether you are considering an market-based or open source solution, consider what resources are available to troubleshoot and assist. They can range from online self-help forums to online tutorials posted by users or the developers themselves. Some solutions are so mature that bugs are nearly non-existent. As such, having a person on staff who is the application guru to offer advice and troubleshoot users' problems may be a good workaround.
Inventory your staff for their skills and interests. You may find a number of technology evangelists that can support you better. The added benefit is that they know your policies and procedures well. Calling someone on the phone or chatting with someone online inherently increases time, energy and frustration as they are not well acquainted with your specific operating environment.
Conclusion
There are many solutions emerging in the market. From market-based to open source solutions, you can probably find what you are looking for. In addition, there are many solutions for other industries that are very applicable to disaster management. For example, social media aggregators like Hootsuite are often built for a wide range of industries and can be applied to the disaster use case fairly easily. In some cases, a white label social network may serve as your primary EOC software. Incorporate non-disaster solutions into your environmental scan. And lastly, don't be afraid to forgo a solution in favor of a change in staffing or process. In fact, a number of organizations that already utilize Google Apps have had much success using its existing applications collect and manage data.
As I reflect on the past month in my 
Government Led, Community Reliant. Building off the issues with interdependencies, we also have a mismatch occurring in that initiatives are often government led, but effective responses to disasters are extraordinarily community reliant. 
The biggest thing driving me to pursue a PhD is the intellectual curiosity I have, especially with so many unique and amazing things taking place in the industry. Social media has taken the industry by storm and technology is changing the way disasters are managed. As a result, there are so many unanswered questions, especially empirically. 
