Integrating the lessons learned process

Abstract

The Lessons Learned process is essential for the success of a complex project. “Lessons Learned” refers to any kind of learning considered useful either to the project itself or to other projects. The principal objective of the Lessons Learned process is to produce continuous improvement (in terms of skills and competencies) and to obtain a sustainable competitive advantage.

However, the Lessons Learned process can only be effective if it is tightly integrated with the processes of the organization, i.e. they are consistently used as a learning tool at the beginning of a new project. But how far are the Lessons Learned collected and diffused at the end of a specific project from being a learning tool for a new project? Can they be used as they are, or additional work is needed to make them effectively reusable? And, in addition, how to achieve that Lessons Learned are effectively leveraged upon at the beginning of new projects?

The paper will describe how existing Knowledge Management processes can be of great help on both topics:

  • To ensure that Lessons Learned specific to a project can be contextualized and generalized so that they actually become a learning base for future projects;
  • To ensure that key project team members are consistently made aware of the main learning before starting new projects.

The paper will present some practical examples from Oil & Gas Development Projects that have been carried out within Eni Exploration and Production (E&P).

Introduction

A Guide to the Project Management Body of Knowledge (PMBOK Guide®) defines Lessons Learned as the “learning gained from the process of performing the project”. The Lessons Learned process should feed a “Lessons Learned Knowledge Base”, i.e. a store of historical information from the outcomes of previous project selection decisions and previous project performance (PMI, 2008, p437).

The Lessons Learned process has a peculiar importance within an Oil & Gas organization which is dealing with more than two hundred projects, whose investments range from tens of million of dollars up to a billion dollars each. Typical Oil & Gas projects comprise: the evaluation of complex seismic and well data to assess the potential productivity of the field; the drilling of the wells; the design, construction and commissioning of the onshore/ offshore facilities and pipelines to produce and export the hydrocarbons. Projects are typically split into phases, which are managed with a stage and gate model.

The paper will shortly introduce the Lessons Learned process which is currently used within Eni E&P Development Projects, together with the Lessons Learned database which has been populated over the last few years. Some samples of Lessons Learned will be presented to demonstrate their level of reusability within new projects.

The paper will then introduce the Company Knowledge Management process and the Community of Practice (CoP) tool. CoPs were mostly used to provide operational assistance to geographically distributed people within Eni's organization, as well as to abstract and generalize the solutions of the problems and distil a corresponding “Knowledge Object”, contributing this way to the maintenance of the enterprise knowledge.

The core part of the paper will then show how the Knowledge Management process and the Lessons Learned process have been integrated with each other, with the result of a reciprocal improvement of both processes.

Finally, the paper will also describe and demonstrate the integrated Search Tool that has been built in order to provide integrated access to both the Lessons Learned database and the Knowledge Object database.

The Lessons Learned Process

With reference to Lessons Learned, Eni has defined a specific process to handle them and a set of tools has been developed to support the process and its practical use across the life cycle of a Field Development project. Main existing tools consist of specific documents/guidelines, and a web based tool and the related database.

Exhibit 1 shows the general learning process implemented during all the project lifecycle: the initial gathering of lessons from other projects, the capture of lessons learned by team-members, and the final transfer of the knowledge to the company and/or to other projects (Marini, F., 2005). This process is aligned with the indications of the PMBOK: “Lessons Learned are documented throughout the project life cycle, but at a minimum, during project closure” (PMI, 2008, page 214).

The Learning Process

Exhibit 1 – The Learning Process

The Process

In order to guarantee the above learning process, each Lessons Learned event follows a process based on four fundamental steps:

Lessons Learned Process

Exhibit 2 – Lessons Learned Process

The main purposes of the “Set-up” activities are:

  • to make use of experience from past projects; to avoid repeating mistakes made in past projects; not to waste time learning lessons that have already been learned;
  • to establish timing and criteria for collecting Lessons Learned;
  • to set up the Lessons Learned process for inclusion in the phase schedule and to make them available for the whole phase/project.

“Set-up” activities should take place at the beginning of each Project phase.

The two main purposes of “Gathering of Lessons Learned” activities are to organize gathering points and to collect the lessons which are formalized at these points. New lessons should be captured whenever they arise and not at the end of a Project phase or – even worse – at the end of the Project. For this reason, gathering activities are performed both during and at the end of each Project phase.

The principal purpose of “Analysis” activities is to compare newly collected Lessons Learned with existing ones, to organize them so that they are simple to use and to share them with the Project team. The analysis of collected Lessons Learned should be performed both during and at the end of each Project phase.

“Record and Disseminate” activities are aimed at storing the learnings and sharing them with the Team. Put another way, they serve to organize captured knowledge and to transform it from individual learning into Company learning. The “Record and Disseminate” activities are performed at the end of each Project phase.

Lessons Learned are included in the Lessons Learned Register. The register itself is:

  • attached to the “Feedback Report” produced at the end of each phase and to the “Close Out Report” produced at the end of the Project;
  • loaded into the Company Lessons Learned database through which they are made available and therefore disseminated.

The Database

The Lessons Learned database has been designed as a structured online form feeding a back end Oracle database. These forms have been designed to compare what was supposed to happen with what actually happened in order to enhance what has been really learned. Each form (Exhibit 3) clearly identifies the four key element of the Lesson Learned: the “Issue” (what was supposed to happen?), the “Impact” (what actually happened?), the “Causes” (what are the reasons for the discrepancy?) and the “Recommendation” (what can we learn?). Moreover, the Lesson can be classified upon the Involved Areas (Development Management, Facilities, etc) and the Impacted Processes (“Basic Engineering”, “Detailed Engineering”, etc; these categories are not shown in the Exhibit). This approach facilitates the later retrieval of pertinent Lessons Learned.

An important element of the Lessons Learned database is the possibility of importing existing Lessons Learned from the database into a specific project, and to adapt and contextualize them (instead of creating them from scratch). This approach allows for identifying recurrent patterns and behaviours across projects, as will be shown in the final section of the paper.

The Lessons Learned Database

Exhibit 3 – The Lessons Learned Database

The Knowledge Management Process

Knowledge Management is defined as the ensemble of processes that allows the capture, validation, consolidation, archiving, re-use and diffusion of knowledge in order to improve both the business processes and innovation processes.

Knowledge can be defined in two categories: Explicit Knowledge is concerned with information and rules mainly in written form, as for instance Project Reports, Contracts, Process Diagrams, Case Studies, Books, Manuals, Company Standards and Best Practices; Tacit Knowledge is not codified and difficult to formalize, since it is based on practical experience, short-lived and volatile. It is embedded in the knowledge patrimony of people, and people can only make it explicit via direct contact with other people. Explicit knowledge is estimated to be only about 20% of the total amount of knowledge.

An important tool to help sharing tacit knowledge is Virtual Communities, i.e. groups of people who interact with the scope of promoting knowledge exchange. Virtual Communities can use information tools, such as e-mail, chat, video conferences and so on (all these have a possibility to record and retrace the contacts); moreover, they are based on personal relationships between people. Eni's Virtual Communities, called Communities of Practice (CoP), are made of people who share a passion for something that they know how to do and who interact regularly to learn how to do it better. Examples of such communities are the Reservoir CoP, the Drilling CoP, etc.

The Knowledge Management Process

Exhibit 4 – The Knowledge Management Process

The Process

Exhibit 4 shows how CoPs are currently used within Eni. From one side (upper part of the picture), they provide a constant support to the Operational Line in helping them to solve problems. Any professional is entitled to submit an Issue to the CoP (usually through an email to the CoP mailbox); CoP members are requested to leverage on their own experience to propose possible lines of action; the result of the actions are then reported back to the CoP (After Action Report), in order to measure the effectiveness of the solutions. From the other side (lower part of the picture) the CoP is requested to de-contextualize the specific Issue and look for a more general applicability of the Solution; this leads to the creation of a “Knowledge Object”, which can be uploaded into the “Knowledge Library” [Piantanida, M. 2008].

The Database

Exhibit 5 shows how the CoP consolidates a Knowledge Object into the Knowledge Library. An online collaboration environment has been designed on top of SharePoint, where Issues are collected and discussed, suggested actions are proposed and evaluated, and the generalization and abstraction process converts the Issue – Solution elements into a Knowledge Object. The Knowledge Object shares the same approach based on a structured form where the initial Issue, the suggested Actions and the achieved Results are documented, together with the abstraction and generalization considerations of the CoP. Moreover, the Knowledge Object is tagged with classification keywords, allowing the classification of the Knowledge Object by Discipline (e.g. Project Management, Reservoir Management, etc) and Process (not shown in the Exhibit).

The Knowledge Library

Exhibit 5 – The Knowledge Library

Integrating the two Processes

From the analysis of the two processes described above, and the screening of the Lessons Learned (LL) currently stored in the database, the following considerations arise:

  • A few LL can be considered of general applicability across all projects, e.g. LL related to the successful application of a technical methodology whose applicability can be widely spread to other projects/areas. Such LL have the same level of generalization of the Knowledge Objects (KO);
  • Other LL can be considered extremely valuable for the specific project, but they have not undergone an abstraction and generalization process as it occurs for the KO. For example, a LL as the following:

    Difficulties in the proper control and integration of the three different Work Packages provided by the three Contractors […]. It would have been better to assign the three Work Packages to one main Contractor.

    While true in the specific project, a different project with an experienced full time Interface Engineer would have probably succeeded in the task.
  • Finally, recurrent LL (for example: those that are imported and adapted from other projects) help identifying patterns and behaviours that need to be addressed with organizational tools and/or training sessions. Examples of such typology of LL are the following:

    Poor Stakeholder Engagement leads to delays in the project. Too many unproductive meetings, etc

  • CoPs were designed to contribute at different levels (Exhibit 6): they are mainly used for Problem Solving and Knowledge Sharing, but they can also contribute to the improvement of the business processes, speeding-up the sharing of best practices, lessons learned and other know how across the organisation (Business Improvement level).

The integration between Lessons Learned and Knowledge Management process is based on the fact that CoP activities are now triggered not only by operational problems, but also by Lessons Learned that need to be consolidated into a generically applicable Knowledge Object. All Knowledge Objects, including those that are project-generated, can be used as a learning base for new projects, in addition to the raw Lessons Learned themselves. More specifically (Exhibit 7), technical Lessons Learned are made available to the existing technical CoP (Reservoir, Drilling, Facilities, etc). Lessons Learned that are more related to project management activities are made available to a newly born CoP, named “Value Management CoP”, with the specific purpose of improving value management activities like Risk Management, Decision Making and Lessons Learned. The Value Management CoP, in addition to performing an abstraction and generalization process on PM-related Lessons Learned, can also act as a focal point for the identification of recurrent patterns that are worth designing and implementing specific training sessions to improve the culture of project management topics across the Company.

As a collateral result, the fact that CoPs are consistently discussing Lessons Learned also ensures that project team members are aware of the learnings from old projects; moreover, they get aware of new Lessons Learned not just by reading them from the database, but from active discussions within the abstraction/generalization workflow, i.e. a much more effective learning process.

CoP Contributions on different Levels

Exhibit 6 – CoP Contributions on different Levels

Lessons Learned triggering the CoP Contribution

Exhibit 7 – Lessons Learned triggering the CoP Contribution

Finally, both Knowledge Objects and raw Lessons Learned are made available through a unified web-based search tool, allowing project team members to access the widest possible knowledge about the searched topic (Exhibit 8). The query of the user (e.g. find what is available about “pipeline” within the items tagged with the Engineering and Facilities keywords) retrieves the corresponding Lessons Learned (bottom-left part of the page) and Knowledge Objects (bottom-right part) in a way that makes it possible an interactive analysis of both. The tool also allows to easily export the resulting objects into portable formats (e.g. Excel), as well as to initialize a new project with the Lessons Learned that have been found.

Integrated Search of Lessons Learned and Knowledge Objects

Exhibit 8 – Integrated Search of Lessons Learned and Knowledge Objects

Conclusions

The integration of the Lessons Learned and the Knowledge Management process proved to be beneficial on both sides: Lessons Learned can become better Lessons (i.e. they go through an abstraction/generalization process that improves their usability on new projects), as well as more Learned (i.e. the discussion process itself is a more effective learning process for the people involved). On the other hand, Communities of Practices were able to begin to operate for Business Process Improvement rather than just for Operational Problem Solving and Knowledge Sharing.

Acknowledgements

We wish to thank all the personnel who contributed to this work, with specific reference to the Knowledge Management team and the members of the Communities of Practice. We wish to thank Eni's management for the permission to publish this work.

References

Marini, F. (2005, June). Lessons Learned in Eni E&P. PMI Rome Chapter Presentation, Milan.

Piantanida, M. (2008, November). Getting a Global Workforce to Collaborate: Harnessing Knowledge at Eni. IQPC Oil & Gas Exchange 2008, London.

PMI (2008). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Fourth Edition Newtown Square, PA: Project Management Institute.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2010, Marco Piantanida, Elena Cheli, Franca Marini
Originally published as a part of 2010 PMI Global Congress Proceedings – Milan Italy

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.