Lessons Not Learned

Lessons Not Learned

By Jeffrey Gentilello

     Technical professionals tend to overlook a valuable resource. Many organizations publish white papers and technical  journals of significant value containing key historical data and insight.

     The titles are varied, but the common thread is simply "Lessons Learned". In many instances, simply providing background information on a similar issue from a different perspective could prove inspirational in providing a solution to a problematic situation.

     Many engineers, scientists or others in the technical field never take the time to read through this material. They consider it old news, not applicable, or otherwise nice to know, but not essential information.

     Others claim they have no time to read as it would take away valuable time spent on more "productive" endeavors. Yet, these professionals are the very ones who should embrace this valuable resource. The wealth of knowledge contained within these, in many instances, vast repositories, contain valuable and vital material information.

     To those who would say they have no time, let me ask you this; if reviewing Lessons Learned saved you from committing to a wrong process, or to a choice of wrong material, eventually saving many tens of thousands or even millions of dollars in lost revenue, not to mention thousands of man hours in lost productivity, what would that be worth?

     To others who say that older lessons learned aren't applicable to newer process or technologies implemented, I would caution that valuable insight could still be gleaned. A better understanding of the situation from diverse backgrounds can in many instances lead to fewer missteps and errors.

     It is not necessarily the exacting methodology from which past failures can be learned, but also the thought processes which can be altered, perhaps gaining new insights on implementation methodologies or even more simply, what not to do. The "Not Invented Here" mentality can be hard to overcome, but the rewards can be substantial if engineers can learn to look beyond their immediate surroundings.

     I will cite an example for consideration:

     One organization for which I previously have been a stakeholder routinely committed the same mistakes, repeatedly, time after time. This outfit is one that produced and published vast amounts of lessons learned documentation, continuously disseminated training to employees, and took pride in the vast resources it was able to provide within its organization.

     Yet, when it came down to producing product, the new management team brought in to develop the product didn't follow company processes, didn't adhere to stated company policy, ignored many (seemingly all) of the lessons learned the organization produced, and went about haphazardly creating their products without any semblance of organized thought or process. 

     In discussions with the new management team, I pointed out that they were not adhering to the specified guidelines for the creation of their products and weren't following a logical organized path. I outlined to management each area that needed improvement and the methodology required to implement the much needed changes.

     Interestingly, several articles in their own Lessons Learned publications explicitly indicated that failure to follow proper guidelines and stated procedures was an endeavor doomed to failure.

     Even more fascinating was that the team charter also described the process and implementation plan. Worse yet, the team charter was instrumental in procuring the contracts for which the products were to be delivered. 

     The management team acknowledged the lack of progress in the development of product, but stated that it was under control and in capable hands. I continued to offer guidance and counseling as the management team was being pressured from corporate executives to increase productivity.

     Eventually it became clear to me this lack of discipline wasn't about to change, despite the failures and high turnover. My counseling and consultation was not being implemented, so we parted ways.

     To my knowledge, this organization has yet to implement any of my recommendations and is still meandering through haphazardly creating product, well beyond deadline, and well over budget. Lessons Not Learned.

Key Takeaways:

• Lessons Learned are a valuable tool in the arsenal of any technical organization.
• Knowledge of previous undertakings can pave the way towards a better understanding of the path forward.
• Lessons Learned can not only be a resource of what not to do, but also a valuable tool in learning a correct methodology, implementation of a proven process, or simply not reinventing the wheel.
• Lessons Learned are not all about mistakes and their avoidance.
• Properly documented Lessons Learned are also useful for understanding what went right and why, things that didn't go wrong but should have, or simply documenting a positive outcome.
• Lessons Learned can save valuable resources, time and money.

This is the first in a series of articles I plan to introduce on Lessons Learned and other topics related to Systems Engineering, Systems Safety and Technical Assurance. If you enjoyed or found it useful, please drop me a line.

©2016 Jeffrey Gentilello

Systems Engineering & Technical Assurance

Session 1 "Lessons Not Learned"