View source for Lessons learned - a tool for sharing knowledge in project management

''Developed by Line Hye Sun Elmshøj''


'''Lessons learned ''' is a cost-effective project management tool that aims to bring together any insight gained during a specific project, which can be usefully applied in future projects. <ref>[''https://www.projectsmart.co.uk/lessons-learned.php''] ''Project Smart, Last visited 13-09-2016''</ref>.Lessons learned is a mean to learn what went wrong and what went right in a given project, and builds on this knowledge acquired in order to improve future projects. Lessons learned is thus an important tool for any organisation, as it can share knowledge across projects thus improve their project processes and elements as it will aid in avoiding repeating the same mistakes and in building on the successes. 

According to the <span class="plainlinks">[https://en.wikipedia.org/wiki/Project_Management_Institute Project Management Institute (PMI)]</span>, ''project management'' is the application of knowledge, skills, tools and techniques to project activities in order to meet project requirements and objectives. <ref name=PMI2008>Project Management Institute. (2008). <i> A Guide to the Project Management Body of Knowledge</i>. 4th Edition. p. 6. USA. ISBN 9781933890517</ref>. The challenging task of managing projects can somewhat be aided through the usage of the tool, <span class=plainlinks">[https://en.wikipedia.org/wiki/Lessons_learned Lessons learned]</span>. 
The Project Management Institute defines lessons learned as: " ''The learning gained from the process of performing the project'' ".<ref>''http://www2a.cdc.gov/cdcup/library/pmg/implementation/ll_description.html'' ''Project Management Institute, Project Management Body of Knowledge, Last visited 13-09-2016''</ref>.

[[File:Knowledge management.PNG|290px|thumb|right|<b>Figure 1:</B> Lessons learned - a knowledge management tool (Soruce: Elmshøj, Line)]]

Lessons learned is part of <span class="plainlinks">[https://en.wikipedia.org/wiki/Knowledge_management Knowledge Management]</span>, which is defined as<ref name=km> Davenport, T.H., Prusak, L.,  ''Successful knowledge management projects'' Sloan Management Review 39 (2), p. 43-57 </ref>.:
  
<blockquote> '' "managing the corporation's knowledge through a systematically and organizationally specified process for acquiring, organizing, sustaining, applying, sharing and renewing both the tacit and explicit knowledge of employees to enhance organizational performance and create value" ''</blockquote> 

Lessons learned is spawned from the knowledge management process, <span class="plainlinks">[https://en.wikipedia.org/wiki/Knowledge_sharing Knowledge Sharing]</span>, as lessons learned indeed is a mean to sharing knowledge. Knowledge sharing covers both '''explicit knowledge''' (codified knowledge e.g. found in documents), '''tacit knowledge''' (intuitive knowledge and know-how) and '''embedded knowledge''' (knowledge locked in processes, products, cultures etc.), and lessons learned can be used to communicate either type of knowledge and is hence not bounded to one type, but will probably tend to focus on explicit, and at times, embedded knowledge. It is however important that lessons learned covers all types of knowledge obtained within the project in order to make the sharing optimal.<ref>[''http://www.knowledge-management-tools.net/different-types-of-knowledge.html''] ''Types of Knowledge, Knowledge Management Tools, Last visited 14-09-2016''</ref> 

Lessons learned is not a new term in the world of project management, but is nevertheless often a neglected one. The downsizing of the usage of lessons learned in projects seems conflicting with the importance of what can be gained from an effective lessons learned.  An effective lessons learned process should prevent the organisation from repeating its mistakes and allow it to repeat its successes. It should be an instrumental part of any organisation’s overall continuous improvement process.  <ref name=WestneyConsulting>Westney Consulting Group 2014 <i> Implementing an Effective Lessons Learned Process in a Global Project Environment</i>. Mark Marlin PMP Sr. Vice President, Article. <span class="plainlinks">[http://www.westney.com/wp-content/uploads/2014/05/Implementing-an-Effective-Lessons-Learned-Process-In-A-Global-Project-Environment.pdf Available online here]</span> </ref>


The article starts out by providing a brief introduction to lessons learned and its role in a project management framework. Further, the application of the tool is presented; firstly by describing the methodology and then as an example application. The article lastly moves on to discussing the benefits and limitations linked to lessons learned.

= Overview =
== Introduction ==
Project management is becoming a more and more integral part of every organisation - spanning different countries, areas and sectors - in order to improve projects. Many organisations base their project management methods on the project management methodology, <span class="plainlinks">[https://en.wikipedia.org/wiki/PRINCE2 PRINCE2]</span>. PRINCE2 (PRojects In Controlled Environments, version 2) is a framework that provides guidelines that encompasses quality management, control and organisation of a project with consistency and review to align with project objectives. <ref>''https://www.axelos.com/best-practice-solutions/prince2'' ''PRINCE2 Official Website, Last visited 13-09-2016''</ref>.

PRINCE2 is process-driven project management methodology, which builds on seven principles/processes that defines project management:

[[File:PRINCE2 process model.PNG|520px|thumb|right|<b>Figure 2:</B> The PRINCE2 Process Model. The closing principle encomppases Lessons Learned (Edited by Elmshøj, Line) <ref name=prince2process>Wikipedia. <span class="plainlinks">[https://en.wikipedia.org/wiki/Project_management#/media/File:Prince2_procces_model_.jpg <i>The PRINCE2 Process Model.</i>]</span> Last visited 13-09-2016</ref> ]]

#Starting up a project (SU)
#Initiating a project (IP)
#Directing a project  (DP)
#Controlling a stage (CS)
#Managing product delivery (MD)
#Managing stage boudaries (SB)
#Closing a project (CP)

Projects are parts of organisations everywhere, anytime and occurs in different sizes, duration and complexity levels. Often, a lot of the work is focused on the initiating of the project as well as the execution of the project - however, at least as important is the '''closing of the project'''. The closing of a project concludes the project, the project should formally be decommissioned. The key activities of the ''closing the project'' is listed: <ref name=closing>Pr. <i> https://en.wikipedia.org/wiki/PRINCE2</i>. ''PRINCE2 Closing principle''. ''Last visited 14-09-2016'' </ref>

* '''Decommissioning a project'''
* '''Identifying follow-on actions'''
*'''Preparing of benefits review plan''' 
*'''Project evaluation'''

''Decommissioning the project'' basically means that the project needs to be formally closed in order to avoid letting the project going on infinitely, ''identifying follow-on actions'' are actions that needs to be carried on after the completion of the project. ''Preparing the benefits review plan'' is a plan for when the benefits of the project ought to be measured and how and what resources are needed, and finally ''project evaluation'' is where the project is evaluated;  excellent and poor experiences are listed and improvements for future projects can be listed.
This can be accomplished by utilising the ''lessons learned'' tool. 

However - although lessons learned is often performed at the closing phase, it is worth mentioning that it is not restricted to this phase. As lessons learned is not a fixed method, but a rather flexible one, which can be suited to fit the organisation's needs, it can be carried out whenever the project team/ project manager finds it appropriate. 
This being said, it is important to remember that lessons learned is about sharing and using knowledge derived from experience to promote recurrence of desirable outcomes and preclude recurrence of undesirable outcomes <ref name=pmg>''http://www2a.cdc.gov/cdcup/library/pmg/implementation/ll_description.htm'', ''PMG Lessons Learned'', ''Last visted 15-09-2016'' </ref> hence having the need to conduct the lessons learned process as a minimum and requirement at the closing phase in order to ensure all knowledge is captured throughout the project. This means that lessons learned can be an iterative process conducted at various stages or a summary process conducted only at the closing phase. 

Whenever and wherever the lessons learned is performed, it is a very useful tool in the project management environment as it focuses on continuously improving and optimising projects across the organisation.

= Application =
== Methodology ==
The lessons learned is not a ''fixed'' method, but rather depends on the temper and environment of the organisation hence the format and syntax may vary from organisation to organisation. However, if an organisation is having trouble defining the lessons learned scope then following the PRINCE2 methodology, a lessons learned template is provided. It should be noted that the template is in no way prescribed and the various organisations are encouraged to develop their own template which includes the necessary fields/themes in order to improve projects specific to that organisation. An example application is provided in the article (see section: ''Application''). 

The lessons learned is a five step process <ref name=steps> Weber, R. ''et. al'',''An Intelligent Lessons Learned Process'', Berlin Heidelberg-Springer Verlag <span class="plainlinks">[http://www.pages.drexel.edu/~rw37/ismis2kweberetal.pdf<i> Available online here.</i>, ]</span> Last visited 16-09-2016</ref> consisting of:

* '''Step 1: Collecting (Record)'''

*'''Step 2: Validating'''

*'''Step 3: Storing (and categorise)''' 

*'''Step 4: Disseminating (Communicate)'''

*'''Step 5: Reuse'''


These steps illustrate the generic approach on how to perform the lessons learned; first the knowledge or lessons are ''collected'', then it needs to be ''validated'' - is the knowledge relevant, and recommendations are generated. Then the learned lessons are stored, meaning the organisation need to have a storage unit and the project manager needs to consider where they are appropriately stored - this also includes categorising the lessons learned appropriately. The last steps regard the explicit sharing of the lessons learned by first ''disseminating'' the knowledge and then having other projects ''reusing'' it.

The PRINCE2 methodology suggests a template for collecting and validating the lessons learned. This is illustrated in ''Figure 3''. 



[[File:Lessons_learned_log.PNG|700px|thumb|right|<b>Figure 3:</B> Template for lessons learned log (Source: PRINCE2) <ref name=prince2template> XLS-file, choose hit no. 3  <span class="plainlinks">[https://www.google.dk/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=prince2%20lessons%20learned%20template<i>The PRINCE2 Template for Lessons Learned.</i>]</span> Last visited 14-09-2016</ref> ]]

{| class="wikitable" style="color:black; background-color:#DFF1FF;" cellpadding="10"
|+ style="caption-side:bottom; color:#070707;"|''Instructions/Definitions for the PRINCE2 template for lessons learned. <ref name=prince2template/>''
|'''Column'''
|'''Definitions'''
|-
|'''Project name'''
|<Optional>. Can be filled out for easy access
|-
|'''National Center'''
|<Required>. 
|-
|'''Project manager'''
|<Required>. Full name and/or initials. 
|-
|'''Project description'''
|<Required>. Short summary of the project. It is advised to add specific conclusions, implementations and results.
|-
|'''A'''
|'''ID''': Lessons learned log's idenfication number. The ID number must be unique to the specific lessons learned
|-
|'''B'''
|'''Date identified''': The date the lessons learned was identified. 
|-
|'''C'''
|'''Entered by''': The employee who identified the lessons learned. Can be either full name or initials.
|-
|'''D'''
|'''Subject''': A brief attention grabbing headline describing the subject of the lessons learned.
|-
|'''E'''
|'''Situation''': A detailed description of the situation learned from.
|-
|'''F'''
|'''Lessons Learned and Recommendations''': A detailed description of the lessons learned from the situation. Extends and supports the ''subject'' (D) and ''situation'' (E) columns. Further describes the corrective actions taken. Includes recommendations in regard to the corrective actions in order to guide future projects.
|-
|'''G'''
|'''Follow-up needed''': A description of if follow-up actions are needed.

|}

The template provided by PRINCE2, as shown in ''Figure 3'', is a very generic template, but yet covers the utter most important aspects of lessons learned; the subjects that went well and wrong and providing recommendations. As stated earlier, the organisations are highly encouraged to create their own templates, as what is essential to include may differ from organisation to organisation  -and perhaps even from project to project. However - a lessons learned should as a minimum include <ref name=pmg/>: 


*'''Project information and contact information for additional detail'''

*'''A clear statement of the lesson'''

*'''Background summary of how the lesson was learned'''

*'''Benefits of using the lesson and suggestions how it can be used'''


Within this framework it quite informally defined what organisations ought to include hence giving them a rather large degree of freedom. This can be a benefit for the organisation as they can structure the lessons learned so it fits perfectly with the specific project, but it might also create some challenges as some prefer default templates to work from and by having no ONE template might create frustrationt for the employees working on projects with different approaches. 

It is in general recommended to only have one template for the lessons learned, which the organisation has created themselves or having the organisation use an acknowledged template (e.g. the one from PRINCE2), in order to focus on the lessons learned rather than the structure and syntax and for it to be easily recognisable and understandable for all employees within the organisation aiding the knowledge sharing.
Employees can be stymied by complex document formats, thus the organisation is encouraged to try preparing and pre-testing some different document templates beforehand to see what fits the organisation best.

== Settings ==

Lessons learned is not a process that should be hurried within the last five minutes of an ending project meeting neither should it be conducted among a few of the project members in the hallway. The lessons learned brings some '''settings''' requirements / guidelines along, which are worth considering when conduction the process.

* '''When?'''
Lessons learned requires knowledge gathered throughout the project as an input thus making it an obvious choice to include it in the closing phase and/or as part of the evaluation (as stated earlier in the article). However - the project manager can choose to include it as part of every phase in the project ensuring the knowledge is fresh in the employees' minds. This however might be quite time consuming and might create more irrelevant lessons compared to only performing the process once where it is probably only the most important lessons that are remembered. 
If the project group members change often (e.g. due to a process based on functions), it might be beneficial to conduct the lessons learned when the shift of employees take place to ensure the knowledge is not lost. 
This being said - it is generally recommended to conduct the lessons learned as part of the closing phase in order to not over-do it.

*'''Where?'''
The physical environment is an important factor to consider when conduction the lessons learned as it should aid in engaging the employees. The most obvious choice will be to conduct it in meeting rooms or if the organisation does not room such - at least some sort of formal setting as it is important they employees understand the importance and seriousness of the lessons learned and do not just expect it to be dealt with over lunch if at all.

*'''How?'''
Lessons learned ought to be written down in a template, and it should be stored in a document management system in order to be able to share it within the organisation. Lessons learned should be conducted face-to-face to make sure the right meaning of the specific lessons is shared appropriately. It can be argued that a survey could be conducted in order to assure anonymity (e.g. in case of a lesson being "poor management") but this is not recommended as some knowledge might be lost in the process as it is not quite as exhaustive.

*'''Who?'''
It should  as a minimum be the involved project team who conducts the lessons learned - either by having the group or project manager facilitate. 
Other parties participating could be selected e.g. stakeholder representation including external project oversight or auditors. It might also be project support staff. <ref name=pmg> http://www2a.cdc.gov/cdcup/library/pmg/implementation/ll_description.htm </ref> Including other stakeholders (beside the project team) depends on the project and the group will decide on the need for them.

== Collecting and validating lessons learned ==

In order to concretise how an application of lessons learned can be carried out, an illustrative example application of step 1: ''collecting'' and step 2: ''validating'' is provided in ''Figure 4''. The example is based on a case project revolving collaboration among Danish municipalities in order to create a common payment system and is fictional example, however a realistic suggestion for a project, where lessons learned could be applied.

First of all, the '''subject''' needs to be as clear and precise as possible e.g ''Lack of effective communication channels'' clearly states the purpose of the lesson learned.

Second, the '''situation''' should also be very specific on what exactly did go well/ did not go well e.g. ''Communication took too long using too many different media making sharing a burden''. It clearly states what went wrong and the reason for it.

And lastly, the '''recommendation and comments'' should just as well describe the actions to take and how to carry them out in order to correct the stated issue e.g. ''Make sure to agree on means of communication beforehand...by using OneDrive or the like'' - it both states what and how it should be done as well as mentions a specific tool to overcome the challenge.


It should be notified that the colours highlightening the identification, ''ID'', are used to represent a '''red''' = ''negative'' implication in the project from which lessons were learned to conduct in an improved/optimised way, and '''green''' = ''positive'' experience in the project from which lessons were learned to successfully apply to other projects.
Organisations have a tendency to focus on only the ''negative'' implication the project carried on its way, but it is important not to forget the ''positive'' experiences as well. The positive experiences are just as important as these are means to continue great methods, tools etc. The organisation does not need to reinvent everything and start from scratch every time a new project is started. This will be further described in ''Section: Alternative approach to lessons learned'' as some researchers have focused on this problem to lessons learned and has come up with an alternative lessons learned process.


[[File:Lessons learned filled.PNG|1100px|thumb|center| '''Figure 4: Example of collecting and validating lessons learned: Collaboration between Danish municipalities creating a common payment system''' Lessons learned log example (Source: PRINCE2, Edited: Elmshøj, Line) <ref name=prince2template/>]]


Once step 1 and step 2 have taken place, step 3: ''storing'' needs to take place. For this example it would be smart to find a common platform in order to ease communication and sharing. Then step 4: ''dissemination'' takes place to make sure the lessons learned are actually ''reused'' (step 5). Steps 3-5 are further described on how to operationalise the lesson learned in ''Section: Ensuring sharing the lessons learned''.

= Ensuring sharing the lessons learned =
Lessons learned is not just about collecting and validating the knowledge - the lessons learned process also goes beyond the closing of the project with conducting the lessons learned. 

== Storing ==

It is not sufficient for the project managers to "just" conduct the lessons learned within the project group. As described earlier, lessons learned is spawned from knowledge sharing. Once the lessons learned has been conducted, it is important that the project group/ project manager also remembers to '''share''' it, otherwise it will just be a waste of resources conducting it. It is further important to make sure the workers/users actually utilise the tool to future projects so knowledge does not go to waste.

Currently a lot of tools exist to aid the knowledge sharing process, these include: <ref>['http://www.knowledge-management-tools.net/knowledge-management-tools.html''] ''Knowledge Management Tools, Last visited 14-09-2016''</ref>  :

[[File:Dms.PNG|520px|thumb|right|<b>Figure 5:</B> Example of a Document Management System - simplified (Source: N/A due to anonymity hence the blurriness. Edited by: Elmshøj, Line) ]]

*'''Groupware Systems'''
Groupware systems is basically a technology designed to help people collaborate. These include ''communication tools'', ''conferencing tools'' and ''collaborative management tools''. These tools are probably best applied in regard to conducting the lessons learned if participants cannot meet.

*'''Intranet and Extranet'''
Many organisations use intranets to inform employees of both formal and informal news as it works as small-scale version of the internet - often only accessible by employees. The intranet allows for multimedia collaboration and can hence function as a platform for groupware applications. The intranet can function as a place to store lessons learned - but probably not for every project. It might be most beneficial focusing on perhaps having a ''best practice'' summation of the lessons learned throughout time, across different projects as many companies use the intranet as a one-way communication channel rather than a collaboration platform.

The extranet is an expanded version of the intranet including the organisation's external network. Depending on the security level, it might again be beneficial to keep the sharing of the lessons learned to a minimum and as a maximum have them illustrated through best-practice. 

*'''Content Management Systems'''
Content Management Systems are responsible for creating, managing and distributing the content, the knowledge, on different media; intranet, extranet and websites. If lessons learned is included on either the intranet or extranet (or both), the content management system becomes an essential tool in making this happen and should be taken into consideration. It is not advised to distribute lessons learned to the organisation's website, as this is a public forum.

*'''Document Management Systems'''
Document Management Systems are probably the most essential tool in sharing knowledge learned from lessons learned. A document management system aid in publishing, storage, indexing and retrieval of documents. Documentation management systems are often part of content management systems and mostly deal with explicit knowledge. Document management systems are essential to an organisation as it deals with a lot of projects thus the need for a useful system keeping track of the enormous volume of documents provided through the various projects hence making it quite useful for distributing/sharing lessons learned as well. The tool allows for structured and organised projects, so it ought to be easy to implement a feature for lessons learned or to just add a folder, file or the like to the specific project. If the document management system allows for grouping of for advanced searching for projects with similar characteristics it even eases the process of retrieving lessons learned relevant for certain future projects with the same characteristics. An example of such system is illustrated in ''Figure 5''.

== Disseminating and reusing ==

It is important to not forget step 4 and step 5 in the lessons learned process. One of the main deficiencies of lessons learned, is that once the lessons learned has been documented, the organisation seems to forget about its existence and will never use it again. This would be a waste for the company hence a need for an effective approach to immediately turn the lessons learned into improved standard process descriptions. 
After all, lessons learned ( = ''ll'') efficiency can be described as the relationship between lessons ''documented'' and lessons ''used'' hence in order to improve efficiency, it is necessary to increase the use of the lessons learned. The organisation must thus ensure that the lessons learned are actually used, throughout the organisation spanning different projects, after storage.


<math>Efficiency_{ll} = \frac{Documented_{ll}}{Used_{ll}} </math>


[[File:Disseminate and reuse.PNG|520px|thumb|right|<b> Figure 6: </B> Ensuring sharing the lessons learned (Source: Elmshøj, Line)]]

The tools mentioned for storing are mostly focused on sharing ''explicit knowledge''. It is crucial that management utilise the stored lessons learned and make sure to disseminate and reuse it with employees across projects. This links to turning the lessons learned in to improved standard process descriptions immediately. This could be done by updating company project execution processes, update templates, update requirements or agenda of milestone review meetings and the like. 

Part of the learned knowledge might also be ''tacit''. In order to ensure the sharing of the tacit knowledge, the organisation is encouraged to promote informal networks. Further, it can be difficult to codify tacit knowledge and sometimes impossible thus resulting in knowledge loss. This should be avoided. Davenport and Prusak <ref name=km/> suggests to externalize the sources of knowledge rather than the knowledge itself meaning having experts externalize ''what'' they know rather than ''how'' they know it. This results in the organisation needing to find experts that can pass on the knowledge through either: practice, mentoring or networking. 

Management ought to implement the right processes, frameworks and systems as well as communicate and foster the knowledge sharing culture in order to enable the knowledge sharing within the organisation.
 
Whether it is explicit knowledge or tacit knowledge that needs to be shared, it might be beneficial for the organisation to consider assigning a ''knowledge manager'' or employing a ''knowledge consultant'', whom will aid in getting the processes running in order to have the organisation embrace a knowledge sharing culture - at least if they are novice to the subject or have trouble implementing it. No matter what, it is important management engage in the disseminating and reusing the lessons learned and express the importance of this throughout the organisation.

=Benefits and limitations=
Lessons learned is a great tool for enabling knowledge sharing in project management as highlighted in this article. However, it is not a ''perfect'' tool and does bring some difficulties into the projects. The greatest benefits and limitations are listed below.

==Benefits==

*'''Continuous improvement of projects'''
Lessons learned is tool that can aid projects in preventing repeating mistakes and allowing repeating successes. If an effective lessons learned process is carried out consistently this will create a continuous improvement of projects, provided the learned lessons are shared and utilised across the organisation's projects.

*'''Long-term cost-effective project management tool'''
By continuously recording and sharing mistakes and successes of various projects, it allows the organisation long-term to save costs, as similar projects can can utilise the lessons learned and start from "step 2" or "step 3" rather than "step 0" thus taking precautions from the beginning rather than corrective actions as the project moves along.

*'''Proper closing of a project'''
Many projects keeps going in the uncertainty and are still passively active. The lessons learned tool ensures the project does not continue infinitely - it is formally decommissioned with the evaluation or lessons learned. 

*'''Cross-functional perspectives'''
Many projects are carried out with a team consisting of different employees spanning functions and hierarchy. By conducting lessons learned with the project-team (possible additional stakeholders may be included if the project manager and/or team decides upon it), different perspectives are brought into play and increases the likelihood of covering all necessary and relevant areas.

==Limitations==

*'''Lack of willingness and engagement from particpants'''
Lessons learned heavily depends on the participating employees. If the employees are firstly not willing to participate and secondly engaged in contribute, the lessons learned will not be conducted optimally, if at all, and contributions may not be useful.

*'''Lack of management involvement and support'''
As with ''lack of willingness and engagement from participant'', if the project manager does not fully commit to conducting the best possible lessons learned, he/she might as well not. This is one of the most critical barriers as it is the project manager's responsibility to ensure the lessons learned is filled out. Without the manager's support it is quite likely that the project team neither will support the need for lessons learned - if they are even aware of its existence. 

*'''Capturing all types of knowledge'''
It is definitely easier capturing explicit knowledge (and embedded knowledge), but that does not mean tacit knowledge should be excluded from the lessons learned - there will however be a challenge in codifying the knowledge and making it understandable for all employees.

*'''Lack of time'''
Lessons learned is resource-heavy tool that requires a lot of time. Further - the employees in an organisation are typically engaged in many projects simultaneously hence if a project is delayed they might prioritise going straight to other projects after the closing of a project rather than spending time on lessons learned. It is therefore crucial that management clearly sets aside time for lessons learned.

*'''Lack of clear guidelines'''
It is important that the participants are well-instructed in how to conduct the lessons learned. Lessons learned is not supposed to be a cornucopia of knowledge hence it is the project manager's responsibility to ensure that it is only the ''important and relevant'' lessons that are included. It might however be a difficult task to differ between relevant and irrelevant knowledge. 

*'''Lack of storage'''
Once the lessons learned has been conducted it might be tempting to just close the project and put away the lessons learned in a random location. This does not work if the lessons learned are to be used by other employees for future projects. It is therefore important that the project manager makes sure to store the lessons learned in a relevant location that is easily available and accessible.

*'''Lack of sharing'''
Once the lessons learned has been store, it is natural for the employees and project manager to think that the project is finally closed and will then discard the project and move on to the next one. However - this is not the case because id lessons learned is to be fully utilised, it needs to be communicated to other employees in order for them to know they exists. The storage of the lessons learned plays a key role for easy access, but the sharing of existence and advice of which lessons learned might be useful for other projects is just as important.

=Alternative approach to lessons learned =

== 4ALL ==

As stated earlier, many tend to focus on the negative aspects of the lessons learned rather than "what went well".
The '''4ALL''' is a method developed by Baaz et al. <ref name=alternative> Baaz, A., ''et al.'', ''Appreciating Lessons Learned'', IEEE Computer Society, 2010 </ref> and takes its basis in  <span class="plainlinks">[https://en.wikipedia.org/wiki/Appreciative_inquiry Appreciative Inquiry]</span>. '''The appreciative inquiry'''  focuses on the positive impacts and aspects of the project thus is a ''strength-based'' approach. The appreciative inquiry is based on five underlying principles <ref name=alternative />: the positive principle, the anticipatory principle, the constructivist principle, the simultaneity principle and the poetic principle. 


[[File:4all.PNG|thumb|right|500px|'''Figure 7:''' The five steps of the 4ALL method (Source: Baaz et al. <ref name=alternative/>, Edited: Elmshøj, Line]]

Guided by the principles of the appreciative inquiry, Baaz et al. has developed an alternative lessons learned method that promotes a '''balance''' between what went wrong and right - this is called the '''4ALL''' method (Appreciative Lessons Learned - A Lessons-Learned Method for All). The method was developed in close collaboration with the company, Ericsson, who has a strong tradition of conducting lessons learned. The method takes it foundation in the ''workshop'' setting and consists of five steps as listed below and illustrated in ''Figure 7'':


#Introduce appreciative inquiry basics. Set agenda for workshop. Recap project and define workshop focus.
#Individually identify excellences and challenges. Present, explain and elaborate each identified lessons learned (one by one)
#Collectively sort lessons learned into areas. Vote on areas. Decide what areas to analyse.
#Select work group based on interest. Analyse cause and effect for the lessons learned. Suggest improvements.
#Present improvements. Get feedback and agreement from other groups. Conclude workshop highlights.


The alternative method's most important feature is the emphasis on balancing positive and negative experiences hence the importance of learning from both challenges as ''well as'' '''excellences'''. This method will bring a new perspective to employees otherwise problem-oriented - it will bring improvements based on strengths by identifying the excellences. 
The approach of 4ALL is thus quite similar to the original lessons learned process with the only difference being the enhancement of the importance of identifying excellences in order to achieve a balance between challenges and excellences.
It may seem like a dull method not really bringing anything new to the original lessons learned method, but people do tend to revolve around problems rather than successes when evaluating projects, and it is just as important for the company to build on and utilise successful experiences hence they ought not be forgotten.
It will further benefit the 4ALL method that it builds so closely on the structure and process of the original lessons learned, as it will be easy to integrate it into a company's established lessons learned processes. The participants will still need to address problems, but with 4ALL, from a perspective that equally values learning from strengths. 

Where lessons learned ''recommends'' to include both positive and negative experiences, it will realistically most likely focus on problems, where 4ALL ensures the successes or positive experiences of different projects are included.

For a more detailed description see [http://findit.dtu.dk/en/catalog/31302161 ''Appreciating Lessons Learned''] (''Section: Annotated Bibliography'').

=Annotated Bibliography=

For further reading on the subject or related subjects, the reader is encouraged to check out the following:

'''Books:'''

Zbigniew, R.W., ''Foundations of Intelligent Systems'',12th International Symposium, ISMIS 2000, Springer, Chapter 5A, ISBN 3-540-41094-5 
:::The book covers lessons learned in regard to an ''intelligent lessons learned process''. The book is recommended for readers interested in getting a more in depth description of both knowledge management as well as lessons learned processes - both in terms of theoretical terminology as well as example applications.

'''Articles and Web-pages:'''

Marlin, M. (2008), [http://www.westney.com/wp-content/uploads/2014/05/Implementing-an-Effective-Lessons-Learned-Process-In-A-Global-Project-Environment.pdf Implementing an effective lessons learned process in a global project management environment], <ref name=implement>Marlin, M. (2008).<i> Implementing an effective lessons learned process in a global project environment</i>. UTD 2nd Annual Project Management Symposium Proceedings –Dallas, Texas. [http://www.westney.com/wp-content/uploads/2014/05/Implementing-an-Effective-Lessons-Learned-Process-In-A-Global-Project-Environment.pdf Available Online]</ref> '', UTD 2nd Annual Project Management Symposium Proceedings –Dallas, Texas. 
:::The article describes barriers for performing lessons learned and how to overcome these in great detail.

Knowledge Management Tools, [http://www.knowledge-management-tools.net/ ''KMT'', Last visited 15-09-2016]
:::A website providing the reader with all aspects of knowledge management - including knowledge sharing and tools to overcome the difficulty over knowledge sharing both in regard to explicit and tacit knowledge. The website gives a great overview for the novel reader of knowledge management.

Doule, F. (2009),  [http://findit.dtu.dk/en/catalog/4846252 Knowledge sharing: an index of terminological specificity], MEDES, Lyon, France
:::The article describes how to deal with controlled diffusion of knowledge; sharing knowledge whilst ensuring the quality of the knowledge and how to understand the diffused knowledge unambiguously. The article then proposes an index of terminological specialty.

Project Smart [https://www.projectsmart.co.uk/lessons-from-the-perfect-science-hindsight.php] ''Project Management: Lessons from the perfect science - hindsight ''
:::The webpage gives great examples of lessons learned as provided by senior managers and executives. It is a great opportunity for the reader to get an overview of some of the most common, generic pitfalls projects bring and what lessons learned can do.


'''Case Studies and Research:'''

Baaz, A. et al. (2010) [http://findit.dtu.dk/en/catalog/31302161 ''Appreciating Lessons Learned''], IEEE Computer Society
:::The case study gives an alternative lessons learned method focusing on ''balancing'' what went wrong and what went right in a given project as many projects tend to focus only on the bad experiences. The article describes the new developed method, 4ALL, which is based on the appreciative inquiry approach. The 4ALL method was developed in close collaboration with Ericsson.


'''Related course articles'''

[http://apppm.man.dtu.dk/index.php/Knowledge_management_in_projects_and_organizations Knowledge Management in Projects and Organizations]
::: The wiki-article describes how knowledge is created, transferred and reused in a project management environment in organisations. It focuses on intra-project and inter-project learning and organizational memory and knowledge sharing. 

[http://apppm.man.dtu.dk/index.php/Visual_Project_Management_-_War_Rooms Visual Project Management - War Rooms]
::: The wiki-article describes the benefits of utilising the so-called war rooms as a mean to ease communication and collaboration. The method would also be a great way to realise lessons learned. The visualisation might help the tacit knowledge becoming more tangible hence decreasing the possibility of knowledge loss. Further - gathering the project team in a war-room will show the importance of lessons learned and might engage them in the process as much as in other phase of the project.

= References =
<references />
[[Category:Project Management]][[Category:Uncertaity]][[Category:Information flow]][[Category:Tool]]