A journey around a risk governance systems implementation

I recently met with a former colleague of mine who recounted a story that as first seems extreme, but which I have subsequently established to be a common problem:

My contact was a risk manager in a large financial institution and he was recounting to me his experiences in implementing a  risk and compliance governance system.  The system had entailed a substantial investment in software licenses and an even larger amount for professional services associated with implementation. The objective of the system was to engage the whole enterprise in the management of operational risks. The compliance and risk deaprtments ere tasked with establishing a repository of risk & regulatory issues togther with associated guidance for compliance and risk mitigation. Line management would be responsible for identifying, assessing and confirming risks and compliance issues associated with their activities were being managed in accordance with policies, guidelines etc. This seemed like a great plan, leveraging collaborative web technologies and ditching the mountain of dosuments and spreadsheets. Yet, in around 12 months following the implementation of the system, the system had fallen into redundancy outside of the risk function. A couple of data entry staff had been recruited to re-input spreadsheets that the rest of the organisation emailed to them so that the "main risk system" could be updated and MIS produced.  What went wrong?

Basel II and regulatory requirements have established a requirement to demonstrate the existence of a regulatory compliance management programme and maintain associated records. It's therefore  a generally accepted "good idea" to establish some kind of IT solution to manage the enterprise risk management process. Acting as the organisation's "conscience", a repository and automated governance tool identifies responsibilities, tracks actions and remedial activity, identifies exceptions, enforces risk ownership and creates an environment where no risk remains ignored

But, as my former colleague found out, it didn't happen.  The systems were devised, marketed, procured and implemented. Then what? The majority of them fell into misuse because:

• Users forgot how to use the systems because they used them infrequently;
• Experienced users left or moved on and no-one else knew how to operate the system;
• The systems were designed by risk experts for risk experts - not mere mortals with a "day job". Many were just to complex to use;
• Because of occasional, intermittent use, informal knowledge sharing doesn't occur and the application never really becomes part of the fabric of the firm.  Outside of the risk function no real familiarity across the wider organisation is achieved
• Even though employees in financial institutions are "tech savvy" - their deep familiarity tends to be with applications that they use on a day to day basis.  Outside of this their comfort zone remains with standard Microsoft Office apps. Most just don't have the time or inclination to learn new applications that are outside of their daily routines;

All in all, what seems like a great idea in principle - getting an efficient and transparent risk governance system in place - is a bit like trying to push jelly up a hill with a stick. 

We need to rethink our approach to technology and how we expect the wider organisation with many ad-hoc users to engage with risk governance systems.  A good risk governance system will provide all of the "expected" features such as:

• Flexible approach to risk assessment;
• Assigning risk management responsibilities throughout the organisation;
• Tracking remedial actions;
• Alerting individuals when actions are required.

But more importantly, to ensure that the system is widely adopted and ingrained within the firm, system designers are going to have to learn that users want to perform these activities via application interfaces that they are already familiar with.  Which means that the application not only sends out emails telling users that they need to do something, it allows them to use familiar tools to complete their activities such as:

• Allowing the user to respond to the systems request via email (and the application sorts out what needs to be updated when it receives an email from the user);
• Information that needs to be updated is given to the user in a format they are familiar with (an excel spreadsheet perhaps);
• Spreadsheet can be updated, sent back via email or saved in a shared area, where an application agent takes the information and performs the required updates;
• Information that requires review and feedback has to be delivered direct to the user with easily followed hyper-links for recording confirmation of receipt and concurrence.

Although there are some application design challenges here, there's a simple message; let users operate through applications interfaces that they are familiar with and ensure that the system shields the users from its design complexities.  That way you stand a fighting chance of the system's use being sustained within the organisation.