Revision as of 08:15, 22 September 2016

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. ^[1].Lessons learned is a mean to learn what went wrong and what went right in a given project and build on this knowledge aquired in order to improve future projects. ADD WHY IT IS IMPORTANT.

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. ^[2]. The challenging task of managing projects can somewhat be aided through the usage of the tool, Lessons learned. Project Management Institute (PMI) defines lessons learned as the learning gained from the process of performing the project. ^[3].

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

Lessons learned is part of Knowledge Management </ref>, which is defined as^[4].:

"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.^[5]

Lessons learned is not a new term in the world of project management, but is however often a neglected one. The downsizing of the usage of lessons learned in projects seem 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 organization’s overall continuous improvement” proces. ^[6]

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. ^[7].

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) ^[8]

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, durations 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 below. ^[9]

• Decomissioning a project
• Identifying follow-on actions
• Preparing af benefits review plan
• Project evaluation

Decomissioning the project basically means that the project needs to be formally closed as in to avoid letting the project going on internally, identifying follow-on actions are actions that needs to be carried on after the completion of the project. Prepapring 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 to share and use knowledge derived from experience to promote recurrence of desirable outcomes and preclude recurrence of undesirable outcomes ^[10] 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.

MORE?? Consider including scope, time, cost triangle or the like - Consider a sought of conclusion

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, 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 ^[11] 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 is relevant, and recommendations are generated. Then the lessons learned 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) ^[12]

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 ^[10]:

• 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 be frustrating 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 use an acknowledged template (e.g. as 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 them i 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.

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

• 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 stakeholder representation including external project oversight or auditors. It might also be project support staff. ^[10] 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 amongst 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 clear 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 mentioning a specific tool to overcoming the challenge.

It should be notified that the colours highlighten 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.

Once step 1 and step 2 has 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). Step 3-5 are further described in how to operationalise the lesson learned in Section Ensuring sharing the lessons learned.

Ensuring sharing the lessons learned

Storing

It is not sufficient for the project managers to "just" conduct the lessons learned within the project group - he/she must also make sure the lessons learned are shared; this includes recording, categorising and communicating the lessons learned from the lessons learned steps.

As described earlier, lessons learned is spawned from knowledge sharing. Once the lessons learned has been conducted, it is important it is also shared 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: ^[13]  :

Figure 2: 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 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 or 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.

The tools mentioned are mostly focused on sharing explicit knowledge - but 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. However - as most of these systems focus on storing explicit knowledge, it might be necessary to codify the tacit knowledge. This can however be a difficult task, and might result in knowledge loss. Davenport and Prusak ^[14] and takes it basis in The appreciative inquiry focuses on the positive impacts and aspects of the project thus is strength-based approach.

The Appreciative Inquiry is based on five underlying principles: - PROBABLY EXCLUDE - FOCUS ON 4ALL

1. The positive principle: the user needs to bring positive thinking to the project to provide needed energy to future projects.
2. The anticipatory principle: if the user thinks positively about the future, this will lead into positive actions
3. The constructivist principle: the user needs to understand that reality is constructed from the perceptions of multiple individualists.
4. The simultaneity principle: the project manager needs to realise that the inquiry itself affects the process through having users see reality from alternative perspectives.
5. The poetic principle: the user needs to understand that the organisation is viewed as a book that is created over time through individuals telling their stories.

• 4ALL method short described

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

Short description

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, ^[15] , UTD 2nd Annual Project Management Symposium Proceedings –Dallas, Texas.

The article describes barriers for performing lessons learned and how to overcome these.

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: FIND SOME!!!!!

Author (year) [webpage Title]

Short descriptions

References

1. ↑ [https://www.projectsmart.co.uk/lessons-learned.php] Project Smart, Last visited 13-09-2016
2. ↑ Project Management Institute. (2008). A Guide to the Project Management Body of Knowledge. 4th Edition. p. 6. USA. ISBN 9781933890517
3. ↑ http://www2a.cdc.gov/cdcup/library/pmg/implementation/ll_description.html Project Management Institute, Project Management Body of Knowledge, Last visited 13-09-2016
4. ↑ Davenport, T.H., Prusak, L., Successful knowledge management projects Sloan Management Review 39 (2), p. 43-57
5. ↑ [http://www.knowledge-management-tools.net/different-types-of-knowledge.html] Types of Knowledge, Knowledge Management Tools, Last visited 14-09-2016
6. ↑ Westney Consulting Group 2014 Implementing an Effective Lessons Learned Process in a Global Project Environment. Mark Marlin PMP Sr. Vice President, Article. Available online here
7. ↑ https://www.axelos.com/best-practice-solutions/prince2 PRINCE2 Official Website, Last visited 13-09-2016
8. ↑ Wikipedia. The PRINCE2 Process Model. Last visited 13-09-2016
9. ↑ Pr. https://en.wikipedia.org/wiki/PRINCE2. PRINCE2 Closing principle. Last visited 14-09-2016
10. ↑ ^{10.0 10.1 10.2} http://www2a.cdc.gov/cdcup/library/pmg/implementation/ll_description.htm, PMG Lessons Learned, Last visted 15-09-2016
11. ↑ Weber, R. et. al,An Intelligent Lessons Learned Process, Berlin Heidelberg-Springer Verlag Available online here., Last visited 16-09-2016
12. ↑ ^{12.0 12.1 12.2} XLS-file, choose hit no. 3 The PRINCE2 Template for Lessons Learned. Last visited 14-09-2016
13. ↑ ['http://www.knowledge-management-tools.net/knowledge-management-tools.html] Knowledge Management Tools, Last visited 14-09-2016
14. ↑ Baaz, A., et al., Appreciating Lessons Learned, IEEE Computer Society, 2010
15. ↑ Marlin, M. (2008). Implementing an effective lessons learned process in a global project environment. UTD 2nd Annual Project Management Symposium Proceedings –Dallas, Texas. Available Online