Abstract
Sharing lessons learned in a structured way and documenting them while assuring their proper dissemination raises the rate of success for the future projects of any organization. Even though the value of lessons learned documentation and communication is evident and formally recognized, the discipline is often neglected or only some elements of it are performed. This paper underlines the importance of a systematic approach of sharing knowledge and suggests some techniques project managers could use to identify, document, update, and communicate lessons learned inside their organizations. It also presents recommendations for a successful implementation by pointing out some of the pitfalls than can be surmounted only by courage, commitment, compassionate intelligence, creativity, and humor.
The first part presents the successes and the failures from the perspective of their usage as lessons learned. Mistakes are also discussed by showing how they can be recognized and how the responsibilities that come with those are accepted. The second part discusses the way lessons learned are documented and illustrates some options that we have to motivate team members not only to gather but also to use lessons learned in their projects.
Introduction
Lessons learned and historical information are part of the organizational knowledge base, and therefore, considered by the Project Management Institute (2008) organizational process assets. There is a clear distinction between lessons learned and information. Information about project management processes, best practices, or project results can be written down and stored in information systems. It becomes knowledge only if it is available to project team members for practical application. Are lessons learned information or knowledge?
The process to capture and transmit what has been learned on projects is a process for transmitting information rather than knowledge (Cooke-Davies, 2001). As soon as the information is available for another project team and they are ready and willing to apply it in the new project, it becomes knowledge. Applying this knowledge will help the project team to act differently in their new projects and by this enhancing the probability of success. As Buchanan and Huczynski (1985) defined, learning will change the behaviour.
Therefore, we can conclude that learning lessons is not just an acquisition of knowledge, but the application of it through doing something different in the world (Cameron & Green, 2004).
Gathering Lessons Learned
Successes and failures—study the past to practice for the situations you expect.
Today, marketplace realities are making revenue targets harder and harder to reach, placing a huge premium on the ability to focus scarce resources in every corner of the organization on the strategies and tactics most likely to result in success. This is also valid when talking about successful projects; concluding a successful project is a major achievement for the project manager responsible for it but also for the organization that needs to be capable of repeating it. If the strategy and the tactical decisions of a successful project can be reproduced, this knowledge will help the organization to maximize its revenue, reduce its costs, minimize risk, and to achieve competitive advantage. The knowledge becomes an asset for the organization.
Unfortunately, project successes are mostly seen as normal and are not celebrated or properly communicated inside the companies. The knowledge gained by the team and the project manager remains with them, no doubt that it is used by the organization, but only to the point when the people leave the organization. In order to preserve this knowledge inside the organization, the success needs to be disseminated throughout it and the best practices that have led to this success should be documented and used by other members of the organization as well.
Disseminating the success can be easily done by celebrating the completion of the project. This helps not only to make the achievement known within the organization but is also a reward for the project team: an official thank you from the organization in an event with a large participation is—for a large number of team members—a motivating factor.
Documenting the best practices is not as easy as celebrating the success. For these activities, planning and the time allocation are required. Few projects ever take time to capture lessons learned (DeCarlo, 2004), as people are too busy starting on the next venture. However, if this activity is scheduled and included in the project plan, we increase the chance that this session takes place. Even though the project is a success, some issues or problems might have occurred during its development. Therefore, some basic norms need to be followed so that the meeting does not become a finger pointing session. Participants will contribute only if an atmosphere of trust is created. The individual emotions of the meeting participants influence the communication process directly (Gareis, 2005). Recalling previous projects’ failure is a well-known danger signal for the project managers aware of the possible reactions of the stakeholders. Using failures and transforming them into advantages is an art that experienced project managers have learned to apply. The process consists of two major steps:
- Analyze the cause of the failure. Time should be allocated to this process as in order to identify some actions the problem needs to be properly defined. Once the cause clarified, the next step is to
- Identify new approaches or improvements that will reduce the probability of failure of the new projects.
These are steps that take time and need proper resource allocation; therefore, they have an associated cost as the failure itself. Organizations do not appreciate additional costs for projects but an experienced project manager will argue for this tuition cost instead of any other theoretical training the project team may get.
Accepting Mistakes and Responsibilities
Mistakes are things everyone commits, and if they are courageously admitted —even if only privately to ourselves—they enrich the knowledge and make learning possible. However, cultural differences come into the picture when admitting mistakes; this paper presents only some of the most known sensible aspects of cultural assumption people have about mistakes and failures.
Learning from a mistake is possible only after we admit we have made it. Blaming others, finding external reasons, and pointing out colleagues, team members, or other stakeholders raise an imaginary wall between us and any possible lesson we could learn from what happened. The project manager has to be aware of this threat and by being an example (and taking some of the mistakes upon himself or herself) to encourage its team members to admit their mistakes. Admission of a mistake, sometimes only privately, makes learning possible by moving the focus away from blame and towards understanding.
Cultural assumptions that we have about mistakes and failures sometimes makes this admittance very difficult, namely that mistakes are shameful things. We were taught in school and by our families or even at work to feel guilty about failure and to do whatever we can to avoid mistakes. This sense of shame explains why many people prefer to conceal or to cover some of the mistakes actually inherent in any project; it also explains why some of the team members do not accept challenges (as they are afraid of the possible failure and shame to fail). Project managers have to raise the team members’ self-confidence, help them to understand that accepting a mistake is their chance to learn, that mistakes are actually experiences that can be shared with colleagues in order to help them avoid making the same mistakes. This way they add value to the project and to the organization. This message should be communicated to different project team members by the management of the organization as well; the message should be consistent throughout the organization.
Once the mistake is admitted, it needs to be corrected. This means, in most of the cases, that we need to change either our behavior or some of the processes or practices we use in projects.
How and When To Document Lessons Learned, Whom to Involve
Who will document the lessons learned? First of all, the project team has to be involved because they know the project. In order to have a comprehensive view on the way the project was implemented, we need other perspectives as well. The context is many times as important as the project itself. Therefore, we involve other stakeholders: the management of the organization—who gives the holistic perspective of the project and its alignment with the strategy of the organization; the users of the results of the project, as their acceptance is finally the most important measure of the project success; the line managers of the organization, as they may be affected by the way the project attracted and consumed the resources they provided; and contractors and subcontractors to identify procurement, quality, communication, or other issues that arise during the collaboration within the project. In addition, the list continues with all the identified stakeholders of the project. Having a substantial number of contributors to the lessons learned gathering process, it becomes clear that appropriate planning is required and that this should be reflected in the project communication plan.
The involvement of a large number of contributors could be achieved only if they are motivated. Especially the project manager and the project team members need to know that documenting the lessons learned is important for the organization, and therefore, they need to see a commitment of the management in order to assure all the required conditions for the lessons learned process to be followed. By these conditions, we understand:
- Investment for a tool or system that not only gather the lessons learned but also stores it and allows easy access to the stored information (knowledge management system)
- Investment in establishing a project management office, responsible, among others, with maintaining and developing the knowledge management system
- Incentive system established and maintained across the organization for the usage of the knowledge management system
- Continuous training of the employees for the usage and development of the knowledge management system
- The development of culture of a problem solving attitude across the organization
Once the lessons learned process is defined in the organization and it is applied in projects, the organization needs to assure that the process is integrated with the other processes of the company, granting this way the survival of the process.
When do we document the lessons learned? Each and every project meeting could bring a valuable lessons learned for the organization; it is the project manager responsibility to understand the value of specific information and to be ready to spread it among those who are interested in it. Then, of course, we have the project review at the end of the project, when most of the lessons learned are gathered and the degree of success that was actually achieved is assessed. Because many of the benefits will not be harvested until after the project is complete, the post-implementation review is best carried out in two stages—a lessons learned review while members of the project team have the actual events of the project fresh in their minds, and a post-implementation review after the project implementation, when the benefits can be more accurately assessed. (Cooke-Davies, 2001).
Using Lessons Learned
Incentives or How to Motivate People to Use Lessons Learned
Gathering lessons learned is sometimes the easiest part of the process; convincing people to use them can be more difficult. This is why we need the commitment of management in making the lessons-learned process a viable and followed process inside the organization. The project management office and the human resource department are also involved, in most of the cases, in developing incentive systems and in motivating people to use lessons-learned information. Some of the methods we have seen in multinational companies with medium to high maturity in project management are listed below:
- Bonus based on key performance indicators. Two of the companies interviewed by the author mentioned that they have KPIs based on the gathering and use of lessons learned. Examples of these KPIs are:
– Number of success stories published/total number of projects completed
– Meetings and communication events for sharing lessons learned/project
– Number of lessons learned documents published/total number of projects completed
– Usage of the existing lessons learned repository (average number of accesses/employee/month)
- Ranking documents in the lessons learned repository. The lessons learned repository is a database containing the project files but most important, the documented lessons learned of the different projects. Project teams not only access this database in order to re-use the project files but also to learn about what happened in the project, what should they do similar or differently in order to achieve success with their projects.
- Project management community of practice. If different project teams within the same organization see themselves as members of a higher-level community, sharing same values and having their “own project language,” the process of sharing information and learning from their experiences will be more easily accepted and incorporated in their project activities. “Communities of practice are emerging in companies that thrive on knowledge” (Wenger, 2000, p. 212 ).
The lessons learned documents are the documents produced by the review conducted during the project close-down and their structure varies from organization to organization. Some of the most common sections inside these documents are:
- Lessons learned about planning
- Lessons learned about human resource factors
- Lessons learned about technical issues
- Lessons learned about communication issues
– Internal (among team members)
– External (with clients)
- Lessons learned about methodology issues
An other lessons learned document that we have seen used by several companies is the so called What-Went-Wrong (WWW) document. It ranks the top five aspects that need to be improved or changed for the organization's next projects and strongly focuses on the weaknesses of the projects, and therefore, sometimes the good results—the things that went well in the projects are neglected:
WWW Lessons learned Ranking (List Top 5):
- Planning
- Technical issues
- Resources
- Communication issues
–Internal
–External
- Project management processes
A simpler but interesting lessons learned document that we have seen contains:
- Key tasks missing from project plan
- Top three lessons learned from the technical team
- Top five lessons learned from the client team
From the interviews conducted, we concluded that what is appreciated by the users is not necessarily the structure of the document but the consistency of this structure, the concise and clear information and the suggestions made for improvements.