Downside of Capturing Lessons Learned in Processes

While we have just spent the last portion of this section discussing why processes make a good repository for lessons learned we must also cover the potential drawbacks of that action. As most of us know from working any project or being a member of any organization the only constant is that there are few constants and almost no absolutes. Even when organizations are basically structured in the same way, independent of geographic location, that does not mean the different locations capture lessons learned in the same way and same place. It is those slight variations in structure that shift the system dynamics in such a manner that capturing information, such as lessons learned, and its best repository could vary extensively. However, when you apply the theory of diminished returns the prime location for capturing such information is at the apex or when put in organizational terms the mid-level which is most commonly the process level.

Organization Structure—Localization

When a process is captured within one department it can diminish both the sharing or the lesson learned, and the potential enhancement of that lesson learned. As with most changes, which is what a lesson learned promotes, perspective plays a major role and thus obtaining a second perspective, especially from an external source, can assist in determining the true usefulness of said lesson learned. If we look at Kotter’s 8 step change model in steps 1 and 2 he discusses communication and the make-up of the team/group being from different departments and when we look at the McKinsey 7S step change model, we see the emphasis placed on knowing the current state and understanding the desired future state.[1] In both Kotter’s 8 step approach and McKinsey’s 7 step change model there are steps that work to identify the scope of the change including the required participants. Thus consider the present organization’s structure and breadth of the focus of the change event.

Process Restrictive

Process restrictive is the focus of the improvement on a single process or component of that process. While this type of dilemma is not restricted to just processes, when process exploration is solely captured within the process and not shared with others for evaluation of applicability, then it will only serve the process owner. This hiding a lesson learned is yet another example of information control. If lessons learned are captured within any procedure, process, or even a functional area a brief overview should be provided to at least one or two other equal areas for an application review: this constitutes knowledge sharing.

Many processes are structured such that if they are a standalone they are still a part of a system or organization. Knowing how and where the processes fall within this system, its predecessors and depending functional relationships will aid in reducing the process restrictive effect caused by the lack of system understanding.

System Effect Restriction

In this case we make alterations to the process based upon what we learn, without considering the entirety of the system, having impact on depending actions and processes. Similar to the discussed process restrictive, but with the key being solely on the system dynamic of the lesson learned is what is meant by “System Effect Restriction.” Unlike in the process restrictive section, the lesson can be shared, but the actions developed from it have little to no evaluation of the overall dynamic of

Rotter's 8 step approach

Figure 2.14 Rotter's 8 step approach.

the whole. Tills type of pinpointed assessment usually leads to corrective actions that contain unintended consequences as we discussed similar to the proximity and cause discusion in Chapter 1.

Lesson from Lessons Learned

We have discussed some of the places to deposit lessons learned and why they might or might not work for an organization, but one thing we have yet to discuss is the lessons we learn from what we have learned or think we have learned. This is two different topics and we shall approach them in the following sub-sections. However first we should look at what is a lesson learned from what a lesson is; to best understand this we must review actions we employed from what we thought we learned, the results we expected from those actions, and how those actions related to the genesis of the lesson learned. Measures of Actions from Lessons Learned

Correlation of lessons learned with the data captured is essential to longevity and effectivity of any organizaton or project improvement endeavor to be able to build some measure of crediblity how we handle the lessons learned. The approach should be congruent with the scientific method, which enables us to make some definitive statements, within the context of the experiment, about what is observed.

  • 1. Identify the problem
  • 2. Research and Hypothesis
  • 3- Experimentation
  • 4. Data analysis
  • 5. Conclusion
  • 6. Repeat

The actions we take generate measurements, or they should. These measurements will be compared to specific goals of the organization or the project. Therefore it is important to develop metrics that are associated with the goals of the project and the organization. This is not a trivial activity, and we must remember that metrics or measurements tend to drive individual behavior. Correlation of Lessons Learned for Data Capture

It is not uncommon to find that the lessons we have learned do not apply toward the actual change that is needed. This is why we are of the opinion that when an issue arises and is covered by a basic root cause analysis or team learning session, the outcome is neither long term nor sustainable. Most root cause analysis and team learning sessions performed by companies are superficial and, from experience, often driven by those with a political agenda, whereas in a learning organization the issues that produce lessons learned are actively sought out and checkpoints along the path are inserted to verify if a directional change is needed in the process, project, or organization.

For example, while heading across the Atlantic it is noted the course is off by 3° at the beginning, so a 3° correction is made. The reason for the difference of the desired course and the actual course is not determined, but a validation point is set for a certain number of miles to ensure the correction is effective. At the validation point it is noted that a minus Г from the desired course is being made. At this point an evaluation of cross currents is done and noted as shifting along different points on the path taken to our destination. This produces the action of setting the course based upon the different areas of cross current and establishing more validation points where corrections are needed to be made.

Above is an example of stacking a lesson learned and its collective application. Often, we learn a lesson, and there are follow on lessons directly related to that lesson. The manner in which these lessons are captured is just as important as the original lesson itself, perhaps more so as this lesson is linked to other lessons. If these lessons are captured as several different lessons learned the overall point will likely be missed and thus the actions will more than likely be disjointed and ineffective. However, if we capture them as they occur and link them in such a way as to show the evolution and the actions that developed them along the way we can better see the direction and the effect upon the system as a whole.


Organizing lessons learned by process helps codify knowledge, in a way in which there is a measure of confidence in the results (not anecdotal stories). The processes provide a starting point and baseline for future learning. While most people look solely at the actions taken or done, it is best to know the why behind the actions as well. If an action or reaction to something is based upon a flawed assumption, it will not lead to our goals and most likely lead to secondary issues, even if the initial action proves successful—accidentally. When there is a secondary issue from this type of logic they are commonly attributed to some unrelated event because the action or the first issue was successful and thus is incorrectly removed from the potential cause of the second issue. This type of logic is only compounded if the action from the first issue was also successful on some other action as well thus further reinforcing the logic flaw. As we discussed in this section we can see how as the loops increased, single, double, and triple, the likelihood of this type of flawed assumption is diminished. Knowing this and then applying the Action Theory we can or at least should be able to determine if some form of personal bias is affecting the outcome and/or analysis and thus diminish its effect on developing the best solution as well.

Sharing Lessons Learned across Processes

From experience, we can say spreading the learning is one of the more difficult tasks that an organization will attempt to execute. There are numerous obstacles to the sharing of knowledge. They range from indifference, the manner in which the lessons are captured to lack of information or concern of office politics. As we can see from most of the references on organizational learning and leadership the political aspect is the most difficult to overcome followed not so closely by understanding or informational application. In this section we shall discuss how sharing lessons learned across processes could help negate at least two of these three issues: understanding and informational application. The political aspect, I’m great and you’re not,[2] is discussed in section on Office Politics subsections.

Processes are a collective of several different procedures and can span across several departments of an organization. While this possible multiplicity could potentially cloud the gain of a lesson learned it in fact aids in the understanding and could assist in the propagation of the lesson and if conducted in a manner to promote understanding between process owners and thus better systems understanding. The fact that sharing a lesson across processes could open the lines of communication and promote understanding of the processes end to end rather than as a discrete activity, including another process owner and vice versa should be reason enough to approach it in this manner.

  • [1] Using the 7s model to increase the chance of successful change. (2017, February 10). Retrieved November 15, 2018, from
  • [2] Logan, D., King, J. P., & Fischer-Wright, H. (2011). Tribal leadership: Leveraging natural groupsto build a thriving organization. New York: Harper Business.
< Prev   CONTENTS   Source   Next >