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?
Posts
