Projects & Technology

Upstream Major Projects EMEA Project Design

Quality Management System Procedure

Lessons Learned Procedure

Document Number: PTM-EDES-PR-40

Restricted
ECCN: EAR 99 Deminimus
This document is made available subject to the condition that the recipient will neither use nor disclose the contents except as agreed
in writing with the copyright owner. Copyright is vested in Shell UK Ltd.

Shell UK Ltd 2010. All rights reserved.

Neither the whole nor any part of this document may be reproduced or distributed in any form or by any means (electronic, mechanical,
reprographic, recording or otherwise) without the prior written consent of the copyright owner.

Doc No. PTM-EDES-PR-40

Revision: A01

Originator (Custodian): Peter Hopkins

Checker: David Booth

Issued: 10/10/2012
Approver (Owner): Ian Bishop
Page 1 of 12

Printed copies are uncontrolled

Document History
Date

Revision

Reason for change

06/01/2012

R01

Issued for IDC Review / Comment

10/10/2012

A01

Issued for Use

Contents
1

Introduction

1.1

Abbreviations

1.2

Definitions

1.3

Frequently Asked Questions

Scope

Responsibilities

3.1

Leadership Team

3.2

Engineering Manager / Project Manager

3.3

Quality Assurance

3.4

Shell Projects and Technology Personnel

Procedure

4.1

Overview
4.1.1 Principles

7
8

4.2

Capture of Lessons Learned

4.2.1 Workshops
4.2.2 Day-to-Day Capture
4.2.3 Customer Feedback
4.2.4 Interviews

8
9
10
10
10

4.3

Lessons Learned Data

4.3.1 Collate
4.3.2 Review / Screening
4.3.3 Analysis / Classification

11
11
11
11

4.4

Feedback

12

4.5

Communication

12

4.6

Database

12

Doc No. PTM-EDES-PR-40

Revision: A01

Issued: 10/10/2012
Page 2 of 12

Printed copies are uncontrolled

Introduction

This procedure details the process implemented by Shell Projects and Technology in respect to Knowledge
Management, specifically the capture, review and analysis of Lesson Learned in the execution of Shell Projects and
Technology associated scopes of work and projects.
Effective implementation of the Lesson Learned process will facilitate the application of learnings from previous
and current projects to current / future projects that will enhance project performance and add value.
Implementation of identified improvements and best practice will provide a suitable foundation upon which Shell
Projects and Technology may maintain its status of a Learning Organisation optimising the transference of
knowledge and experience.
A critical element of the process is the creation and maintenance of environment supportive of learning. Such an
environment must apply a concerted focus to the issues and systemic corrective actions, as opposed to short-term
corrections.

1.1

1.2

Abbreviations

KM Knowledge Management

LL Lessons Learned

OFI Opportunity for Improvement

Definitions

Lessons Learned A Lesson Learned results from analysis of past events leading to a recommendation
for the future. Lessons Learned can be either of a technical or non-technical nature and result from
successes or failures. Positive lessons learned represent opportunities whilst negative lessons learned
indicate possible risks.

Knowledge Management - there are many definitions and the one best suited for Shell Projects and
Technology is - "Knowledge Management is the discipline of enabling individuals, teams and entire
organisations to collectively and systematically create, share and apply knowledge, to better achieve
their objectives"

Facilitator is defined as an individual appointed to help a group of people understand their common
objectives and assists them to plan to achieve them without taking a particular position in the
discussion.

Opportunity for Improvement - An OFI is a lesson or learning that can be used to amend, modify or
correct an existing procedure / work process, Management System / Management Manuals / Shell
Technical Specifications

Lesson Capture is defined as the gathering, recording and sharing of experience / lessons from the
project

Best Practice is defined as a process or a methodology that represents the most effective way of
achieving a specific objective.

Doc No. PTM-EDES-PR-40

Revision: A01

Issued: 10/10/2012
Page 3 of 12

Printed copies are uncontrolled

1.3

Frequently Asked Questions

Question - How can we ensure that a Lessons Learned session does not become defensive and blame
orientated?

Answer - The facilitator will reiterate at the opening of the Workshop that Shell Projects and Technology
Management fully support and encourage constructive input which underpins the blame free culture
established.

Question - How do we ensure that a Lesson Learned on one project is applicable to another project
which may have a completely different context?

Answer - The screening process applied to the data collated will ensure that Lessons retained will be
suitably articulated that will facilitate a new readers ready understanding. Lessons that are defined as
Project specific may not pervade the same degree of learning to other projects.

Question - How should we manage the list of lessons?

Answer - This is managed by application of a robust screening process that facilitates classification of
the opportunities that may present an immediate improvement the OFI process will ensure these the
lessons learned database remains both manageable and effective.

Doc No. PTM-EDES-PR-40

Revision: A01

Issued: 10/10/2012
Page 4 of 12

Printed copies are uncontrolled

Scope

The Lessons Learned Process (LLP) must be a structured process for capturing, interrogating, analyzing,
communicating and implementing actions that emanate from Lessons Learned and previous experiences.
Wherever reasonably practicable the Lessons Learned Process (LLP) will be applied at predetermined stages /
phases of the project and preferably prior to departure or re-assignment of personnel who have been engaged and
are perceived to have suitable constructive input to the process. This may be extended to 3rd Partys and
Contractors who may have had a suitable impact and may provide suitable input.
It may be prudent, subject to scope and duration, to implement Lessons Learned Workshops at pertinent stages
within the life cycle of the project, as approved by the Leadership Team and Project / Engineering Manager. The
Lessons Learned sessions will be commensurate with the scope and duration of the project.
Implementation of a robust Lessons Learned Process (LLP) enables learnings from previous and current projects
that may be applied to current / future projects add value and provide assurance that projects have taken on board
the opportunities for improvement and best practices.
Lessons Learned is one of the fundamental success factors underpinning world class projects. The aim of the
process is to ensure that projects are cognisant of previous errors or deficiencies and that proposed improvements
are considered at the earliest practicable juncture.
Lessons Learned are key elements that underpin Shell Projects and Technology commitment to continuous
improvement in all aspects of its business.

Doc No. PTM-EDES-PR-40

Revision: A01

Issued: 10/10/2012
Page 5 of 12

Printed copies are uncontrolled

Responsibilities

3.1

Leadership Team

It is the responsibility of the Leadership Team to implement this procedure and to ensure that all parties are fully
conversant with their responsibilities and its intent. Visible and demonstrable support to the process is critical to its
effective implementation within the Shell Projects and Technology organisation.
Constructive and unambiguous input is of paramount importance if Shell Projects and Technology is to effectively
monitor and review their performance in the execution of complex scopes of work.
The Lessons Learned must be endorsed approved by the Leadership Team, communicated and actioned to ensure
Shell Projects and Technology maintains the highest level of service and continues to add value to their customers.
Review and approval of all associated Lessons Learned reports and subsequent distribution to ensure effective
communication is achieved. Where Lessons Learned / Best Practice from similar scope projects are applied it is
advantageous to reference this within the report, supporting Continuous Improvement.

3.2

Engineering Manager / Project Manager

The Engineering Manager / Project Manager shall initiate and co-ordinate the Project Close-Out Report ensuring
that suitable input and participation is provided by all applicable discipline personnel.
Shall encourage or invite client / external party representatives, where considered appropriate, to provide
constructive input through active participation.
Establishing an environment that is supportive of learning, fostering a culture of challenge and innovation.

3.3

Quality Assurance

The designated Lessons Learned Champion shall liaise with the Leadership Team, Engineering Manager and
Project Manager throughout this process and associated activities.
In co-operation with and support from the Leadership Team, Engineering Manager and Project Manager initiate and
implement all actions identified, and amend the Management System to reflect potential changes which shall
subsequently be communicated to all personnel.
The Quality Assurance Team, are responsible for the development, co-ordination and implementation of the
Projects and Technology Audit and Improvement Plan wherein verification of effective implementation of the
Lessons Learned process will be included.

3.4

Shell Projects and Technology Personnel

It is Shell Projects and Technology expectation that all personnel accept responsibility to present and record any
activity wherein the potential for improvement may be reviewed and subsequently applied. Proactive participation
will support the Business Unit as a learning organisation one that is resolute in its pursuit of continuous
improvement and delivery excellence.

Doc No. PTM-EDES-PR-40

Revision: A01

Issued: 10/10/2012
Page 6 of 12

Printed copies are uncontrolled

4
4.1

Procedure
Overview

Implementation of a robust Lessons Learned Process (LLP) enables learnings from previous and current projects
to be considered for application to current / future projects that add value and provide assurance that pertinent
improvement and best practices proposed have been considered.
Critical to the success of Lessons Learned Process (LLP) is creating an environment supportive of learning. Such
an environment focuses on the issues and systemic corrective actions, not one that apportions blame or elects to
pursue short-term corrections.
The fundamental principle for the Lessons Learned Process (LLP) is embedded within the following principles of a
learning model:

What was the original intention of a given activity

The actual outcome of this activity

Lessons Learned from the original intention and actual outcome

What different action would we take in future based on the lessons learned

Then Lessons Learned Process (LLP) must not apply a concerted focus on the negative aspects it must
acknowledge what was considered to be success factors. An important responsibility of the Facilitator is to prevent
a defensive culture developing and promote and encourage learning. The good practices that will emerge may
subsequently be shared and be reflective of the innovative culture established.
This process requires two major steps retrieval / implementation of lessons from previous projects and capturing
of lessons learned in the current project.
These steps are performed in the phases of a project commensurate with its size and complexity. The lessons that
are captured in the current project are either used to provide systemic corrective actions through changes to
specifications and procedures and consideration in future projects.
Capture and retrieval of Lessons Learned may be achieved utilising a number of mediums that include;

Lessons Learned Workshops

Day to Day capture

Customer Feedback

The process for each is detailed within this procedure.

Doc No. PTM-EDES-PR-40

Revision: A01

Issued: 10/10/2012
Page 7 of 12

Printed copies are uncontrolled

4.1.1

Principles

The fundamental principles of the Lessons Learned Process include;

When - Lessons are to be captured at various points in the life cycle of a project, the key phases / milestones of a
project at which juncture lessons capture is mandatory will be identified by the Leadership Team and disseminated
accordingly by the Project / Engineering Manager
Who - The Lessons Learned Champion coordinates the process and has defined responsibilities in this respect.
However, all members of the Project Team will participate and provide demonstrable support to the Lessons
Learned capture process.
Why - Lessons Learned is one of the fundamental success factors underpinning Shell Projects and Technology
commitment to continuous improvement and delivery of world class projects. The aim of the process is to ensure
that projects are cognisant of previous errors or deficiencies and that proposed improvements are considered at the
earliest practicable juncture.
The process flow follows the typical Knowledge Management route of Ask Learn Share
Projects are required to:

Ask previous proportionate projects for lessons

Demonstrate to have learned from the experience of others

Share new lessons learned with other Shell Projects and Technology projects and external communities

Each lesson must be followed up (actioned) until it can be demonstrated that it no longer represents either a
significant risk or opportunity.

4.2

Capture of Lessons Learned

The primary method for capturing lessons will be through open dialogue, progressive capture and structured
Lesson Learned Workshops implemented at pertinent stages / phases.
This step consists of generating lessons, screening and filtering the lessons prior to the appropriate action being
endorsed.
There are a number of primary aspects that must be discussed by all parties within the organisational in relation to
the capture and subsequent use of lessons learned. The primary influencing cultural factors may include the ethos
of lessons dont go there, we did and it failed versus this worked for us, itll work for you too and the ownership
of lessons, irrespective of the source ensuring the lesson is in context is of critical importance.
The scheduling of Lessons Learned Workshops will be cognisant of the project scope, milestones, phases and
duration. This will not detract from the progressive capture of lesson as previously detailed.
It is important to consider that:

Capture is not an end in itself, where the information captured is of no value it will be retained within the
Lessons Learned Database to be established

The relevance of the information captured is based on an assessment done by the source project. Further
analysis is required in identification of action implemented that will support improvement

When capturing and recording a lesson it is of paramount importance that the description provides sufficient detail
and provides the reader with suitable proprietary knowledge of the project and understanding of the lesson
captured. This facilitates the reader understanding whether the root causes of the lesson applies in the case of the
project.
The Lessons Learned will be populated into a software database, which will facilitate e initial interrogation and
retrieval for all personnel and enhance their utilisation of the process.
Similar to the retrieval and implementation steps, the capture of lessons must ensure constructive and objective
input from project personnel, management support and 3rd party engagement as considered appropriate.
Doc No. PTM-EDES-PR-40

Revision: A01

Issued: 10/10/2012
Page 8 of 12

Printed copies are uncontrolled

The primary methods for capturing lessons are through structured Lessons Learned Workshops, however, this must
not detract for the accessibility of the process and subsequent input from all personnel at any stage / phase of the
project life cycle.
The Lessons Learned Workshops will be facilitated by the designated QA Lessons Learned Champion, and must
establish an environment of open dialogue, solicit and support constructive input from all attendees.
The data collated from the Lessons Learned Workshops will be subject to initial screening and analysis prior to
classification of the lesson captured.

4.2.1

Workshops

The capture of lessons is the process of collecting learnings on the project from the project team members in a
structured manner so that these lessons can be retrieved and used by future project teams. Capture of the lessons
learned can be done in many ways, progressively as the project evolves and from formal Lessons Learned
Workshops scheduled at pertinent phases / stages of the project.
Lessons Learned Workshops are an effective and efficient method and which has demonstrated suitable degrees of
success. A key element is to invite, assemble and engage the right people who it is considered may provide
constructive input from their experiences.
This will facilitate creation of an interactive environment in which the people most familiar with the project get an
opportunity to register their experiences, obtain clarification, and have open and constructive a discussion about
what the real learning is.
The workshop format ensures that this method of capture is done with a minimum of inconvenience to the project.
For large projects, it can be beneficial to combine the workshop with individual of interviews prior to the workshop.
This allows the workshop to discuss lessons by pre-defined themes and / or focus on pre-selected major areas.
Critical success factors include:

The planning of Lessons Learned Workshops must be comprehensive in all aspects and ensure a suitable
representation of personnel involved with the project is available

Visibility and support from the Leadership Team an opening and closing address is beneficial

Prior to a Lessons Learned Workshops the Lessons Learned Champion will distribute an overview of the project
scope, highlight key learnings that may have been progressively recorded, and a supporting aide memoir of the
process. This will facilitate both a process refresh and stimulation that will enhance the process and reiterate key
expectations and output from the workshop.
An opening project overview and Lesson Learned Process presentation should support the project introductions
and must establish and communicate expectations of the process a key expectation is that the Facilitator creates
a suitable relaxed environment wherein all personnel in attendance feel at ease and empowered to provide their
comments. Constructive input must be encouraged and supported, it is not a blame session the process will focus
on key elements not an individuals performance.
The composition of personnel identified and invited to attend the Lessons Learned Workshops must, wherever
reasonably practicable, be structured to optimise the process without compromising its integrity.
A key characteristic of the discussion to develop lessons is to work to identify real root causes. The facilitators
should keep asking why? working to understand what the underlying problem was.
If the proposed lesson can be considered an event then thats where we should be intervening. Similarly, the group
should consider the consequences, and how could these be minimised. What contingencies should future projects
incorporate into their plans to prevent recurrence of this issue or the improvement recommended, the outcome of
these discussions is recorded during the event.
Where considered appropriate, typically small scope projects, pre-interviews may be scheduled prior to the
workshop and used as a facility in identification of key areas of focus. In some instances, a Lessons Learned report
may be issued after the interviews without a workshop, particularly when the interviewees have convergent views
on the learnings.
Doc No. PTM-EDES-PR-40

Revision: A01

Issued: 10/10/2012
Page 9 of 12

Printed copies are uncontrolled

4.2.2

Day-to-Day Capture

One of the fundamental strategies behind the experience transfer process is to implement a suitable facility that
encourages and supports the recording of experience that progressively evolves. A standing item in scheduled
meetings will help promote and remind personnel that the process remains live ensuring not all lessons are stored
until project completion.
There is no definitive necessity that stipulates these are required periodically they must not be diluted by a sense of
obligation.
Lessons may be generated by individuals assigned to or supporting the project, Shell Projects and Technology
have a reasonable expectation that where anything may be applied to enhance or improve a process this should be
communicated immediately.
It is the responsibility of all personnel to share constructive input and alternative ways of doing things it supports the
environment of innovation and technical change - Ignoring and continuing with a less than satisfactory process is
unacceptable and unprofessional.
These individual lessons should be reported to the designated Lessons Learned Champion for initial review and
validation. Suitable action may be implemented immediately commensurate and in direct correlation with the nature
of the Lessons Learned.
The Lessons Learned Champion will coordinate suitable review by the Leadership Team and identify whether
immediate action or carry over to the next Lessons Learned Workshop is the most appropriate action to be
implemented.

4.2.3

Customer Feedback

Shell Projects and Technology implement a Customer Feedback process that must engage the project focal points
and provide objective and constructive input.
This process provides a suitable facility wherein the actual performance perception of the client or end user is
solicited for pertinent aspects of the project. These include but not limited to the following categories;

Deliverables Quality

Service Quality

Customer Interface

Adding Value to Project

Project Management

The completion and subsequent review of the Project Customer Feedback reports will further compliment the
Lessons Learned Process.

4.2.4 Interviews
Lessons Learned Workshops may not be the best format for all projects or may not be practicable for all project
personnel. If the number of key personnel is limited, consideration may be afforded to scheduling a series of
interviews which can provide a useful alternative.
A single interviewee may be somewhat restricted not having the benefit of the exchange and interaction with peers
and guide the conversation in the right direction. As a consequence this format applies additional demands on the
interviewers / facilitators, and may require more in respect to the collective preparation by all parties in determining
the specific areas, themes or subjects to which primary focus should be applied during the interview. This may
provide suitable preliminary guidance but must not detract from or compromise the integrity and objectiveness
It is recommended that the main interview takes place face to face. This creates a relaxed and informal
atmosphere, which helps the discussion. It is important to expedite concise clarity when recording each Lesson
Learned it will compromise the process if the interviewer misinterprets a statement.

Doc No. PTM-EDES-PR-40

Revision: A01

Issued: 10/10/2012
Page 10 of 12

Printed copies are uncontrolled

4.3

Lessons Learned Data

4.3.1 Collate
The scope complexity and duration will determine the frequency of Lessons captured throughout the project either
in structured meetings, interviews and / or through Lessons Learned Workshops. Lessons may also be presented
by individuals or department teams at anytime during the project and may be incorporated into and discussed
further at the next structured capture session. All Lessons Learned Workshops sessions must be facilitated by the
designated Quality Assurance Champion.
Critical to the process is the collation retrieval of lessons it does end there that is the start what we do with them
will be critical in capitalising on the potential and subsequent optimisation of their true value.

4.3.2 Review / Screening

The process of review / screening must initially identify whether the lessons present;

Immediate Action (IA) this may also include situations where the immediate transference of the learning
is considered applicable to current projects which would benefit for the learning captured

No Further Action (NFA) this may result for the lesson captured not being considered to have an
immediate benefit to the business unit however, will be retained within the database for future
consideration

Opportunity for Improvement (OFI) this may have significant global opportunity for Shell and have
potential for improvements not only to business execution but also improvement to Shell standards,
specifications and work processes.

The Lessons Learned Database will retain information collated from the experiences that have been presented,
including those that are considered to present significant risks or opportunities and include screening for
consequence, probability, and applicability. The entries will also be pre-screened prior to upload.
Proposed lessons which do not pass screening are passed on to the appropriate Subject Matter Expert. In cases
where the proposed lesson may be a non-compliance with existing standards, the Technical Authority is also
informed.
Lessons that are rejected following the review / screening process will be retained within the database for future
consideration. The reasoning or justification for rejection will be communicated to the project and the individual who
generated the proposed Lesson in all instances, feedback is an integral element of the process.

4.3.3 Analysis / Classification

One of the main tasks assigned to the Lessons Learned Champion is to review the information collated from which
key lessons may be identified. This may necessitate reverting to the source project for clarification or further
information. It is of paramount importance that the full story and underlying message of the lesson is understood in
all aspects.
Proposed lessons are occasionally embedded in our management systems processes, procedures, codes and
standards. Some lessons are evidence of a Non-Compliance with this Management System. In order to understand
whether a proposed lesson is new, the Lessons Learned Champion must consult with the Leadership Team.
Additional clarity may be sought from Shell Community of Practice / Technical Authority / Subject Matter Experts
where considered appropriate.
Where the Non-Compliance is resulting from a deviation from or lack of knowledge or understanding of the
Management System this may present a lesson that should be acted upon, either by reinforcing or modifying the
Management System or possibly by strengthening the assurance processes through which projects are held
accountable.

Doc No. PTM-EDES-PR-40

Revision: A01

Issued: 10/10/2012
Page 11 of 12

Printed copies are uncontrolled

4.4

Feedback

It is important that we generate a report wherein all pertinent points are captured / acknowledged and
improvements implemented accordingly. The report distribution recipients will be approved by the Leadership Team
prior to circulation.
Individual feedback is a critical element that is integral to the success of the Lessons Learned Process. Where
personnel have been engaged to provide constructive input it is a realistic expectation that the outcome of the
individual lesson and its subsequent acceptance / rejection is explained to the originators.
Acknowledging the significance of input helps maintain a positive environment in this respect and supports
continuous improvement within the organisation.

4.5

Communication

Communication of the Lessons Learned Process begins with each individual reading and having a suitable
appreciation of the Lessons Learned Process and their responsibilities therein. The success of the process is
dependent upon collective input to the process from all parties.
There are a number of mediums that may be utilised to publish Lessons Learned and subsequent improvements
that have been generated. This may include;

4.6

Leadership Team acknowledgment

Enhanced visibility of the process on Notice Boards

E-mail communication

Database

The Shell corporate Lessons Learned Database has been established by Shell Knowledge Management function
and resides within the Shell web domain.
The database is designed to be user friendly facilitating access by all personnel Access filters will be applied that
support expedient accessibility, typical example being that if the user requires information in relation to Flowlines,
they simply type Flowlines and any examples of the profiles to read something about the contextual background of
the Flowline and the profile owner. This facilitates and promotes the individual to take a view on whether he / she is
the most suitable from whom to seek advice likely to be valid for the current enquiry.
Read / write access restriction is applied to Lessons Learned Focal Point and business unit Leadership Teams to
ensure the integrity of the process is not compromised.

Doc No. PTM-EDES-PR-40

Revision: A01

Issued: 10/10/2012
Page 12 of 12

Printed copies are uncontrolled