Beware of Geeks bearing Gifts
In the run-up to the OCHA +5 Symposium (which apparently I’m not going to), Dennis King asks:
How do we get more “Non-geeks” to use information technology and tools on a consistent basis?
This has been the central problem with most of our work over the last decade. It’s particularly obvious in the field, where staff do not have the time to learn how to use new tools. There seem to be a range of considerations if we want any of our projects to succeed:
- Embed new tools into existing processes where possible. New processes are even harder to introduce into an organisation than new technologies, so enhance existing processes first. This builds the credibility of the technology and familiarises people with it, strengthening your position within the organisation for future developments.
- Build on existing and familiar technologies (mobile phones) rather than introducing new and unfamiliar ones (standalone PDAs). If you want staff to use a tool, it will be easier for them to accept and adopt if they are comfortably with it. This is why Sahana is browser-based, for example, since most people are now comfortable using services on the web.
- Invest in preparedness by a) training key staff in tools that we want them to use, and b) getting management support for their implementation. The first one may rely on the second, since you’ll need budgets to pay for training, but as I said above – don’t ever try to introduce something new in the middle of an emergency response.
- Make them useful. This might seem really really obvious but it feels like a lot of us forget it. We might think our project is the best thing since sliced bread, but if the rest of the organisation doesn’t agree, then we may as well not bother. Let’s start by helping staff to articulate how technology can help them in their work, and then move on to designing what they really need.
- It’s not just “non-geeks” that we need to persuade. IT departments in many of our organisations are seldom enthusiastic about new ideas, since they have the tough job of making sure that the old ideas keep working. We need a) to make sure that our IT strategies have room for innovation and b) our IT staff are aware that it’s acceptable for them to innovate. This will get ideas flowing.
- The final issue is our very own digital divide question. None of the above can be accomplished if we do not build better working (and personal) relationships between tech staff and non-tech staff. In nearly every organisation I’ve worked with, the links between the IT department and the Emergencies department has been very poor (if it exists at all). This has to change, otherwise we’ll never get anywhere.
These points were off the top of my head – any other thoughts are welcome.
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif){kind=small}
One suggestion would to use technology already in the hands of non-geeks, without forcing them to use new technologies, devices or ICT mechanisms. However sophisticated in and of themselves, ICT mechanisms that aren’t grounded in local work cultures will run soon become ossified artefacts.
I’ve written extensively on how ICT solutions for humanitarian aid need to be sensitive to, amongst other factors, the local socio-political, cultural, ethnic and religious dynamics:
http://ict4peace.wordpress.com/2006/07/03/humanitarian-aid-and-peacebuilding/
http://ict4peace.wordpress.com/2006/04/30/technology-for-humanitarian-aid-6-mantras/
and contributed to a list that a bunch of non-geeks at Strong Angel III (http://en.wikipedia.org/wiki/Strong_Angel) came up with:
http://ict4peace.wordpress.com/2006/08/24/strong-angel-iii-design-consideration-for-humanitarian-aid-systems/
Online Technology for Social Change: From Struggle to Strategy by dot.Organise is also compelling reading in this regard. Though US-centric, it clearly brings out the challenges of sustainable use of ICTs by “non-geeks”, irrespective of how technologically advanced the makers think their ICT solutions to be.
See http://ict4peace.wordpress.com/2006/10/17/online-technology-for-social-change-from-struggle-to-strategy/
Sanjana Hattotuwa
13 Oct 07 at 1:42
Paul,
Sorry to hear that you won’t be attending the Symposium and be able to talk with you in person, but glad you are contributing through this blog. You have contributed a lot to the progress in humanitarian information over the last several years. Thanks for your input into the Symposium Google Groups discussion and the issues I raised and I will make sure they are incorporated into the best practices and recommendations.
Dennis King
18 Oct 07 at 4:52
Hi Paul, I’ve made a few comments supporting and discussing yours, and adding a couple more on my blog.
http://www.rediguana.co.nz/gav/2007/10/22/encouraging-non-geek-use-of-information-technology/
Gavin Treadgold
22 Oct 07 at 8:32
Having had some experience in “getting” non-geeks in humanitarian organizations to use databases, I actually I think that this question is needs to be split up into a couple of different issues.
Information Technology and tools should be designed to enable non-geeks to do their jobs more quickly, efficiently and generally better, therefore we (the geeks) should NOT do anything to “get” non-geeks to use IT, they should just innately want it. We shouldn’t be trying to “push” the technology onto people, but instead we should be responding to the “pull” of what the non-geeks want. Geeks trying to “get” non-geeks to use IT, is like putting the cart in front of the horse. Geeks should be making non geeks aware of what IT is out there, and then responding to people’s needs.
Of course all of this hinges on the fact that the non-geeks in humanitarian organizations want to do their jobs more efficiently, which should be a given, although sometimes I fear that this is not always the case.
I’ve trying to expand this out in separate points below:
1. People need to be aware of the potential uses of technology. In my experience, this is seldom the problem. Any staff who are using computers (which is a fairly significant proportion) will know that IT has more potential than how they are currently using it (Excel isn’t the Holy Grail of information management!). And there will often be power users who push the envelope a bit further, and often have a good idea of their IT needs.
2. We need to respond to the actually needs, without getting carried away with the latest technology. I recently had someone coming into my office, asking me about GIS. Immediately my pulse started racing, and my head was filled with fantasies of all our project sites plotted on Google Earth. However after sitting down and talking with him, I realized that all he really needed, was a standardized Excel format to collect the project information in.
3. In order to ensure that our IT systems are useful, we need to involve all the stakeholders during the entire duration of the project. This includes specification analysis, development, training, and follow up. I believe that the Agile development model is best suited to the humanitarian environment. When I am implementing software (especially in the rollout), I make it very clear to the users that they are the most important people for ensuring that the software can be as useful as possible. I observe them using the software and encourage them to speak up to let me know what improvements could be made. I think this also increases their sense of ownership in the project, which adds to the sustainability of the project. I think that this is crucial for breaking down the digital divide (and power imbalance) between geeks and non-geeks. Geeks need to remember that we are service providers, and behave accordingly.
It’s interesting to look at the way in which the development industry has move away from top down program implementation, to a more participative approach, which involves the beneficiaries. I think that geeks could look at how we can shift to doing more “participatory programming” too.
4. Finally we need to look at the long term sustainability of our projects, which raises a number of questions:
a. Who will be responsible for maintaining and upgrading the software (and possibility hardware)? This could include everything from installing or restarting the software, restoring corrupt data, to changing the code in response to changing requirements.
b. Who will ensure that people keep using the software once the initial “geek” leaves? It is very important that people are comfortable using the software, and that they have someone to turn to when they have problems. But people also need incentives to keep using the software. Ideally it should make their jobs easier, which should be incentive enough, but incentives can also come from managers, or by including the use of the software in people’s job descriptions and evaluation criteria.
c. How will continuity be ensured, when staff leave and new staff arrive? It is important to “socialize” software to ensure that it will continue to be used. This can be done by including the use of the software in organizational policies and guidelines, writing training material and hand over guides for new staff.
5. IT departments are stuck in a difficult place. For them, new IT project can often represent an additional workload for them (well beyond the implementation cycle too), so it is very important to involved them in the project from the start.
The IT departments I’ve worked with, haven’t been responsible for developing new information systems. The projects I’ve worked on have been lead from outside of IT. Often there are IT staff who are capable of innovating, and may actually start designing new systems on their own. In this case it is imperative to ensure that they have sufficient communication with the program staff, to ensure that they aren’t just designing white elephants.
Michael Howden
23 Oct 07 at 18:09
Clearly a collection of IT proverbs is in development: how about ‘Look before you geek’ as a contribution? Too many IT projects in our sector forge ahead with only the most cursory scan of the existing landscape…
Paul is too modest to mention his excellent assessment of the use of ICTs in emergency reponse, carried out in 2005/6 for the Emergency Capacity Building Project, which deals with many of these issues in depth: (http://www.ecbproject.org/publications_4.htm)
Our more recent experience with ICTs in emergency capacity building suggests a couple of generalizations:
1. Where we have had success, it has been through a multi-disciplinary project team including both IT specialists and program people, involved from the get-go. Sometimes painful to watch: always worth it in the long run.
2. Related to this, our experience suggests that at least 50% of the budget and effort involved in an ‘IT project’ needs to be directed away from the computers and towards ‘soft’ activities such as facilitation, communication and internal marketing, if any return is to be realised on your IT investment.
Matt Bannerman
25 Oct 07 at 12:45
[...] – the “if you build it, they will come” principle (which has its limits, but is a good starting point). However then the article goes into areas which I really, really disagree with. “The IT [...]
humanitarian.info » ICT4Peace in the news
5 Jan 08 at 15:02