By Ebe Brons, INSSA Board Member and CEO of Centre for Safety and Development**
Nine years ago we, Arjen Joosse who works for World Vision and Ebe Brons from Centre for Safety and Development, started the Simson system***. Our idea was to develop a system in which NGOs can share their security incidents. The goal of the system: saving the lives of aid workers.
Our initial concept was a real-time incident reporting and sharing system that projected the information on a satellite map. This map was needed to make the system user-friendly and also because it looked cool.
Simson 3, homepage
Looking back after nine years, this concept was too idealistic. We had this notion that fellow NGOs would tell each other where dangers were lurking and by doing that, give other aid workers the opportunity to mitigate this risk. In the end this would save lives and improve the quality and access of programmes.
A simple example; an NGO would be robbed at an illegal checkpoint. The aid workers would alert other NGOs via the Simson system. These NGOs would take another route and by doing that avoid another robbery. It proved to be an assumption too easily made.
Simson 3, Field Location
In almost a decade we went from a very idealistic system (Simson 1) to a more pragmatic system that is a general security management system for NGOs (Simson 3). We added security document sharing, provincial threat assessments options, field office compliance levels and many more features. For this paper, these are not interesting. What is interesting are the challenges and hurdles we had to overcome.
Simson 3, Threat Assessment
The first lesson we learned was that sharing security incidents between NGOs is not a given. Although rhetoric in the NGO security management world might give you a different idea, the reality is that NGOs are not very eager to share real-time incident reports with other NGOs. And to be honest; it is only very human not to share. In the Netherlands we have a saying that you do not exhibit your dirty laundry outside for everyone to see. This is no different with security incidents. Embarrassment about what went wrong is always a factor in these matters. To ignore this fact is to ignore the human side of security systems.
How did we solve this problem? We developed different compartments within Simson and added a new concept: internal sharing (within your organisation) and external sharing (outside your organisation). Every participating NGO has its own isolated section in Simson and reports, analyses and shares its incidents internally. Sharing to external NGOs is an option. Participating NGOs can decide themselves how they want to share. Most NGOs start with internal sharing. This can be a stepping stone for sharing externally if the need arises. The advantage of sharing externally is receiving more security information from other NGOs. This can be extremely helpful for your own security management.
Secondly, we learned that getting staff to report incidents is not easy. This is another side of the ‘dirty laundry’ issue, but is rooted internally. Sometimes an incident happening is just very bad luck. But if we are honest, human behaviour almost always plays an important role. Aid workers ignore a curfew and are robbed at a checkpoint at night. A colleague is a bit naïve and in an bar expresses too loudly that he is alone at home tonight. A robbery follows. Someone does not like to make a proper travel plan and forgets to check the car. He ends up with a flat tire in the middle of nowhere. Let’s hope only the car was stolen. All security related moments that are probably not your best moment in life. Or something you are proud of.
If bad judgement is involved in the occurrence of an incident, who is going to report it? The aid worker? What will the (career) implication be for him or her if (s)he does? The Security Manager? He or she might also be reluctant to report, fearing others might think (s)he lacks control. The Country director? If the incident happed on his or her watch, would you not question his or her leadership skills? Security reporting a not a neutral action.
The problem described above, is not fixed easily. Basically, it is not a technical problem but an managerial problem. For staff members to start reporting incidents, a culture change is needed. CSD wrote an article about this topic with the title: NGO Security Incident Reporting; Towards a “Just Culture”.* The Just Culture approach comes from the aviation and medical world. The basis of a Just Culture is that people make mistakes and that that is ok. These mistakes are to be reported not with the intention to punish the staff member but to update and improve your security system. Only unacceptable behaviour might result in punitive actions. Organisations that implemented a Just Culture saw a sharp rise in reported incidents.
Thirdly, complexity of a system can be a problem. Complexity has several aspects.
For example, it has to be extremely easy to start using and to keep using the system. When we started with Simson 1 nine years ago, we used Microsoft Groove. This was a sort of Dropbox long before Dropbox existed. The user had to install the Simson programme via CD-ROM to their computer. This hurdle was too much for most users. If they did succeed they had to change some parameters in the programme. This was the part that made the rest abandon the system.
We also learned that cool features and complex filtering systems was something that users wanted but never used. In the end they want a simple system that is understandable and user friendly.
Staff turnover was another hurdle. The staff turnover within NGOs is very high, especially in the field. This emphasises the need for a simple system because you will have to train a new staff member every time someone leaves. A simple system is easy to explain and makes training your staff less of a hurdle.
We also learned that users do not like Excel. There are exemptions of course, but most people do not like to use it. Simson 1 was based on Excel (via MS Groove). This meant that users had to fill in a great number of cells with information. The result was a matrix with thousands of data cells. Only if you have a strong analytical brain you could make sense of it. Most people just ignored the Excel. We realised we needed a system with simple forms and buttons.
We solved these complexity problems through adapting a web based system. Simson 2 was the first web based version, using the Ushahidi platform. After two years we abandoned the Ushahidi platform because it is made for open sharing. This implies that there are digital holes in the system and it was impossible to repair them all. Sensitive information could therefor leak out of the system. Simson 3, the latest version, is based on Drupal, a more secure programming language.
Web based also means that users can go to the Simson website and just login. That is all. Users do not have to perform IT tasks like installing or updating programmes. The updates are done at the main server and are not the problem of the individual user or even the IT department of the organisation.
We also made Simson more simple by adding two users; managers and users. The managers have access to the complex features of the system. They can change, block and assign new users. The managers receive more information and reports than normal users. The normal user has a limited interface and options. This makes it easier to train them to use the system. Most users just want to get the report in the system and get on with their professional life. That is why we have a simple form that can be filled in in just a few minutes. After that the system automatically synchronises and alerts all the relevant users and managers.
Another challenge was the unpredictable behaviour of users. When we started to develop Simson we needed to predict how users would use the system. We had to make a lot of assumptions and guessing was a major part of the development. We constructed what we considered ‘logical paths’ for users to follow. When the system went live, we were expecting the users to follow them easily. But they didn’t.
This is the main reason why Simson is developed as a ‘Software as a Service (SAAP)’. SAAP means that you pay for the use of the programme and not for owning the system. This implies that you do not have the responsibility to keep Simson running and updated. Simson is updated continuously and is improved all the time. Requests from users on how they would like the system to be changed or new features they would like to see added, are sent to our team. We gather them and start changing the system accordingly.
As the Simson system grows, more and more incidents are reported and the database is rapidly increasing in size. This development has its own challenges. Some managers in the system are overloaded with information. Some may receive incidents from more than 200 users. This can be overwhelming and it is easy to lose sight of the important aspects of the data. Although the system has some filtering options, we recognize they might not be sufficient. We plan to expand these options in 2015, for instance with integral reporting features that summarise all the data in a certain timeframe or location.
As I said, Simson is never finished.