Organizational learning through post–project reviews in R&D

Abstract

Post-project reviews are one opportunity to systematically improve performance in subsequent projects. However, a survey reveals that only one out of five R&D projects receives a post-project review. Postproject reviews -if they take place -are typically constrained by lack of time and attention as well as lack of personal interest and ability. They focus mostly on technical output and bureaucratic measurements; process-related factors such as project management are rarely discussed.In this paper we review the role of post-project meetings as a tool to improve organizational learning at the group level. Based on 27 in-depth interviews with R&D managers carried out between 1997 and 2001, we categorize four classes of learning impediments. These difficulties are not easily resolved, as is illustrated by examples from Hewlett-Packard, DaimlerChrysler, SAP, Unisys, the US Army, and others. We propose a five-level post-project review capability maturity model, identifying some of the key capabilities that need to be in place in order to advance to the next process maturity level. Most companies reside on the first or second maturity level. Our conclusion is that many companies give away great potential for competence building by neglecting post-project reviews as a tool for systematic interproject learning.

A fuzzy methodology for innovation management measurement

“…This area measures the intensity with which a company launches its products to the market (Calantone and Benedetto, 1988;Globe et al, 1973), i.e., market research, testing and development adapted to a systematic marketing program (Griffin and Page, 1993). It additionally measures the way firms reach the consumer, formal post-sale operations (Atuahene-Gima, 1995;von Zedtwitz, 2002) and technology and marketing synergy, which has been empirically demonstrated to have an influence on product performance (Huang and Tsai, 2014).…”

Function of Project Manager and Officer

“…The project manager frequently reviews the general progress of the work that constantly put input towards successfully complete the project [11]. Regular meeting overcome communication problems.…”

On the Process of Software Design: Sources of Complexity and Reasons for Muddling through

“…The long loop represents this crucial but often unmanaged flow of experiences, solutions, and other knowledge from individual projects back to the organization for reuse in other projects. Zedtwitz [37] reports that 80% of projects are not reviewed after completion or cancellation to systematically and regularly make acquired project knowledge available for organizational learning. Further, in the design documentation made during projects designers are likely to make extensive use of condensed writing, which leaves most of the context unsaid because the documentation will be understood by its primary readersusually other project members -as belonging to a certain ongoing activity.…”

“…Projects are ubiquitous in software design, indicating that organized collaboration is biased toward the short loop whereas collaboration across projects tends to be informal [35,37]. This is clearly illustrated by the browserinterface and common-platform projects.…”