This article was first published in Managing Business Risk – Edition 5 by Kogan Page in 2007
Creating a risk management software solution
By Andrew Birch, Symbiant
Symbiant specializes in creating data management solutions. In the past we have developed some very powerful and complex tools for some of the worlds biggest corporations. So, when we were approached by a Big-Four accountancy firm that needed a risk management solution for its clients, we thought nothing of it and readily agreed.
The firm was trying to help some of its middle-market clients find a risk management tool that was economical to buy and yet included features that other systems appeared to be ignoring, such as virtual workshops, flexible ways of recording risk appetite and linkage to control self-assessment. The firm gave us some inputs and agreed to work with us as a means of pushing forward risk management thinking and practice. It did not want to get into selling risk management software itself as its policy in this area is to provide consulting and advice, rather than actual software. So ownership of the software would be ours, as would all the costs of development.
This therefore was the gamble: how much would it cost us in time and money to develop such a solution? From our initial conversations with the firm, with nine programmers on the job, we anticipated three to six months and up to £500,000. This was in April 2005. It took us until March 2006 to have the first working model, a period of almost 12 months.
The task in hand
The problems we faced were plentiful. Solutions we create have to be useable, and this is almost our trademark. However complicated the software or the tasks it performs, it must be intuitive and need little or no training for the clients to use it. We had done this very successfully with Symbiant ‘Tracker’, which was an internal audit tool for implementing issues and
recommendations. The auditors enter issues on to the system and then assign the issue actions to auditees. This gives ownership of the action and the auditees keep the issue updated with their progress. Thus at any one time the auditors know the exact state of all the issues on the system.
The companies that had already bought Tracker were telling us how wonderful it was, how they had managed to roll it out and how, without any training, the auditees (users) had taken to it. They also commented on the powerful reporting suite and how it made producing reports for the audit committee such a simple affair. In essence, they were all more than satisfied with what we had created.
This was the precedent we had to follow. We had to make a risk management tool as good and as easy to use as Symbiant Tracker. Even though there are many more elements to risk management, we had to create a tool that simplified it for the users.
We first looked at other solutions on the market to make sure we were not re-inventing the wheel. What surprised us the most was the lack of user friendliness that seemed to dominate software in this area. For something that is ideally a company-wide issue (risk management), these other solutions would require a good level of user knowledge and a great deal of training.
I think the main problem with the other solutions we looked at was that they had been written by experts in a set methodology that directed programmers what to write and assumed everyone who used the solution would understand the process as they performed it. In reality, this is never the case. It is fairly easy to create a solution that will do what you want it to do, but it is difficult to create a solution that will get others to do what you want them to do.
On the other hand, we are software developers who knew nothing about risk management or its practices. This was our main advantage over the other products on the market. We knew from years of writing software solutions that if users don’t get to grips with the software quite quickly you can forget it; they just will not use it and that makes the expense pointless. We had to create something we could use and understand. but more importantly that any risk manager, computer literate or not, could use and understand. It had to allow someone who may never have seen the program before to use it without any training. In other words, we were seeking a solution that a company could embed with very little effort and no steep learning curve.
Workshops or sweatshops
Our first step was to understand the risk management framework: the information that needs to be collected and how that information is assessed. This involved lots of flip charts and asking what must have seemed like very silly questions, especially when we got to risk maps, gross impact and likelihood, and net impact and likelihood. What was that all about? The workshops helped us to understand this. We had our voting paddles and a list of 10 risks we had to discuss then measure. It took us two hours to vote on three risks. One of the voting paddles stopped working for no apparent reason; other paddles missed responses and had to be redone. We started the day full of enthusiasm and by lunch time just wanted the pain to go away. Worst of all, we knew
we had another seven risks to assess. In the afternoon session the first two risks were probably quite accurate; the next five were just a rush and any button would do. We just wanted to bring the day to an end. We had got the message and learned that this had to be the most arduous task risk managers have to endure.
We also discovered that companies tend to run these workshops only once a year at most, and that they may last a week. So, at best, the risks that companies face on a dayto-day basis are generally only tackled once a year, the main reason being the logistics and costs involved in getting all the required people together at the same time in the same room. This in itself seemed to conflict with the combined codes recommendation (derived from the Turnbull Report) that a company’s risk identification process should be continuous. Rather than being continuous, this seemed like an annual event, and not one to which people would look forward.
Due to the potentially mundane nature of these workshops it has also to be said that the accuracy and quality of the results must be questionable. How can anybody be working efficiently and thinking clearly when they are willing the day to end?
The next part of our training was learning how the results are assessed, scores totalled and averaged and risk maps plotted with hot spots. We then learned about risk appetite and producing risk registers – normal, standard deviation and distance from appetite.
A to Z is not always that simple
Eventually we had a road map. The basic architecture of what a solution needs to do provides a total risk management solution: not something that only deals with a small section of the risk process but a solution that would cover all the areas a company needs to run an effective risk programme.
The problem was putting this together in a workable intuitive solution, and this was when the huge scale of the task started to dawn on us. Risk management is actually quite a complex issue, with many parts; simplifying would not be easy. We had to have a risk identification process: some way that users could make management aware of potential threats. This could partially be done via incident reporting. Give users the ability to report an incident and all the relevant details, which could then be converted to a potential risk by management. Also, questionnaires would help with this task, applying standard, assessment and key risk indicators/performance indicators. In this way management could ask specific questions and use the indicator questions to see if trends or danger zones were emerging.
Now to tackle the workshops, something to replace the annual boardroom nightmare. A virtual workshop would allow users to discuss the issues, vote on them and then suggest and ballot a specific treatment. This would provide a key solution to the current problem of annual risk assessment in the boardroom. It would also allow risks to be assessed in small, workable chunks as they emerged. A workshop is opened and assigned to a group or groups; members of those groups would have access to the workshop(s). The workshop would start in the open stage, with a date set when the open stage would finish. Issues would then be added to the workshop and users could discuss them in a forum/blog style. All members of the group would receive an e-mail notifying them of the new workshop and all the relevant details. Users would then log in, in their own time, from their own computers, read user comments and add their own responses. This allowed everyone to discuss the issues and ask any questions they may have had.
When the target date was reached the workshop could be moved into its voting phase, a new target date set for when the voting stage will end and an automated email sent notifying the relevant people of what they have to do. Using preset responses users decide on the gross and net impact and likelihood for each issue and, if required, a risk appetite choice Management can then assess those responses in real time using risk maps and other reports.
Once the risks have been assessed the issues that the group felt were not major risks or were within the appetite could be removed from the workshop. The workshop would then be moved into its treatment phase and the automated e-mails triggered. Users would then log in and either suggest treatments or agree with other users suggestions.
The reports would let the management know which were the most popular treatments were and they could then adopt one or more of the proposed actions.
The final stage involved assigning the actions to people so they could carry them out. Again an automated e-mail would notify individuals of the action assigned to them and they could report back via the system, keeping the action progress up to date. For this tracking part of ‘Risk Suite’ we decided to use a cut-down version of Symbiant Tracker.
A better way
The key to a good product is giving the user a ‘better way’, and the solution we were creating was certainly achieving that; we just didn’t know how much of a better way it would be until someone actually used it for real. But we had managed to make sense of and simplify what had been quite a drawn-out and complicated procedure. All we now had to do was get some users to test it under realistic conditions.
We approached our client base and asked for volunteers. Out of about 35 volunteers we picked 10 from different sectors so that we could get a spread of opinion. All the testers liked the solution and made suggestions as to what they would need to make it work for them. User feedback is the best way to develop a program; the basic structure was in place and so all we had to do was modify it so that it would fit into all 10 companies.
This in itself became a new task. We ended up making the solution use a skin template so users could rename things and change the layout to suit their own individual requirements and terminology.
One of the most annoying parts of software development is the bugs, and Risk Suite had its fair share; but after a few months of intensive trials across 10 companies we found probably 98 per cent of them.
Once we had fixed the bugs we knew about, and added all the ‘nice to have’ features that our volunteers had suggested, we launched ‘Risk Suite Version 1’ as an affordable total risk management solution.
Because Risk Suite is installed on the corporate intranet or internet, it does not need to be installed on everyone’s PC. This makes rolling it out simple and, because it is intuitive, it is easy to embed.
One of our first clients was the Institute of Chartered Accountants in England and Wales (ICAEW), which was then looking for a risk management solution. To say they were impressed may be an understatement. They were so impressed they took the unusual step of endorsing it as a user. As they had never endorsed any software before or since, this in itself gave testimony to what a superb product we had created. Since then we have continued to build and develop Risk Suite in response to user feedback.
We are now on Version 2.4 and have users all over the World. We have also recently learned that The Cape Peninsula University of Technology in Cape Town South Africa uses our Risk Suite to teach students about risk management and what an effective risk program should consist of. Apparently, the students enjoy using the program; it is fun to use and they are impressed with its capabilities.
When we first started out to develop Risk Suite the last thing I would have expected is that risk management was fun, but I have to admit that I now love running the workshops when we are doing demonstrations for clients. We get people without any training who have never seen Risk Suite identifying risks, assessing them and suggesting treatments. When we provide the risk managers with a risk register and risk maps, all created from their users’ input, we can feel the joy of knowing there is finally a product to help them do their job properly.