This document is classified as Public

LESSONS LEARNED GUIDELINES

Compiled by
Patrick Williams (Assystem UK)

Abstract:
This document presents a range of guidelines supporting lessons learned processes
within the Supply chain. The report is primarily based on the Aerospace sector, but
the methods are applicable in a wider industrial context.

Dissemination:
PU

Deliverable/Output n°: D1.2.6_3 V2 Annex 2 Issue n°: 1.0

Keywords:
Lessons learned, Knowledge management,

VIVACE 1.2/6/Assytem/T/07022 Page: 1/ 20

© 2007 VIVACE Consortium Members. All rights reserved.
VIVACE Lessons Learned Guidelines
This document is classified as Public
Approval Process
Name Partner Organisation Role / Title
Deliverable Leader: Patrick Williams Assystem UK T1.2.6 team member

Contributors: Joe Cloonan Airbus UK T1.2.6 lead

T1.2.6 J Cloonan Airbus UK T1.2.6 task leader
Reviewers E Carver BAE SYSTEMS T1.2.6 team member
Users: WP3.1, T1.2.6

Owner(s): AI-UK, BAES, Assystem UK

Internal Reviewers:

Process Auditor
agreement:

Document details
Document identifier VIVACE 1.2/6/Assystem/T/07022
Deliverable/Output n°: D1.2.6_3 V2 Annex 2 Contributing Companies
th
Issue Date 27 September 2007 Assystem UK, AIUK
Contract n°: AIP-CT-2003-502917

Project n°:

Revision table
Issue Issue date Modifications
st
0.1 1 August 2007 Draft issue
0.2 17th Sept 2007 Release for internal reviewer
th
1.0 27 Sept 2007 Final version including update following internal review comments

Electronic file details

Master file location VIVACE MV site > wp 1.2 > t126 kewe > t126 deliverables

Filename D126_3_V2 Annex-2 LL_Guidelines 27sep07.doc

Internal ref

VIVACE 1.2/6/Assytem/T/07022 Page: 2/ 20

© 2007 VIVACE Consortium Members. All rights reserved.
VIVACE Lessons Learned Guidelines
This document is classified as Public

TABLE OF CONTENTS

1. EXECUTIVE SUMMARY ...................................................................................4

2. KNOWLEDGE MANAGEMENT AND LESSONS LEARNED ...........................4
2.1. Introduction ................................................................................................................ 4
2.2. Knowledge Management (KM)................................................................................... 5
3. GUIDELINES FOR LESSONS LEARNED IN THE SUPPLY CHAIN................7
3.1. Scope ......................................................................................................................... 7
3.2. Overview and Definitions ........................................................................................... 8
3.3. Guidelines - for a Lessons Learned Process ............................................................. 9
3.4. Guidelines - for Lessons Use and Re-use ............................................................... 10
3.5. Guidelines – for Storing and Managing Lessons Learned ....................................... 11
4. DEPLOYMENT AND ORGANISATIONAL CULTURE....................................11
4.1. Business Change and Culture ................................................................................. 11
4.2. Guidelines – to support Acceptance and Deployment of a Lessons Learned
Approach within Organisations ........................................................................................... 12
5. ROADMAP ......................................................................................................13
6. CONCLUSIONS ..............................................................................................14
7. BIBLIOGRAPHY .............................................................................................14
8. APPENDIX A – PROFORMA EXAMPLE........................................................16
9. APPENDIX B – EXAMPLE OF A DATABASE SPECIFICATION...................18

VIVACE 1.2/6/Assytem/T/07022 Page: 3/ 20

© 2007 VIVACE Consortium Members. All rights reserved.
VIVACE Lessons Learned Guidelines
This document is classified as Public

1. EXECUTIVE SUMMARY
This report introduces a range of guidelines associated with the generation and application
of lessons learned processes aimed at the Knowledge Enabled Wing Engineering function
and processes, but in reality applicable to other aerospace functions also.
The report highlights the main functions associated with the subject of Knowledge
Management (KM). Experience with KM in the Aerospace sector shows the process is only
used sporadically, and there is considerable scope for development and growth of this
discipline.
This report looking at the specifics of lessons learned as one of a range of inter-related
studies in the VIVACE project, which progress the subject of KM and its application.
The guidelines are presented in relation to the process, capture and management of data,
reuse of lessons learned, and the issues associated with deployment of lessons learned as a
business change.
Throughout it has to be emphasised that the lessons learned process is a means of
supporting the networks of personnel who are employed to deliver the necessary functions. It
is an approach for use across the whole organisation, and considerable benefits exist when
these can be expanded into supply chains.
It is also important to recognise within a supply chain framework the importance of trust, and
the management of Intellectual property, and the use of the contract to the benefit of those
parties within the supply chain, in the creation, management and use of lessons learned.

2. KNOWLEDGE MANAGEMENT AND LESSONS LEARNED

2.1. INTRODUCTION
The subject of Knowledge Management is well researched, and its application is recognised
as an important feature of business.
It has been recognised that the way people learn is a combination of explicit and tacit
techniques. Research has also recognised that the capture and reuse of knowledge is not an
easy subject, not least because of the implications on the workplace, and the cultural
implications, but also because of the dispersed way in which organisations and supply
chains operate, combined with the commercial pressures on delivery.
Work completed with VIVACE since 2005 has brought together a range of considerations
associated with working relationships in the supply chain, processes and tools all associated
with experience in the Aerospace industry.
Knowledge management in its own right and its use in projects is a complex subject,
particularly when used between customers and suppliers in the supply chain, and within an
industry such as Aerospace with multinational activities, complex systems and products, and
extensive regulatory requirements whilst operating under an environment of intense
competition and the associated controls on cost and schedule.
Unfortunately, the research completed indicates that within the Aerospace sector, KM is
used sporadically and is not built into the businesses processes as an inherent function.
Where it is used, knowledge is not shared that widely, and the data produced is not
structured, and hence is not as easy to use as it could be.

VIVACE 1.2/6/Assytem/T/07022 Page: 4/ 20

© 2007 VIVACE Consortium Members. All rights reserved.
VIVACE Lessons Learned Guidelines
This document is classified as Public
In order to progress the subject, the VIVACE project is looking at the various functions
associated with KM to generate a range of processes and tools that can be applied to
support the Aerospace supply chain. The particular focus here is on the design and
development of wings, however many of the processes are generic, and can be applied in
other aspects of the Aerospace sector with minimal tailoring.
The guidelines generated in this report are based on the application in a collaborative
engineering and virtual operating environment. However the techniques themselves can be
applied in other working environments within organisations and projects.

2.2. KNOWLEDGE MANAGEMENT (KM)

Within VIVACE, Knowledge Management (KM) has been considered within a range of
activities associated with the basic functions of capturing, storing and re-using knowledge,
along with IT tools, and relationship evaluation tools, that support the organisation or inter-
organisation working. This concept has been specifically assessed in the context of
Knowledge Enabled Wing Engineering (KEWE), and the supply chain.
Knowledge management is ultimately about the identification, use, and re-use of knowledge
to be applied in specific contexts at specific points in time related to a project work package
or functional activity. Knowledge can be captured and stored electronically, be held by
individuals in the business, or be on networks and web based applications where interaction
of data and people can be achieved through data and networked communities.
It is technique to answer the following, in the context of a specific subject or method, at a
point in time, or under definable circumstances. :
I. How can you replicate ‘success’ or improve on it?
II. How can you identify the causes of failure and rectify them?
To do this the following have to be considered :
a) What went well in the application of a method?
b) What can be improved in the application of a method?
c) What is the best practice for this situation/subject/process/technology, at this point
of time?
d) Who has this knowledge, if it is not recorded in a place that can be easily
searched?
In this context Knowledge Management is a method that should consider the following
functions:
• Capture of Knowledge.
• Storage and searching.
• Re-use of knowledge.
• People and ‘Yellow pages’ as a means of searching for knowledge.
• Interactive networks.
• Inter- organisational relationships, and evaluation tools (Supply Chain Relationships
in Action (SCRIA)).
• Management and protection of Intellectual Property Rights (IPR).
• IT and KM software, shared data environments.
• Personnel roles.

VIVACE 1.2/6/Assytem/T/07022 Page: 5/ 20

© 2007 VIVACE Consortium Members. All rights reserved.
VIVACE Lessons Learned Guidelines
This document is classified as Public
• Management of knowledge and management methods on capture, sharing and
deployment of knowledge.
• Processes applied across the project life cycle, and timing.

This can be defined by the relationship shown below.

The capture, management and deployment of lessons learned is an important ‘subset’ of the
overall KM function, and each of the items included above can be considered in the context
of lessons learned, which can be defined as follows :

Considerations within
lessons learned

Push/Pull of information Legal/Contractual

Process Flow
Information flow Constraints on Information
flow

Methods of Communication
Dispersion/Location

Knowledge Enabled Wing

Engineering

Notes re-use
Roles

Collaboration
Information Capture Culture – Ways of
working
Relationship Building Trust
Experience capture & re-use

The guidelines identified within this document will therefore reflect each of these areas.
VIVACE 1.2/6/Assytem/T/07022 Page: 6/ 20
© 2007 VIVACE Consortium Members. All rights reserved.
VIVACE Lessons Learned Guidelines
This document is classified as Public
The lessons learned process also fits within the knowledge life cycle shown below.

3. GUIDELINES FOR LESSONS LEARNED IN THE SUPPLY CHAIN

3.1. SCOPE
The guidelines defined here are based upon a combination of results from the VIVACE work,
combined with the experiences associated with the creation and management of lessons
learned in a supply chain context.
The guidelines will cover information on process, management, tools, and roles.
Why apply lessons learned, and what are the benefits?
Within organisations considerable experience is developed through all elements of the
workforce, technical, management, production, commercial etc. Often this knowledge
remains with the individuals, and where it is documented it is unstructured, stored in various
places, and not readily or easily used. Invariably the existence of the knowledge is not
known.
The result of this can be that best practice is not applied, mistakes made are repeated in
projects, and the experience gained by successful or unsuccessful practices are not applied
elsewhere. Hence the experience gained has to be re-learned.

VIVACE 1.2/6/Assytem/T/07022 Page: 7/ 20

© 2007 VIVACE Consortium Members. All rights reserved.
VIVACE Lessons Learned Guidelines
This document is classified as Public
Hence the benefits of the applying lessons learned are in retaining knowledge of what went
well and what did not in the context of the work being done, identification of where expertise
exists that can be accessible either through electronic information, networks or people, with
the overall benefit in the return to the business in quality, time and ultimately costs to achieve
the objectives of programmes of work, and recognition of personnel and the roles they
perform and expertise they have.
Where the lessons learned are captured in a more structured approach, then this knowledge
can be considered as part of an organisations or supply chains knowledge assets.

3.2. OVERVIEW AND DEFINITIONS

Lessons learned are aimed at progressing knowledge beyond the existing
knowledge and be for the benefit of everyone on the organisation.
A lesson learned can be defined as ‘a short context specific statement that passes on
information that would help someone else who is performing the same task’. It can also
be considered as useful knowledge gained from experience, or information that acts as
an example, that can be set as ‘the best way of doing something’. In this context
‘experience’ can be a success or failure, the key is the recognition that something has
been learned and therefore can be used in the future as guidance.
Lessons learned can cover a range of subjects and issues : technical,
management, commercial, contract interpretations, organisation and inter-
organisation relationships, processes and procedures inside the organisation or
by customers and suppliers.
A lesson learned must have a structure. An example would be: Title-Subject-Context-
Solution-Recommendation. See figure below

Title (brief Structure of a lesson learned

and relevant)

Subject (brief
description of the
situation)

Context (circumstances
that lead to the
situation)

Applied solution
(How the situation
was rectified)

Supported by keywords to Recommendation

aid searching (how to avoid the
situation in future)

As background information the project or function involved can be included in the basic
introduction to provide some context on the experience gained, and where it may be
more relevant for future use.

VIVACE 1.2/6/Assytem/T/07022 Page: 8/ 20

© 2007 VIVACE Consortium Members. All rights reserved.
VIVACE Lessons Learned Guidelines
This document is classified as Public
3.3. GUIDELINES - FOR A LESSONS LEARNED PROCESS
• The lessons learned process should be built into the normal daily management
and technical practices, so that it is not considered as an additional task.
• Lessons learned processes should feature within the overall organisation
quality processes.
• Where possible Lessons learned should be included within the definition of
any piece of work, within the statement/Description of work.
• Where possible within a supply chain include it as a specific part of the contract for all
parties to generate and share lessons learned throughout the programme, where
they are appropriate to the customer and supplier interaction. (But to retain trust, do
not enforce it where it is only for the use in one organisation only, and do not use it to
gain commercial advantage).
• Ideally the process should have two functions a) a record of lessons learned for the
wider use of the organisation b) as a means of encouraging contact with or between
‘experts’ based on the information they hold, and is recorded, to allow the
dissemination and exploitation of the knowledge held.
• Lessons learned can be generated and applied at any stage of a project or a piece of
work.
o Ongoing activities, e.g a new way to use a function within a software tool
that benefits the users.
o At a milestone point within a project or work-package, e.g. the capture of
the things that went well, and the things that did not go so well for
application in the next piece of work or task.
o At a gateway (i.e the progression from one phase of a project into the
next phase by the successful achievement of a range of objectives e.g
e.g the capture of the things that went well, and the things that did not go
so well, for application within the next phase.
o End of a project or work package.
o Note that a lessons learned task that is only applied at the end of a
project, is probably going to be viewed as an extra task, and will not be
applied that widely. It is also likely that the benefits that could be gained
throughout a project would have been lost.
• A process should be defined which, captures requirements within a structure, ideally
by a proforma, keywords are generated, the subject audience are identified, the
information is agreed with a Project or Functional manager before being stored for re-
use.
• Lessons learned can be generated by anyone, as long as a structure is applied for
recording the lesson learned, and the process is used for its development and
release.
• A central database, and shared data environment should be used to allow ease of
access.
• An alpha/numeric referencing system should be used with version numbers to show
how the lessons are updated, and evolve.
• To enable the process Lessons Learned should be a routine item on any project or
functional meeting agenda, to reinforce the process, and encourage the generation of
and use of lessons learned.

VIVACE 1.2/6/Assytem/T/07022 Page: 9/ 20

© 2007 VIVACE Consortium Members. All rights reserved.
VIVACE Lessons Learned Guidelines
This document is classified as Public
• A regular communication programme should be applied to support the Lessons
learned process, and ease it into the organisational culture, and maintain awareness
of it, its benefits, and any changes.
• As well as recognising that the lessons learned process generates a data record, it
also highlights the people who have knowledge that can be approached for advice on
the relevant subject. A contact database or yellow pages supplements this approach
for the wider subject of knowledge management.
• The lessons learned process should be integrated into other business processes, e.g
Project start up, proposal generation, budgeting, risk analysis.
• Include lessons from a variety of sources to widen the knowledge base, and
introduce variations on themes, and allow the ability to compare and contrast
experiences.
• Define an approach where benefits can be realized easily, and the administration
burden is minimized.

A specification for a simple lessons learned proforma is included in Appendix A.

3.4. GUIDELINES - FOR LESSONS USE AND RE-USE

• Information can be reused in a formal or informal context. Either by using the
information available through formal processes, and databases, or by
communication with people who hold the knowledge in the context required.
Recognition that people play a critical role in holding, relaying and interpreting
the knowledge and experience they have, cannot be understated.
• The ability to easily search relevant information is probably one of the key
abilities in a Lessons Learned system and process, and will be a significant
factor in its usefulness and acceptance.
• The selection of relevant keywords, and possible subject matter, e.g CAD,
Project Management, Procurement etc are important in assisting the search
process, and allowing the user to find relevant information efficiently.
• Where information is beneficial, or can be reinforced by further knowledge and
experience update the lesson learned, but ensure any numerical issue number is
updated to reflect the additional information which may reflect different contexts.
• The use of lessons learned can be at any time. However the real benefit is at the start
of a task or project, to understand the issues that have positive and negative
experiences that have happened previously, and incorporate this in the planning and
risk management actions.
• Where possible consider a range of lessons learned related to a particular subject, to
expand the knowledge of potential solutions, and understand cause and effect.
• Intelligent search capability has to be included, but users need to be trained also in
how to be intelligent searchers of the data to ensure they obtain the information they
are looking for.

VIVACE 1.2/6/Assytem/T/07022 Page: 10/ 20

© 2007 VIVACE Consortium Members. All rights reserved.
VIVACE Lessons Learned Guidelines
This document is classified as Public
3.5. GUIDELINES – FOR STORING AND MANAGING LESSONS LEARNED
• A structured database for managing and search lessons learned is an
important part of the formal lessons learned process. This supports the
network of people involved in delivering a project or function.
• The lessons learned should be stored in an environment to allow access by all
personnel, but the information has to be secure, and should only be open to
third parties if this acceptable within the operation and strategy for the
business.
• Lessons learned in the supply chain context, may need to be operated through a
controlled internet/intranet portal or network to ensure the integrity of the data is
maintained. Provide as much access as is practical with suppliers, and encourage
supply chain lessons learned that emerge from the suppliers themselves to be
incorporated in the lessons learned records/database.
• Ideally any information created within a proforma should be available through the
database.
• The database should allow searching by computer, or visually scanning of the
content.
• Where a database is applied, this does not need to be complex. Accessibility and the
ability to evolve the capability, and maintain the data are the priorities. Hence use of a
commonly used database language or system is preferable. Obvious examples are
Oracle, or MS Access. MS SharePoint is also an option for internet operations but
should be considered in relation to any security requirements.
• If an off the shelf lessons learned package is used, e.g Data Art Lessons learned
system, this should be assessed for suitability against the environment for sharing
knowledge, and the ease of searching, using and generating lessons learned.
• Roles should be identified against the different functions for the creation and
agreement of lessons learned. In a technical context anyone can raise a guideline,
but these should be agreed and released by an identified expert in the function.
Similarly in Project/Programme Management terms this agreement would be by the
Project/Programme Manager, in Commercial terms it would be by a Commercial or
Contract Manager, or Procurement, the Procurement Manager. In each case the
person may also undertake a role as the skills manager for the function.
A specification for a simple lessons learned database is included in Appendix B.

4. DEPLOYMENT AND ORGANISATIONAL CULTURE

4.1. BUSINESS CHANGE AND CULTURE

The initiation, development and delivery of any business change is never easy, for a range of
reasons, and barriers will in most cases always occur. See figure below.

VIVACE 1.2/6/Assytem/T/07022 Page: 11/ 20

© 2007 VIVACE Consortium Members. All rights reserved.
VIVACE Lessons Learned Guidelines
This document is classified as Public
No-
No- one will
listen even if I
share?

I wish that I
Oh…another could talk to
initiative from someone who
central. has done this
before

Why didn
didn’’t
anyone ask US
for OUR
opinion?

I don’
don’t have the time
or resources for this. I’ll go along with
it, but THEY
won’
won’t!

The application of good practice through planning, involvement of personnel at all levels,
high level acceptance and support as a catalysis for organisational acceptance, and
continual communication, supported by training, and securing and publicizing early
successes and benefits is a means of working for a successful outcome.
Critically some personnel will feel threatened by having to share ‘their’ information. Hence
these barriers have to be crossed. An important consideration is that information is not lost
when someone shares it, they are not now under threat, but because of the increased
knowledge available from lessons learned, or any other Km practice applied with it, each
person now has access to more knowledge to improve their overall performance, and
decision-making ability.

4.2. GUIDELINES – TO SUPPORT ACCEPTANCE AND DEPLOYMENT OF A LESSONS

LEARNED APPROACH WITHIN ORGANISATIONS
• Recognise that the introduction of any initiative is bound to have some opposition or
skeptical reaction within an organisation or organisations. A lesson’s learned
approach is no different.
• Plan the change programme to include the beat practice techniques that are
appropriate (consider the categories raised above)
• Encourage the process to be used at all levels of the organisation to create
acceptability for the system use, and benefits, and widen the knowledge available
quickly.
• Gain the active support and usage by seniors in the organisation, as well as
specialists, and those managing and delivering the necessary work.
• Create a focus around a project or function to start the lessons learned process, to
expand the knowledge base, and gain real benefits quickly.
• A ‘super-user’ is an important consideration in the database operational
management, and training.

VIVACE 1.2/6/Assytem/T/07022 Page: 12/ 20

© 2007 VIVACE Consortium Members. All rights reserved.
VIVACE Lessons Learned Guidelines
This document is classified as Public
• Train people to use the process and system, and how to get the best from it as
efficiently as possible, ‘create intelligent searchers’.
• Communicate its existence, communicate its benefits, and communicate its
successes, communicate its evolution and development. Encourage involvement.
• Define and use the terms of reference of key people to operate and manage the
system. Ideally there should be a system/process owner, super-user’s, system
operators, and managers who are responsible for the acceptance of information, and
the upkeep and forward strategy for the lessons learned process.
• Use organisational network tools to identify where knowledge is held, who operated
with who, and where the strengths and weaknesses are, and encourage the use of
lessons learned to support the integrity of information through a single source/point of
control where possible. This will enforce the yellow pages concept, but also use the
yellow pages to support the network of personnel in their respective functions.

5. ROADMAP
In terms of creating a lessons learned capability the chart below identifies the key areas that
should be addressed when considering either in an organisational or in a supply chain
context.
The guidelines support each of these various areas.

VIVACE 1.2/6/Assytem/T/07022 Page: 13/ 20

© 2007 VIVACE Consortium Members. All rights reserved.
VIVACE Lessons Learned Guidelines
This document is classified as Public
6. CONCLUSIONS
Lessons learned are an important part of the processes for managing and deploying
projects. The process is applied but not as widely as is possible.
To apply a lessons learned approach, requires a structured approach through the life of a
project, and a recognised means of recording data, for re-use, but the challenge to the
concept is the ease of extracting the correct information.
The approach defined should be integrated in the Quality processes, and applied as a
routine method within daily operations (as opposed to an additional function), in order to gain
the most benefits efficiently.
Use within a supply chain has obvious benefits that require the means of operating across
organisational barriers, for the benefit of all organisations. This can be in the arena of
lessons learned only or the wider arena of Knowledge Management. Hence in this context
mutual trust, and where necessary contractual arrangements have to be in place to allow
free access to information, in a controlled environment, whilst protecting IPR, and
organisational confidentiality.
This can be enabled through a portal arrangement or virtual enterprise network, with the
necessary security in place.
The software applied need not be expensive; the simplest database can be used as a means
of collecting and searching as long as the processes and data structure is completed to aid
the application.
It is also important to recognise that the lessons learned approach should recognise the
knowledge people have and the value attached to it from both the organisation and the
personal level. To this end a lessons learned database should be considered in the context
of information to assist through a problem, or identification of a best practice in its own right,
but critically should be used as a means of recognising also who has what knowledge and as
a means of initiating direct communication.
Hence a good combination to support a knowledge management environment would be a
lessons learned process and database, combined with a yellow pages of contacts and
knowledge ‘expertise’.
The application of lessons learned or knowledge management techniques will invariably be
seen as an afterthought, an additional expense to a programme, or a challenge to
organisational culture.
In the latter case this can only be managed by a well planned change programme, however
the issues associated with the approach being an additional function and cost, can easily be
reduced by the application of the approach within normal procedures. Lessons learned can
be applied at any time, but in particular in regular review meetings, and at specified
milestones or gateways. The main benefits are likely to be on commencement of a project
progression through project stages, where the lessons learned can be applied within the
planning process for the work being completed, and the day-to-day operations.

7. BIBLIOGRAPHY
VIVACE deliverables:
• D1.2.6_1 Use case definition for KEWE
• D1.2.6_2 Sharing knowledge across the supply chain – J Cloonan, P Williams, E
Carver

VIVACE 1.2/6/Assytem/T/07022 Page: 14/ 20

© 2007 VIVACE Consortium Members. All rights reserved.
VIVACE Lessons Learned Guidelines
This document is classified as Public
• D1.2.6_3 Knowledge sharing guidelines for the supply chain – J Cloonan
• KESP Platform level definition – P Nuzzo, F Lockwood

Other sources:
• Sharing knowledge across boundaries – C Ciborra, R Andreau

VIVACE 1.2/6/Assytem/T/07022 Page: 15/ 20

© 2007 VIVACE Consortium Members. All rights reserved.
VIVACE Lessons Learned Guidelines
This document is classified as Public
8. APPENDIX A – PROFORMA EXAMPLE
Reference number

Title Author

Programme Status draft

or agreed
and
confidentiality
Date Date
created released to
database
For use in Assystem UK only, or available
for discussion with client or suppliers.

Lessons learned type : Technical,

Project Management, Process,
Behaviour.

Lesson learned

Context

Recommendation for application in future

Target audience for lesson learned

Key words for searching :

VIVACE 1.2/6/Assytem/T/07022 Page: 16/ 20

© 2007 VIVACE Consortium Members. All rights reserved.
VIVACE Lessons Learned Guidelines
This document is classified as Public
Feedback or comments from other reviewers, or interested parties Assystem
or clients, partner companies, or suppliers
Feedback or comment, name, Action taken from feedback or
organisation and comment, date. comments where necessary, by who,
and date.

VIVACE 1.2/6/Assytem/T/07022 Page: 17/ 20

© 2007 VIVACE Consortium Members. All rights reserved.
VIVACE Lessons Learned Guidelines
This document is classified as Public
9. APPENDIX B – EXAMPLE OF A DATABASE SPECIFICATION
This specification has been generated as a means of developing a simple database that can
be used to record and present lessons learned, and allow searching of the database, and
data entry once for use many times.

1.Specification.

The following specification information has been defined as a range of individual statements
that define the functionality needed within a project Lessons Learned database.

1.1 Systems level requirements.

• The lessons learned database shall be available for all personnel to search and
identify lessons that can be applied to their programmes.

• The lessons learned database shall have some security so that it cannot be accessed
by third parties, but has to be routinely available on every PC within the business
through a simple access/log on process (e.g this could be comparable to or part of
the intranet access process)

• The Lessons Learned database shall be generated with commercially available

database software, and shall be supportable within the IT function and software suite,
(e.g Oracle or Microsoft products).

• The basic system should be transferable easily within organisations or across

organisational boundaries

• The Lessons learned database will be made up of a ‘table of lessons learned’, which
contain proforma containing the lessons themselves (possibly recorded on proformae
See Appendix A) as links.

• The database shall have two levels of operation with drafts which are proforma that
have been/are under development prior to agreement for release, and released
lessons.

1.2 Database usage.

• Lessons Learned can be created by anyone in the company. The information created
should be on to a proforma as a draft, which identifies the project, context, keywords
and information associated to the lesson. See Appendix A.

• The database ‘table of lessons learned’ will have a reference number system, that is
created automatically by the system, reflecting the lesson learned its status e.g draft,
and when agreed and released ; issue 1, issue 2 etc.

VIVACE 1.2/6/Assytem/T/07022 Page: 18/ 20

© 2007 VIVACE Consortium Members. All rights reserved.
VIVACE Lessons Learned Guidelines
This document is classified as Public

• The ‘table of lessons learned’ content shall be developed automatically from fields
from within the proforma.

• A lesson learned can be added to by another person, but this would mean an update
of the lesson, and an update in the lesson learned reference issue number to ensure
both versions are maintained, and a release of information agreed by the project
manager(s) involved.

• The lesson learned should be agreed as being appropriate for release by the Project
Manager for the project, and the release process on acceptance be a single button
process to take the lesson learned from draft to released ‘issue 1’. It is assumed
therefore that unless a workflow process is made available, that the existence of the
lessons learned and its progression from draft to issue 1 would be by communication
between the author and Project Manager)

• If the lesson learned can be shared with customers or suppliers this should be noted
on the proforma and the database.

• The database shall be searchable under the keywords.

• Search facilities shall be included against a question, or a string of words.

• Search results shall show a % relevance to assist the user.

• The user shall also be able to review the database to determine if there are lessons
that are applicable by reviewing the titles and project information in the database
‘table of lessons learned’.

• The content of the proforma shall be able of being transferred into a word file on
request by a user.

• The lessons learned table shall be able to be transferred on to a word file as a table
on request by a user.

• Both the proformae and the table shall be able of being printed out on A4.

VIVACE 1.2/6/Assytem/T/07022 Page: 19/ 20

© 2007 VIVACE Consortium Members. All rights reserved.
VIVACE Lessons Learned Guidelines
This document is classified as Public

Knowledge Management database

Database requirement to support template .

.
Originator Subject. Keywords for searching Link to lesson Target audience Usage. Project. Agreed for
and Lesson learned and function use by
learned type
AN Other Project Project Link to lesson Project Setting up AXXX, A Person
Management Management,Programme learned Managers programme leading
Management, reference Within Airbus organisation edge wing
Communication, number nnnnnn programmes in structures design
Organsaition Filton and detail
AN Other 2 Configuration Data, Configuration, Link to lesson Technical leads, Managing AXXX, A Person
of design control learned Designers, data from wing
data reference Project client aileron
number nnnnnn Managers, actuator
Configuration Hydraulic
controllers system

VIVACE 1.2/6/Assytem/T/07022 Page: 20/ 20

© 2007 VIVACE Consortium Members. All rights reserved.