Realizing the learning organization

Lessons Learned (LL) comprise the written recording and systematic collection, evaluation and condensation of experiences, developments, indications, errors and risks in projects. Observing and avoiding these can prove useful for future projects. Lessons learned are part of the project completion documents, but can also be used for any other process in an organization or company and are usually provided in a structured, accessible archived form.

Learning and lessons learned - the danger of isolated consideration

Looking at lessons learned in practice, various shortcomings and gaps become apparent. For example, the following situations can be found:

• Lessons learned are part of the defined project procedure, but are only done because it is mandatory.
• Lessons learned disappear in the project documentation and are no longer used.
• The project manager prepares the documentation alone so that the project can be completed.
• Lessons learned are generally not found in the production processes.
• There is no systematic collection and evaluation of lessons learned.
• The benefit of lessons learned is not reported.

In most cases, lessons learned are understood as a single event and are therefore neither anchored in the organisation nor are they a component of organisational learning. Thus, the impact is also very limited and usually only takes place in the respective teams. In order to overcome these shortcomings and gaps, the focus must not only be on lessons learned, but must be seen in the context of the learning organisation.

loop learning

A learning organization is ideally a system that is permanently in motion. Events are received as stimuli and used for development processes in order to adapt the knowledge base and the scope of action to the new requirements. Learning in the organisation can only take place if the people in it also want to learn and the framework conditions are created for this. The learning loops of Argyris and Schön are a good model to check learning processes for their effect and integration in organisations. Figure 1 shows these learning loops, which are nested within each other. This is also referred to as first, second and third order learning. Second-order learning cannot take place if first-order learning is not present.

1. Single Loop: Are we doing things right? Everyone performs this loop on an ongoing basis. In the Single Loop, individual learning takes place when the results of our actions deviate from expectations.
2. Double Loop: Are we doing the right things? In this loop, second-order learning, we question our assumptions: a. Why are our previous solutions not achieving the desired results? b. Why do we believe they can produce the expected results? Correcting the assumptions results in completely different actions that can then produce the desired results.
3. Triple Loop: How do we decide what is right? Triple LoopLearning involves principles. Learning is about insight and patterns to context. The result creates a shift in our understanding, our view of things. This form of learning challenges us to understand how problems and solutions are connected. The connection between organizational structure and behavior is fundamentally changed because the organization learns how to learn.

Double-loop learning is to be strived for, as this involves questioning the action. In the context of lessons learned, this means that not only are the actions improved, but the specifications and assumptions can be continuously adapted to the requirements.

Implementation in the IT project environment of a bank

At Credit Suisse IT, in order to achieve higher quality and efficiency in IT projects, software development has been implemented and certified in accordance with the CMMI (Capability Maturity Model Integration; Level 3) reference model. The practices included in CMMI for development cover project management, process management, systems development, software development and other supporting processes. Within this definition, the application of lessons learned is required and therefore mentioned several times. According to this definition, lessons are to be stored in a "library of process assets" to be used to improve this environment. The implementation of this requirement is open and is done individually.

The newly created Lessons Learned knowledge process is linked to the Project Management (PM) process. The trigger for the creation of lessons learned is anchored in the PM process and the lessons are retrieved from this process and used directly or passed on to the appropriate discipline. The following figure shows the process schematically.

From the figure, it is clear which steps occur within the PM process and in which the project team has no or very little involvement. This knowledge process was implemented in the organization and in conjunction with the CMMI specifications with the following flow:

1. Within the PM process, the project manager is required to convene a lessons learned session. For this purpose, he gets the support of the central knowledge management team, which assigns him a neutral moderator.
2. In a moderated meeting lasting approximately three hours, the lessons are created with the project team members (Create). Through structured brainstorming with subsequent evaluation, the top issues are filtered out and discussed with the following questions: a. What should have happened? b. What really happened? c. Why did it go that way? d. What will be done differently next time?
3. The facilitator creates a report from this, which usually contains three to four lessons (Organize). It is reviewed and approved by the participants.
4. Now the lessons can be stored in a central repository and are thus available to all authorized users (Distribute).
5. The PM process specifies that at certain stages the repository is searched for applicable lessons (Apply).
6. Lessons are used by individuals (Reuse) and adapted and modified to the current situation (Personal Evolve). In addition, the stored lessons are evaluated every six months and assigned to defined topic areas. These are then passed on to the process managers of the process areas, who use them as a basis for process improvement (Organizational Evolve). As a result, the same topics should not appear more or less frequently in the lessons learned.

The design of the process was aimed at establishing individual learning and organizational learning within the IT project environment. Thus, the single loop and the double loop have been implemented in the organization. Accompanying this, the necessary operating processes of the LL environment were established.

Effect and benefit

Through the open process, especially in the creation of lessons (create), much could be achieved on the individual level. The hierarchical organisation was broken through the knowledge process and new elements were introduced. The result was a small culture change. The participants of the LLMeetings were able to benefit in the following areas: -.

• Team building and common understanding
• Additional insights from the project from other roles
• Experience in an open group reflection with a neutral moderator
• Improvement of project results through the application of lessons learned in different situations
• Establishing contacts and a network for similar project situations
• Personal and professional development

Acceptance at the organizational level was much lower, although an LL environment is one of the requirements of a CMMI implementation. The evaluations from the collected lessons learned were handed over to the process manager so that they could flow into the corresponding process area as improvements. They were only processed very slowly - if at all. The double loop "Are we doing the right things?" was only weakly implemented and had a very low impact.

The first lessons learned in this environment were created in 2006. The rollout of the CMMI environment lasted until November 2010, when Maturity Level 3 was successfully achieved. The operation of the LL environment mainly took place in a phase when the target environment was still being changed. The project managers were under the impression that they could bring about lasting changes and improve the working environment. However, as this was not visible over the years, a certain fatigue developed. Lessons learned were still being created because it was mandated that way.

Approaches to improvement

The approaches to improve the impact of lessons learned were limited. Attempts were made to simplify the structure of the lessons learned, to adapt the infrastructure accordingly and to better involve the process managers. However, these measures only led to minor progress. The following conclusions were drawn:

• The LL process still needs additions regarding implementation of the recommendations.
• The field of action of the recommendations is too large and so they cannot be implemented or can only be implemented to a limited extent.
• The implementation of lessons learned results requires more and high decision-making power in this environment.

Therefore, the concept was modified so that everything took place in only one department. The effect was much better, because the decisions about changes and actions could be made immediately and locally.

Opportunities and perspectives for future implementations

From the experiences and the scientific findings of learning, some lessons can be derived for future LL environments. Lessons learned can be applied in different environments, not only in IT projects. Therefore, the target environment is one of the most important influencers in implementation. The following list does not claim to be exhaustive and is intentionally not rated, nor should the order be considered in any way.

• The influence of a company's existing culture and organization cannot be underestimated. 
• As soon as Lessons Learned are linked to another initiative, there is a high probability that Lessons Learned will die as well.
• Learning processes are recurrent processes and should be closed loops.
• Learning processes should be integrated into the daily processes. In a process-driven environment, the approach through process-oriented knowledge management is highly recommended because it also allows the adjacent processes to be viewed from a knowledge management perspective.
• Argyris and Schön's learning loops are a good model to check whether learning is taking place and how deep it is.
• It is always more difficult to embed a lessons-learned environment in a large organization than in a manageable area such as a department or division.
• The source (creator of the lesson) and the sink (implementer of the results from lessons) of lessons learned are the most important pillars of an implementation. If one of them is weak, the whole environment cannot function properly, because you can only stand securely on two legs.
• For lessons learned, at least double-loop learning should be aimed for in order to ensure optimal benefit.