What are the best practices for creating and maintaining a risk lessons learned database?

Most companies (mid-to-large) must recognize that different parts of each organization have different risk management needs. Trying to create one database that meets the entire organization likely will result in a database that isn’t particularly useful to any one part of the company. Start with defining the specific risks to be measured or managed. I have seen this particular step become way too complicated making it so individuals don’t even know how to categorize something. Keep it as simple as possible otherwise people will get lost in just trying to determine how to categorize something - and fail right at the beginning.

To establish a robust risk lessons learned database, it is important to document the incidents comprehensively, categorize root causes, and regularly update the database to incorporate evolving risks. It is always impactful to encourage a culture of openness to foster continuous improvement, ensuring the repository serves as a valuable resource for informed decision-making and risk mitigation strategies.

Comprehensive Capture: Document all risks, impacts, and mitigation strategies. Structured Organization: Categorize by type, severity, and project. Continuous Updates: Regularly add new insights and outcomes. Ownership & Accountability: Assign responsibility for upkeep. Analysis & Application: Extract trends for refining future strategies. Accessible & Secure: Ensure authorized access with robust security. Integration & Training: Incorporate lessons into processes and educate stakeholders. Continuous Improvement: Use insights to enhance risk management continually.

Categorize the risk lessons as 'Internal' or 'External.' Internal lessons are derived from organizational events or scenarios, such as process failures, management decisions, or internal system breakdowns. External lessons stem from factors outside the organization, like publicly known fraud incidents, operational losses, or specific company failures. In terms of data, include specific details about the risk event (cause, impact, response actions), how the risk was managed, the effectiveness of the response, and actionable insights or lessons learned for future handling or retrospection.

Don't know why LinkedIn thinks I am an expert. Not feeding LinkedIn's algorithm to mine users feedback and responses. Thus, my answer is I don't know the answer.

I think that the best way is to use high management to sanitize confidential information and divulge the second line of managers the critical risks. It make they responsible for repetitive at the same risks and preventive.

In my journey, I've learned the importance of rigorously validating risk lessons. It's crucial to base them on hard facts, not just opinions. This diligence, ensures that our database remains a reliable, bias-free resource that truly serves its intended purpose in risk management.

Don't know why LinkedIn thinks I am an expert. Not feeding LinkedIn's algorithm to mine users feedback and responses. Thus, my answer is I don't know the answer.

I will comment on this one as it is the most problematic. Simply put - even if you manage to constructively capture and categorize “what went wrong”, the hardest part is to get the right people to read and absorb it when the “next” project is being planned and priced. It takes a significant effort to continually educate the planners and pricers - and actually sit down and go through 50 or so “lessons learned” and see if they have been addressed in some way. Have to say have never seen anyone do this.

Don't know why LinkedIn thinks I am an expert. Not feeding LinkedIn's algorithm to mine users feedback and responses. Thus, my answer is I don't know the answer.

Don't know why LinkedIn thinks I am an expert. Not feeding LinkedIn's algorithm to mine users feedback and responses. Thus, my answer is I don't know the answer.