User login

You are here

Topic 38: Lessons - how are these captured

Trevor Strawbridge's picture


I would like to start a discussion regarding lessons learned and the best practice for capturing these. More importantly is how we apply the lessons we learn. To often I see company's that utilise enourmous databases for the sole use of storage of lessons and this knowledge is kept in a "black hole"  where sometimes it is never utilized. Furthermore, there have been instances where lessons laerned have been well documented, yet the same issues have been repeated with similar consequences. THe point to consider is that "Knowledge is usless unless it is applied". I have a few of my own ideas here but I would like to see what other fellow students and indeed lecturers views on this topic were.

Trevor Strawbridge

MSc Subsea Eng Stnt.  


Tony Morgan's picture

I'd like to start with which term is correct if there is such a thing ? as ive seen it used interchangeably and never sure which one to use myself.......English lessons aside then i totally agree that the most common theme is certainly to produce an ever increasing database of notes and subject matter  and that the bigger this is the harder it is to use.........I've always questioned the most basic style of simply broadcasting information and hoping that people pick up on a MEMO or E-MAIL. That is not to say that these do not contain the lesson but that for it to be learnt there should be clear evidence that the lesson has been documented, broadcast, understood and applied ( as suggested) it should then be monitored / tracked to ascertain if it has been effectively controlled and this needs to take place over a time period of weeks, months, project to project, person to person, generation to generation over years. It needs to be part of the 'Corporate or Social memory depending on the scale of the lesson and implications of a repeat event. Another point i'd like to make is that there is generally a propensity to focus on failure and mistakes but phsychologically maybe it may be more beneficial to balance this with positive messages and pro-active lessons and promotion of positive activity, methids, behaviours etc. Certainly at an institutional level and in the safety arena there is much more focus on best practice, benchmarking and promotion of safe behaviours and i think that this needs to be developed more when considering any lessons learned. It can be done by using a WHAT WENT WELL EVEN BETTER IF methodology. 

i guess the thing with lessons is that to be effective the lesson generally has to be evidenced in process, procedures, people and culture and that if any part of this is not adequately addressed then it has the potential to be lost and repeated if a failure or never repeated if a positive. 

tony morgan

Richard Milne's picture

Tony, having a look around the fountain of all knowledge (the internet) and there is no determined answer to whether it is 'Lessons Learned' or 'Lessons Learnt'. It would seem that this is an argument which will continue on for a long time!

As for Lessons databases, these are indeed a tricky subject. A large company trying to capture lots of lessons, may end up with a huge database which is totally unsearchable! THis will mean that lessons are not learned, but just stated somewhere. I wonder whether having people controlling the database may be the best way to handle it? A type of auditor if you like, who keeps an eye on the companies activities, and points out past failures or past achievements and shows what was done well and what wasn't.

This however, may not work in a company which has a great depth of different activities. Could there be a computer program which picks up certain queues as to the type of job you are about to do and links you to lessons? Or would this just annoy the regular user?

I think it is quite easy to pick up lessons within smaller or newer environments. For example, incorporating new lessons into a procedure each time one is learned. This is especially easy if the procedures have been written from scratch and are under your control.

Lessons learned however, can also rely on people being willing to listen. This may not always be the case. It's a tricky situation to have.  

Foivos Theofilopoulos's picture

The problem with information is a double-edged blade. Until recently, information was kept in huge dusty tomes filled with numbers that were kept in basements and file cabinets around the world. The amount of work needed to gain something out of them was tremendous (making lists of similar occurrences out of 500 books full of numbers and then trying to make some statistical correlations between them) and few companies and even countries were willing to spend resources (time and money, most of the time) to do that.

Nowadays, most of these databases have been computerized, but a new problem has arisen from this procedure, that everyone can have access to huge amounts of information that most of the time is very impractical to go through and try to process it.

Tony mentioned an e-mail system. I've heard this from people working in big companies, that the amount of memos and e-mails coming to them everyday is huge and that they usually do not have the time to go through all this information. This phenomenon usually becomes more and more annoying when you go up at the corporate ladder, higher positions getting spammed everyday with memos from many different projects that they participate in.


Neil Fraser James Carr's picture

Yeah I agree with all of the previous posts,


Most drilling contractors or marine operations seem to have
a wealth of reactive information that fly between them involving safety flashes
and urgent FAO HSE emails incorporating the daily news of who has done what,
the biggest problem is that these systems become bogged down and used in a way
that doesn’t best represent the data.


Recently I saw a MSF that had a story about a sailor that
was beaten up for not paying a lady of the night….. try reducing that to ALARP.
The outcome was do not hang around dark streets with strangers.


The very best use of information that I have seen in the industry
is applying safety flashes directly to the procurement chain by discontinuing
any equipment that could be supplied that has a proven number of instances of
failure however this obviously is an internal reaction within a company and not
applied or shared across multiple businesses.


As for the point of the this discussion, there is a real
need for a unified utilisation of this data but if this was to occur you have
to ask yourself how useful it would become with the differences in culture,
geography, weather and types of operators. You often find that most of these
come down to human factors and no one can really find a one fix shop for some
of the ways people find to hurt themselves at work.

Trevor Strawbridge's picture

Hello fellow forum contributors

Many thanks for your comments, all of which, in my opinion are  valid points and I generally concur with the majoriy. I am not sure how other industries outside the O&G sector capture and utilise these lessons but this is just one idea how I could see best practice applied.

Firstly the database to be used would require a suitable search engine especially for the larger companies. Synergi seems to be the prefered tool to be used in our sector

Secondly, to ensure the lessons entered are quality lessons with substance there should be some sort of management, eg in a large company perhaps a steering group, for smaller companies perhaps department managers

So at this stage we have this wonderful database with all this useful knowledge sitting there waiting to be applied.  Now most O&G companies that have had dealings with in the past perform HAZOP's, HAZIDS, and HIRA's. The normal prerequisits for these tend to be the activity presentation and where applicable the risk assessment and matrix. So in my view these sessions are the ideal opportinity to refresh lessons of yesteryear.  Maybe there could be a prerequesite  that all delegates invited to these sessions are to perform a word search in their own databases to identify relevant lessons and introduce them into the applicable session.

Just one idea, as I have witnessed at first hand; lessons entered into a database and repeated issues both from a Health and safety and quality perspective with subsequent similar tasks. All because the database was not reviewed prior to performing the relevant activity.

Look forward to you comments  

Kelvin Osaro's picture

I truly agree with what Trevor is saying about the lessons from a proactive perspective. From my own opinion, I think lessons from a proactive approach in safety management can be improved from looking at everyday performance of an activity rather than why it occasionally fails [1]. This would help to deal with uncertainties by implementing conservative values of variables and “safety factors” in design calculations. For example, if we consider a high loading and low yield strength in a design calculation, it is possible to look at the uncertainty in failure through probability in order to know or expect failure in the near future (whether two days, a month or a year time). This helps to identify which outcome is more likely than others thereby guide good decisions on design, replacement and maintenance, and helps prevent unwanted failure events from happening. 

From the above discussion, it can be observed that we should not only learn from an incident that has taken place, but also to focus on better and safer methods of performing activities rather than waiting for a huge incident to happen before a change can be made. 



Brenda Amanda's picture

I hope I do not digress too much
from the direction the discussion has taken. I would just really like to point
out that the UK Oil and Gas industry does a good job of learning lessons from
past events and forging a better way forward. Statistics for different
companies’ health and safety performance standards are kept and the EHS
continues to use these to improve safety regulations to address issues as they

After the Macondo incident, Oil
and Gas UK put together the Oil Spill Prevention and Response Advisory Group (OSPRAG)
almost instantly in the UK to make sure such an eventuality could be capably
dealt with, with minimal damage. The group consists of experts in their
respective fields and this allows for pooling of knowledge (lessons learnt in
light of this discussion). This resulted in the capping device that is
currently being field tested.

This is only one of many examples of how lessons
are being learnt and captured in the industry.

Thomas Ighodalo's picture

In engineering design, lesson learnt are usually captured in standard and codes, theses codes have been built up and revised over the years based on the lessons learnt from experienced individuals that makeup the body of the particular body involved, and incidents/accidents that have occured. A typical example is the American Petroleum Industry Recommended practice, going through a relevant API R.P that suits the exact phase guides the design engineer from making desions that could prove fatal, a wrong design increases the probability of an incident occuring.

Other companies also develop thier own standards which might be more stringent that the international standards and codes example of such standards are the Chevron Engineering Standards [1], and  Shell Design Engineering Practice (Shell DEP)

Shell also prescribes mandatory technical standards relating to process safety requirements. These standards are informed by recommendations arising from industry incident investigations, such as the Baker Report on the Texas City incident, which included guidance on safe siting of occupied portable buildings and avoiding liquid release relief to atmosphere. [2]

Also the Client company puts in place a review team that ensures that the standards have been rigourously adhered with in the design submitted, and finally a HAZOP session, constructability review session comprising of the design company, operations personnel, Client engineering review team, experienced engineers, and other relevant disciplines are gathered to critically review the drawing, this ensures that lessons learnt from past experiences are captured/incorporated into the design.













"Everything we hear is an opinion not a fact"

xenios.ze's picture

Lesson learned

Lessons can be learned with practice but
cannot be learned only from paper. I believe that all these terrible incidents that
took place in the past happen because of the man’s failure to predict or to
understand briefly a problem or a situation. The regulatory committees from
different industries are doing a very good job regarding the health and safety in
order to ensure that everything is well constructed and organized. Not only this,
but the private companies develop their own health, safety and environmental
regulations because they have learned from previous mistakes and omissions.
So I think we have learned that we need to consider safety issues in the future
but nothing is more important from the experience that we will need to achieve in
order to do everything in the right way.


Xenios Zenieris

MSc Oil and Gas Engineering 

Kareem Saheed Remi's picture

 Lesson learnt in most cases could be outcome of RCA carried on incident/near misses, improvement opportunity in safety and production perfomance. Before these lessons are said to be learnt they must be compiled, processed, stored for reference purpose and transferred to the target audience through a medium and must be registered in the brains of the recepients and the recepients must be able to apply them when the need arises. 

Means by which lessons learnt are stored and shared differed with respect to the accumulated volume of the information over time, size and location of target audience. In a small organisation, sharing of lessons learnt can be conveniently done via emails and individuals safe keep such emails for reference purpose. But in a bigger organisation where email traffic is higher, sharing such information via email might not be effective considering the volume of email exchange on regular basis, in such case it would be better to have a central collection point, i.e searchable data base, where the lesson leanrt would be stored and awareness about new information would be made via news flash in the organisaion's intranet. 


Kareem R. Saheed

Soseleye F. Ideriah's picture

It is necessary for organisations to have well documented information of past experiences, especially those experiences related to safety. Obviously, this is an excellent way to avoid recurrence of undesirable events. The question of how this should be done is very important. I would limit my point to how I think information should be captured.

Industry regulators must take a leading role in capturing safety information. All efforts must be made by regulators to ensure that they clearly and completely document information on all safety issues and events. Regulators must make sure that proper system audits are carried out regularly and ensure that no safety issues are left undocumented. It is also the duty of the regulators to develop a robust mitigation strategy in preparation for future events. An example to this approach is the Lord Cullen’s inquiry to the Piper Alpha disaster. The public inquiry established the cause of disaster and made recommendations for changes to the safety regime [1].

[1] Oil & Gas UK, Piper Alpha: Lessons Learnt, 2008.

Trevor Strawbridge's picture


 This is all good and valid points that I read. Kareem's point regarding the difference in the company size is also a valuable point. Brenda is also correct that the UK O&G industry probably leads the way in capturing lessons. However, the thread I am reading seems to be dealing mainly with major incidents. These tend to have primary focus even at Regulator level and hence, seem to remain in the industy domain. Nevertheless, could we look at lessons from a proactive perspective. That is; not only to learn from an incident that has taken place, but also to focus on better and safer methods of performing activities that have already been performed sucessfully. The term I look for here is "Continuous Improvement". For example; perhaps a specific task had been sucessful more by luck than judgement. Is it then appropriate to continue with the same method?

On another note lets not overlook the smaller points that have a potential to create major incidents with high consequiential loss. As an example; consider a faulty Flange bolt that has bi-passed its inspecton. The bolt is relatively low value but its failure could result in high consequential loss - even fatality. Such an incident  could be entered into a database, but when would  the most appropriate time be, to exctract this knowledge and ensure it is understood in subsequent activities, tasks, projects etc.

Many thanks to all that hve commented



Kobina Gyan Budu's picture

Trevor while I agree with you that the topic is a good one, I think it should be Lessons - "how are these captured and utilised"

considering the trend of the discussions.

Safety lessons are a very important aspect of a company’s safety culture. Lessons from accidents/incidents are
normally captured in Incident Notifications, Incident Flashes or Incident/Accident Investigations Reports. Safety
minded companies make a database of these and treasure them as they form significant part of their proactive safety
culture. These learnings are immediately populated across all the company’s operating sites to be used in respective
Toolbox Meetings.

In the industry especially in mining, many organisations have Continuous Improvement Units within their portfolio
responsible for work place safety. This encompasses process safety, human safety and environmental safety improvement.
It is championed by experts in the Safety/Quality fraternities (Six Sigma personnel) as the focus is mostly on the
quality of the company’s safety systems.
Some of the areas they look at are the company’s safety standards versus how they have been implemented over a certain
period on the ground. The company’s standards on the use of safety learnings are reviewed and as a result, policies and
procedures reviewed to be forward looking leveraging on the past experiences. Standard Operating Procedures (SOPs) for
routine tasks are revised, Job Hazard Analysis (JHA)/Job Safety Analysis (JSA) techniques revised for non-routine tasks
and EHS Case revised to include any safety lessons learnt. These are some of the ways some safety oriented companies use
lessons for continuous improvement.

Charles Stuart's picture

Trevor, I agree with your statement that it’s much more of a challenge for large organisations (such as a main contractor) to capture lessons learned through procedure amendments, due to the differing customer requirements and a potential lack of globally adopted procedures.  One way around this could be to create central database of procedures based upon best practise with a responsible person linked to each document.  This person could be responsible for periodically reviewing the lessons learned/learnt database and incorporating any relevant improvements.  Any project specific documents could then reference the centrally held document to ensure global application.  To use the bolting example –  following the failure an FPR would be created which would reference the Material Specification prompting the responsible person to review, and if required update the central material selection procedures.  Having said this, there are still quite a lot of stages at which this process could fail and it relies on a culture of continuous improvement within the organisation.  Quite often people deliberately choose to remain ignorant of improvements as they have established ways of conducting certain operations which they are reluctant to change.

On the learnt/learned issue,   the difference appears to be the country of usage (UK, Learnt/US, Learned), so both are equally acceptable.

Tony Morgan's picture


i'm maybe picking you up wrong but it wouldnt matter how small the part was if the implication of its failure was critical as you suggest.

In my experience as you note the smallest parts can have the most serious consequences. An example of this would be where a £50 fitting was placed on a threaded port of a tool and pressurised to  20kpsi.

The unit is then functioned and its design is such that pressure is trapped in a localised area. The test pressure is removed from source but trapped pressure remains. The unit is then shipped and arrives at another location under pressure. This results in a projectile incident which could have been avoided by some very simple changes. Due to the seriousness The lessons learned are spread across the a multi-national organisation and must come from many sources.

As suggested a full RCA is completed to identify the route cause ( typically 5 Why questioning can help to get to the right level of detail eg why did the item have pressure trapped, each answer can have a why question posed eg design, hidden pressure, operator/procedure error then why for each of these why hidden pressure, fitting used was a blind, why a blind, only fitting available, why used when not on bill of material or drawing - why was change not approved
, No bill of material why no bill of material - root cause identified as cultural issue where test equipment is not logged, recorded and controlled as detailed as full manufacure equipment !!!

Various remedies introduced.  Global standards for Pressure Testing. Update to JRAs for design risks, ban on use of blind plug's unless engineering approved with no other means of control of all pressure test equipment by part number, drawing and procedure ( i.e through engineering dept with formal check and approval process to reduce single person errors) . Vent down check by supv. no matter how simple or repetitive the task(these can be the most dangerous as people naturally relax).

Controls should follow the below hierarchy
'' 1.
Removing the hazard, eg taking a hazardous piece of equipment out of service.
Replacing a hazardous substance or process with a less hazardous one, eg substituting a hazardous substance with a non-hazardous substance.
Restricting access to plant and equipment or in the case of substances locking them away under strict controls.
Redesign a process or piece of equipment to make it less hazardous. Isolating the hazard from the person at risk, eg using a guard or barrier.
Adopting standard operating procedures (SOPs) or safe work practices or providing appropriate training, instruction or information.
Personal Protective Equipment
The provision and use of personal protective equipment could include using gloves, glasses, earmuffs, aprons, safety footwear, dust masks.
Ref -

But also evidence of ''What went well even better if'' used as basic review of incident for POSITIVES to be enforced and publicised as well as what went wrong !

eg - Blast screens and test bays were used and stopped the projectile fitting, CCTV cameras were in use and controlled perimiter areas with permit to work for entry to the zone.

Lessons should be learned PRO-ACTIVELY and this is certainly a cultural and leadership  issue and remains the biggest one to be addressed in COMPANIES...Not simply lip service but follow through activities.


tony morgan

faizakhatri's picture

It is a good topic to share many ideas  Trevor point is really good that  lets not overlook the smaller points that have a potential to create major incidents with high consequential loss “ since every single potential which create hazard is noted down HIRA activity  and related with every equipment Risk management checklist  is been made to minimize the error it is also cover in  HSE audits which help for minimize incidents/accidents But if risks and hazards define in frame work of company’s HSE policy and some of outside factor like natural disasters  occurs it  can affect the whole system Refer to famous Quote “Practise makes man perfect “and this apply to our related topic , accident demonstrates the causes and consequences  and  HSE Concern is just like learning  of human and risk  by  method of Root cause analysis and making new better performance measures ,modification  can reduce high frequency to low potential risk  and prevent of accident/incident  Faiza khatri M.Sc oil and gas engineering 


Andrew Strachan's picture

My take on this worthwhile topic is that a data base would be good in theory but difficult and time consuming to put into practice due to (a) a lack of willingness to proactively search for lessons learned and (b) the shear amount of information that would build up over time some of which becoming obsolete/irrelevant as time goes on.

I largely agree with Tony Morgan in that the best method of capturing lessons learned is integrating them into processes/procedures etc. Along with a good RCA process, as described by Faiza Khatri, this is full proof in terms of capturing the lesson learnt and addressing the problem in a systematic way. Where this is not practical, or sufficiently expedient or far reaching enough there are alternatives.

Within the subsea sector the operators at times distribute lessons learned from failures in the field, and these filter down through email. For instance a recent one related to particular grade of bolting which failed on a flange subsea. This is a highly effective method of communicating the failure widely and getting the information "out there" reasonably quickly, (although I suspect it is a drop in the ocean with respect to the amount that does go wrong in the field.)

Lastly, post project "lessons learned/what went well" wash up meetings can be a good forum in which to get the feedback from all disciplines through the project life cycle. These can then be taken and applied at the start up stage of the next project. This type of review could be integrated into the QA system to ensure this approach is adhered to and maintained.

Trevor Strawbridge's picture

Andrews points are valid but not without flaw. I agree entirely with the 1st statement especially "lack of Willingness to proactively search for lessons learned" and this is really down to culture change. Lessons should be captured into procedures and this is a relatively easy task in a small organisation. However if you consider a large international main contractor, these tend to have separate project teams thoughout the globe,  that compile bespoke procedures relevent to they're project's needs and items such as previous bolt failures or any other low profile lesson can easily get overlooked. A good database with a user friendly search engine and appropriate use of the data  is where I would recommend focus especially prior to HIRA sessions etc. I agree with wash up meetings and would encourage data entry on "what went well" as well as "what went not so well".

Hope these points make sense

once again thanks for the discussion



Hanifah N. Lubega's picture

This is an interesting topic which carries more importance than it appears. Lessons in the context of safety can be defined as experiences that re-awaken human senses leading to knowledge or wisdom.

In the industry, the purpose of lessons is to put the entire organisation on its toes in as far as safety is concerned. A safety conscious organisation will have a prudent way of logging lessons taken from incidents.  As Trevor rightly put it “…knowledge is useless unless it is applied”, having logged the lessons, organisations will have find a way disseminating these information to all employees so they do not repeat the same mistakes. This bring to mind the old cliché of ‘Experience is the best teacher’ before certain incidents happen, one may think they are safe enough because probably they have ignored certain failures or even regarded then negligible, but when an incident occurs all eyes are open to every detail. Sometimes I wonder why for example in the Macondo Incident, the Engineers did not notice the increase in the Drop-pipe pressure? Am sure after the incident other companies are now keen on monitoring even the slightest pressure changes as part of the lessons learnt from the incident.

Documenting lessons therefore is benefit to the organisation in terms of safety standards. Failure to do that may result is series of repetitions of the same mistakes and sometimes with more severe consequences.  

Trevor Strawbridge's picture

This is a great Blog Hanifah, I could'nt agree more. As I would reiterate; there needs to be a culture change, not so much in the way we capture the lessons, but how we later search for this knowledge and apply it. To often I have seen engineers of different disciplines participating in wash up meetings, and they follow these up by entering "useful" lessons into large Databases. It then becomes frustrating to see incidents that occur later in subsequent projects, tasks etc, that may have been avaidable, were this already stored knowedge sought, and applied beforehand. Its on these occasions where my immeadiate thoughts are "such a waste of knowledge", what can we do to ensure that knowledge is applied and re-applied ?

I like the blog Hanifah



Tony Morgan's picture

I agree cultural change is the key and the importance of experience and knowledge transfer must be given its place.

One way ive seen this done very effectively is in the safety of most organisations ( since this rightfully should have the highest priority as we all go to work with the intention of coming home again !)

Key regular review sessions need to be given priority in small functional, project or dept calendars key meetings which should be encouraged, supported and enforced from leadership teams on a monthly basis are....RISK REVIEWS,SAFETY BRIEFINGS, LESSONS LEARNED other tools for encouraging this have been incentivising SUGGESTIONS, IMPROVEMENTS, GOOD REPORTING, KNOWLEDGE SHARING

Key Performance Indicators should be established and form part of the employee, supv and snr manager appraisal/bonus system.

A balance between the use of Lagging and leading indicators must be struck ( my preference is to promote LEADING and positivity for live sessions, LAGGING i feel is simply fo reporting processes and backward looking not prevention as such although i recognise that it can provide the justification for ACTION rather than speculative potential issues that need addressed...

SAFETY uses lagging indicators with lots of abbreviated naming conventions such as DAFWC. LTI, TRIR etc. Leading indicators such as  No's of observations raised or ratings of these suggestions made, No of meetings or attendance figures, inspections / audits completed, hosting or leading reviews or presenting lessons on a particular topic ( my favourite for this is to use a strict 5min impact presentation( ref  eg like a SAFETY MOMENT but for RISK reduction or LESSONS LEARNED,   can be adopted across knowledge / risk systems too by similar processes and building them into the daily, weekly, monthly practices eg Daily/Site  Reports, Observation system or registering/submitting suggestions for entries, Weekly, monthly reports and meetings as mentioned also Mini KAIZEN events called PECHA KUCHA
Ref -

In my experience is THE WAY of truly embedding it into the culture its costs time, money and leadership but it has its rewards.

Ref - COINS are the key ( a bit like this course assessment !!!)
The five essential elements of collaborative innovation networks (what Gloor calls their "genetic code") are as follows:
 1.Evolve from learning networks[clarification needed]
 2.Feature sound ethical principles
 3.Based on trust and self-organization
 4.Make knowledge accessible to everyone
 5.Operate in internal honesty and transparency

tony morgan

Derek Porter.'s picture

At present the majority of small scale lessons is kept at a certain level in an organisation such as department manager. For example the lessons may be implemented for the duration that this manager is in charge of future projects . In the event where the manager has been replaced, his replacement has his own way of doing things thus often changing the procedure regardless whether the lesson has been documented in a database.

The responsibility relies on standards agencies such as DNV, HSE, API etc to implement changes applying a legal binding best industry practice. I suggest there should be greater negotiations between all relevant companies with the standards agencies. To eliminate future small scale dangers there is a need for standards agencies, backed by the industry to have a greater influence on operations.

Kelvin Osaro's picture

Lessons are definitely learnt from the occurrence of major industrial accidents in the energy sector in that, new safety legislation law are implemented if the incident creates harm to the environment where by involving loss of life and high financial loss for a company. For example the Piper Alpha disaster of July 1988 [1] has lead to a total change in the safety legislation in the UK offshore waters in that, Offshore Installations (Safety Case) Regulations 1992 was implemented and later revised in 2005 [2,3]. More so, it also lead to the transfer of responsibility from the Department of Energy to the Health and Safety Executive (HSE) in offshore activities in the UK [2,3].


From the discussion above it can be seen that lessons are definitely learnt in the energy sector in that, the Government and pressure groups have created legislation laws through Health and Safety Executive (HSE) in order to be implement to reduce these incidence from recurring.    



[1] Cullen, The Honourable Lord. The Public Inquiry into the Piper Alpha Disaster. London : The Stationery Office, 1990.

[2] Great Britain. The Offshore Installations (Safety Case) Regulations 1992. London : The Stationery Office.

[3] Health and Safety Executive [HSE]. A guide to the Offshore Installations (Safety Case) Regulations 2005. HSE Publications, 2006.

Oluwasegun Onasanya's picture

I strongly agree with Kobina's view, as the utilisation of lessons captured should also be an integral part of this discussion. What
happens next when lessons are captured from an event and what is put in place to prevent a re-occurence?

Root cause analysis(RCA), 5-Why, Why tree are all accident investigation tools that are used to investigate the inherent reason(s) why an incident
occured and what to be put in place and implemented to prevent such an occurence in the future at the work place.

In the facility where i work presently, lessons captured are communicated in the safety briefing given to returning employees,when they
arrive back to the platform.
Morning safety talks in tool box talk is another platform where lessons that were cptured are shared to the work force.
Regular bi-weekly safety meeting is another avenue that is utilised to get across to the employees in sharing with them lessons captured
from any event.

Using the 5-why accident investigation tool as an example, the "why did it happen" is asked, that leads to an answer and the question is asked until
the inherent reason for the incident is captured, filed in the data base of the company for futher use.

Trevor Strawbridge's picture

I dont disagree with Oluwaseguns or Kobinas blogs. Infact I fully concur. However, the issue I have is  the apllication of a lesson. If you consider the following scenario: A weld fails in service and has financial and human consequeces, an investigation takes place that may include a tap route, route cause analysis etc. The outcome was that the weld was incorrectly designed for example. The lesson is then captured into a data base  and will probably be applied by the people whom were at the front end of the investigation as they have full awarness of the incident. So consider 12months from now , a new project kicks off with a new project team and the same/similar fabrication is to be performed. The new people on that project team may have no knowledge or understanding of the incident/ investigation/lesson that happened 12 months earlier. So the potential for a repeat failure is high unless delegates from that team are made aware of that lesson. which brigs me to my next question How do we do that?



adavis's picture



Ouch!  That's sounds too familiar.  Every organization I've ever worked for has struggled with these issues.  However, here are a few practices that I  feel help close the gap slightly.  Note there are not necessarily in the order of importance.

1. Share the information - Though it can sometimes be embarrassing, its best to share this information across the organization so that others can learn from your mistakes.

2. Implement a knowledge database - Too often, I seen individuals come up after an incident an state that they knew that would happen and it could have been prevented if they for their opinion.  A properly laid out knowledge database can help improve communication across an organization and keep "the answer" from being buried in one engineers files.

2. Tie lessons learned to the quality system - Manufacturing organizations often believe quality is only about the actual product.  They often lose sight of the fact that mistakes made within a process that has nothing to do with the manufacturing of the product can have a major impact on the organization. Documenting the issue is only the first step.  Quality systems are designed to take a issue through documentation to implementation (see steps 3-5).

3. Integrate best practices into the design tools

4. Incorporate the lesson into training for new and experienced employees.

5. Modify procedures before closing out the lessons learned.



Trevor Strawbridge's picture

A few good points here which are indicative within a quality system that has " Continuous Improvement" written within, and whilst documenting the lessons is paramount , its; "what happens next" that I struggle with. How are lessons that are recorded within a database rolled out and re- rolled out again and again....etc. After all a lesson doesnt realy expire but it can very often be developed or improved. So the important point to note is that whist we have this knowlegde stored in our database how and when do we recall that information so that we can re-use it? Researching the database prior to HAZIDs, HIRA's etc may be a plausible idea. Your thoughts welcome


Craig Donaldson's picture

Maybe not researching beforehand but an idea may be to assign each incident a set of key phrases based on how the incident led to an accident. Key phrases would be best utilised if they were ones often used in things like HAZOPS and could include such parameters as high temperature, low flow, loss of air etc. Then after a HAZID or HAZOP where situations have been highlighted by a team then a search using the same key phrases could be run on the lessons database and all past incidents with the same key phrases would be flagged. Obviously this could lead to a large amount of "hits" in certain scenarios where only one key phrase is used and thus is not a full proof method.

I think some sort of variation on the above using an automated method of pattern identification is most certainly the way forward. This would remove the need for regular training (reminding) new and old employees of past incidents which would be time consuming, costly and most likely pretty tedious.

You really have struck a very difficult to solve challenge here and I would be interested to see if anyone can come up with a solution to fit all scenarios.

Manuel Maldonado's picture


Lessons learned process is a part of the Knowledge Management process which has been discussed for quite some time. Most of the objectives and disciplines have been already mentioned in this forum and they have also been discussed widely in the literature. The most important processes which have provided significant performance improvements to the industry in areas of safety, productivity, human resources, operations and technology advances are related to continuous improvement processes through the sharing of best practices and knowledge. One interesting book I would recommend to read is called Learning to Fly written by Chris Collison and Geoff Parcell which is very related to a practical knowledge management (lessons learned) and some of what has been discussed in this forum.

In my opinion, the first stage of the lessons learned process and mainly the Knowledge Management Process can be addressed by what and how we have learned, why and how of the capturing of learning experiences. The outcome of this stage would then be the base for a second stage which is the analysis of what went well and/or what and how we could have done differently and the implementation of the learnings via a Management of Change process. This then agrees with what has been said about the importance of implementing the learnings (becoming the best industry practices) in a practical way by developing new standards, regulations, and/or procedures. That would be then a formal and an effective way of ensuring a continuous improvement which will be reflected in good performance improvements.

The industry has been heavily reinforcing and supporting these processes during the last two decades and significant improvements have been observed. Regulations and new standards have been established, best operating practices are now being observed on offshore installations. Formal management of change processes, incident investigation processes, formal reporting and recording processes are now rigorously followed as part of the Process Safety Management, all of these resulting from a good leadership. However, those tools and processes are part of a culture of learning and therefore that culture needs to continue growing in order to maintain safer work places and guarantee operations with zero incidents or accidents.

Alabi Ochu Abdulraheem's picture

When we talk of lessons learnt from safety issues, we are referring to both the positive and negative lessons safety issue brings to our door step. A comparative study by the HSE has revealed that the main causes of accidents include inappropriate actions from the management on board before and during the incident, the weakness of the management system which allows for incompetent leader to be in charge of an operation and of cause human factor can’t be ruled out of this. HSE also concluded that some of the lessons learnt from these major causes of accidents include putting in place effective procedures for assessing and ensuring competence and for monitoring management scheme, safety and best interest of the younger employees should always be placed first and strict adherence to safety regulations as stated in the safety case. I would wrap up by saying that if you think safety is expensive then try an accident.
Name: Alabi Ochu Abdulraheem
Reg no: 51231595

farman oladi's picture

Safety is the main concern for both, Administration’s Regulators and every operator / owner when it involves a major hazard. Although big steps have been taken to minimize the risks involve special when it concern is oil & gas industry and powerful regulations has been implied to avoid such accidents , but still human error and poor maintenance and improper technical and commercial management  shows that these regulations are not thoroughly implied .  Also there are still day to day small safety aspects that nor the regulators , neither  the operator / owner have much concern for  , but the operators suffer in day to day work.

These are the areas that lesson learned has less applications , especially when it concerns big companies operating in less advance and developing countries where rules and regulations do exist , however are not implied due to cost involved or some other restrictions.  To me although it is important to learn from each and every incident / accident , but implication of existing safety rules and regulation has much more importance . 

Ike Precious C.'s picture

Of course whatever safety measures we have in place at the moment, 80-90% of them have come from lessons learnt from one accident or the other whether catastrophic or not.
But one of the issues plaguing the Oil and Gas industry is the fact that some of these lessons refuse to be learnt as long as there is no occurence of accident. This I would point out, as Alabi commented earlier, as being the weakness of the Senior management of the organization.
I believe a system must be put in place so as to have a hindsight of what performance per time and issues that had gone wrong and likely outcomes if disastrous.
On the other hand, I think Operators should learn to venture into new concepts that will boost their technology. It is not new that most Industries develop cold feet when a novel technology is introduced from outside the organization; they all prefer the way things have been done, especially if there has been no report of a disaster.
During the Post-Macondo lecture, it was pointed out that Operators were not so quick to opt as partners during the testing of the Capping device, developed as a result of the lesson learnt from the Deepwater Horizon Disaster. Organizations should look for system of looking at novel technologies and analyzing them as soon as possible so as to incorporate changes and improvements accordingly.

Thank you.

Patricia Fleitas's picture

The ideal case would be that the organization can track and trace the information, but in fact this is the most difficult part. In my own experience in the oil industry, I have founded that several barriers makes difficult to save and share the information:

• The organization is divided and some of the information is considered as “confidential”.
• The organization needs to put huge human resources to load, update and manage the information.
• The safety record is not shown on public data base due to organization polices or governmental decisions.

In some countries, when an industrial disaster happed, the government try to don’t make a public opinion about the causes of the accident (governmental decision). It is sometimes understandable, because people mix politics with safety. But, what is not understandable is that technical people can’t talk about the accident in order to evaluate the lesson learned from the accident. I am very surprised about the Piper Alpha public enquiry developed in 1989. It has two volumes and analyses every detail of the accident. For the ones that haven’t seen before, don’t miss the opportunity to have a look at the Taylor Library.

I conclude by suggesting to the organizations to make a high value of their own historical data resources, share the information and put the cap of safety polices without being ashamed of the bad past experience, in contrast make the most of previous experience to gather a better future for the energy industry.   

talal slim's picture

I am currently working on a subsea project and we use a formal lessons learnt process inorder to ensure that knowledge gained from experience , successful or otherwise , is used to improve the project outcomes.

The objective of this process are :

1) ensure that the lessons learnt are effectively captured by a) seeking experience from other projects in the corporate through the lessons learnt share point b) engaging with other project teams executing similar subsea scopes c) maintaining database of lessons to ensure that key lessons learnt are retained and not lost d) conducting formal engagement with suppliers and contractors to solicit  input

2) ensure that the  lessons learnt are effectively applied to imrpove the project outcome by : a) facilitating sessions early in each project phase to identify high priority lessons for application b) holding regular reviews of the lessons learnt database to discuss and document applicability

3) ensure that the lessons learnt are effectively shared with others in the organisation by a) holding a workshop at the end of each project phase to capture and prioritise all lessons learnt b) Sharing those lessons  with other project teams worldwide through the internal net and by uploading the main lessons learnt on the database

For us the process is working well so far , but I believe that no matter how good the process is , without the right organisation culture and the right human behaviour , knowledge retention and management will fail regardless .

Richard Milne's picture

Good Morning all,

I was recently at a graduate training session with graduates from around the world within my company. One of our courses involved Lessons Learned and how they are shared and implemented.

It seemed to me that the Lessons Learned database that we have has the same downfalls all around the world: It is tough to search through and will take you up to half an hour to find 2 useful lessons, and that is if you know the type of thing you are looking for. If you are having a browse through the lessons hoping to pick something up for a specific project, it is very hard to navigate.

Most of the problem behind this is an outdated system, which was around when the company was much smaller and the lessons learned were fewer. It seems that this is the sort of thing that companies do not invest in when they grow.

Another part ofthe problem is quality control. From the graduate session, it became clear that some countries graduates have been set targets of entering 2 lessons into the database per year. This sort of target setting introduces the argument of quantity over quality and can add to the confusion in the database.

We do have internal checks for the lessons, the engineer sends it to his manager for approval in the system, but quite often, the manager is just as busy and just presses the accept button.

These situations need to be handled in a more robust manner, with more emphasis placed on quality and tracking, and possibly finding a way to link similar lessons.

Tony Morgan's picture

Lessons and Database 

You make some excellent points and it is essential that time and priority is given to the value and scoring of the lessons.

A key factor in the use of any database is the design of it and search capabilites - the best have a variety of ways of searching - dates, projects, assembly, product types as well as keywords however real lessons should be worked into the management/control system via procedures, processes and checklists to ensure lessons are documented into the fabric of standard procedures, guideline documents or checklists. As noted by another contributor SUBJECT MATTER EXPERTS assigned ot the management and control of specific products or areas of engineering or organisation should be given time to spend on controlling, validating, accepting and providing feedback on lessons. Some kind of scoring and categorisation should be applied to each lessons as you suggest so that they can be grouped and then combined into standard practices and woven into the working documents of the organisation as well as simply being part of the browsable database.

I think it is a good idea to set the targets in order to generate the ideas/ solutions and 2 a year does not seem very much to be honest. I would expect 2 per workscope or 1 per month ?

The review of these does need a senior engineer to be allowed the time to review, coach and feedback but this is all part of a valued mentoring system that many companies are bought into.....the challenge as always is to make these sessions weekly and stick to them. Keep them short and regular and if you miss one then the next one cannot be missed, no excuses. The mentor or supervisor should have mentoring and knowledge transfer as one of his appraisal KPIs and be measured by his mentee and boss on his performance via true 360 degree appraisal system. This culture should be rolled across the organisation as an investment in the value of lessons learned and importance of knowledge management.

All main institutions eg IMECHE and IET profess mentoring as an essential skill and this should be more than lip service. It is essential that the knowledge of success and failure is passed on from engineer to engineer and this cannot be enforced but the best organisations identify the personality traits and people with the drive and passion for this type of work and ensure that they are given the time and tools to carry the torch.

tony morgan

Mark Haley's picture

You are absolutely right. The key to learning lessons from others is to have a robust database of previous errors or incidents that others can learn from. Unfortunately, the data in the energy sector can be quite sporadic and companies do not like to share information.
An example of a good database is in the aviation industry where a central investigation branch (AAIB) is responsible for investigating all aviation incidents. The reports from these incidents are then available for all to read, from a single source that is unbiased and completely professional.
The good thing about the Air Accident Investigation Branch is that they report the incident, they make safety recommendations, but they do not apportion blame or liability. This means the reports can be read by all and lessons can be learned.

I think that it is long overdue for a similar branch to be setup for the energy industry. It will only be through an independent investigation branch, that is responsible for investigating all incidents, that we will have an accurate and representative database of incidents which we can all learn from.

Mark Haley

Richard Milne's picture


A central database would be great for Oil and Gas. With all the learning that has gone on in the North Sea, and all the learning that is still to be done in other secotrs (West of Africa, Gulf of Mexico etc) then a central agency would work wonders. The trouble I can see with that however, is that aviation works slightly differently. A small malfunction on an airplane can cause catastrophic failure and loss of life, whereas a small malfunction on an offshore installation may cause a small injury to one person. The trouble therefore would be working out a scale for which we the oil and gas industry will report incidents for.


Going to back to a previous point about the number of lessons to be posted per procedure/month/year, I think that 2 per year is quite a lot if there are several engineers working on a project. There may also be lessons for us that are project specific, or experience specific (ie, another engineer has experienced it before and recorded a lesson) that it is not appropriate to share with the entire company because it is not relevant.     

Richard Milne's picture

Hi again, guys. Just remembered a further point I want to add.

While attending the graduate seminar, we were asked how our respective countries and departments share knowledge - ie lessons.

It became clear that there is a large tendency towards informal sharing - going to talk to someone with experience - than there is towards formal - writing a lesson in the database. In a way this is good because is allows people to develop by being able to ask the relevant questions and have interaction with more experienced engineers, however, it means that if the more experienced engineers retire or move on, then we are up the creek.

I'm not sure how it should be implemented - perhaps by graduates taking it upon themselves to record the things they ask more senior engineers, but there needs to be some sort of way to record the knowledge of those who have been there, without inconveniencing those people too much.

Tony Morgan's picture

Lessons - learning logs

Personal you could use your weekly report to generate the inputs to your learning log - this should consist of lessons from each event that was worth reporting eg Deviations, NCR's, performance reports, MOC's, VO's, Late / on time deliveries or deliverables, Successes,
you can also record your more personal thoughts on the items, people or methods employed as these are not always for publishing but are likely some of the most valuable lessons you will learn personally.

On at least a monthly basis you should take your top5 or less to your mentor for discussion and review - this can be over a coffee and record feedback - this may come in the form of some directed further learning on the subject matter however it could be that you have uncovered a true lesson and its value should be recorded more formally in the company system for sharing with others.

look at what these kids do these days......

isnt it amazing. REAL mindmapping of lessons...i gonna try to emulate these guys this week( just 10mins worth every week i'm sure shall show potential value to making continious improvement in my business/ dept.

Project - as part of the monthly reviews a short time could be set-aside for review of the big issues from the month and then stepped through as suggested below using WHAT WENT WELL EVEN BETTER IF methodology.

The more regular these reviews take place the easier and more valuable the contributions shall become as it becomes almost second nature to brainstorm the way things are done, questioning is to be encouraged as long as solutions are offered for improvement rather than as criticism.

One of the biggest sources of lessons will be a formal reporting or performance system which can start simply enough with daily and monthly reports and be developed toward the major database systems in use across many organisations where the data recorded demands even more detail to allow seperate analysis of the failures in order to provide trends and reports across categories which help to direct resources and focus toward the most valuable lessons to be learned.,_Analysis_and_Corrective_Action_Systems

These systems are quite advance now in the larger organisations and allow real statistical analysis of trends, root cause and effects being document as a matter of course and when we get to true root cause real lessons are learned.
The balance is always made against the value of the learning but a basic time allowance should be allowed in order to get to the root and identify possible solutions before some scoring is applied to help management prioritise the follow up work to obtain a truly corrective action preventing re-occurence.regards
tony morgan


"Those who don't know history are destined to repeat
it."- Edmund Burke

"Those who cannot remember the past are condemned to repeat
it." - George Santayana

times, lessons learnt are captured but the big question is: are they always

disaster cost the company about $5billion in damages. Did that damage their
reputation? That incident was a turning point for the company even if it was
seen as a low point in many quarters. It led to the introduction of a new
safety strategy now adopted throughout the company. A risk matrix was
introduced which triggers referral to higher level of management and cost
cutting proposal now have to go through a risk assessment process. Exxon learns
and apply.

at BP, I will say they learn but pretend to apply, cheaply or maybe not at all.
The basis for my argument will not lie solely on the Gulf of Mexico spill. In
March 2004, the Texas City Refinery explosion resulted in various OSHA
violations, In the same Refinery 2 months later a worker fell to his death in a
tank, a few month later a worker was burned to death in an accident and in
March 2005 multiple maintenance failures caused an explosion in the
Isomerisation unit leading to 15 deaths and 200 injuries. BP did not learn from
these cost-cutting related accidents as it again in 2006 neglected maintenance
of the Prudhoe Bay pipeline leading to its rupture and leaking of 4800 barrels
of oil per day.

to the Macondo incident, Exxon was drilling an ultra deep well, Blackbeard
similar to Macondo well (HPHT) in 2007 but had to stop drilling because the
Drillers suggested that with the complications encountered, a blowout was
eminent. The management listened to the Drillers and walked away from a
$200million investment. Lessons were learnt, captured and applied. BP
underestimated safety. They learnt, captured but didn’t apply. A $34million
drilling lease resulted to paying out tens of billions of dollars




Etienne Gunter's picture

On an international level, I think the best way to deal with this is to have forums on a regular basis, where all major issues can be discussed. This can lead to the publication of papers and also the collective influencing in policy making or improvement of standards. These issues can easily be circulated in news bulletins for specific industries or topics. The challenge here would be to get companies to collaborate and share. It might not be so difficult when dealing with health and safety, but discussing designs or IP sensitive issues might be more difficult.

On a lower/company level, I think, in some ways it might be more difficult. In the past, we have had events like Project Close Down meetings or Critical Design Reviews, but the documenting and accessing of the information afterwards still remain difficult. In this regard, there is no substitute for experience. But considering that people often change jobs or retire, one would think that a company would put in more effort to maintain continuity regarding lessons learnt and the retention/transfer of knowledge.

Mohamed H. Metwally's picture


When the top management in any company has the will to learn from past lessons, everything else is easy.

I think the solution may be a small software package that has the capability to store lessons and retrieve them by using key words or whatever....Maybe the contribution of the company's employees in developing this kind of software would guarantee some sort of management commitment towards making best use of past lessons.

Trevor Strawbridge's picture


I agree with what you are saying , The database  is only a tool and should be designed so that it is easy for all to search and utilize. The main factor for knowledge management to work comes from the people within the organization. If there is genuine commitment then you woluld see continuous improvement for sure.


Thanks for the comments guys

SanjayVyas's picture

Accidents happen in Oil and Gas Industry and to help prevent their recurrence, it’s
always important to learn what from those incidents. Sharing lesson learned is
one of the most effective techniques for improving safety performance. Generally,
accident or significant “near miss”, are written up, describing the
circumstances and consequences of the incident, analyzing its causes and
formulating practical recommendations. The purpose is to learn practical
lessons, share them and ensure that each entity concerned benefits from them.

Regulators updates HSE regulation based on lesson learned from accidents / incidents occurred at
any part of the world. For Licensing and Engineering Industry “Lesson Learned” is
a critical element to ensure continuous improvement in safety performance of
their process and engineering design. HSE feedback from design, construction,
commissioning and operation phase is of projects helps in evaluating HSE
compliance, identification of hazards, enhancing risk management techniques

Sanjay Vyas-51234203


Promoting lessons learned

 Piper Alpha: Lessons Learnt, 2008

Subscribe to Comments for "Topic 38: Lessons - how are these captured"

More comments


Subscribe to Syndicate