International Journal of Project Management 21 (2003) 219228 www.elsevier.

com/locate/ijproman

Harvesting project knowledge: a review of project learning methods and success factors
Martin Schindlera,*, Martin J. Epplerb
b a Business Media AG, Lerchenfeldstr. 5, CH-9014 St. Gallen, Switzerland Institute for Media and Communications Management, University of St. Gallen, Blumenbergplatz 9, CH-9000 St. Gallen, Switzerland

Abstract This article presents an overview of proven methods to record experiences from projects and discusses their use in project management. We distinguish between process-based and documentation-based debrieng methods. Process-based methods focus on a procedural approach to capture key learnings from a project. Documentation-based methods serve as appropriate representation formats or structures for project insights. The article bridges the current gap between theoretical insights into this topic and the managerial reality today. It discusses central project debrieng problems such as the lacking willingness to learn from mistakes or the lacking discipline in the use of project management manuals. We conclude the article with recommendations on how debrieng processes can be integrated successfully into project procedures. # 2003 Elsevier Science Ltd and IPMA. All rights reserved.
Keywords: Project management; Knowledge management; Organizational learning; Lessons learned; Action learning; Debrieng

1. Introduction More and more organisations choose project work as exible and reliable structures for the development and production of their goods and services. Due to their special nature as a secondary type of organisational form (e.g. limited time and resources, pressure, great complexity, new teams), projects are especially suitable for learning [13]. However, our research1 with various project teams (in product development, controlling, consulting and nancial services) over the course of
* Corresponding author. Tel.: +41-860-797-703-260; fax: +41860-797-703-260. E-mail addresses: martin.schindler@gmx.ch (M. Schindler), martin.eppler@unisg.ch (M. J. Eppler). 1 We conducted (problem-focused and iterative) action research in nine multinational companies from the industry and service sector with regard to their project knowledge management using the case study research methodology to document our ndings [4]. Forty-six semi-structured expert interviews helped to record eld experience with debrieng methodologies. Using half-day follow-up workshops, the interview results have been validated and developed with representatives of the participating companies such as DaimlerChrysler, IBM Global Services, Pixelpark, Schindler Elevator & Escalators, Roche and UBS. This participatory research approach has resulted in the problem compilation that is described below. The ndings from this action research can complement (and contrast) the literature review on the available debrieng methods.

three years shows that knowledge and experiences gathered in dierent projects are not being systematically integrated into the organisational knowledge base and that there is a great discrepancy between the need for project debrieng and its actual deployment. In order to overcome this apparent gap, the present article examines reasons for project amnesia (i.e. not retaining project insights) and presents an overview on the available methods for the project-centred gathering and use of lessons learned. As a result of this survey, the article presents various key success factors for eective debrieng methods.

2. Problems of project learning The systematic retention of project experiences enables a company to compare its various projects more systematically and document its most eective problem solving mechanisms. In addition, the systematic documentation of mishaps, mistakes or potential pitfalls helps to reduce project risks. From a long term perspective, systematic project learning enables the enterprise to develop project competencies that lead to a sustainable competitive advantage. Experienceswhich are by denition bound to the people who are personally involved in the corresponding

0263-7863/03/$30.00 # 2003 Elsevier Science Ltd and IPMA. All rights reserved. PII: S0263-7863(02)00096-0

220

M. Schindler, M.J. Eppler / International Journal of Project Management 21 (2003) 219228

problem solving processesare often not a part of a projects documentation and they are seldom transferred to other people during the course of a project. Project team members return to their line functions (or they are being moved into other functions) after having completed their tasks in the project [5], and they usually take their new experiences with them [6]. These experiences are then only accessible through informal networks [5,7]. Relevant project documentationsuch as a feasibility study, a summary, a technical report or a user manual which has to be produced to meet minimal documentation standards is often supercial and has its focus on merely capturing standardised business gures or the description of the projects results. Recordings of failure reasons or how particularly ecient solutions have been built or how certain special issues have been addressed are often omitted. The end of a project is consequently the end of collective learning. The involved sta move on to new projects or they are reintegrated into their line functions. If their specic knowledge of that project is not directly needed, organizational amnesia begins. In addition, external partners or consultants, who have provided crucial project inputs, leave the company after the completion of a project. In case their knowledge is needed (e.g. if similar problems occur in other projects) it is even harder to identify and can only be reconstructed partly without their personal support. Some consulting companies have realised this problem and emphasise the thorough documentation of their project work. Up until now, however, clients have often been reluctant to pay extra fees for this documentation eort. The risk of a knowledge loss at a projects end is a serious problem for organisations, especially in knowledge-intensive industries, such as pharmaceuticals, nancial engineering, or high-tech. Companies could save considerable costs, which result from redundant work and the repetition of mistakes, if they master the project learning cycle. The next section reviews some of the insights that are documented in project management literature to overcome this problem. 2.1. Debriengs in project management literature While earlier publications on debriengs as vehicles for project learning have focused primarily on knowledge that is relatively easy to document (such as costs, time lines or other quantitative data) recent publications also take tacit aspects into account. These recent articles refer to knowledge that is dicult to express such as know-how (procedural or heuristic knowledge) and especially know-why (e.g. experiences, insights into causeeect relationships) [8]. The reason why these tacit components are stressed in recent publications is that numerical data often does not provide answers to

pressing project questions or problem [9]. Numerical data mainly answers what, where and how many questions, but does not address crucial why and how questions that are better addressed by stories, case studies or project reports. Existing research on project learning has recognised the situation described above and voices the demand for learning within (e.g. [10]) and from (e.g. [11,12]) projects. In recent publications one can nd more and more often the demand to perform a more detailed analysis at project end and to document the positive and negative experiences gained in the sense of a project post-mortem (see for example [11,1316]) or a retrospective [17]. In the same context the term lessons learned is frequently used (and has also been added into the glossary of the recent edition of PMBOK [16]). We will use it as a superordinate term. Lessons learned are dened as key project experiences which have a certain general business relevance for future projects. They have been validated by a project team and represent a consensus on a key insight that should be considered in future projects. In classical project management literature handling the codication of project insights is usually limitedif it happens at allto the demand to capture the learnings at the end of the projectfor instance with a project debrieng workshop. Often, the remarks are limited to aspects of the return of personnel or special resources, the transfer of responsibility and the reallocation of the team and the project manager for other tasks as well as the product hand-over to the responsible line managers (e.g. [18,19]). Remarks on how this capturing can be accomplished and how knowledge can be diused in the organization can only rarely be found in current literature. Authors reduce their recommendations to the demand to institutionalise project debriengs in performing a nal project analysis or a lessons learned workshop and/or providing a nal project report [2,20,21]. 2.2. Debriengs in project management practice In practice, the necessity to document and re-use project experiences was recognized likewise and is reected in numerous management statements regarding the codication of experiences in project manuals, as the following authentic examples illustrate. Gathering lessons learned is requested in the project method manual of the Swiss bank UBS (the worlds largest asset management institution) as an element of the nal project report for all types of projects with the explicit goal of knowledge transfer for future projects. These reports should include conclusions and recommendations in the sense of summarizing what can be improved in future projects. The nal project report has to be compiled by the project manager [22].

M. Schindler, M.J. Eppler / International Journal of Project Management 21 (2003) 219228

221

The PCP (Product Creation Process) manual at the Swiss technology company Schindler Elevators and Escalators as well as Roche Diagnostics project manual also demand the recording of experiences at projects end. Both manuals outline possible steps to derive lessons learned. The manual of the Swiss pharmaceutical giant Roche even outlines how to moderate a debrieng workshop. At IBM Consulting Group a project is closed by composing a nal project report (for internal use as well as for client use) with a so-called End of Engagement Summary. This form is composed during a team meeting by the project team and by the responsible engagement manager. In principle, the project methodology requires every engagement manager to ll out the forms contents, in practice, however, this is not always done. After the team meeting, customer feedback is requested by sending out another form in order to include the opinion of the client. 2.3. Reasons for project amnesia These documented requests stand in sharp contrast to the everyday practices of project managers. There, the gathering of lessons learned does not take place systematically, but predominantly via informal meetings or at the end of formally planned gatherings such as committee meetings. The fundamental problem of organisational learning in connection with project work can be found in the conicting aims between a project and the surrounding organization. While the existence of an organization is designed for the long run, a project exists only for the duration of its completion. During our action research and literature studies we identied the following reasons for project amnesia, i.e., not eliciting and documenting lessons learned, they are all related to four elements, namely time, motivation, discipline, and skills:  High time pressure towards the projects end (completion pressure, new tasks already wait for the dissolving team).  Insucient willingness for learning from mistakes of the persons involved.  Missing communication of the experiences by the involved people due to wrong modesty (with positive experiences) or the fear of negative sanctions (in case of mistakes).  Lacking knowledge of debrieng methods. Underestimation of process complexity which a systematic derivation of experiences brings along.  Lacking enforcement of the procedures in the project manuals.  Missing integration of experience recording into project processes.  Team members do not see a (personal) use of

coding experience and assume to address knowledge carriers directly as more ecient.  Diculties in co-ordinating debriengs. Persons cannot be engaged for a systematic project conclusion, since they are already involved in new projects. In those cases where a lessons learned gathering takes place, the gained knowledge is often not edited for reuse, or not accepted as valuable knowledge by others. If debriengs are conducted, there is still a certain risk that the results (i.e. the insights compiled by a project team):  are not well documented and archived,  are described too generically or are not visualized where necessary, which prevents reuse due to a lack of context (e.g. it is too dicult to understand or not specic enough for the new purposes),  are archived in a way so that others have diculties retrieving them,  are not accepted, although they are well documented and easy to locate (the so-called not invented here-syndrome). A well working project learning or debrieng process must address these problems. We will look at ways of resolving them in the following sections.

3. Debrieng methods in overview A number of concepts can be found in literature to foster learning from project experiences. They can be classied into two groups:  Process-based methods of gathering lessons learned from concluded projects  Documentation-based methods to learn from project experiences Process-based methods stress the relevant steps and their sequence in course of a projects time line while documentation-based methods focus on aspects of the contentwise representation of the experiences and the storage of contents within the organization. During our research activities we examined a set of proven approaches, which we briey describe now. 3.1. Process-based methods Well-known forms of project analysis, control and evaluation are suitable for the derivation of experiences from projects such as project reviews or project audits. These formats, however, are not going to be further described here, since their original purpose lies in performing a status analysis of a project and they have

222

M. Schindler, M.J. Eppler / International Journal of Project Management 21 (2003) 219228

been discussed already in detail in other places in traditional project management literature. Such formats are e.g. Project Review/Project Audit or Postcontrol (see Table 1 for an overview). Post-Project Appraisals and After Action Reviews are described in more detail as they are recent formats with their original purpose on recording experiences and fostering project learning. Other process-based approaches, which are in essence variations of the above techniques, are described in [9] and [11]. They are, however, often quite abstract and generic and sometimes lack specic tools to implement the proposed steps. 3.1.1. Post-Project Appraisal Post-Project Appraisal is the name of a method published by Frank A. Gulliver. It represents a special type of project review that includes a strong learning element. By the example of the mineral oil company British petTable 1 Process-based methods to learn from experiences Parameter Method Project Review/Project Audita Time of execution After project completion or in the course of the project during individual project phases Postcontrol

roleum (BP) Gulliver describes the introduction of Post-Project Appraisals in order to perform an ex post evaluation of already completed large-scale projects [23]. This is carried out by a special organizational unit called the Post-Project Appraisal Unit (PPA). A goal of such evaluations is to support world-wide learning from errors and the repetition of successes. A project-external team is selected which leads to a higher objectivity, since the team members are regarded as independent entity and have no prejudiced opinions and no interest in being an inuence factor to the results of the evaluation. The PPA examines completed projects (usually about 2 years after their completion) and analyses the entire course of the project, beginning with the project idea up to the time of the evaluation, in order to include possible late eects and positive as well as negative project results in the evaluation. After the screening of the

Post-Project Appraisal Approximately two years after project completion

After Action Review During work process

Exclusively at projects end

Carried out by Review: moderators respectively Project manager auditor

External post-project Facilitator appraisal unit (a manager and four assistants) [23], project homework group [24] Project team and third parties that are involved into the project Project team

Audit: project-external people Participants Project team and third parties Project manager (inclusion of project that are involved into the project team not neglected) Status classication, early recognition of possible hazards, team-internal focus

Purpose

Serves as delimitation/in addition to a Learning from mistakes, more formal project end that focuses knowledge transfer to on the sole improvement of future third parties projects goal conformity Best practice generation for large-scale projects, improvement of forecasts and proposals

Learning from mistakes, knowledge transfer inside the team Immediate reection of the own doings to improve future actions

Benets

Improvement of team discipline, Result is a formal document, which prevention of weak points and considers the ranges of aims of the validation of strategies [20] project, quantitative goals, milestones, check points and budget goals and contains an evaluation of the project result as well as a recommendation for future improvements [19] Face to face meetings Non-cooperative form of recording experiences, analysis of existing project status reports, milestones, checkpoints and budget targets are being compared in order to identify relevant backgrounds of dierences between estimated and actual eort

Interaction mode

Document analysis, face to-face-meetings

Cooperative team meeting

Codication

Partly in reports, usually no predened circulation with knowledge transfer as a primary goal (excluding predened distribution lists)

Partly in reports, usually no Booklets as well as predened circulation with knowledge personalized transfer as a primary goal (excluding predened distribution lists)

Flip charts

Also known as walk-throughs.

M. Schindler, M.J. Eppler / International Journal of Project Management 21 (2003) 219228

223

project documentation by the PPA, verbal interviews involving as many as possible members of the former team are conducted (on average, approximately 40 persons are questioned). Such an evaluation process requires a time investment of approximately 6 months. The resulting report is submitted to the team members for verication and afterwards passed on to the review board, before being ocially released. The reports are collected centrally after being released by the board and made available as case collections. They are updated regularly (by adding more lessons learned reports or updating existing ones) and distributed via paper-based manuals. Garvin presents an approach that is similar to the procedure illustrated by Gulliver. It describes the gathering of key experiences as a case study example of the aircraft manufacturer Boeing. In order to avoid making similar mistakes as in the development of the airplane types 737 and 747 (the development of which encountered huge problems) in later projects, a working group was formed (similar to a group in a PPA), the so-called Project Homework-Team. The team had the order to compare project processes of the machines of the 737 and the 747 with those of the types 707 and 727 (two very successful development projects). The team prepared an experience report of the two rst projects and presented a book with appropriate recommendations. Some members of the Homework-Team were then moved into the project teams of the 757- and 767-development. Due to this procedure, the most successful and error free market launches could be accomplished in the history of Boeing [24]. 3.1.2. After Action Review Another action oriented approach that was originally developed by the US Army and that is being used by BP is called After Action Review (AAR) [13,25]. It was conceived for soldiers in crisis periods during and after missions, where a complete mission evaluation is not possible. AAR help to learn immediately from errors and successes. There are various formats for After Action Reviews, ranging from a 20-min brainstorming to a 2-h discussion session. In an AAR a team is confronted with four main questions. They are:     What was supposed to happen? What actually happened? Why were there dierences? What can you learn from this experience?

method is used by the Swiss subsidiary of the German industrial group Siemens. The same four questions must be answered by every project manager who has completed a development project. In addition, he or she must state what should be done dierently in future development projects (and by whom). 3.2. Documentation-based methods After having presented dierent formats for gathering experiences from a process perspective, we now present three methods of how to prepare and structure the content of project lessons learned. They are:  Micro Articles  Learning Histories  RECALL The emphasis of these methods is on the contentwise organization of experiences which have been gathered. 3.2.1. Micro Articles Sociologist Helmut Willke proposes the use of so called Micro Articles to secure experiences after completion of a project [26]. The process of making the experiences explicit takes placein analogy to scientic or journalistic publicationsvia the authoring of small articles. The scope of a Micro Article is usually limited to half a page. It is written in an informal style, yet it can quote other related micro-articles. An important element for the use of such an article is the transport of the respective learning context, without which the article would be of limited value for a reader who has not been involved in a particular project. The framework of a Micro Article consists of a topic, an introductory short description of its contents and a keyword part for indexing the article. The author recommends the use of illustrations to support the individual learning processes. For distribution, Willke suggests the storage of such Micro Articles in databases and providing them via a companys intranet. He also recommends the substitution of pure textual contents by using multimedia objects, for instance video clips. The main idea behind the micro article, that contrasts the methods presented so far, is that project experiences must be recorded in authentic, and yet entertaining manner, hence the magazine article style emerges as one possible format. In terms of their scope (compared to the Learning Histories of the next section), the Micro Article is a light-weight approach towards debrieng, whereas Learning Histories represent a rather heavy-weight concept. Another light-weight debrieng method that is similar to the Micro Articlecomes from the domain of software development and is called the LIDs approach (LID stands for Light-weight Documentation of Experiences) [27].

Team learning, building trust and team integrity are crucial goals of the process. BP took over the informal version for itself and stresses the necessity for a prompt execution. The learning points are being captured on a ip chart, which is referred to on relevant occasions, e.g. before or during similar situations. Another company which has adopted this quick-and-dirty debrieng

224

M. Schindler, M.J. Eppler / International Journal of Project Management 21 (2003) 219228

3.2.2. Learning Histories A research team of the Learning History Research Project of the Sloan School of Management at the Massachusetts Institute of Technology (MIT) was concerned with the development of a tool to record teamreferred experiences for organisational learning [28]. The resulting methodology, the Learning History, is a written story consisting of the main events of a project arranged in a chronological order. The resulting document can be anywhere between twenty and one hundred pages following a storytelling approach to make the recorded experiences more appealing and rich of context. By describing relevant experiences from the view of the involved individuals via direct literal quotations, project historians try to address the weaknesses of conventional codication approaches that are hardly able to express tacit knowledge elements (e.g. about cultural/political boundaries inside the team) or simply ignore their existence and relevance. The page layout of such a Learning History usually consists of two columns. Interview participants are quoted in the right column. The left column contains comments made by the Learning Historians who provide more context or remarks, especially with regard to tacit elements (e.g. by interlinking statements or describing impressions on an interviewees face). Between the columns there are additional comments explaining relevant project details. Boxes between text blocks contain summary information. The interview partners are quoted directly and are made anonymous as far as possible (this makes it easier to admit errors). The interviewees are identied via their role labels for the reader (e.g. project manager). Once compiled, learning histories are validated in discussions with the people involved. The following distribution of the compiled Learning Histories takes place exclusively via accompanying workshops [28] or group discussions where the contents are discussed and applied to related problems. 3.2.3. RECALL An approach using a database front end to collect lessons learned is used in the lessons learned program of the National Aviation and Space Agency NASA [29]. Users of the RECALL prototype can submit their lessons learned directly using an Internet browser. The main idea of the concept is to facilitate and automate the capture and retrieval of lessons learned. A check list with guiding questions helps the individual to decide whether one is passing on a noteworthy lesson or not (such questions relate to the potential application scope and the validity of the recorded lesson). Lessons are submitted to the database via a lessons learned submittal form that show a framework for describing a project scenario. Afterwards, the user is asked to answer a set of questions to the system in order

to add relevant context information. This meta-information enables others to nd the right learnings later on according to their needs or problems. 3.3. Summary Tables 1 and 2 contain a comparative overview on the methods discussed so far. After this overview of methods on how to record experiences we examine the key success factors that are inherent in these approaches, as well as their shortcomings.

4. Key success factors of project learning 4.1. From single review to continuous project learning As already mentioned, the gathering of experiences is regularly demanded in practice and in literature to be done at the projects end. In this article, we stress the necessity for continuous project learning through regular reviews. In co-operation with the companies involved in the accompanying action research a regular gathering of key experiences was judged as most relevant, having a positive impact on both the motivation of the team (who could directly prot from the lessons learned) and on the quality of the gathered insights. There are several other advantages to a periodic reviewing during a projects progress:  The events are more recent and the subsequent learnings can be recalled more easily. A continuous gathering of experiences is especially meaningful with projects with a long life cycle, where the danger exists that procedural knowledge could be forgotten due to a large time delay.  A gradual derivation of experiences during the course of a project reduces expenditures of the parties involved that occur at the project end compared with a unique quasi cumulated gathering.  It is easier to assemble the entire team during the projects course than once the project is terminated and the team recongured. Particularly, the problem of the availability of outsiders (e.g. management consultants) can be avoided. In our action research we observed that the participation of such experts was rejected at the projects end due to cost reasons. If the gathering of experiences is already done during the course of the project, such cost arguments are not as pressing. Apart from the question when lessons learned should be gathered, there is also the question, who is to be involved. This question is addressed in the next section.

M. Schindler, M.J. Eppler / International Journal of Project Management 21 (2003) 219228 Table 2 Documentation orientated methods to learn from experiences Parameter Method Micro Article Scope IT-support Participants Supported by dedicated roles Frequency Anonymity Embedding/ distribution Between half and one page Possible but not required, unless multimedia is used Not explicitly stated, focus on one author Author, reviewer On demand, regularly No Paper-based, databases/intranet Learning Histories Between 20 and 100 pages Not required Individuals and teams depending on the process step Learning historian necessary for all process steps Maximum once per project: after completion Yes Cases with accompanying workshops RECALL

225

Several screens Mandatory (database interface) Individual user Working group for reviewing On demand No Databases/intranet

4.2. New project roles and tasks From the remarks made above the need for new roles for project knowledge management should have become obvious. One role that is of central importance for the project learning process is the role of the debriefer. The debriefer acts as a facilitator who manages the debriefing process (i.e. the workshop preparation, the workshop itself, and its documentation) [30]. Apart from the development and supply of suitable tools, he or she takes the position of an independent, neutral moderator who promotes the dialogue in a collective team debriefing and asks provocative questions in order to identify critical key learnings. He or she is responsible for the lasting eect of the recorded experiences. In case of single debriengs by use of Information and Communication Technologiese.g. as shown with RECALL or via a lessons learned inventory [27,31,32]he or she is responsible for the validation of the context information and for the cross-references to other related lessons leaned. The debriefer takes the role of a facilitator both during and after the actual debrieng workshop. The role can be found in the AAR at BP whose task it is to help the team to learn and to be a guide to point to relevant sensitive issues. It is obvious, that the debriefer needs to have strong facilitation skills. Meredith and Mantel discuss the dilemma when selecting between internal and external debriefers: If the auditor/evaluator is an outsideranyone who cannot be identied as a project team memberthere is the fear that we wont be understood. . . If the auditor/ evaluator is an insider fear focuses on the possibility that the insider has some hidden agenda, is seeking some personal advantage at the expense of the rest of us. [19]. The tables presented earlier illustrate the relatively broad consensus that an external moderator has numerous advantages. We come to similar results based on our comparison of 12 debrieng workshops held with action research partner companies. During our action research we found that reservations outweigh

the possible benets of an internal debriefer. Therefore, it appears important that an external debriefer has access to project-relevant documents, in order to be able to prepare as intensively as possible for any debrieng meetings. 4.3. Institutionalising the lessons learned process Throughout this article, it was argued that project learning is too important to be left to chance or to the initiative of motivated individuals. As stated in [12] learning,. . . has to be managed together with the project and must be integrated into project management as standard practice. The question that remains to be answered is how this can be achieved consistently. As mentioned earlier, discipline is one of the key ingredients of successful project learning. Discipline can be fostered through three ways. First, by enforcing project debriengs in all relevant project guidelines and policies. Second, by training or educating project members about the importance of systematic debriengs. And third, by encouraging project managers to lead by example and make project debriengs a strategic priority. The rst measure, including debrieng steps in relevant project guidelines, consists of two elements, namely:  the integration of learning and knowledge goals into the project phase model of a company, and  the integration of learning and knowledge goals into the overall project goals and metrics. These two elements help to balance the fundamental conict between the time pressure of most projects, and the necessary reection period for systematic project learning. 4.3.1. Integration of learning and knowledge goals into project phase models The demand for the integration of learning and knowledge goals into project phase models to anchor

226

M. Schindler, M.J. Eppler / International Journal of Project Management 21 (2003) 219228

learning into the enterprise processes is based on the following reasons:  Adding knowledge goals to every project step can foster systematic reection about every milestone in a project.  In order to overcome the natural urge of classifying project learning as low prioritywhich is often justied by the subjectively felt symptom of time pressure.  A higher degree of formalizing can lead to a more binding character of lessons learned. Examples of such knowledge goals are the production of a team glossary and team (communication and working) rules, a milestone plan or the documentation of a stakeholder analysis at the beginning of a project to adjust of the project goals to the stakeholders expectations. Such a documentation can be achieved by the extension of so-called gates that work as decision points in the course of a project. A gate serves as a point of decision to examine predened time, cost and/or output targets. It follows the trac light conventions. Red meaning target(s) not reached, operations need to be abandoned, yellow designating goals that are at risk, and green designating goals that have been reached. This procedure was identied as meaningful for the implementation of measures in our action research process. The gate structure represented in Fig. 1 illustrates this procedure on the basis of a truck development project.

The completion of the goals is examined by the owner of the project (usually a senior manager or the head of the project committee) and the project manager. The integration of learning goals should happen on the basis of their impact. For crucial knowledge goals, the integration within existing gates is recommended (for example the goal to transfer new knowledge to team members abroad). In case of less important knowledge goals, the use of (smaller) milestones seems more appropriate (e.g. for the lessons learned in cooperation with suppliers), since other managers do not have to be involved. In such a phase model cost and output targets are being enhanced by knowledge and learning goals as depicted in Fig. 1. The integration of learning goals into project processes leads to the represented course of project structures as shown in Fig. 1. The knowledge and learning goals become a xed component of the goals which have to be achieved. Nevertheless, it its important to keep the codication eort at a reasonable level (e.g. not more than one day per milestone). Otherwise, too many forms, checklists or other bureaucratic checkpoints can destroy the motivation of a project team to gather and document lessons learned (see also [33] for the issue of fostering the motivation to learn). 4.3.2. Integration of learning and knowledge goals into project goals While the implementation of learning and knowledge goals into the project phase models of a company is a way to implement learning on a micro level, an adjustment of

Fig. 1. Modied gate concept (example).

M. Schindler, M.J. Eppler / International Journal of Project Management 21 (2003) 219228

227

the projects goals concerns the project result on a macro level. Before the implementation of a project, client and contractors agree on the goals of the project (the overall goal as well as partial operational goals in sense of a hierarchy of objectives). From a traditional point of view, such goals are at the centre of attention, as for example the development of a certain product or the contribution of a service. Here, one has to view the projects outcome not only in terms of its physical or tangible results, but also as a contribution to the companys knowledge base. Every project should therefore have two distinct goalsto successfully develop the product and to advance the learning of the organization. [7] The change is closely coupled to the consciousness-shaping that projects have eects on the capabilities of the enterprise as a whole.

nding an appropriate time slot for all participants and ensuring a proper documentation. However, if the gathering of crucial project experiences is done on a regular basis, these administrative diculties should disappear quite soon. A permanent, conscious and systematic gathering, analysis and communication of project experiences requires an adjustment of the role understanding of project teams, as well as reconsidering the nal reports and their main functions.

References
[1] Damm D, Schindler M. Security aspects of an enterprise knowledge medium for distributed project work. International Journal of Project Management 2002;20(1):3747. [2] Smith B, Dodds B. Developing managers in the project-orientated organization. Journal of European Industrial Training 1997;21(5):16570. [3] Lundin RA, Midler C. Emerging convergences or debates. In: Lundin RA, Midler C, editors. Projects as arenas for renewal and learning processes. Boston: Kluwer Academic Publishers; 1998. p. 23141. [4] Dickens L, Watkins K. Action research: rethinking Lewin. Management Learning 1999;2(30):12740. [5] Argyris C. On organizational learning. Cambridge, Oxford: Blackwell Publishers; 1999. [6] Kanter RM. When a thousand owers bloom: structural, collective, and social conditions for innovation in organizations. In: Myers PS, editor. Knowledge management and organizational design. Boston: Butterworth-Heinemann; 1996. p. 93131. [7] Bowen HK, Clark KB, Holloway CA, Wheelwright SC. The perceptual enterprise machineseven keys to corporate renewal through successful product and process development. New York: Oxford University Press; 1994. [8] Ryle G. The conception of mind. London: Hutchinson; 1949. [9] Williams T, Eden C, Ackermann F, Howick S. The use of project post-mortems. PMI 2001, Project Management Institute Annual Symposium, Nashville, Tennessee USA, November; 2001. [10] Nevison JM. What can we learn about learning on projects? PMNetwork 1994;8(6):68. [11] Collier B, DeMarco T, Fearey P. A dened process for project postmortem review. IEEE Software 1996;13(4):6572. [12] Ayas K. Professional project management: a shift towards learning and a knowledge creating structure. International Journal of Project Management 1996;14(3):1316. [13] Collison C, Parcell G. Learning to ypractical lessons from one of the worlds leading knowledge companies. Oxford: Capstone Publishing; 2001. [14] Schindler M. Wissensmanagement in der Projektabwicklung Grundlagen, Determinanten und Gestaltungsempfehlungen eines ganzheitlichen Projektwissensmanagements. Lohmar/Koln: Josef Eul Verlag; 2002. [15] McMasters G. Can we learn from project histories? PMNetwork 2000;14(7):667. [16] PMBOK. A guide to the project management body of knowledge2000 edition. Newtown Square, Pennsylvania: Project Management Institute; 2000. [17] Kerth N. The ritual of retrospectiveshow to maximize group learning by understanding past projects. Software Testing & Quality Engineering 2000;2(5):537. [18] Cleland DI. Project managementstrategic design and implementation. New York: McGraw-Hill; 1994.

5. Conclusions The management of project insights requires signicant improvements with regard to the format, process, and use of lessons learned. Various formats, process steps, and usage scenarios exist that can enable project-centred learning in a company. Without the managements leadership, however, these methods remain ineective. Prerequisites for systematic project learning include discipline, motivation, debrieng skills and know-how about adequate documentation formats. The following points can be summarized as key success factors to gain lessons learned in debrieng workshops. They have been identied by the authors as a result of over a dozen project debrieng workshops:  Regularly capture the most important project experiences directly after important milestones with the entire project team.  Have an external, neutral moderator of the debrieng workshop (not to be done by project managers or other team members).  Perform the lessons learned gathering graphically, e.g. collecting and structuring the project experiences along a time line (e.g. as a process map with mistakes, successes, insights etc.) and provide a workshop documentation in a poster format visible for all sta involved.  Ensure a collective, interactive evaluation and analysis of experiences made by individual team members.  Strive to gain a commitment in the sense of action consequences from the gathered insights (consider possible forms of implementation and who should be responsible for them). The most frequent problems, which arose in such workshops, were administrative ones, in particular

228

M. Schindler, M.J. Eppler / International Journal of Project Management 21 (2003) 219228 [27] Schneider K. LIDs: a light-weight approach to experience elicitation and reuse. In: Bomarius F, Oivo M, editors. Proceedings of the Profes 2000 Conference. Oulu, Finland: Springer; 2000. p. 40724. [28] Roth G, Kleiner A. Developing organizational memory through learning histories. Organizational Dynamics 1998;2(27):4360. [29] Sary C, Mackey W, Bagg T, Mayer S. RECALL prototype lessons learned writing guide. NASA Goddard Space Flight Center, Greenbelt, 1995. Available: http://hope.gsfc.nasa.gov/RECALL/ homepg/recall.htm [accessed: 31 May 1999]. [30] Senge PM, Kleiner A, Roberts C, Ross RB, Smith BJ. The fth discipline eldbookstrategies and tools for building a learning organization. London: Nicholas Brealey Publishing; 1995. [31] Eppler MJ, Sukowski O. Managing team knowledge: core processes, tools and enabbling factors. European Management Journal 2000;18(3):33441. [32] van Heijst G, van der Spek R, Kruizinga E. The lessons learned cycle. In: Borgho UM, Pareschi R, editors. Information technology for knowledge management. Berlin: Springer-Verlag; 1998. p. 1734. [33] Revans R. The ABC of action learning. London: Lemos & Crane; 1998.

[19] Meredith JR, Mantel SJ. Project managementa managerial approach. New York: John Wiley & Sons; 1995. [20] Rosenau MD. Successful project management. New York: John Wiley & Sons; 1998. [21] Lammers IS, van Eijnatten FM. Improving the management of knowledge in an automation department of a Dutch bank. In: Schreinemakers JF, editor. Knowledge management: organization competence and methodology. Wurzburg: Ergon; 1996. p. 3549. [22] Anonymous. ProjektmanagementGuidebook fur den Unter nehmensbereich Privat- und Firmenkunden sowie fur das Cor porate Center. Internal document of UBS AG. Zurich; 1999. [23] Gulliver FR. Post-project appraisals pay. Harvard Business Review 1987;65(2):12832. [24] Garvin DA. Building a learning organization. Harvard Business Review 1993;71(4):7891. [25] Roth G, Brown FJ, Cosby N, Madden JL. A World-class reective practice eld. In: Senge P, Kleiner A, Roberts C, Ross R, Roth G, Smith B, editors. The dance of changethe challenge of sustaining momentum in learning organizations. London/Naperville: Nicholas Brealey Publishing; 1999. p. 4707. [26] Willke H. Systemisches Wissensmanagement. Stuttgart: Lucius & Lucius Verlagsgesellschaft; 1998.