Gav's Blog

One of my fellow Sahana Board members, Paul Currion, has been asked – How do we get more “Non-geeks” to use information technology and tools on a consistent basis? Paul has come up with six good points to which I’d like to comment on his offerings, and then suggest some more.

1. Embed new tools into existing processes where possible.

This is essential for ensuring people use the tool on a day-to-day basis so that they are comfortable with the technology that they are using. Much as most people are comfortable using a web browser and email. However, we strike one difficulty with IT specifically designed for disaster/emergency management, in that it is the sort of information system that is often infrequently used, except by those that are regularly responding to disasters.

;

2. Build on existing and familiar technologies rather than introducing new and unfamiliar ones.

Familiarisation with any form of technology is almost always required for proficient usage. However, one of the problems that we often face in disruptive events such as disasters is that the familar systems become unavailable or their functionality is degraded due to the lose of say electricity or a connection to the telecommunications network or the Internet. This is particularly the case where a technology has been designed to work well under normal circumstances, but it does not degrade well. This has commonly popped up where organisations are trying to produce a nice Internet service for disasters, but sometimes miss the critical point that people in the affected area may not have Internet connectivity, and hence not be able to make use of their service. Therefore, any purchasing decisions around technology needs to also consider how they degrade during a disaster, and how resilient the technology is. This suggests that users need to become more familiar with resilient technology such as peer-to-peer networking, systems that can store data locally, and operate in a disconnected mode.

3. Invest in preparedness by training key staff in tools that we want them to use, and getting management support for their implementation.

Training is of course not only an issue for technology, but also for other processes and management techniques that may be used during a disaster. I don’t quite agree with with Paul’s suggestion however to never introduce something new in the middle of emergency response. As long as there is a process to manage change – particuarly reviewing the success of any modifications – change should be allowed in response, but on a measured basis. Often times it is response to a real event that identifies shortcomings in training, systems and/or processes that need to be customised on the fly to improve response. This can include the introduction of new technology as well – but once again the benefits should be well justified to cause a change of systems.

4. Make them useful.

I wholeheartedly agree! However, there is a stumbling block here where, and it is one that we are experiencing with Sahana. Without the engagement and involvement of the end users during the design, development, testing and implementation stages, we can’t guarantee that we are producing a system that is truely useful to the end users.

Related to this is the fact that it can often be difficult to build a technology that is useful for everyone. Different users in the same domain may see diffierent levels of utility and have different requirements of a similar tool. The answer to ‘Make them useful’ then is that it can be difficult to optimise the utility of a form of technology without decreasing the utility in at least some of the users – especially when some forms of utility may not co-exist within the solution.

5. Engage the geeks.

This should be quite easy, as geeks tend to grasp concepts quite quickly, so in most cases it is little more than increasing their awareness as to why they should investigate new ideas and strategies. It is also important that they mix with geeks from other organisations to allow cross-pollination and the sharing of ideas. I believe that getting involved in community driven and led projects are the best way to encourage this. There is nothing like being kicked out of your comfort zone to encourage greater thought and engagement.

6. The Digital Divde.

Yes, we do need to bridge the divide between the tech and non-tech personnel. In the article, Paul gives the example of the IT department needing to better engage with, in our case, the part of the organisation responsible for emergencies. I’ve seen some of these problems first-hand outside of emergencies.

I think a lot of the problem boils down to this. Often, the IT department is understaffed and it has to meet the needs of a whole organisation with many different tasks to fulfill. The part of the organisation that is responsible for emergencies also operates with too few personnel, but more importantly, they lack the technical knowledge to be able to meaningfully engage with the IT department.

This is probably a good point for me to offer some more suggestions.

7. Get more tech people involved.

A question I’d like to raise – is it easier to train disaster response personnel in technology, or train technology personnel in disaster response? It may be that, in terms of the use of technology for response and recovery, that it may be easier to take technologically proficient people, and train them in disaster response, rather than trained personnel to use technology. Let’s face it, if you are in an environment that isn’t particularly technology friendly such as a disaster, I’d prefer to have someone that is technically adept and can adjust and customise on the fly, rather than someone that may struggle at the first hint of going outside their technology training. Perhaps we shouldn’t be encouraging non-geeks to learn technology, rather we should just send geeks in there to do the technology work for the non-geeks so that they can focus on the key skills that non-geeks have, such as people skills, management, and experience with disasters.

8. Get younger people involved, or just let churn take care of it.

Some people may not like me for saying this, but we are already seeing a flood of personnel coming into every workplace that are completely comfortable with technology and will be screaming out for it – the texting, facebooking and youtubing generation. This again raises the question of should we try and train people that possibly don’t want to be trained in tech, when we could be looking at selecting people that are comfortable with technology and give them the training appropriate to assist our organisation in response and recovery. Clearly as the years go by, natural churn within organisations is likely to bring increasingly technically adept people into organisations – all we have to do is wait.

9. Accept that we will always have a difference between geeks and non-geeks, and realise that we should manage around it.

Just like any organisation, people have strengths and weaknesses, and it is critical that the leader builds the best team to meet the needs of those affected by a disaster. This is unlikely to be a team where everyone has tech skills, rather the manager will have a mixture of personalities and skills best designed to meet the task at hand – this may mean accepting that some people do not need to be trained in tech, rather they just have to have some damn good backup sitting behind them that can meet the technology needs of response and recovery.

To summarise, I don’t know if the issue is really how do we get more non-geeks to use IT more consistently, as this will come with time as more technically adept personnel enter the organisation. Perhaps we just need managers that are capable of recognising when and how technology should be involved and that they have the support to accomplish that.