Are lessons really learned?

Without the appropriate atmosphere, procedure and tools to incorporate Lessons-Learned, an organization may continue to make the same mistakes over and over.

By REUVEN BEN-SHALOM
an office place 370 (photo credit: REUTERS)
an office place 370
(photo credit: REUTERS)
"You almost caused our mission to fail!" the deputy squadron commander reproached me during debriefing. I rechecked my checklist and discovered that I had followed procedure to the letter. "Apparently you failed to read the Lessons-Learned report from two weeks ago," he went on, "and we didn't get around to updating the checklist yet."
This incident, some 15 years ago, shaped my philosophy on Lessons-Learned (LL) implementation that I hold to this day.
Whatever the nature of the organization, there is always a need to streamline the way it operates in order to increase effectiveness, efficiency and productivity, save time and money, and boost client satisfaction.
Learning from both failure and success, helps us decide what to do differently next time. On a personal level, we do this automatically by experience. But an organization may continue to make the same mistakes over and over, without the appropriate atmosphere, procedure and tools to incorporate LL.
Many organizations find that the process, consuming substantial resources, turns into a mechanism for observing and collecting lessons, without much learning at the end of the day. Learning only occurs when lessons are "institutionalized," i.e. that they lead to change in policy and procedure.
The Israeli Air Force is famous for the following straightforward debriefing culture: What was supposed to happen, what actually happened, why did it happen, and what can be done to make it better next time?
This constantly generates good lessons, but the challenge is not only capturing the right lessons, but dissemination and application.
I learned this the hard way. As an organization that "sanctifies" manuals and procedures, we should have been better at making the appropriate amendments in our Standard Operating Procedures (SOP). We were learning the right lessons but failing to make them accessible and practical.
Do not conclude that this only relates to operationally oriented organizations. It doesn't matter if you're running a pizza parlor, race track or an investment company. A common objective is to learn from mistakes (and successes), and get better at what you do.
Knowledge is not naturally stored in one place but dispersed in people's minds, and in endless documents and information systems. It is not a data bank, but an information network.
This is why it is necessary to consolidate all corporate knowledge and produce practical SOPs. There's no reason to reinvent the wheel and a good LL process leads to constant updating of the SOPs.
Who should manage LL in the organization?
An external entity will tend to be detached from the core issues and create a separate agenda of self justification. I have seen organizations that host outside "experts" who walk around with notebooks collecting irrelevant "lessons".
Lesson learning must be driven from within, by dedicated LL Facilitators (I shall refer to them as LLFs) and they must act as coordinators, not generators.
Dealing with LL is a long term investment. It does not usually contribute to the current project, and sometimes not even to the current people. It "wastes" resources, and in a way asks people to give the education of their predecessor priority over their own success.
Investing in LL is counterintuitive for veteran employees, because they know how to get the job done, and are getting better and better at it anyway.
There is of course the ego factor too. People may feel that sharing knowledge with others reduces their own prominence. Competitiveness is surely a negative factor when it comes to lessons learned. This is true between people, departments, companies and countries.
People may tend to suppress lessons that reflect poorly on their performance. Not many organizations can boast a culture that enables, promotes and rewards the act of admitting failure.
And there is laziness. The last thing people want to do after a long day is talk about lessons for two hours. Still, it is essential to exercise discipline and conduct a LL "after action review," in order to capture the main points. Other phases leading to implementation can be performed offline, with full transparency through the organization's information system.
I am not implying that LL should be dealt with in a linear fashion. Quite the opposite - it should be a continuous process, best explained by this cycle: Plan - prepare - brief – execute (identify) – debrief (capture) - filter - process - implement (SOP) - review.
Technology is nice, but is not the most important thing. An organization can excel using Microsoft Excel, but will fail even with the most advanced software if leadership fails to instill a supportive culture of openness to learning and change.
An important phase in the process is sifting through the accumulated lessons observed, filtering those of value and deciding how to implement them. I have seen organizations that keep a "lessons learned notebook" during projects, urging everyone to make entries as lessons surface. The result may be hundreds of hand written notes, many of them irrelevant or impractical for implementation, such as "need cooler with free drinks."
Can we dispose of raw LL after implementation? We ascertained that a lesson is learned only after it has come full circle, so all we need is the updates SOP, right?
Not quite. The LL database is still a valuable tool.
A new boss may unintentionally choose methods that have already been tested in the past and rejected. This is the point where LLFs must speak up, and save the boss from himself, using an accessible and searchable system.
Every entry in manuals and SOPs should be tagged and hyperlinked to its historic evolution. It should allow us to see what was there before, and the logic leading up to the current version. This kind of historic documentation can prevent a rollercoaster effect of unnecessary repetition of old mistakes.
The LL database should have absolutely no personal references. Failure is exposed here only for the sake of procedural improvement, not personal accountability.
Every project or mission should begin with a LL "before action review," introduced by the LLF. The main clusters should be LL from recent activities and LL from past projects with similar characteristics. This helps focus the team on areas that should be monitored, and reduce surprise or objection from those who encounter changes to a routine they are familiar with.
Leadership must propel change in organizational culture and incorporate mutual learning for the sake of organizational development and success.
The writer is a former pilot in the IAF, founder of Cross-Cultural Strategies Ltd. and International Project Manager at CockpitRM.reuven@CCSt.co.il