Much has been written about lessons learned systems and the need to convert from a ‘lessons identified’ to a tracked action and subsequently a closed out action such an updated standard. I would like to expand on that theme by illustrating why that might not be enough.
Picture the scene, the engineer is in the test facility about to witness the testing of a piece of equipment when he sees a similar piece of equipment nearby. It’s similar to the equipment he is about to test but not identical. He enquires about it and is told that it is for another company, does the same thing as his equipment does, but is much simpler in design. Over coffee he enquires how it is simpler and if very surprised that in many ways this piece of equipment does what his does but always in a simpler and he learns later on, much cheaper way. Both pieces of equipment do essentially the same job but one is more complex and more expensive than the other but why should that be the case.
When he gets back to the office, the engineer digs out the standard and looks at it with renewed interest. This time rather than just accepting what it says, he starts to question why the standard is written the way it is. He starts to ask people, why is that requirement included in the standard? Sometimes they don’t know but frequently they respond that it must have been due to a previous lessons being learned and the standard being updated.
At the end of the investigation he concluded that over a period of time lesson, upon lesson, upon lesson had been used to update the standard without any attempt to review previous lessons to see if a previous requirement had been superseded. The net result was a standard that was probably too complex and adding cost to the equipment that was being procured.
Using lessons to update standards is good but the context in which the lesson was learned is important. Perhaps your standards could do with a spring clean?