Talk:Lessons learned

Deliverable 1

In general, the content and figures in the original article are good. My focus is not going to be on rewriting what is already there, as the majority is well written and relevant. However, my focus is going to be on creating a better structure and a common red thread between the sections. In addition, I will be adding a number of sections and figures that will touch on things that are not already there. If you have any comments for what I have suggested below, please write your comments in the end of this page or send an email to s193974@student.dtu.dk.

My proposal for the structure of the updated article is listed below.

• Abstract
• Introduction
  • Setting
• Application
  • Methodology
    • Phase 1: Identify
    • Phase 2: Document
    • Phase 3: Analyse
    • Phase 4: Store
    • Phase 5: Retrieve
• Avoid project failure with the use of lessons learned
• Benefits and limitations
  • Benefits
  • Limitations
• Alternative approach to lessons learned
• Annotated bibliography
• References

Below I have described the improvements and changes I want to make. This list might be updated as I gain more knowledge about the topic.

General improvements

• Change the overall structure of the article to make it easier to follow and create a better connection between the sections.
• Make the article more up to date. E.g. has PRINCE2 changed some of there figures within the last 5 years.
• Create a red thread between the existing figures and tables and the ones I develop.
• Develop missing figures.
• Refer to all figures and tables in the text.
• Enhance the quality of the article by adding more references.
• Update the annotated bibliography and references.
• Add authors of the article.

Abstract

• Include the perspective the tool covers (uncertainty, learning: how can we know?).
• Include the project manager's role in using the tool.
• Rewrite the last past of the section.
• Update Figure 1.

Overview

• Remove the overview title and make the introduction the main title.
• Include the “big idea” - what is the purpose of the tool?
• Create less focus on the PRINCE2.
• Merge the introduction so it both contains the theory of PRINCE2 from the original article and merge it with the setting section.
• Develop a golden circle figure to support the content about the setting (why? how? what?).
• Update Figure 2.

Application

• Add an introduction to the application section before continuing to the methodology.
• Develop a figure which illustrates the lessons learned process in the methodology.
• Divide the methodology into five subsections, each describing a phase of the lessons learned process.
• Change the names of the lessons learned phases to the most commonly used in literature.
• Eventually change the methodology title to lessons learned process.
• Move the last past of the methodology down to the section about benefits and limitations.
• Move the setting section to the introduction.
• Rewrite the collecting and validating lessons learned section and implement it in the methodology.
• Explain how to collect lessons learned (i.e. a list of questions to ask during a lessons learned workshop).
• Update Figure 3 and 4.
• Update the table and give it a name.

Ensuring sharing the lessons learned

• Rewrite the section and implement it in the methodology. Add more content about storing lessons learned (i.e. PRINCE2 lessons learned log).
• Update Figure 5.

Write a section about how to avoid project failure with the use of lessons learned

Benefits and limitations

• Elaborate more on the benefits and limitations (especially the benefits). Currently this section is very short.
• Support the content with references. At present, the section does not contain any references.
• Remove the bullet points from the subtitles.
• Update Figure 6.

Alternative approach to lessons learned

• Compare lessons learned and the alternative approach more - what are the benefits and limitations of the alternative tool?
• Update Figure 7.

Annotated bibliography

• Update with new references.

References

• Update with new references.

Deliverable 2

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 . Lessons learned is a mean to learn what went wrong and what went right in a given project, and builds on the 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 Project Management Institute (PMI), project management is the application of knowledge, skills, tools and techniques to project activities in order to meet project requirements and objectives . The challenging task of managing projects can somewhat be aided through the usage of the tool, Lessons learned. The Project Management Institute defines lessons learned as: " The learning gained from the process of performing the project "..

Figure 1: Lessons learned - a knowledge management tool (Soruce: Elmshøj, Line)

Lessons learned is part of Knowledge Management, which is defined as.:

"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"

Lessons learned is spawned from the knowledge management process, Knowledge Sharing, 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.

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.

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, PRINCE2. 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. .

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

Figure 2: The PRINCE2 Process Model. The closing principle encomppases Lessons Learned (Edited by Elmshøj, Line)

1. Starting up a project (SU)
2. Initiating a project (IP)
3. Directing a project (DP)
4. Controlling a stage (CS)
5. Managing product delivery (MD)
6. Managing stage boudaries (SB)
7. 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:

• 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 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 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.

Figure 3: Template for lessons learned log (Source: PRINCE2)

Instructions/Definitions for the PRINCE2 template for lessons learned.

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 :

• 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. 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.

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)

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:  :

Figure 5: 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.

$Efficiency_{ll} = \frac{Documented_{ll}}{Used_{ll}}$

Figure 6: 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 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. and takes its basis in Appreciative Inquiry. 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 : the positive principle, the anticipatory principle, the constructivist principle, the simultaneity principle and the poetic principle.

Figure 7: The five steps of the 4ALL method (Source: Baaz et al. , 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:

1. Introduce appreciative inquiry basics. Set agenda for workshop. Recap project and define workshop focus.
2. Individually identify excellences and challenges. Present, explain and elaborate each identified lessons learned (one by one)
3. Collectively sort lessons learned into areas. Vote on areas. Decide what areas to analyse.
4. Select work group based on interest. Analyse cause and effect for the lessons learned. Suggest improvements.
5. 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 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), Implementing an effective lessons learned process in a global project management environment, , 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, 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), 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 [1] 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) 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

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.

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.