A risk manager can provide a company with enormous benefits in terms of creating and protecting value, but every gain has its price. Personally as a risk manager, one of the worst things I have seen is the tendency of many companies to avoid changes necessary to prevent new risks or redefine the exposure to the existent ones. This tendency is especially obvious in those organisations in which the risk management process is in a start up phase.
The most common problems are related to operational changes requested by a risk manager, especially if these could be expensive or stressful for the organisational structures. It may be valuable, therefore, to measure the capacity for change that an organisation demonstrates under the pressure of risk management requests. In other words, it could be useful to measure the resilience of the company.
Resilience is 'the physical property of material that can return to its original shape or position after deformation that does not exceed its elastic limit'. In applying this concept to a company activity, the resilience can be considered as the capacity of a company to respond to pressure for change.
To consider it from a different point of view, the idea of resilience can be linked to the difficulties a risk management process can have in achieving change inside an organisation after a risk analysis.
Testing the resilience is important in adding value to the risk analysis and it can have consistent benefits in terms of the information collected because:
- the resilience, or lack of it, is a risk factor
- the benefits of a risk management plan, especially if it is related to processes, can be increased by a strong resilience
- by testing the resilience, you implement another important control for your activities
- making comparison in an index over different periods of time allows you to evaluate a kind of measure for capacity to accept change.
How can we measure an organisation's resilience? Three steps can be defined:
- creating a data model for the delivery time of those projects directly related to risk management requirements
- using information on operational risks from the internal audit activity
- using checklists to assess an organisation's cultural reaction to risk management projects.
The first step is to collect data on the risk management activity involved in past projects and to record the starting and closing date of all such projects. These need to be aggregated into similar classes to give you a homogeneous cluster. For each, you need to add a risk rate and a complexity rate.
The first rate denotes the general risk of the project, while the second indicates its complexity according to, for example, the resources used, its cost, its impact on the business, the measurable benefits and so on. Using a simple scale you can define a severity scale from 1 (high) to 5 (low).
The second step is to calculate the difference between the starting date and the closing date. Now you have a set of data to help you test and verify the average life of each clustered project.
According to the information you have derived from the past, you can build a range with which to test your future activities. So, by making a simple comparison between your open projects and their closing time which is calculated in the same way, the model can give you an idea of the 'speed' of the organisation.
In the example shown, it is assumed that we want to apply the resilience test to various IT projects that were suggested for implementation in order to modify the risk profile of this function. Following collection of the data, Figure 1 shows how the projects are presented in terms of the risk and complexity ratings.
It is then possible to create a table to calculate the average number of days for each entry, with reference to the risk and complexity ratings (Figure 2).
The next step is to evaluate the time taken by open projects, as shown in Figure 3, testing them against the averages calculated previously. This shows we have a 67% percentage of 'failed'.
For the next step, the best proxy commonly defined may be the results of a check from the internal audit activity, for there are some overlapping areas between internal audit and risk assessment that can be used to help our analysis. The internal audit data should be put into a spreadsheet to count the percentage of negative checks against the total number of checks done. We need to restrict the controls we include to those strictly related to the risk area we are analysing.
Tests from the internal auditors' table can be summarised as shown in Figure 4.
At the end of this process we can combine the data to calculate the average of the percentage of 'failed' in the first step and the percentage of 'failed' in the second step: the result is 0.585. So with an index that, according to the way we build it, can vary between 0 and 1 we can assess how much resilience there is in the activity we are requesting.
Finally you can draw up checklists to use as a qualitative back test to test the numeric results against the perceptions of those involved in the management of the projects.
Obviously the parameters of the model can be modified to take in all the possible scenarios you manage. The better your organisation is, the more likely it is that you will have a strong database from which to collect information.
- Massimiliano Zanetti is risk manager, Finaosta SpA, E-mail: zanetti@quantitativefinance.co.uk
