Many Oil and Gas companies believe they are fine with their current way of managing lessons learned, until "it" happens. An incident occurs that should not have happened. Whether it is an injury, or simply money, the worst incident (relatively) that can happen is the significant incident that happens twice. They enter the unfamiliar situation, realizing that their lessons database is not good enough, and must adapt, looking for the solution.
This is what we're trying to do, build the better database. We don't have the perfect solution, but realize the need to continually search or risk an even greater cost.
The problem - "people are reluctant to admit failures."
The two options we see. Either you change the culture, or make it anonymous to submit incidents. Since changing a culture is a little more time intensive, lets start by making a place comfortable for people to submit incidents with the choice to be anonymous.
The problem - "Quantity does not equal quality."
Submission of incidents need to be held to a high standard. Submissions need to be graded by expert industry selected moderators to make sure the ones kept are valuable.
The problem - "Lessons are not documented in an actionable format."
The lessons cannot contain the words "be safer". Be specific about what needs to happen for people to avoid this particular incident.
The problem - "no one looks into the huge lessons learned database."
Hopefully by limiting the lessons to only decent lessons, the database is not a black hole. There still needs to be a good filter system however, that allows quick and effective searching for relevant incidents.
The problem - It is difficult to apply the lessons to your specific work, so you don't try. Then the database is ignored completely.
Learning needs to be constant. Everyone needs reminders of all of the incidents that happen all around them. Make it entertaining to learn about these things. Daily lessons, daily activities, reward the daily user.
When putting steps into a procedure, many steps are written in blood, it is much harder to skip a step if the user knows the purpose behind that step being there. Every incident we make has a specific attachable link, making it easier to communicate why that step is in there, and the incident that caused it.
We don't have all the answers, but are trying to build a better database, and know the right solution is out there. Follow these steps to get the change you want in your database. If you want to try our free beta database, do it. Let us know how we can make it better. You can then return to your familiar rig, or job site knowing that you are better equipped.