See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/258517486

Development of a Methodology for Lessons Learned Practice : From post-

project learning to continuous process-based learning

Thesis · November 2013

CITATIONS READS

5 3,315

1 author:

Koteshwar Chirumalla
Mälardalen University
56 PUBLICATIONS 441 CITATIONS

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Special Issue "The Role of Digitalization and Industry 4.0 Technologies for Product and Production Development in the Manufacturing Industry" View project

Husmuttern Social innovation View project

All content following this page was uploaded by Koteshwar Chirumalla on 28 May 2014.

The user has requested enhancement of the downloaded file.

 DOC TOR A L T H E S I S

Department of Business Administration, Technology and Social Sciences

Division of Innovation and Design

Koteshwar Chirumalla Development of a Methodology for Lessons Learned Practice

ISSN: 1402-1544
Development of a Methodology for
ISBN 978-91-7439-781-9 (print)
ISBN 978-91-7439-782-6 (pdf) Lessons Learned Practice
Luleå University of Technology 2013
From post-project learning to
continuous process-based learning

Koteshwar Chirumalla
Development of a Methodology for
Lessons Learned Practice
From post-project learning to
continuous process-based learning

Koteshwar Chirumalla

Product Innovation
Luleå University of Technology
© 2013 Koteshwar Chirumalla
Product Innovation
Division of Innovation and Design
Department of Business Administration, Technology and Social Sciences
Luleå University of Technology (LTU)
SE-971 87 Luleå
SWEDEN
www.ltu.se

Printed by Universitetstryckeriet, LTU 2013

Doctoral Thesis 2013

ISSN: 1402-1544
ISBN 978-91-7439-781-9 (print)
ISBN 978-91-7439-782-6 (pdf)

Luleå 2013

ii
 To my family
Kalyani, Kruthi, Mohan, Sarojana, Devika and others
for their unconditional love, care and support!

iii
 Acknowledgments
I have spent four long years on this wonderful research journey, hoping to contribute in some way to
both science and society. This journey has been a highly stimulating and challenging experience for
me. I still remember the first few months of my PhD when I was really struggling about how to plan
my research, how to write a research paper and so on. So, I am happy to see myself reach this point
where I can proudly present and disseminate my four years work in these 100 pages. This whole
process would not have been possible without support from many nice people.
Initially, I would like to begin by conveying my sincere gratitude to my supervisor Dr. Christian
Johansson, who has motivated and guided me throughout the entire process of writing this thesis.
Thanks Christian for your patience to listen and understand all my ideas, thoughts and arguments in
the last six months. I really enjoyed the long constructive discussions we had in this long reflective
process.
I would also like to express my heartfelt gratitude to my former supervisor Dr. Marco Bertoni,
who has taught me about the research world ever since I began my PhD. Your continuous
encouragement, feedback and critiques really helped me to grow as a person as well as a researcher.
Thanks for all your kind efforts at the beginning of my PhD for making me feel comfortable in Luleå.
I wish to express my sincere appreciation to my main supervisor Dr. Åsa Ericson, who has
provided valuable inputs whenever required. I really appreciated all your talks and inputs on the
research methodology.
I would like to extend my sincere appreciation to my industrial contact person Dr. Ola Isaksson,
who has been so patient in arranging the meetings and interviews with key informants from the
industry. Thank you for providing the industrial perspectives in many inspiring talks and discussions
all these years. I would also like to extend my sincere appreciation to Dr. Petter Andersson, Mats
Lindeblad, Johanna Wallin and Stefan Jansson for interesting discussions within my research area.
I would like to express my special thanks to Dr. Vinit Parida, who was always there for me when I
needed support. Thanks for all your useful feedback on the writing process and other useful tips in
writing applications.
I would also like to thank the rest of my colleagues: Dr. Peter Törlind, Dr. Henrik Nergård,
Alessandro Bertoni, Johan Holmqvist and Johan Wenngren. Thank you Peter for all the
administrative support and for providing two amazing winter experiences, thanks Henrik for good
discussions on our research area, thanks Alessandro for all the interesting lunch talks, thanks to both
Johan’s for helping me out with all the problems in the daily work.
I would like to thank my former colleagues and supervisors Dr. Andreas Larsson and Dr. Tobias
Larsson for their support during initial stages of my PhD. Thanks a lot for your inspiring talks on the
research subject. I was always glad to listen to your talks, which always stocked up the energy levels
with many useful insights. I would also like to extend my thanks to Åsa Kastensson for all friendly
talks during these years.
Big thanks are also due to Vinnova for the financial support, and to the companies that provided
me the opportunities to conduct research through industrial case studies. I would also like to convey
my gratitude to all my interview respondents from the case companies. Special thanks go to PIEp and
ProViking research schools for supporting me in the research education.
Last but not least, my deepest appreciation and thanks go to all of my family and friends, especially
my parents Mohan and Sarojana, my lovely wife Kalyani, my beloved aunt Devika Bobbishetty and
my family friends Gunilla Lindgren and Sune Lindgren. Kalyani, thank you so much for your endless
support and care all these years as well as giving me confidence in the difficult times. Together with
our little princess Kruthi, these last nine months have been so special for us. Sadly, I could not spend
much time with both of you in the last two months, I hope I can pay you guys back in the coming
months.

Luleå, November 2013.

Koteshwar Chirumalla

v
 Abstract
Product development involves a set of complex problem-solving activities. Their
effectiveness depends on how well companies share learnings from one problem-solving
experience to another. “Lessons learned (LL) practices” are common knowledge management
efforts through which companies attempt to foster experience-based learning environments
within them. However, many companies fall short in utilizing LL at an action level—which
is, capturing and sharing lessons learned and applying them in new situations is still difficult.

This thesis is largely based upon qualitative data collected in three case studies that had two
main objectives. Firstly, to investigate the current state of LL practice in order to identify
potential barriers in the light of emerging product development trends. Secondly, to identify
ways to improve current practices from both capture and reuse perspectives.

The case studies showed that effective LL practice requires a continuous approach with a
standard format that should be applicable not only to capture lessons from design projects, but
also from manufacturing, use, and maintenance phases, where much of the learning is still
tacit in nature and difficult to articulate. From a reuse perspective, current project-specific
lessons lack contextual knowledge related to learning—that is, the lessons’ background, root-
causes, and applicability—thereby demanding a method to capture LL at a process-based level
with a richer context. In total, the research work identifies 11 functional requirements for
improving LL processes based on the outlined potential barriers in as-is practice.

Based on the functional requirements analysis, a methodology has been developed for
representing LL in a standardized format together with guidelines, using videos and
storytelling as enabling media. This methodology includes a seven-step representation of LL,
consisting of: (1) lessons learned statement, (2) working context, (3) task description, (4)
“what went wrong” or “what went well”, (5) lessons learned, (6) lessons learned measures,
and (7) applicability and delimitations.

Preliminary validation activities revealed that the methodology facilitates the preparation and
formulation of concise LL with richer context than traditional text-based formats. The
methodology has proved to be beneficial in capturing lessons from skill-oriented activities in
a narrative form, by visually displaying defects, problems or improvements in complex
products and associated actions in production or maintenance phases, for instance. Thus, a
video-based LL captures a single learning point with more specific details and actionable
recommendations than traditional post-project text-based approaches, thereby enabling
process-based learning. Moreover, the reuse of video-based LL was found to facilitate the
execution of new design tasks by increasing users’ contextual awareness, thus enabling them
to select possible solutions and apply them in new design situations relatively quickly. The
methodology has potential advantages in leveraging experience-based knowledge and
learning in early product development phases to avoid reinventing the wheel, and repeating
potentially costly mistakes in all relevant company environments.

Keywords: Lessons learned, knowledge management, knowledge reuse, Web 2.0,

storytelling, process-based learning, video sharing, engineering design.

vii
 Appended Papers

This thesis comprises an introductory part and the following appended papers:

Paper A
Bertoni, M. and Chirumalla, K. (2011). Leveraging Web 2.0 in New Product
Development: Lessons Learned from a Cross-company Study. Journal of Universal
Computer Science, Vol. 17, no. 4, pp. 548-564.

Paper B
Bertoni, M., Chirumalla, K., and Johansson, C. (2012), Social Technologies for Cross-
functional Product Development: SWOT Analysis and Implications, In: Proceedings of 45th
Hawaii International Conference on System Sciences (HICSS-45), 4-7 January, Grand Wailea,
Maui, Hawaii.

Paper C
Chirumalla, K. (2013), Managing Knowledge for Product-Service System Innovation:
The role of Web 2.0 Technologies, Research-Technology Management Journal, Vol. 56, no.2,
March-April 2013, pp. 45-53.

Paper D
Chirumalla, K., Johansson, C., Bertoni, M. and Isaksson, O. (2012), Capturing and
Sharing Lessons Learned across Boundaries: A Video-based Approach, In: Proceedings of
20th European Conference on Information Systems (ECIS’12), 10-13 June, Barcelona, Spain,
Paper 236, AIS Electronic Library (AISeL).

Paper E
Chirumalla, K., Bertoni, M., and Johansson, C. (2013). Experience Feedback using
Social Media: From the Product Lifecycle Phases to the Design Practices. In: Proceedings of
5th CIRP International Conference on Industrial Product-Service Systems (IPS2): Product-Service
Integration for Sustainable Solutions, ed. H. Meier, pp. 459-471, Heidelberg, Germany:
Springer-Verlag.

ix
 Additional Publications
The following papers are related to the thesis, but not included:

Bertoni, M., Larsson, A., Ericsson, Å., Chirumalla, K., Larsson, T., Isaksson, O. and
Randall, D. (2012). The Rise of Social Product Development, International Journal of
Networking and Virtual Organisations (IJNVO), vol. 11, no. 2, pp. 188-207.

Chirumalla, K., Larsson, A., Bertoni, M., and Larsson, T. (2011). Knowledge Sharing
Across Boundaries: Web 2.0 and Product-Service System Development. In Proceedings of
3rd International Conference on Research into Design (ICoRD): Research into Design-Supporting
Sustainable Product Development. ed. A. Chakrabarti, pp. 360-367, Bangalore, India.

Bertoni, M. and Chirumalla, K. (2010). Engineering 2.0: Leveraging a Bottom-up and

Lightweight Knowledge Sharing Approach in Cross-functional Product Development
Teams. In: Proceedings of 10th International Conference on Knowledge Management and
Knowledge Technologies (I-KNOW), September 1-3, Graz, Austria, pp. 105-116.

Chirumalla, K., Bertoni, M., and Larsson, A. (2010). Exploring Lightweight

Knowledge Sharing Technologies for Functional Product Development. In: Proceedings of
2nd CIRP International Conference on Industrial Product Service Systems (IPS2), 14-15 April,
Linköping, Sweden, 2010, pp. 347-354.

Chirumalla, K., Bertoni, A., Ericsson, Å. and Isaksson, O., (2012). Knowledge Sharing
Network for Product-Service System Development: Is it Atypical?, In: Proceedings of 4th
CIRP International Conference on Industrial Product-Service Systems (IPS2): The Philosopher’s
Stone for Sustainability. Eds., Shimomura, Y. and Kimita, K., pp. 109-114, Tokyo, Japan:
Springer Berlin Heidelberg.

Wallin, J., Chirumalla, K., and Isaksson, O. (2013). Enabling Organizational Changes
for Development of Product-service System Offers. In: Proceedings of 19th International
Conference on Engineering Design (ICED), Seoul, South Korea, 19-22 August 2013.

Chirumalla, K., Bertoni, A., Parida, A., Johansson, C. and Bertoni, M. (2013).
Performance Measurement Framework for Product-Service System Development: A
Balanced Scorecard Approach. Accepted to the International Journal of Technology Intelligence
and Planning, October 2013.

xi
 Table of Contents



 




 





 





 




  

!

!
  
 

!



 

"





#



 

$

*&*&)
 !%
)
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
1

*&*&*
 !%
*
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
1

*&*&+
 !%
+
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
)(



 





  



*&,&)
 "#
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
))

*&,&*
!
!

 
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
)*

*&,&+
!"%
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
)+

*&,&,
" 
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
)+

*&,&-

$ 
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
)+

!

  

!

"

 

"




  

$


 
  


  

%


 
 




 

 




 
 



!



"

"
 
 

%

#
 



$
 




%







 
  

!


 

 


"





#





$





%







!






 

 
 
    

   
   


!
 

 


  
  



!
 


 

!

-&*&)
 !
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
,.

-&*&*
 
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
,/

-&*&+

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
,0

-&*&,

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
,1

-&*&-

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
-(

-&*&.
!
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
-)

!
   

 
  

!

xiii






!
   


 

 
 
 



"
 
 
 
  

!!

"
  



 

"

.&*&)





 
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
.)

.&*&*
  %


"'


 !
 
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
.)

"
 
  

!

#
  
   

"!

/&)&)
 %
$
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
.-

/&)&*
! 
$
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
./

/&)&+

$
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
/)

#
    

"

$
 

 
  

#$

$



#

%
   


$

%
   


$


 

#


  

$

xiv
 Introduction

1 Introduction
This chapter starts with a background section describing my area of investigation, then presents a
more detailed discussion of the research problem. These sections together provide the basis to formulate
the research question.

1.1 Background

The product design process is typically viewed as a bundle of interdependent human

problem-solving activities (Thomke and Fujimoto, 2000; Ullman, 2002). As products are
becoming increasingly complex, design efforts require an increasingly wide range of skills,
knowledge, and expertise, as well as flexible resources, which are difficult to find within a
single company (Acha et al., 2004). Thus, manufacturing companies are increasingly
moving towards strategic alliances (Hamel, 1991) with customers, suppliers, research
centers, and even competitors to develop radically new product solutions or simply to
incrementally improve existing products. A recent survey of 315 European manufacturing
industries found that around 20% have more than 30 external design partners and 34%
have more than 30 external manufacturing partners, and among these 15% have design
units and 30% manufacturing facilities based in more than 10 countries (Economist
Intelligence Unit, 2007).

Moreover, in recent years many manufacturing companies have been trying to remodel
themselves as service providers (Clayton et al., 2011; Oliva and Kallenberg, 2003),
exploring the possibility of moving beyond ‘traditional’ product-centered offerings to
deliver integrated product and service combinations that can provide unique customer
value (Baines et al., 2007), and to generate significant revenues from the aftermarket
(Ward and Graves, 2007; Wise and Baumgartner, 1999). For example, aircraft engine
manufacturer Rolls-Royce’s service revenue now represents more than 50% of group
sales and the company has increased its revenues from aftermarket services by 60% over
the past five years (Smith, 2013). In academia, researchers often refer to this new mode of
business offerings as Product-Service Systems or “PSS” (Mont, 2002), describing a shift in
manufacturers’ strategic focus from selling a physical product to selling its performance or
availability (Baines et al., 2007; Tukker and Tischner, 2006). In such cases customers pay
only for the provision of usage of a product and the manufacturer retains ownership of it
and is responsible for servicing and maintaining it throughout its entire lifecycle.

The focus on product design from a lifecycle perspective radically changes the scope and
objectives of design activities (Harrison, 2006), obliging designers to confront challenges
in order to find solutions based on a deep understanding of customers’ needs rather than
developing products based on physical characteristics (Ericson, 2007). This affects the way
new products are conceptualized and designed in the early phases (Harrison, 2006). It has
been acknowledged that approximately 75% of product development costs are dependent
on decisions made in the first 25% of development efforts (Ullman, 2002). So, in a new

1
 Introduction
situation, a design team must carefully determine and balance the properties governing a
product’s behavior across its entire lifecycle (Morelli, 2003; Isaksson et al., 2009),
including manufacturing, use, maintenance, and end-of-life treatment. This requires
integration of an extended set of competencies and capabilities beyond the “traditional”
product development domains (Isaksson et al., 2009).

Consequently, the availability of downstream knowledge, i.e. knowledge from the “in-
service” experience of existing products, is becoming crucial in early design phases (Goh
and McMahon, 2009; Wong et al., 2008) in order to tackle “in-service” issues through
design and improve early-stage decision-making (Jagtap and Johnson, 2011). This new
scenario calls for methods and tools that enable development teams to continuously
capture and share experiential knowledge, know-how and lessons learned (LL) beyond
geographical, functional and organizational boundaries (Larsson et al., 2008). Thus,
knowledge sharing and management practices have become critical activities to enable
organizations to consistently learn from experience and employ experiential lessons in the
development of future products (e.g., Ericson et al., 2005; McMahon et al., 2004;
Vianello, 2011; Wong et al., 2008).

Lessons learned practices are common knowledge management efforts through which
companies attempt to accelerate learning from experience and bridge the gap between
standard processes and the reality of tasks (Bergmann, 2002; Milton, 2010). Thomke and
Fujimoto (2000) proposed project-to-project knowledge transfer as a potential way to improve
“front-loading” of problem-solving related to product development, involving the
effective transfer of problem- and solution-specific knowledge and experiences between
development projects to avoid “re-inventing the wheel”. Similarly, Verganti (1997) noted
that systemic learning from past experience is the real keystone for effective management
of the early phases of product development processes. A number of concepts can be found
in literature to foster learning from past experiences, including post-project reviews, after
action reviews, project milestone reviews, postmortems, reflection, project debriefings,
project histories, closeout meetings, project evaluation, and project audits (Disterer, 2002;
Schindler and Eppler, 2003; Williams, 2008).

Several researchers (e.g., Kotnour, 1999; Milton, 2008; Zedtwitz, 2002) regarded LL
practices as building blocks of organizational learning and knowledge creation, because
they enable the capture and transformation of individual (or group) experience into
organizational knowledge, which is considered crucial in the well-known works of
Argyris and Schön (1978) and Senge (1990). Hence, organizations need to have “…an
effective means of learning from experience on projects, that combines explicit knowledge with tacit
knowledge in a way that encourages people to learn and to embed that learning into continuous
improvement of project management processes and practices” (Cooke-Davies, 2002, p.189).

To summarize, dynamic changes in the market situation and global business environment
are driving a rapid evolution of learning needs in manufacturing companies. Hence, there
is a need to create better experiential knowledge capturing, sharing and reusing methods
and technologies to solve problems and exploit opportunities, which could allow them to
stay ahead of the competition.

2
 Introduction
1.2 Research Problem

Brown and Daguid (2000) asserted that most tasks in organizations are spontaneous,
practice-centered and “there is a large gap between what a task looks like in a process manual and
what it looks like in reality” (p.5). In particular, design problems in the early phases are often
ill-defined (Rittel and Webber, 1973), as designers are usually seeking directions rather
than specific solutions (Sharmin et al., 2009). Thus, design teams use trial-and-error
approaches with varying levels of prior knowledge (Wallace et al., 2006) such as physical
examples of previous products, drawings and reports. Although existing product design
systems address many issues related to use of prior knowledge, their main focus is on the
detailed design and later phases (Chandrasegaran et al., 2013), when designers are seeking
solutions to defined problems (Sharmin et al., 2009). Moreover, the prevailing domain-
specific and hierarchical structure of traditional Knowledge Management Systems (KMS)
does not facilitate the acquisition of knowledge from a large network of independent and
geographically distributed teams (Larsson et al., 2008). Hence, most people who might
have knowledge about emerging aspects of a product cannot contribute to populating the
knowledge base (Bertoni and Larsson, 2011).

In many organizations, proven practice at the beginning of a new project has been to
carry forward knowledge from past and current projects. However, many organizations
are struggling with the collection and dissemination of lessons (Carillo et al., 2013;
Milton, 2010; Rhodes and Dawson, 2013; Williams, 2008), which greatly hinders the
attainment of potential benefits from LL practices (Keegan and Turner, 2001; Rhodes and
Dawson, 2013). There is a disparity between the goals and outcomes of LL practices, and
a lack of transparency about what happens to collected lessons (Carillo et al., 2013).
Milton (2010) found that 60% of 74 examined organizations that attempted to implement
LL processes were dissatisfied because lessons were identified and captured but often not
followed through and applied internally to deliver the intended changes in personal or
organizational behavior, processes, best practices or standards. Similarly, Williams (2008)
found that 62.4% of 522 project practitioners had a formal procedure for learning lessons,
but only 11.7% of that group used it because their methods did not clarify root causes (i.e.
the entire cause-and-effect chain causing the problems) of project outcomes.

One of the most common kinds of LL sessions are post-project reviews or postmortems,
but their effectiveness for leveraging experiential knowledge has been widely questioned
(e.g., Goffin et al., 2010; Koners and Goffin, 2007; Milton, 2010; Tan et al., 2006).
Associated problems include dissolution of project teams after the end of projects,
reassignment of people to new projects, staff turnover, time-consumption and delays in
both capturing LL and deriving generalizable lessons from learning that are typically
specific to a single project (e.g., Disterer, 2002; Tan et al., 2006; Williams, 2008).
Researchers have also highlighted the limited use of KMS (Carillo et al., 2013; Goffin et
al., 2010)
and even where systems are used the promotion of knowledge sharing and reuse
is generally limited due to the adoption of ad-hoc approaches (Weber et al., 2001). Thus,
there are several barriers to the transfer of experiential knowledge between projects, or
inter-project learning, especially systemic knowledge about the overall structure of new
product development processes (Bartezzaghi et al., 1997).

3
 Introduction
The existing literature is majorly referring to post-project reviews for capturing lessons
learned. There is a need for embracing a continuous approach towards lessons learned
practice to capture experiential knowledge effectively.

In addition, knowing in action (Amin and Roberts, 2008) from complex tasks is largely tacit
and embedded in local norms and practice (Wood et al., 2009), and deeply
“contextualized” in the experiential environment (Arora and Gambardella, 1994).
However, most lessons learned reports seem to lack both contextualized information
(Carillo et al., 2013; Milton, 2010) and tacit knowledge (Buttler et al., 2011; Goffin and
Koners, 2011; Williams, 2008). This hinders the application and reuse of captured lessons
in new situations (Ahn et al., 2005). As existing information systems require codification
of these experiences, it is difficult for people who carry out tasks to articulate their
experiential knowledge without losing its original “context” (Weber et al., 2001; Zack,
1999).

A lack of contextual information in LL reports isolates important knowledge elements from

original situations, resulting in the limited and distorted understanding of lessons, thereby
affecting the selection and reuse of relevant lessons in new situations.


In fact, this could be the reason why most people depend on informal sources, i.e.
personal contacts and networks, to obtain and access past experiences rather than the
formal documentation available in their company (Marsh, 1997). Several researchers assert
that the social processes of story telling and recording are effective ways to capture lessons
related to complex issues and skill-oriented tasks (Desouza et al., 2005; Goffin and Koners,
2011; Hoegl and Schulze, 2005; Milton, 2010; Williams, 2008). The literature also
indicates that IT-mediated methods are appropriate for recording codifiable knowledge
and social methods appropriate for tacit knowledge (Aoshima, 1996; McMahon et al.,
2004; Williams, 2008). However, practical tools have been developed, and are being
applied, for the former but not the latter (Aoshima, 1996; Williams, 2008).

There is a lack of practical methods and tools for capturing LL related to tacit knowledge or
experience-based knowledge from skill-oriented activities.

1.3 Research Question

The identified research problems have led to the efforts to:

(1) investigate the current state of lessons learned practices in order to identify
potential barriers in the light of emerging product development trends such as
product-service systems;
(2) identify an alternative ways to improve current practices from both capture and
reuse perspectives.

Accordingly, this thesis is guided by following research question:

RQ: How can lessons learned practice be supported to improve lessons learned reuse?

4
 Introduction
1.4 Delimitations

This study is considered to have two main limitations. Firstly, it is addressing engineering
practices and technical projects, while not addressing other perspectives of a product
development process. In particular, the focus is on cross-functional teams involved in
product development projects in the manufacturing industries. The study is based on
development of complex products in large companies, hence a second delimitation is that
lessons learned in small or medium sized firms are not included.

1.5 Thesis Outline

This thesis consists of nine chapters.

Following this introduction (Chapter 1), Chapter 2 initially presents the research strategy
applied, and the rationale for selecting cases to study. It then describes the three case
studies. The following section introduces the literature review process I have undertaken
in the research. Various forms of data collection and analysis are discussed in the next
section. The chapter concludes with the discussion on various measures that have been
considered to improve the quality of this research.

Chapter 3 presents and discusses the theoretical background for the thesis, including
knowledge dimensions of product development, product-service systems, theory of
knowledge, knowledge management, lessons learned, knowledge lifecycle, storytelling
knowledge reuse, Web 2.0, and video sharing.

Chapter 4 summarizes the appended papers, providing information on the purpose,

empirical basis and analysis, main findings, and finally contribution to the thesis of the
studies they respectively describe.

Chapter 5 combines the results from the appended papers related to the research question.
It first explains the importance of learning from experience in an engineering
environment, then describes as-is lessons learned practice in relation to knowledge
lifecycle stages. Based on this analysis, the following section describes functional
requirements for supporting as-is lessons learned practice.

Chapter 6 presents and describes capabilities that are needed to deliver the functional
requirements. The development of a new methodology for LL practice is then presented.

Chapter 7 presents the results from preliminary validation activities conducted in the form
of a laboratory experiment, an industrial experiment and a design experiment.

Chapter 8 summarizes the overall conclusions from the studies related to the research
question. It then highlights both the academic and industrial contributions.

Chapter 9 presents potentially valuable directions for future research to address both
methodological and technological issues.

5
 Research Methodology

2 Research Methodology
This chapter initially presents the research strategy applied, and then describes the case studies in
detail. The following section introduces the literature review process I have undertaken in the research.
Various forms of data collection and analysis are discussed in the next section. The chapter concludes
with the discussion on various measures that have been considered to improve the quality of this
research.

2.1 Research Strategy

Given the research effort to investigate the current state of Lessons Learned (LL) practices
to identify potential barriers, a qualitative approach was deemed appropriate. The
rationale was that such approaches can address “naturally occurring, ordinary events in natural
settings, (Miles and Hubermann, 1994, p.10), and thus capture what “real life” is like,
better than quantitative approaches. Qualitative studies enables researchers to examine and
interpret phenomena in their natural settings, and to understand the perspectives and
meanings people bring to such phenomena (Denzin and Lincoln, 2003). This is because it
has the “ability to provide complex textual descriptions of how people experience a given research
issue. It provides information about the “human” side of an issue – that is, the often contradictory
behaviors, beliefs, opinions, emotions, and relationships of individuals” (Mack et al., 2005, p.1).
Thus, a qualitative approach facilitates elucidation of latent, underlying, or nonobvious
issues (Miles and Hubermann, 1994), which are otherwise inaccessible, using quantitative
approaches for instance. Moreover, qualitative inquiry is beneficial for studying any
process at great depth, as it can uncover underlying rationales, such as how and why
things happen as they do, even for assessing causality as it actually plays out in a particular
setting (Miles and Hubermann, 1994). Therefore, qualitative inquiry often focuses on
relatively small samples, even single cases, purposefully selected (Patton, 2002) for
understanding the dynamics in specific settings (Eisenhardt, 1989).

Case studies (Yin, 2009) have been employed as the overarching research strategy for my
PhD research, because it allows investigators to retain the holistic and meaningful
characteristics of real-life events, such as small group behavior, organizational and
managerial processes, and the maturation of industries (Yin, 2009). Case studies are also
preferred when examining “a contemporary phenomenon in depth and within its real-life context,
especially when the boundaries between phenomenon and context are not clearly evident” (Yin,
2009, p.18). This makes it especially suitable for intervention-research applications, where
it can be used to provide evidence to explain causal links in real-life interventions that are
too complex for elucidation by surveys or experimental strategies (Yin, 2009). Case
studies are particularly valuable when the research aim is to answer “How?” questions
(Yin, 2009), and thus appropriate for my research since the focus was to understand as-is
LL practices, which are contemporary phenomena in real-life contexts, and the aim was
to answer a “How?” question.

7
 Research Methodology
2.2 Case Studies

Case studies were selected by means of purposeful sampling, which provides a powerful,
rational means to select information-rich cases for in-depth study, i.e. cases from which
much can be learnt about core issues related to the aim of the inquiry (Patton, 2002).
Several strategies can be applied for purposefully selecting information-rich cases. In this
research, three purposeful sampling strategies described by Patton (2002) were used for
selecting cases: critical case sampling (i.e. selection of cases with the potential to generate
logical generalizations and information with maximal applicability to other cases),
snowball case sampling (i.e. selection of cases from participants’ referrals), and confirming
case sampling (i.e. selection of cases with the potential to support initial analysis).

Each case study design followed the five guiding points proposed by Yin (2009) definition
of: (1) study questions, (2) study propositions, (3) the unit of analysis, (4) linking the data
to the propositions, and (5) the criteria for interpreting the study’s findings. The guiding
research question (1st guiding point) for each case study were based on the research
problem, which was formulated following consideration of key issues identified in the
literature review. Due to the nature of explorative analysis, the case studies had defined
purposes and followed a set of criteria guiding the investigative propositions. These
criteria were derived (2nd guiding point) by using a Knowledge Lifecycle (KLC)
framework (i.e. capture, store, share, search, access, and reuse; see Andersson, 2011) and a
SWOT framework (i.e. Strengths, Weakness, Opportunities, and Threats; see Helms and
Nixon, 2010). The KLC framework was used for all case studies and the SWOT
framework only for first two. Each case study’s unit of analysis was at the level addressed
in their summary descriptions and conclusions (3rd guiding point; see individual case
descriptions for their respective units of analysis). The SWOT and KLC frameworks
provided the logic linking the data to the propositions (4th guiding point), and the lens
for interpreting the studies’ findings (5th guiding point).

Figure 1. Contextual situations of the case studies in a simplified aeronautical supply chain
8
 Research Methodology
2.2.1 Study 1
This case company provides both machining tool hardware and the application software.
One of the company’s main objectives is to develop and market product and service
combinations to exploit emerging market opportunities by aligning its offerings with
customer needs. The study was conducted to obtain generic data on the company’s
product and service development processes to define scenarios for internal and external
knowledge sharing in the light of emerging product development trends, such as Product-
Service Systems (PSS).

The goal of this case study was to identify methods and tools that might be suitable for
improving the ‘knowledge baseline’ in early stages of innovation projects, focusing
particularly on knowledge that currently resides outside of the traditional scope of product
development teams, e.g., knowledge about how customers use the products, or
knowledge about best practices in various application domains throughout the products’
lifecycle phases. Hence, this case study was designed to investigate the internal and
external knowledge flows within the application development process in order to
understand how cross-functional development teams can capture and share ‘generic’
knowledge assets that can be easily discovered by other team members, regardless of their
domain of expertise and role in the company. Thus, the main unit of analysis for this
study was “knowledge lifecycle flow for cross-functional design teamwork”.

2.2.2 Study 2
This case company offers aero-engine components and additional maintenance services to
aircraft engine manufacturers and airlines. This collaboration with the original equipment
manufacturers (OEMs) is described as a risk-and-revenue sharing partnership, through
which the partners share development costs, risks and revenues throughout the engine
program, unlike an ordinary customer-supplier relationship. Hence, the company has
been increasingly involved in design projects with both aero-engine and aircraft OEMs at
an early stage, in order to be better prepared from both technology and product lifecycle
perspectives.

Partly to address these demands the company recently deployed Web 2.0 capabilities,
such as blogs, wikis and social networking, based on Microsoft SharePoint1 to enhance
internal and external collaboration and knowledge sharing. However, after a pioneering
phase, the company felt the need to establish more sophisticated Web 2.0 approaches,
harmonize methods and tools, and develop more effective practices and guidelines that
address scalability issues. The case study was conducted during this phase and was
designed to elucidate how cross-organizational teams use various existing knowledge
management systems and Web 2.0 capabilities to create, process, share, and reuse
information in their routine activities. The goal was to identify potential opportunities to
improve the capture and sharing of experiential knowledge in the complex, distributed
engineering environment. The unit of analysis was the same as in study 1, i.e.
“knowledge lifecycle flow for cross-functional design teamwork”.

1
Microsoft SharePoint: http://office.microsoft.com/en-us/sharepoint/

9
 Research Methodology
2.2.3 Study 3
To investigate ways to continuously aid designers in early phases in making decisions
regarding process selection, manufacturability and maintainability, this study was
performed at the same company as study 2. For this purpose, study 3 focused on the
company’s Design Practice (DP) support system, a kind of system for distilling and
disseminating best practices in design phases. This is being implemented to collect and
document specific technical realization instructions, activities and related methods for the
design and development of each offered product in a defined stage-gate process. The case
study addressed the DP system to identify alternative solutions to foster sharing of
experiences and LL across product lifecycle phases, regardless of project and departmental
boundaries. The initial focus of the study was to develop a richer understanding of the
current management of experience capture and feedback from different phases of products’
lifecycles to the DP system and the early conceptual design phase. The objectives were to
identify issues associated with current practice, derive a list of requirements for
improvement, and propose a supportive methodology or tool. The unit of analysis in this
study was “continuous experience capture and feedback process”.

Information was gathered during three industrial visits. During the first visit a new
empirical enquiry was planned to investigate the company’s as-is LL practice. Both
empirical and literature analysis helped to develop new concepts and methodology, which
were initially tested in a laboratory experiment at the Luleå University of Technology.
During the second visit, the results of preliminary laboratory experiment and the concepts
were introduced and discussed with different users of, and contributors to, the DP System
and LL management. Feedback on the developed concepts was collected from different
stakeholders, and at the same time an industrial experiment was planned with three
industrial practitioners to test and validate the methodology. During the third visit
preliminary industrial experimental results were shown to different stakeholders and
management teams within the company and a second, iterative industrial experiment was
planned to test and validate the methodology.

2.3 Literature Review

A literature review has been carried out throughout my PhD work to obtain an in-depth
understanding of the main existing theories related to the research topic, address the
previous work, and develop deep insights relevant to the defined research problem.
Existing literature was also used to establish empirical guidelines for the field study, gather
evidence to identify research gaps and validate results from the case studies. During my
PhD research, there were four main iterative literature searches, but literature continued
to be reviewed throughout the process.

The first main iteration of the literature review was performed at the beginning of my
PhD, and primarily focused on cross-functional teams, knowledge sharing, knowledge
creation, product-service systems, Web 2.0, social software and Enterprise 2.0. During
this search, few relevant articles specific to use of Web 2.0 for knowledge sharing within
the product-service systems domain were found. However, the review deepened
understanding of the opportunities and issues associated with its use in several other
domains, such as education, healthcare, library archiving, human resource management
and knowledge management. The empirical studies performed after this first iteration of

10
 Research Methodology
literature review highlighted several new themes, potential opportunity areas as well as
challenging issues related to the research topic.

Based on the themes that emerged from the empirical inquiry, a second review of the
literature was conducted, in which several new concepts were included, such as
knowledge lifecycle management, design rationale, LL management, knowledge
management systems, product/service development, conceptual design and SWOT
framework. The third iteration of the literature review was conducted, after completion
of my licentiate thesis, to further deepen understanding of concepts and issues that had
been highlighted to this point, notably: LL capture, experience sharing, experience
feedback, knowledge transfer, tacit knowledge sharing, video sharing and social media
applications. Another empirical study was performed during this period, which called for
an in-depth review of some other relevant themes, for example, knowledge context,
storytelling and knowledge reuse.

In all of the literature reviews scientific databases available at the Luleå University Library
were used, including Scopus, Web of Science, Proquest, and Google Scholar. Several
distinguished journals and conference proceedings related to the research area, such as
engineering design, product innovation, engineering management, information systems,
knowledge management, knowledge management research & practice, project
management, and management review journals, were also used. Several combinations of
keywords were used to retrieve relevant literature for my study. Some of the most
commonly used keywords and combinations of keywords used in the searches are listed
below:

• Web 2.0: cross-functional teams, knowledge creation, knowledge sharing,

product-service system, social software, Enterprise 2.0
• Web 2.0: product development, knowledge lifecycle, knowledge management,
knowledge management systems, conceptual stage, fuzzy front-end
• Lessons learned: knowledge transfer, product development, Web 2.0, tacit
knowledge, e-learning, video, video sharing, social media, template
• Lessons learned: capturing lessons learned, experience sharing, product
development, experience feedback, storytelling, contextualized knowledge
• Lessons learned: knowledge reuse, product development, experience capture, tacit
knowledge sharing, videos

2.4 Data Collection

As outlined above, the research included three case studies that were purposefully selected
to observe focal social phenomena within their real-life contexts. Interviewing is
considered a primary means for collecting case study information (Yin, 2009; Darke et al.,
1998), as it enables exploration of the world from participants’ perspectives to reveal
meanings of their experiences (Kvale, 1996), interpret their actions and openly describe
problem situations (Lofland et al., 2005). Thus, interviews were used in each of the case
studies, as described below.

2.4.1 Interviews
During my investigations qualitative data were collected through in-depth individual,
face-to-face semi-structured interviews conducted during various sessions at the
11
 Research Methodology
companies’ facilities between May 2009 and December 2012. A semi-structured
interview strategy was chosen because it allows the researcher to cover both sequences of
themes and questions prepared in advance (Kvale, 1996). Furthermore, it provides
flexibility, allowing changes of sequences and question forms in order to follow up
responses and stories told by the interviewees (Kvale, 1996).

The following seven stages were applied in each interview-based investigation, as

recommended by Kvale (1996): (1) thematizing, (2) designing, (3) interviewing, (4)
transcribing, (5) interpreting, (6) verifying, and (7) reporting. The first stage involved
formulation of the investigation’s objectives and description of the concepts to be
investigated (themes), based on theoretical analysis of the focal issues. The following
design stage focused on optimizing the likelihood of obtaining the intended knowledge,
while taking into account the implications of the study. The purpose and design of the
study were communicated to industrial contacts, who served as gatekeepers (Neyland,
2008) to identify candidate interviewees who could be relevant for the study. An
interview guide was then formulated in a semi-structured format, indicating the topics to
cover and their sequence in the interviews, with or without detailed questions (see
Appendices I and II).

In total, 56 interviews were performed in the three case studies. The interviewees
represent people with wide ranges of positions in the company hierarchy (e.g., managers,
specialists, team leaders, process supervisors, system supervisors, engineers, and technicians)
and activities (e.g., business development, product planning, simulations, engineering,
method development, manufacturing, serial production, quality, product support,
maintenance, application development, R&D, customer support, and IT services). The
average duration of the interviews was approximately 45-60 minutes. All the interviews
were audio/video-recorded with the informants’ approval. At the beginning of each
interview the research background was introduced to the interviewee and both the
purpose of the interview and the use of the tape recorder were briefly described (Kvale,
1996), i.e. how I will use the collected data and why I am using a tape recorder.

During the interview process, snowball or chain sampling (Patton, 2002) was used to locate
“information-rich key informants” from the initial sample of people, who suggested or
introduced other informants to me, based on their personal connections to people with
potential knowledge on the focal research topic.

2.4.2 Focus Groups and Meetings

Focus group discussions can be highly valuable for obtaining a more complete picture
than other methods can provide of how a given issue affects a community of people,
accessing broad ranges of opinions, and identifying solutions that a particular group wants
or would like (Mack et al., 2005). Therefore, focus group sessions (each with 3-5
participants) were used in all three case studies, and five in total. In each session the
researcher led the discussion by asking participants to respond to open-ended questions
and all sessions were tape-recorded.

In addition, virtual meetings were used throughout the research, and conducted before
and after each interview session. These meetings were performed with company
specialists, R&D directors and R&D managers, who served as gatekeepers (Neyland, 2008)

12
 Research Methodology
for the case studies. Further, in study 1, a workshop was arranged with eight industrial
participants to validate the outcomes and receive feedback on the study.

2.4.3 Survey
A questionnaire survey was conducted among several major Swedish and other European
companies to discover more about current knowledge-sharing practices, challenges, and
the ways cross-functional teams use collaborative technologies. Of the 28 questionnaires
submitted to potential participating companies, 15 were returned. The questionnaires
comprised 10 multiple-choice questions and seven open-ended questions intended to
elicit relevant data about current cross-functional knowledge-sharing practices, challenges,
and emerging technology adoption trends, such as the use of Web 2.0 in cross-company
collaborations (see Appendix III).

2.4.4 Observations
In study 3, observations (Eisenhardt and Graebner, 2007) were performed at the case
company for about 1.5 months. During this period, I was provided access to the
company’s operation management system, where several design and development related
workflow systems were deployed. Attention was particularly paid to the Design Practice
(DP) system and its interfaces with other related operationalized systems such as
Document Management Systems (DMS), Lessons Learned System (LLS) and SharePoint
sites. Apart from interviewing stakeholders related to the DP systems, LL practice and
product lifecycle phases, I also participated in weekly meetings and strategy meetings
linked to the DP system’s implementation. In this way, the observation period aided
understanding of the issues around various systems from a holistic perspective, and
provided insights related to the daily activities of the engineering design team, including
their interaction with related systems. Field notes were collected during the observational
period, as they can be useful for recording in writing whatever impressions occur
(Eisenhardt, 1989), providing essentially “an ongoing stream-of-consciousness commentary about
what is happening in the research” (Eisenhardt, 1989, p.539). Furthermore, during the
observational period, several organizational documents were reviewed. These documents
were linked to issues raised during the interviews by the participants, and provided
following requests by me, typically on an as-required basis, because the information in
many documents held by aerospace companies is classified as proprietary.

2.4.5 Pilot Experiments

In study 3 three pilot experiments were conducted with varying settings, setups and
objectives: a laboratory experiment, an industrial experiment, and a design experiment.

The laboratory experiment was initially carried out with two researchers based at Luleå
University of Technology to test the developed methodology for LL capture. One had a
Material Science background and was working in the area of laser welding, while the
other had an Operation and Maintenance background and was working in the area of
railway maintenance management. The methodology and detailed guidelines were
introduced to the participants and they were each then asked to record a lesson they had
learned, following the new methodology. I was personally involved and recorded their
lessons learned in their laboratory environments.

The next pilot experiment was conducted in the industrial environment of aero-engine
component manufacturer. The methodology and guidelines were introduced to all
industrial participants during my observational period. The extreme or deviant sampling
13
 Research Methodology
technique (i.e. focusing on experiences with outstanding successes/notable failures; Patton,
2002, p.230) was used to identify information-rich participants to test and validate the
proposed methodology. In total, the methodology was tested six times, with two design
leaders and one quality engineer. After testing the methodology, the participants were
asked to give their reactions and comments on the tested methodology using a follow-up
questionnaire, which had five open-ended questions (see Appendix IV).

As a further test of the proposed methodology, the first design experiment was conducted
with students taking Luleå University of Technology’s Product Development Master’s
Program. Initially three teams of 4-5 members were formed and asked to tackle a
prototypical design problem, the design of a bridge and platform capable of supporting a
donkey bungee-jumping using only paper (see Appendix V for the design brief). The
donkey was included to make the exercise more engaging for the students. On the first
occasion, two teams (designated groups A and B) separately performed the exercise and
were both then asked to reflect on their performance and prepare reports of lessons they
had learnt while executing the task. However, groups A and B were respectively asked to
prepare and formulate their LL report using the proposed methodology and without using
it, i.e. in an unstructured manner. The same task was subsequently assigned to the third
group (C), and the two video-based LL were provided to the group before they executed
it. The exercise was followed with a group reflection interview (see Appendix VI for the
questionnaire), which was audio-recorded. In the interview, group C was asked about the
role of the LL in their successful execution of the task. This design experiment was aimed
at verifying both the “lightweightness” of the methodology for non-expert users to
capture LL and the utility of reusing LL in solving a problem. Figure 2 schematically
illustrates the setup of this design experiment.

Figure 2. Schematic illustration of the setup of design experiment

14
 Research Methodology
2.5 Data Analysis

The empirical data collected from the interviews and focus group sessions were recorded,
transcribed, and reviewed by the respondents for accuracy. Field notes collected from the
virtual meetings, workshop, documents and the observations were documented and
summarized.

Data from the interviews, field notes and survey questionnaires were analyzed using
spreadsheets for drawing tentative conclusions, with a pattern-matching technique (Yin,
2009). The spreadsheet was structured as a conceptually ordered display by addressing all
respondent answers connected to each interview question (Miles and Huberman, 1994).
Moreover, some of the interview questions were conceptually clustered, based on related
topics they were exploring in order to identify specific themes. Several themes were then
drawn for further analysis based on patterns related to stages of the knowledge lifecycle–
that is, capture, store, share, search, access, and reuse. In addition, for studies 1 and 2, a
SWOT framework (strengths, weakness, opportunities, threats) was also used to analyze
the themes.

Collecting data from multiple sources allowed integration of various perspectives to

analyze the data according to gathered themes (Yin, 2009). The themes were then
analyzed to understand the as-is LL practice, and to identify shortcomings of both the LL
practice and existing enterprise knowledge management systems. Further, knowledge
requirements for cross-functional teamwork in the context of emerging product
development trends, such as lifecycle responsibilities and development of product-service
offers, were addressed.

Users’ needs related to knowledge lifecycle management include both explicit and tacit
knowledge. Thus process models were elaborated to enhance understanding of as-is
experience identification, capture, share and feedback processes. Mind-mapping tools
were used to structure and explore these processes in order to identify users’ interactions,
users’ needs and aspects requiring improvement. A list of functional requirements and
possible ways to address them were drawn in matrix format to develop an LL
representation methodology and guidelines for capturing LL. These activities were done
iteratively in order to depict knowledge-related problems with the highest possible level
of accuracy. Conclusions were drawn by iterating between knowledge-related problems,
theory, and empirical data (Eisenhardt, 1989; Yin, 2009).

Questionnaire responses from the industrial experiment, and design experiment, were
analyzed in a similar fashion, using spreadsheets as conceptually ordered displays (Miles
and Huberman, 1994). To analyze the industrial experiments’ results a spreadsheet was
structured by collating all respondent answers connected to each interview question.
Then synthesis and key points were derived for each question by summarizing the
respondents’ answers to them. Finally, the recorded LL videos were transcribed and
compared with the synthesis and key points derived from the questionnaire to identify
final results and draw conclusions.

In addition, the group interview in design experiment was transcribed. Various themes
related to the experiment were then formulated, e.g. capturing LL, reuse of lessons, the
effect of LL methodology in their reuse, and the role of the video medium in

15
 Research Methodology
understanding the lessons. These themes were further analyzed to derive conclusions and
key inferences related to the proposed methodology.

Table 1 summarizes the studies, the collection and analysis of the empirical data, and the
Papers in which they were presented.

Table 1. Overview of studies, methods used, and papers in which results obtained were
presented

Study Unit of Analysis Data Collection Participants Paper

Study I Knowledge lifecycle Interviews R&D Director Papers A
flow for cross- Focus groups R&D Managers and B
functional design Virtual meeting R&D Engineer
team work Workshop Application Engineer
(See Appendix I for study Project Leaders
questions) Development Manager
Production Engineer

Study II Knowledge lifecycle Interviews Senior Company Specialist Papers A,

flow for cross- Focus groups Process Managers B and C
functional design Virtual meetings IT Architect Manager
team work Survey IT Coordinator
(See Appendices I & II for Development Engineers
study questions and survey Customer Support Specialist
questionnaire) Industrial PhD Student
Design Engineers
Project Managers
Study III Continuous Interviews Chief Engineer Papers D
experience capture Observation Process Managers and E
and feedback process Documents Senior Designers
Focus group Quality Engineers
(See Appendix III for study Design Engineers
questions) Maintenance Engineer
Design Leaders
Senior Specialists
Lessons learned Laboratory experiment Two researchers
capture
Lessons learned Industrial experiment Design Leaders
capture (See Appendix IV for Quality Engineer
questionnaire)
Lessons learned Design experiment Master program students
capture and reuse (See Appendix VI for
interview questions

2.6 Research Quality

In qualitative case study research, the research quality is judged in relation to construct
validity, internal validity, external validity, and reliability tests (Bloomberg and Volpe,
2008; Yin, 2009). However, “there is no generally accepted set of guidelines for the assessment of
this type of research” (Eisenhardt, 1989, p.548). Therefore, several strategies were applied
during my investigation to maintain the research quality.

Construct validity logic was verified by using multiple data sources as well as multiple data
collection methods, which provided a broader picture of the focal phenomena. The use
of multiple sources of evidence helped in the development of converging lines of inquiry,
addressing a range of historical and behavioral issues (Yin, 2009). The selection of
16
 Research Methodology
information-rich informants representing different company roles and hierarchical levels
allowed me to mitigate potential respondent biases in the data collection process. It also
helped me to consider diverse perspectives of the phenomena under review. In addition,
transcripts were reviewed by the respondents to check for accuracy, to avoid
misunderstanding the meanings and issues. The case study reports were written with
linear-analytic structures (Yin, 2009), that is with sections sequentially describing the
studied issue, review of relevant prior literature, methods used, findings from the data
analysis, the conclusions and finally implications of the findings. The key industrial
contacts reviewed these reports for construct validation.

The internal validity of the study was verified by applying pattern-matching logic during
the data analysis. The SWOT framework and the knowledge lifecycle stages were used to
summarize the findings and draw inferences from the analysis of empirical data. Literature
reviews were performed at various stages of the research to identify similar (or contrasting)
findings and tie together underlying similarities in phenomena that are not normally
associated with each other. According to Eisenhardt (1989), this process will result in
theory with stronger internal validity, wider generalizability, and a higher conceptual level.

However, It should be noted that many researchers have expressed concern that the goal
of case studies is not to generate findings that are generalizable to other organizations, but
rather to develop deep insights into the dynamics of specific processes and situations (Yin,
2009), and contribute to broadening and building theory (Cavaye, 1996; Eisenhardt,
1989). As stated by Darke et al. (1998, p.278), “statistical generalization to a population is not
the goal of case study research, as cases are not sampling units. Rather, theoretical or analytical
generalization is appropriate, where case study results are used to develop theory or to test previously
developed theory.

Further, Mack et al. (2005) asserted that “although findings from qualitative data can often be
extended to people with characteristics similar to those in the study population, gaining a rich and
complex understanding of a specific social context or phenomenon typically takes precedence over
eliciting data that can be generalized to other geographical areas or populations” (Mack et al., 2005,
p.2). Therefore, the issue of external validity was addressed in my investigations by
positioning the case studies in a specific industry (the aerospace industry) and explaining
the research design, and the rationales for selecting both cases and the techniques used for
data collection and analysis (Eisenhardt and Graebner, 2007), which should help other
researchers to address similar issues in other specific contexts.

The study’s reliability was verified while minimizing bias and errors through the use of a
case study protocol during data collection and analysis by cross-checking interview reports
with participants and maintaining a structured case study database with records of field
notes and transcripts in order to document the rationale applied throughout the research
process (Yin, 2009). All interviews were tape-recorded, to enable transcripts to be traced
back to clarify how the data were analyzed and interpreted (and to detect possible errors
or misinterpretations).

17
 Areas of Relevance

3 Areas of Relevance
This chapter presents and discusses the theoretical basis for this thesis. It initially describes knowledge
dimensions in product development and product-service systems. The following sections describe and
discuss key facets of knowledge management, including theories of knowledge, knowledge
management strategies, knowledge sharing, lessons learned, storytelling, the knowledge lifecycle and
knowledge reuse. The final part of the chapter presents theory related to Web 2.0 and video sharing.

3.1 Knowledge Dimensions in Product Development

Product development is regarded as the set of activities beginning with the perception of
a market opportunity and ending in the production, sale, and delivery of product (Ulrich
and Eppinger, 2008, p.2). Several researchers have asserted that product development is
an information- and knowledge-intensive activity (Clark and Fujimoto, 1991; Madhavan
and Grover, 1998; Thomke and Fujimoto, 2000). Clark and Fujimoto (1991) viewed
product development as a process by which an organization “…transforms data on market
opportunities and technical possibilities into information assets for commercial production.
During the development process, these information assets are created, screened, stored,
combined, decomposed, and transferred among various media” (p.20). The management
of this information and knowledge can help companies to boost product development
performance and enhance their knowledge base to support new product development
projects (Thomke and Fujimoto, 2000).

Ulrich and Eppinger (2008) described a general product development process with six
phases: planning, concept development, system-level design, detail design, testing and
refinement, and production ramp-up, as shown in Figure 3. Thus, the process usually
begins with a planning phase, resulting in the project’s mission statement as an output,
which is the input required for initiating the concept development phase.

Figure 3. A generic product development process, adapted from Ulrich and Eppinger (2008)

19
 Areas of Relevance
Slack et al. (2010) emphasized that every new product development project can be
viewed as a process involving progressive reduction of uncertainty. This uncertainty,
which is particularly high at the beginning of the project, is due to the high number of
design options for the final product. As the project progresses uncertainty gradually
decreases as decisions are taken and the range of options is restricted. It has been
estimated that design decisions in conceptual phases account for more than 75% of final
product costs (Ullman, 2002), as during this phase “information is very fuzzy and incomplete,
which makes the design process quite difficult and challenging” (Wang et al., 2002, p.982).
Cooper (2003) argued that in reality resources for projects are limited, so decisions must
be made concerning which uncertainties to explore and reduce. Both the acquisition of
external knowledge and the development of internal knowledge are critical for effectively
resolving uncertainty. However, acquiring the knowledge required to address concerns,
problems, uncertainties, assumptions, and the relationships between them is difficult in
the dynamic product development environment (Cooper, 2003).

Holman et al. (2003) argued that the focus during the product development process must
shift from a traditional sequential process-based approach to a more information-driven
approach to eliminate sources of time wasted doing unnecessary work or waiting for
either decisions or information, which account for 30% of working time, according to
Marsh (1997). According to Holman et al. (2003), in a process-based approach,
breakdowns of communication among various departments lead to ignorance about
problems that may have costly implications in later stages of the development process. In
an information-based approach, as a first step a team developing a new product should
not only determine critical attributes for its success, but also identify the information
required to make each key decision along the way (Holman et al., 2003). For example, if
cost is critical, the product team should construct a workflow designed to determine and
meet cost targets instead of allowing costs to be an uncontrolled output. According to
Holman et al. (2003), this approach could help companies to solve problems and
synthesize new information continually, instead of merely collecting bits of information
from various sources and compiling the results just before gate meetings.

Thomke and Fujimoto (2000) proposed a conceptual approach to learning related to new
product development called front-loading problem-solving. Front-loading in this context
means shifting the problem-identification and problem-solving to earlier phases of
product development, thereby improving both learning and product performance while
cutting development costs and time. The cited authors identified two general approaches
for the management of front-loading activities:

• project-to-project knowledge transfer—referring to the transfer of problem- and

solution-specific information from previous projects to new projects thereby
reducing the total number of problems to be solved from the onset of
development activities.
• rapid problem-solving—referring to use of advanced technologies and methods to
increase the overall rate at which development problems are identified and solved.

3.2 Product-Service Systems

Product-Service Systems (PSS) emerged as a progressive notion for manufacturing

organizations in a way to respond to a growing attention to life-cycle responsibility,
20
 Areas of Relevance
service-oriented strategies as well as environmental sustainability (Baines et al., 2007;
Mont, 2002; Tukker and Tischner, 2006). In literature, researchers suggested different
definitions and types of PSS based on their focus and perspective (e.g., Baines et al., 2007;
Clayton et al., 2011; Wang et al., 2011). Manzini and Vezolli (2003) defined PSS as “an
innovation strategy, shifting the business focus from designing (and selling) physical products only, to
designing (and selling) a system of products and services, which are jointly capable of fulfilling specific
client demands” (p.851).

Literature (e.g., Baines et al., 2007; Wise and Baumgartner, 1999) reported that
manufacturers could achieve a competitive advantage through PSS offerings, as they could
improve their position in the value chain, create unique customer value, obtain more
stable cash flow, and improve their innovation potential. By providing PSS offers,
manufacturers have in-depth knowledge about how their products perform throughout
their lifecycles, which open up new opportunities for companies to apply this knowledge
to create innovative solutions to the variety of customer applications (Williams, 2007).

Tukker and Tischner (2006) divided PSS business models into three main categories—
product-oriented, use-oriented, and result-oriented. The type of value embedded in the
business offering (mainly product- or service related) is chosen as the main criterion for
this classification. They are:

(1) Product-oriented PSS, in general, represents the traditional sale of a product

embracing some additional services, such as maintenance, repair and upgrades.
(2) Use-oriented PSS represents sale of the use or availability of a product to
customers in different forms (e.g. leasing or sharing), but with the producer
retaining ownership.
(3) Result-oriented PSS represents the sale of the result or capability of a product to
customers, while the producer retains the ownership of the product.

PSS development is quite different from traditional product development because the
service component in PSS introduces new variables, such as maintainability, reliability,
and product’s availability, while reducing the overall product lifecycle costs (Harrison,
2006). According to Kimura and Suzuki (1996), the product developer first needs to
design the lifecycle and then design the product to fit the lifecycle. Tan et al. (2006)
asserted that companies must consider two lifecycle systems when defining requirements
in PSS development projects: the lifecycles of the physical artifact and the customer
relationship activities. Several researchers have argued that suitable feedback loops are
essential for capturing product’s lifecycle knowledge and integrating it with PSS
development (e.g. Goh and McMahon, 2009; Jagtap and Johnson, 2011; Vianello, 2011;
Wong et al., 2008). Harrison (2006) asserted that implanting double-loop learning
mechanisms (Argyris and Schon, 1978)—that is mechanisms for reevaluation and
reframing underlying norms, policies and objectives of both individuals and an
organization—were needed in such settings, to challenge preconceptions and interpret
what is known in the context of new design and operating environments.

Jagtap and Johnson (2011) found that in the design of new products, or products similar
to previous offerings, in a PSS setting designers would like access to more information
related to effects and causes of deterioration at a product level. Similarly, Vianello (2011)
identified that engineering designers were interested in knowledge about changes, issues

21
 Areas of Relevance
and improvements generated during service of the equipment at a component level. Goh
and McMahon (2009) noted that service observations are currently fed back through
unstructured and disparate records, making them difficult to collate and analyze.
Therefore, learning-from-use relies predominantly on laborious manual trawling through
information or on personalization approaches (McMahon et al., 2004). They suggested that
to continually learn from the usage phase PSS companies would inevitably need a series of
organization strategies, processes, tools and methods to capture and reuse experiential
knowledge.

3.3 Theory of Knowledge

Many researchers (e.g., Alavi and Leidner, 2001; Davenport and Prusak, 1998; Nissen,
2002) have conceptualized a hierarchy of knowledge, information, and data to distinguish
between these concepts. Accordingly, each level of the hierarchy builds on the one below:
data are required to create information; information is required to create knowledge.
Briefly, data are raw numbers or facts that have no significant meaning, information is a
meaningful pattern generated from processing and interpreting data, and knowledge is
information that has been combined with experience, context, insight, and reflection (e.g.,
Alavi and Leidner, 2001; Davenport and Prusak, 1998). Knowledge involves an awareness
or understanding gained through experience, familiarity or learning (Boisot and Canals,
2008).

Numerous classifications have been developed to clarify what knowledge is and how it
can be created and shared. One of the most common distinguishes between explicit
knowledge and tacit knowledge (Nonaka 1994; Polanyi, 1967). Explicit knowledge is
formal knowledge that can be relatively easy to express, articulate, share, and transfer
(Nonaka, 1994). It consists of facts, rules, relationships and policies that can be found not
only in an organization’s documents and repositories, but also in organizational routines,
processes, practices, and norms (Davenport and Prusak, 1998; Nonaka, 1994). Tacit
knowledge is deeply rooted in an individual’s actions and experience as well as in ideals,
beliefs or emotions, which cannot be conveniently expressed or written down to
communicate or share with others (Polanyi, 1967), as noted by Wood et al. (2009, p.68)
“you just feel it”. Accordingly, knowledge that can be expressed or made explicit
represents the tip of the iceberg of the entire body of knowledge that may reside within
organizations (Nonaka, 1994), as Polanyi (1967, p.4) put it, “we can know more than we can
tell”. Nonaka (1994) have identified two elements (or dimensions) of tacit knowledge:
cognitive and technical (see Figure 4). Cognitive here refers to an individual’s mental
models consisting of beliefs, ideas, gut feelings, values, perceptions, intuition, and so on,
while technical knowledge is related to concrete know-how, crafts, rules of thumb,
hands-on experience, knowing in-action, and skills that apply to a specific context.

Another prominent classification is procedural vs. declarative knowledge (Alavi and

Leidner, 2001). Procedural knowledge is a type of knowledge someone has and
demonstrates through the procedure of doing something, i.e. knowledge gained from
experience of undertaking a task. In contrast, declarative knowledge is a type of
knowledge that indicates someone knows about something and may be more abstract
rather than a practical understanding. Several researchers have noted that procedural
knowledge is situation- and context-specific (Court et al., 1996; Goldkuhl and Braf, 2001)
and that contextualization is important to improve understanding of knowledge

22
 Areas of Relevance
(Davenport and Prusak, 1998; Nonaka, 1994). A context can be defined as the situation
in which something happens (Merriam-Webster, 2013), or a complex description of shared
knowledge about physical, social, historical, or other circumstances within which an action
or an event occurs (Brezillon and Pomerol, 2001). As knowledge is created in various
contexts, it cannot be perfectly understood when isolated from contexts (Goldkuhl and
Braf, 2001). Thus, several researchers have claimed that understanding the context of
knowledge is positively correlated with the success of knowledge transfer and reuse
(Cummings and Teng, 2003; Hicks et al., 2002; Rehman and Yan, 2010). This requires
information on who created the knowledge, and why, where, when and how it was
created and used (Ahn et al., 2005). As noted by Alavi and Leidner (2001, p.127): “When
the context surrounding knowledge creation is not shared, it is questionable whether storing the
knowledge without sufficient contextual detail will result in effective uses. This could lead to the
essence of the knowledge being lost.”

Figure 4. Tacit knowledge examples in Nonaka’s two dimensions, adapted from Nonaka
(1994) and Panahi et al. (2013)

3.4 Knowledge Management

Knowledge management (KM) can be defined as “…the systematic processes by which

knowledge needed for an organization to succeed is created, captured, shared, and leveraged”
(Rumizen, 2002, p.9). Fundamentally, KM aims to deliver the right knowledge to the
right person at the right time in the right format (Davenport and Prusak, 1998).

The different views of knowledge can lead to different perceptions of managing

knowledge and the role of knowledge management systems (e.g. Alavi and Leidner,

23
 Areas of Relevance
2001). Hansen et al. (1999) distinguished two main types of knowledge management
strategies: Codification and Personalization. The goal of a codification strategy is to
develop electronic document systems—with a major investment in IT—to connect
people with reusable codified, explicit knowledge. In contrast, the goal of a
personalization strategy is to develop person-to-person networks—with a moderate
investment in IT—that facilitate conversations and the exchange of tacit knowledge in an
informal manner. In engineering design of point of view, McMahon et al. (2004) noted
that companies, which develop highly complex, customized solutions to unique problems,
need a proper balance of these two approaches, and that supporting technology must
incorporate both of them.

Further, Huysman and de Wit (2002) categorized developments in knowledge

management into two ‘waves’. Table 2 provides an overview of the main differences
between the first and second wave of developments.

Table 2. Differences between the first and second waves of knowledge management, adapted
from Huysman and de Wit (2002)

1st Wave of Knowledge 2nd Wave of Knowledge

Management Management
Why is knowledge Managerial needs Part of daily work: as a routine
shared?
When is knowledge When there is an opportunity to When there is a need to do so
shared? do so
Where is knowledge Operational level Organization-wide
shared?
Whose knowledge is Individual: Human capital Collective: Social capital
managed?
What knowledge is Codified Tacit and Codified
shared?
How is knowledge Repository systems and electronic Via personal and electronic
shared? networks networks

The first wave of KM mainly centered on issues related to how to support the exchange
of human capital (i.e. individual expertise) to fill knowledge gaps that exist as result of
mobility, globalization and distributed work. Information technological solutions such as
knowledge repositories or content management systems were most prominent in this first
wave. However, their study showed that the first wave of KM overlooked the
importance of the community as the main knowledge producer and consumer (i.e. more
than the individual), and neglected the importance of people’s motivation to share their
knowledge and learn from other people’s knowledge. Huysman and de Wit (2002)
argued that the second wave of KM, although still in its infancy, holds that communities
will foster social capital, thereby increasing people’s motivation to share knowledge. In
the second wave the focus is directed towards the conditions that stimulate knowledge
sharing as a daily routine via personal networks. In this case, it will be the practitioners
themselves who share and manage their own knowledge, particularly its tacit dimensions
(Brown and Duguid, 2000).

Further, Schultze and Leidner (2002) stated that while the development of traditional KM
technologies, such as repositories or databases, may effectively capture some explicit
knowledge, a more comprehensive approach is required to adequately formalize, structure

24
 Areas of Relevance
and capture all knowledge types, especially those relating to conversational, tacit
knowledge. McMahon et al. (2004) noted that traditional knowledge acquisition
approaches in engineering design are still labor intensive because large quantities of legacy
data and information exist, usually in paper form distributed in multiple filing systems in
large communities of practice that have developed over many years. Hence, the tangible
manifestations of KM initiatives depend on the effectiveness of knowledge sharing
processes within an organization (Small and Sage, 2005).

Knowledge sharing processes typically involve at least two agents: the knowledge owner
(i.e. someone who possesses and communicates the knowledge) and the knowledge
recipient (i.e. someone who perceives the knowledge and uses it in a new situation)
(Hendriks, 1999). Nonaka and Konno (1998) stressed the need for a shared context
(referred to as Ba) for knowledge sharing to take place. Ba, which roughly translates as
‘place’, provides a shared space or shared context between the people sharing knowledge,
and serves as a foundation for knowledge creation. This space may be physical (e.g., an
office or dispersed business space), virtual (e.g., e-mail, teleconference), mental (e.g.,
shared experiences, ideas, ideals), or any combination of them.

Various authors have stated that knowledge sharing among individuals and across
organizations does not always flow smoothly (e.g., Ipe, 2003; O’Dell and Grayson, 1998).
Thus, most knowledge acquisition activities in organizations occurs in an informal
manner, mainly through day-to-day social interactions with colleagues and established
networks of contacts (Brown and Duguid, 2000) or through people with weak ties
(Granovetter, 1973). “People drink in knowledge informally and, at times, unconsciously. That is,
they learn much incidentally, while eating in the cafeteria, chatting in the halls, observing their
colleagues’ and supervisors’ behavior—and through the vicarious experience of others” (Swap et al.,
2001, p.98)

Nonaka and Konno (1998) described this phenomenon of organizational learning in

organizations using a four-stage spiral model of knowledge conversion, called the SECI
(Socialization, Externalization, Combination and Internalization) model (see Figure 5).
According to this model, organizational knowledge is first acquired at the individual level
and then moves upwards in an organization.

Figure 5. Knowledge conversion process, adapted from Nonaka and Konno (1998)
25
 Areas of Relevance
• Socialization is a process of sharing tacit knowledge between individuals, thereby
producing new tacit knowledge and relationships via shared mental models, shared
agreements and shared know-how.
• Externalization is a process of converting explicit knowledge into a comprehensible
form by codifying tacit knowledge through reports, models, metaphors, analogies
or concepts.
• Combination is a process of combing explicit knowledge into a complex set of new
explicit knowledge.
• Internalization is a process of embodying explicit knowledge into tacit knowledge
or an organization’s tacit knowledge through practice or learning by doing.

Hence, it is increasingly important to implant mechanisms for sharing what all employees
collectively learn from their work, and for success organizations must apply a holistic and
dedicated approach to manage these factors.


3.5 Lessons Learned

Many companies have established a formal approach to learning through a LL process

(Milton, 2010; Paranagamage et al., 2012), in order to effectively identify, capture, and
exploit knowledge gained from past projects to enhance learning and future performance
(Schindler and Eppler, 2003). Kotnour (1999) found that LL practices help efforts to
overcome the barriers to organizational learning and knowledge sharing in two equally
important ways: as a process for reflecting and identifying actions to avoid and solutions to
implement in similar projects, and a mechanism to document LL to share with others.

LL can be regarded as guidelines, tips, or checklists of what went wrong or right in a

particular event (Stewart, 1997). A statement that is increasingly cited, both in academia
and industries, as a comprehensive definition of LL is the one currently used by the
American, European, and Japanese space agencies:

“A lesson learned is a knowledge or understanding gained by experience. The experience may be

positive, as in a successful test or mission, or negative, as in a mishap or failure. Successes are also
considered sources of lessons learned. A lesson must be significant in that it has a real or assumed
impact on operations; valid in that is factually and technically correct; and applicable in that it
identifies a specific design, process, or decision that reduces or eliminates the potential for failures and
mishaps, or reinforces a positive result” (Secchi et al., 1999, p.57).

This comprehensive definition clarifies the guiding criteria, which must be considered
when implementing a LL process, for reusing lessons. According to Fosshage (2013), this
definition, (1) accepts the legitimacy of learning from successes as well as failures; (2)
reframes the LL as an artifact of knowledge; (3) re-orients towards an emphasis on reuse;
(4) clarifies the guiding criteria for reuse (i.e. significant, valid, and applicable); and (5)
focuses on the processes that a lesson can impact.

Based on a survey of several organizations, Weber et al. (2001) identified the essential
components of a generic LL process as collect, verify, store, disseminate, and reuse (see Figure
6). Accordingly, LL are collected from organizational members and verified by a team of
experts with respect to correctness, redundancy, consistency, and relevance. Later, the

26
 Areas of Relevance
lessons are stored in a repository where they are represented (with a level of abstraction),
formatted and indexed. The lessons are then disseminated to promote their reuse in
various ways, such as broadcasting through bulletins, notifications or alerts.

Figure 6. A generic lessons learned process, adopted from Weber et al. (2001)

O’Dell and Hubert (2011) stated that the LL approach typically focuses on a few key
questions:
- What was supposed to happen?
- What actually happened?
- Why was there a difference or variation?
- Who else needs to know this information?

Collison and Parcell (2001) recommended the following 12 steps for conducting LL
sessions to capture lessons: (1) call a meeting; (2) invite the right people; (3) appoint a
facilitator; (4) revisit the objectives and deliverables of the project; (5) revisit the project
plan or process; (6) ask ‘What went well?’; (7) find out why these aspects went well, and
express the LL as advice for the future; (8) ask ‘What could have gone better?;’ (9) find
out what the difficulties were; (10) ensure that the participants leave the meeting with
their feelings acknowledged; (11) determine ‘What next?’; and (12) record the meeting.

Various formats and capture techniques for LL have been reported (Disterer, 2002;
Schindler and Eppler, 2003; Williams, 2008). A few common ones are LL sessions, after
action reviews, project debriefings, post-project reviews and postmortems (Disterer, 2002).
Shortcomings of existing LL practices and systems have been well documented across
multiple industries (Disterer, 2002; Rhodes and Dawson, 2013; Tan et al., 2006; Weber
et al., 2001; Williams, 2008), especially those related to Post-Project Reviews (PPR), the
most common kind in many industries. According to Kamara et al. (2003), delays
between the discovery and capture of knowledge lead to the loss of important insights
and hinder improvement of current projects via incorporation of knowledge gained as the
projects progress. Tan et al. (2006) identified two major shortcomings with standard PPR

27
 Areas of Relevance
practice. First, the learning captured is not shared effectively and there is no established
way to locate the learning embedded in reports for reuse. Secondly, the current practice
of distilling the key learning captured in PPR in point form is too brief for understanding
and efficient sharing of the knowledge captured. Further, Goffin et al. (2010) revealed
that PPR reports are often limited to capturing merely explicit knowledge, and that much
of the tacit knowledge that emerges in PPR is likely to be lost due to difficulties in
articulating the way that tasks were performed and problems solved.

Several researchers (Fosshage, 2013; Kotnour, 1999; Williams, 2008) have argued that the
culture and structure of the organization are key factors to collect and disseminate lessons
across organization. “Most people have a natural desire to learn, to share what they know, and to
make things better. This natural desire is thwarted by a variety of logistical, structural, and cultural
hurdles that organizations create” (O’Dell and Grayson, 1998, p.157).

Paranagamage et al. (2012) suggested that company processes need to build in feedback
loops to periodically assess their effectiveness, and to ensure that the lessons are accessible
to those who need them, when they need them. In a similar line, Milton (2008) argued
that an organization needs to become “unconsciously competent” to be a learning
organization, analogously to an individual’s “unconscious knowledge”, e.g. knowing how
to ride a bike even after a long gap. He explained that organizations become conscious by
recognizing the need to learn, by acquiring learning through reflection, and finally
become unconsciously competent by embedding new learning in processes and
procedures. When the procedures are always up-to-date and consistently incorporate new
lessons, the learning has been transferred and internalized, and thus the organization has
become unconsciously competent (Milton, 2008).

Further, researchers have argued that the descriptions of the context and background of
lessons are crucial for their reuse (Chua et al., 2006; Milton, 2010; Williams, 2008).
Milton (2010) reported that two factors determine the amount of context that is needed
for lessons: their simplicity or complexity and the similarity of the context within which
they will be reused. He stated that a simple lesson (i.e. a low-context lesson) can be
documented in a few lines, expressed in a process flowsheet or diagram, and may be
captured using a template. In contrast, a more complex lesson (i.e. a high-context lesson)
may be highly situation-specific, are much more difficult to express in writing.

A number of researchers (e.g., Milton, 2010; Weber et al., 2001; Fosshage, 2013) have
attempted to identify systems that would aid organizations to collect LL. Weber et al.
(2001) found that LL systems generally serve their intended goal of promoting knowledge
reuse and sharing poorly. This is because they are not typically integrated into an
organization's decision-making process and are not structurally formatted to support
knowledge collection, storage, dissemination, and reuse (Weber et al., 2001). To address
these limitations, it is necessary to capture learning while it is happening, and present it in
a format that will facilitate its reuse during and after the project, and in other contexts
(Tan et al., 2006). Kamara et al. (2003) and Tan et al. (2006) proposed a methodology for
‘live’ capture and reuse of project knowledge, using a template featuring background
information on the project, an abstract, conditions for reuse, relevant details and
references. Similarly, Milton (2010) proposed a structure for a typical LL database entry
with five text fields for describing the lesson (see Table 3), including: context, description
of the event, root cause, lessons identified and suggested action.

28
 Areas of Relevance
Table 3. Typical format for a lesson database entry form, adapted from Milton (2010)

Field What do need to input?

Lesson title Short sentence
Lesson ID number Assigned automatically
Submitted by Name, role, department of originator
Date submitted dd/mm/yyyy
Status Submitted/approved/implemented
Topic From taxonomy (drop-down menu)
Sub-topic From taxonomy (drop-down menu)
Project name Project name
Context The context in which this learning happened— any relevant
background
Description of the event What actually happened?
Root cause What was the root causes?
Lesson identified The recommendations for the future— specific actionable
recommendation
Suggested action How can these recommendations be institutionalized? For example,
update a process, write a process, fix a problem, notify a person
Accountable person Name, role, department
Action approval date dd/mm/yyyy
Closure date dd/mm/yyyy
Lesson value If possible
Other comments and
attachments


3.6 Knowledge Lifecycle

From a process perspective, KM is often regarded in terms of a series of stages or lifecycle

phases from creation of knowledge to its use, commonly referred to as a knowledge
lifecycle (KLC) (Birkinshaw and Sheehan, 2002), which represents the learning process
within organizations (McElroy, 2000; Rowley, 2001). Different researchers have used
different terms for the same knowledge lifecycle stages (e.g., Birkinshaw and Sheehan,
2002; Blessing and Wallace, 2000; Rowley, 2001) as shown in Table 4. The
differentiating features are their perspectives, focus and level of detail (Tan et al., 2006).

Table 4. Knowledge lifecycle stages proposed by various authors

Authors Knowledge lifecycle stages

Birkinshaw and Sheehan Creation, mobilization, diffusion and commoditization
(2002)
Rowley (2001) Creation and construction, articulation, repository updating,
access, use and revision
McElroy (2000) Production (individual and group learning, claim formulation,
information acquisition and claim validation), integration
(broadcasting, searching, teaching and sharing), and application
(diffusion)
Chan and Rosemann (2001) Identify, create, transfer, store, reuse, and unlearn
Fruchter and Demian (2002) Create, capture, index, store, retrieve and reuse
Blessing and Wallace (2000) Capture, learn, store, retrieve, use, and generate
Nuzzo and Lockwood Identify, capture, store, access, share, use, learn, and
(2006) generate/acquire

29
 Areas of Relevance
Support tools for KM are not universally applicable, because different tools are required at
different lifecycle stages for organizing and modeling knowledge differently according to
the needs at different process stages (Birkinshaw and Sheehan, 2002). It has been
suggested that the KLC view provides insights into when and how knowledge might be
used and can thus help structure meaningful KM systems (Durisova, 2011). In addition,
analysis with a KLC perspective could determine the main flow of knowledge, its
direction, and place of origin, strength and the participants involved in the flow (Durisova,
2011). Hence, several researchers have proposed different knowledge lifecycle stages for
analyzing existing systems or developing new enterprise supporting systems (e.g., Chan
and Rosemann, 2001; Fruchter and Demian, 2002; Nuzzo and Lockwood, 2006).

Blessing and Wallace (2000) introduced a KLC to support designers in use of relevant
information sources, thus overcoming issues related to accessibility, availability and
trustworthiness of knowledge and information sources. They argued that current support
for product development does not deal with this issue because only part of the KLC is
addressed. “In order to know what to capture, it is important to investigate what is used. What is
captured needs to be stored in such a way that it is easy to retrieve and is relevant to the situation in
which it is going to be used” (Blessing and Wallace, 2000, p.27). Moreover, Nuzzo and
Lockwood (2006) defined KLC stages that they used to identify requirements in
aerospace industrial use cases, matching them with appropriate knowledge solution
components for the development of knowledge engineering tools.

As an extension of KLC, Andersson (2011) defined an Experience Lifecycle (ELC) for

decomposing the multifaceted experience reuse process, in order to identify and model
the activities typically involved in experience feedback (see Figure 7). He categorized two
main streams in the ELC, a capturing phase followed by a deployment phase. The
capturing phase is a push process (i.e. broadcasting of information) comprised of four
stages: the identification, capture, analysis and storage of information. Similarly, the
deployment phase is described as a pull process (i.e. users’ active search for information)
where experiential knowledge is searched, retrieved and then used in new situations.

Figure 7. The Experience Lifecycle stages, adapted from Andersson (2011)

30
 Areas of Relevance
3.7 Storytelling

Storytelling is the oldest and most traditional means of passing on wisdom and culture
(Snowden, 1999), which assists us to make sense of what we are, where we come from,
and what we want to be. Swap et al. (2001) defined an organizational story as, ‘‘a detailed
narrative of past management actions, employee interactions or other intra– or extra-organizational
events that are communicated informally within the organization” (p.103). Stories usually include
a plot, major characters, outcome, and narrative perspective, and reflect skills,
organizational norms, values and culture (Snowden, 1999; Swap et al., 2001).

Stories can capture and hold the attention of the audience because, regardless of their
educational background, role or experience, members will gain meaning from stories at
different levels (Snowden, 1999). Adaval and Wyer (1998) demonstrated that information
has more significant impact on judgments and decisions when it is conveyed in the form
of a story than when it is conveyed in a list. This is because narrative forms of information
are easy to comprehend and implications of the conveyed information are easy to imagine
(Rughase, 2002). Cognitive science research has confirmed the significance of storytelling
for memorizing information, as the extent to which people remember information is
strongly linked to the extent to which they reflect upon and integrate it with what they
already know (Schacter, 1996). According to Swap et al. (2001), if a story is sufficiently
clear it will almost certainly stimulate elaborations such as connections to the listener’s
personal experiences or evoke clear visual images, providing a vicarious experience that
increases the likelihood of being remembered. Hoegl and Schulze (2005) argued that
success stories could augment quantitative measures with additional context and meaning.
According to these authors, stories (with a measurement punch line) capture the complex
organizational context, which gives them meaning and cues to remember the measure
described. Hence, stories are more effective carriers of knowledge than less vivid, purely
listed information or statements (Swap et al., 2001).

One of the major advantages of using storytelling in an organization is that it can capture
and share tacit dimensions of knowledge (Buttler et al., 2011; Swap et al., 2001).
Research has shown that project managers, engineers, designers, and technical experts
often represent their experiences while dealing with problems through stories (Brown and
Duguid, 2000; Connell et al., 2004; Erickson, 1995). Furthermore, stories form a primary
medium for clarifying uncertainties and problem-solving as well as problem-based
learning in everyday professional contexts (Jonassen and Hernandez-Serrano, 2002; Orr,
1996).

Further, several researchers assert that telling stories is an appropriate social method for
capturing LL, especially those related to tacit, experiential knowledge (Cheuk, 2007;
Kingston, 2012; Milton, 2010; Williams, 2008). For instance, Williams (2008) argued that
the social process of storytelling and recording is an effective way to explore project issues,
capturing their complexity and behaviors outside organizational norms. Goffin and
Koners (2011) noted that stories are often used in post-project reviews to explaining LL
related to problem-solving, product specifications and budget. Milton (2010)
acknowledged that a story can support a lesson by providing valuable background and
context, and thus stories are easiest to learn from when they carry a learning point that is a
specific, actionable recommendation. “The learning is being identified within a context, and it

31
 Areas of Relevance
helps to understand the context when reviewing the lesson, so that you can know whether it applies
within your context (or not)” (Milton, 2010, p.39).

Desouza et al. (2005) compared two ways of conducting project postmortems, via
traditional reports and stories, using case studies drawn from two software companies.
Both postmortems were conducted in workshops and summarized in document form at
the end of a project, using a template with classified sections. Table 5 highlights the five
salient dimensions in which the report-based and story-based summaries differed.

Table 5. Comparison of report-based and story-based postmortem summaries, adapted from

Desouza et al. (2005)

Dimension Reports Stories

Knowledge structure Highly structured Semi-structured
Codification cost Low High
Knowledge richness Low High
Ease of comprehension Easy Medium
Ease of recallability Difficult-Medium Easy

However, Milton (2010) suggested that storytelling alone—with no analysis of the

learning points, identification of the lesson, and movement into action—is not an efficient
way of conveying information. He specified that every story should have a clear
conclusion as something that others can learn from. It is worth mentioning here that
research has found that stories describing failures or unsuccessful outcomes have the most
impact (Desouza et al., 2005). Finally, the means by which a story is communicated is also
a significant factor (Snowden 1999). If stories are powerful in verbal form, their effect can
be enhanced through the use of multimedia such as pictures and video clips (Swap et al.,
2001).

3.8 Knowledge Reuse

Knowledge reuse refers to deployment of existing knowledge, which generally occurs

after the knowledge creation and storage phases. The reuse of knowledge consists of four
activities (Markus, 2001). The first is defining the search question, which is essential for
successful reuse, partly because it has been found that a key characteristic separating
experts from novices is that experts know what questions to ask (Ahmed et al., 2003).
The second is the search for, and location of, experts or expertise. The third is selection of an
appropriate expert or expertise from the results of the search. The last is applying the knowledge,
which may involve “recontextualisation” of knowledge (Thompson et al., 2001), which
extracts meaning from the original context (if not lost through decontextualization when
the information was captured and codified) in order to introduce it into another context.
Fruchter and Demian (2002) argued that in order for knowledge to be reusable the user
should be able to see the rich context in which it was originally created and interact with
it. “Reuse often fails because knowledge is not captured; it is captured out of context, rendering it not
reusable; or there are no formal mechanisms for finding and retrieving reusable knowledge” (Fruchter
and Demian, 2002, p.127).

Szulanski (2003) identified four major elements in the knowledge reuse process: the
source, the content, the context and the recipient. These are, respectively, the creator of
the knowledge, the knowledge that is intended to be reused, the one who reuses the

32
 Areas of Relevance
knowledge, and the environment in which the knowledge is transferred from the source
to the recipient. In addition to the source and the recipient, Markus (2001) identified
another agent, the knowledge intermediary, one who prepares the knowledge for reuse
by eliciting, indexing, summarizing, sanitizing, packaging and distributing it to the
recipient.

Markus (2001) emphasized that knowledge reuse cannot be seen as a unitary

phenomenon, and that reuse situations can vary depending on who the recipients are and
the purpose that knowledge reuse serves. Accordingly, Markus (2001) proposed the
following four distinct knowledge reuse situations involving different types of knowledge
reusers: shared work producers, shared work practitioners, expertise-seeking novices and
secondary knowledge miners. Shared work producers create and document the
knowledge they later reuse, they have fewer problems with knowledge reuse than other
types of reusers. Shared work practitioners are people doing similar work in different
locations, work units, or organizations and who produce knowledge for each other’s
reuse. As shared work producers documents are often too context-specific to be of
general use or may not contain specific contextual knowledge of the producers’ settings,
practitioners often have difficulties in interpreting these documents (Markus, 2001).
Hence, practitioners frequently rely on their networks of contacts to locate experts and
documentary knowledge sources (Markus, 2001).

In a summary, Markus (2001) stated that the purpose and content of records in
repositories often differ depending on whether the record keepers are knowingly
documenting only for themselves, for others who are similar to themselves in terms of work
product or community practice, or for others who are dissimilar to themselves in knowledge
and outlook, such as members of a different department in the same organization, novices,
or customers.

3.9 Web 2.0

During the past decade, the World Wide Web (commonly known as the Web or WWW)
has undergone dramatic changes with growing maturity and development. In particular,
there have been significant changes in the way people engaged on the web create, store,
access, share and distribute content to larger audiences. O’Reilly (2005) coined the term
“Web 2.0” to describe the set of new principles and development trends evolving in the
second generation (O’Reilly, 2005). An early definition of Web 2.0 is formulated by
Musser and O’Reilly (2006) as follows: “Web 2.0 is a set of economic, social, and technology
trends that collectively form the basis for the next generation of the Internet—a more mature,
distinctive medium characterized by user participation, openness, and network effects.”

Flew (2008) characterized this transition from the static pages of earlier websites (normally
referred to as a first generation of the Web, Web 1.0) to the second generation (Web 2.0)
as a move from personal websites to blogs, from publishing to participation, from web content as the
outcome of large up-front investment to an ongoing and interactive process, and from content
management systems to links based on tagging (folksonomy) (p.36). Some of the most common
Web 2.0 applications are blogs, wikis, social networking, tagging, really simple
syndication (RSS), mash-ups, podcasts, microblogs, social bookmarking and media
sharing sites.

33
 Areas of Relevance
The adoption of Web 2.0 applications has received great attention from organizations due
to their promising potential to boost communication and networking with customers and
business partners as well as to encourage collaboration and KM internally (see the
McKinsey global survey results from 2007 to 2012, e.g. Bughin and Manyika, 2007;
Bughin et al., 2009; Bughin et al., 2011; Chui et al., 2012). McAfee (2006) summarized
this rising interest in companies with the term Enterprise 2.0 and further described the
key elements of Enterprise 2.0 technologies by the acronym, SLATES: Search, Links,
Authoring, Tags, Extensions and Signals, to highlight the business-impacting capabilities
that companies can exploit for effective use of Web 2.0 technologies in and across
enterprises.

In the KM field, several authors have proposed models aiming to empower current KM
tools via implementation of Web 2.0 concepts. For instance, Levy (2009, p.129)
compared Web 2.0 concepts and KM attributes and concluded that there are similarities
in their principles. Web 2.0 tools are considered to be able to trigger sociality and
communication among organizational members, which help to build relationship
between people, establish trust and create awareness of the importance of tasks colleagues
are working on (e.g., Boeije et al., 2009; Dave and Koskela, 2009; Kietzmann et al.,
2011). User contributions in wikis, blog posts and comments, tagging, bookmarks and
ratings form starting points for discussions, relationships and establishment of communities
(Dave and Koskela, 2009; Kosonen and Kianto, 2009). These activities benefit from the
effect of collective intelligence, which means drawing out relevant information from
individuals and combining it in a way that makes it useful (Bothos et al., 2009;
Lykourentzou et al., 2010; Voigt and Ernst, 2010). In this way, social-based Web 2.0
tools provide opportunities to complement the typical top-down approach of KM with
their simpler, smarter and more flexible modes for conversations (Avram, 2006), thereby
removing knowledge acquisition bottlenecks in organizations (Wagner, 2006).

Further, the use of Web 2.0 applications in the field of engineering and complex product
development has been suggested with the approach Engineering 2.0 (Larsson et al., 2008).
The approach started in the automobile and aerospace industries and intended to support
informal knowledge sharing across departmental and organizational boundaries. By
definition, Engineering 2.0 encompasses ‘lightweight’ systems compared with current
product design and management systems applied in engineering such as
CAD/CAE/PDM/PLM (Larsson et al., 2008). Bertoni et al. (2012) also emphasized that
traditional engineering KM approaches alone are not sufficient to support development
activities in virtual organizations, in which teams have increasing demands for social,
comparatively lightweight and flexible platforms for bottom-up, social creation and
sharing of engineering knowledge.

Finally, Panahi et al. (2013) have shown that social media can meet some of the main
requirements of tacit knowledge sharing. According to these authors, social media provide
collaborative spaces where users can theoretically: socialize; freely discuss issues; listen,
watch, and observe best practices shared by peers; build trusting relationships with like-
minded people associated with their organizations; write and share stories interactively
with support from multi-media files; reach or obtain knowledge from much wider
audiences and resources; document their articulated tacit knowledge, and share it
immediately. However, they concluded that whilst there are significant theoretical

34
 Areas of Relevance
arguments supporting the notion that social web facilitates tacit knowledge sharing there
is a lack of empirical evidence to support these arguments and further work is required.

3.10 Video Sharing

Video is an electronic medium for recording, copying and broadcasting moving visual
images (Wikipedia, 2013). The usefulness of video has long been recognized in several
domains, such as education, health, design, e-learning, crafting, and knowledge
management. Notably, video-recording technology has been used in educational settings
as a valuable tool for reflection on interpersonal skills in training sessions. For instance,
Minardi and Ritter (1999) found videotaped recordings to be beneficial adjuncts for skill
development in nursing, as they allow students to view actual objects and realistic scenes,
to see sequences in motion, and to listen to narration (Zhang et al., 2006). Further, videos
provide vast amounts of rich details using images and sound that capture the immediacy
of a real environment, providing a multi-sensory learning environment that may improve
learners’ ability to retain information (Nugent, 1982; Syed, 2001). Daily (1994) argued
that one of multimedia’s strongest contributions to learning is increased visualization.

Choi and Johnson (2005) compared learners’ perceptions of both video-based instructions
and traditional text-based instructions in online context-based learning. They found a
significant difference in learners’ motivation in terms of attention between the video-
based instruction and traditional text-based instruction. The learners reported that the
video-based instruction was more memorable than the traditional text-based instruction.

Video has also been recognized as a useful medium to support design activities (Harrison
et al., 1989; Ylirisku and Buur, 2007). Harrison et al. (1989) found it to be a well-suited
medium for supporting design communication processes, as videos by nature are
“experiential and involving, not detached and compartmentalized like text” (p.86). Ylirisku and
Buur (2007) used video as a medium to raise designers’ awareness of contexts in which
products are used in more varied ways. They asserted that video captures what happens in
the field with detailed richness—that is, portraying the personality and feelings of
people—to allow different observers to contribute their interpretations, leaving more
extensive room for discussion than text, photos and audio recordings. Another advantage
of videos is the emotive aspect of film and its ability to connect with people more
powerfully than written words (Lewis, 2008). “It’s quicker to view, it’s more appealing, and
it’s emotionally rich” (Lewis, 2008, p.28). The cited author further emphasized the inherent
power of the medium by stating that, “no matter how good the writer, words written on a page
from a communications department will never get close to conveying the sincerity and depth of
emotion that one 10-minute video did” (Lewis, 2008, p.30).

Furthermore, video has been identified as an efficient medium for conveying procedural
knowledge and tacit knowledge (Panahi et al., 2013), and invaluable for capturing subtle
or complex aspects of performed activities (Wood et al., 2009) as well as representing
overviews of key dynamic processes (Zender et al., 2006), to be uncovered by participants
in subsequent reflective analysis. The term “video-ethnography” is used to describe this
combination of participant-observation and collaborative video analysis (Leon, 2005).
Wood et al. (2009) investigated the use of videos to elicit, record and transmit the tacit
nature of complex skilled practices, such as crafting knives. They developed a web-based
learning resource—with step-by-step instructions using video demonstrations—for novice

35
 Areas of Relevance
craft practitioners based on observations and video recordings of an expert craftsman’s
working methods, tips and best practices. The study demonstrated that video-based
learning resources offer more flexible learning modes for novice practitioners to acquire
and refine difficult new crafting skills. Further, Zender et al. (2006) developed a video-
based approach for KM, documenting operational procedures and preserving
individual/group experiences during space applications development.

Many researchers have also shown that video recordings can enhance LL capturing
practice. For instance, Sharif et al. (2005) viewed videos as a medium to support a
socialization process within the context of LL practice. They added features to LL systems
allowing users to upload media files, such as pictures and videos, to enrich lessons’ details.
Similarly, Xerox technicians have proactively extended lesson representation with richer
media attachments to further promote their reuse (Weber et al., 2001). Further, the US
Center for Army Lessons Learned (CALL) has used videos for recording field observations
that are used to develop comprehensive training resources for various purposes, such as
compilation of ‘how to’ videos on military operations. The overall goal is to provide users
with knowledge that enables them to rapidly learn from ongoing practices.

Corbally (2005) distinguished three main phases in video production: preproduction

(planning), production (filming) and post-production (editing). He found that
scriptwriting was most important activity for producing purposeful videos, and factors that
should be considered when writing a script include the length of the video, source
material, timing and sequencing.

The use of video as a tool for sharing knowledge is not new. However, novel dimensions
are the Web 2.0-enabled ease and speed of capturing and knowledge in multimedia
formats then sharing it almost instantaneously online (Lewis, 2008). Results of a survey by
Bughin et al. (2011) indicate that video sharing is one of the three most widely adopted
Web 2.0 technologies in companies (applied by 38% of a sampled population). The
survey also revealed that videos are especially useful for scanning the external
environment, finding new ideas, and managing projects. These Web 2.0-enabled
capabilities facilitate video hosting services, which have enabled individuals to store and
share self-produced video clips in social web spaces such as YouTube®2(Cha et al., 2007).
In addition, they allow many social features such as annotation, tagging, bookmarking,
commenting, editing, and ranking, to increase people’s ability to find and discuss videos
across dispersed boundaries. Examples of such applications are social web videos, video
aggregations, podcasts, vodcasts, vidblogging, social video editing and livecasting
(Parameswaran and Whinston, 2007; Anderson, 2007; Redecker et al., 2009).

2
YouTube: www.youtube.com

36
 Summary of Appended Papers

4 Summary of Appended Papers

This chapter summarizes the rationale, empirical methods used, main results of the studies presented
in the appended papers, as well as the author’s contributions to the papers. The first three papers
present results from the investigation of as-is knowledge management practices from different
perspectives and the others describe development of a new methodology for LL practice.

4.1 Paper A

Bertoni, M. and Chirumalla, K. (2011). Leveraging Web 2.0 in New Product

Development: Lessons Learned from a Cross-company Study. Journal of Universal
Computer Science. Vol. 17, No. 4, pp. 548-564.

Summary
The aim of this paper was to explore how Web 2.0-based technologies can enhance
collaboration and knowledge sharing in complex, global, virtual and cross-functional
product development settings. The paper analyses the dichotomy between the prevailing
hierarchical structures of traditional product design systems such as CAD, PLM, PDM
and the principles of the Social Web in the light of emerging product development trends
(e.g., growing ‘virtualization’ and ‘servitization’ of product development organizations).

The empirical data analyzed were primarily derived from two case companies 1 and 2 to
spotlight current Web 2.0 initiatives aiming to introduce a more bottom-up knowledge
sharing approach in product development, to collect examples of applications of these
initiatives and identify associated opportunities and challenges.

The paper first addressed the challenges in coping with the emerging product
development trends from a knowledge sharing perspective: managing unstructured,
informal, tacit knowledge; knowledge acquisition and experience feedback from
geographically dispersed teams; and using ad-hoc domain-specific collaboration platforms.
Subsequently, the paper mapped current knowledge sharing approaches to the bottom-up,
Web 2.0–based approach in a two-dimensional diagram (i.e. structured vs. unstructured
knowledge and co-located vs. virtual teams). This mapping indicated that there is room
for improvement in capturing and managing unstructured, informal, tacit knowledge
across virtual, cross-functional teams.

The paper argued that to cope with upcoming product development trends a more
bottom-up approach for engineering KM is required. Based on the empirical analysis, the
paper outlined potential areas within product development in which the benefit/risk ratio
of a bottom-up approach may be particularly appealing for companies. The areas
identified are: identification of new product opportunities, locating the right capabilities
in the organization, and capturing the design intent and its rationale.

37
 Summary of Appended Papers
The paper mainly contributed to the thesis by exemplifying the importance of
experiential learning environments in the current complex engineering environment. In
particular, it emphasizes the challenges in feeding experiences from front line personnel to
the designers, identifying the right competences for solving ill-defined engineering
problems, and capturing contextual knowledge related to decisions taken in past design
projects. These outlined areas and associated challenges further guided my work in terms
of deciding the focus of the research and planning the future data collection and case
studies.

Author’s Contribution
Bertoni and I conducted the research and the analysis. Bertoni structured the paper, and I
wrote few chapters and commented on the remaining chapters.

4.2 Paper B

Bertoni, M., Chirumalla, K. and Johansson, C. (2012). Social Technologies for Cross-
functional Product Development: SWOT Analysis and Implications. In: Proceedings of the
45th Hawaii International Conference on System Sciences (HICSS-45), 4-7 January, Hawaii.

Summary
With the advent of social technologies, it is argued that the technical capability is available
to provide more effective support for knowledge sharing within a complex, cross-
functional and cross-organizational product development environment (Paper A). In
order to explore this potential, this paper analyzed the key mechanisms introduced by
social technologies—for the benefit of cross-functional development efforts—using a
Strengths, Weaknesses, Opportunities, and Threats (SWOT) framework.

The empirical analysis of the data was primarily derived from two case studies 1 and 2
within the European aeronautical industry. The SWOT framework was used throughout
the analysis to classify factors that influence, favorably or unfavorably, implementation of a
bottom-up knowledge sharing approach, and the adoption of social technologies, within
product development settings.

The paper outlined potentially beneficial and challenging areas related to the adoption of
a bottom-up approach through a SWOT analysis. Identified strengths include provision
of support for: young engineers in exploiting the network of connections; recording and
sharing contextual knowledge; capturing and structuring conversational knowledge;
keeping existing product/service knowledge up to date; reducing information overload;
and eventually the crowdsourcing of creative and innovative ideas. Identified
opportunities this approach provides include: support for more collaborative, iterative
processes of knowledge validation; facilitation of the collection of LL from the extended
organization; assistance for design teams in recognizing relevant knowledge elements for
the project context; and locating individuals with the right capabilities to contribute to
the project. Identified weaknesses hindering implementation of the approach in
engineering environments include a lack of users’ active participation, insufficient
capability to establish a culture of working with unstructured information within the
company, and inadequate validation of knowledge quality and reliability. Threats include
the risk of knowledge leakage, limited longevity of the knowledge, and self-censorship
behavior.

38
 Summary of Appended Papers
The paper mainly contributes to the thesis by arguing that the priorities in the
development of bottom-up tools (and related guidelines) for engineering lie in fostering
the ability to lower the threshold for gathering contextual information in relation to
customer needs, LL and best practices. Further, it emphasized that successful adoption of a
bottom-up strategy to cope with emerging product development trends strongly depends
on the ability to create knowledge workers with “T-shaped” characteristics (i.e. greater
depth of knowledge in a single discipline and breadth of knowledge from a diverse set of
disciplines). Hence, the opportunity areas identified from the SWOT analysis indicated
low-hanging fruits and enablers within product development, which were used as a
starting points for defining focal areas for further analysis, functional requirements and
capabilities.

Author’s Contribution
Bertoni and I conducted the research and the analysis, then collaboratively structured and
wrote the paper. Johansson commented and contributed to some chapters based on his
experience in the aerospace industry project.

4.3 Paper C

Chirumalla, K. (2013). Managing Knowledge for Product-Service System Innovation:

The role of Web 2.0 Technologies, Research-Technology Management Journal, Vol. 56, No.2,
March-April 2013, pp. 45-53.

Summary
Based on the results from papers A and B, it was observed that development of Product-
Service Systems (PSS) poses new challenges in the way knowledge is captured, shared and
managed. The purpose of the study reported in this paper was to investigate the role of
Web 2.0 technologies in capturing and managing knowledge for product-service system
development projects.

The paper was based on a case study 2 in the aerospace supply chain, which provided
insights into how companies are using KM systems and Web 2.0 tools in their regular
activities. The empirical analysis approached knowledge management from a knowledge
lifecycle (KLC) perspective through a set of stages—capture, storage, sharing, search,
access, and reuse.

The paper first identified limitations of current KM systems for PSS implementation
across the knowledge lifecycle stages and then discussed the role of Web 2.0 technologies
in addressing these issues. The study found that Web 2.0 technologies (such as blogs,
wikis, social networks, tags, video-sharing, and RSS feeds) have potential to lower
barriers to leveraging informal and unstructured knowledge, contextualized information,
networks of connections, and collective creation and maintenance of knowledge assets,
which could complement current KM systems in multi-company product development
efforts. Accordingly, the paper argued that the purpose of Web 2.0 technologies is not
simply to replace traditional KM systems, but rather to complement their strengths in
handling informal and contextualized knowledge acquisition. Moreover, the study
identified a number of methodological and technological challenges that must be
addressed before Web 2.0 tools can be widely adopted, and recommended mitigating
actions to overcome them.
39
 Summary of Appended Papers
This paper contributed to the thesis by elucidating limitations in capturing and managing
experiential knowledge, such as lessons learned in different stages of the knowledge
lifecycle. The paper also showed that enriching LL descriptions with contextual cues from
downstream phases and skill-oriented activities is critical for effective reuse of lessons in
new situations. Further, it describes the roles of different Web 2.0 methods and
technologies across the stages of knowledge lifecycle in a complex PSS engineering setting.

Author’s Contribution
I solely conducted the research, and wrote the paper.

4.4 Paper D

Chirumalla, K., Johansson, C., Bertoni, M. and Isaksson, O. (2012). Capturing and
Sharing Lessons Learned across Boundaries: A Video-based Approach. In: Proceedings of
20th European Conference on Information Systems (ECIS’12), June 10-13, Barcelona, Spain,
Paper 236, AIS Electronic Library (AISeL).

Summary
The results from Papers A, B and C highlighted the need for continuous capturing,
sharing and reusing LL from downstream product lifecycle phases in early product design
phases to enrich decision-making. Further, it has been observed that Web 2.0
technologies have potential capabilities for capturing and sharing LL across functional and
organizational boundaries. Consequently, based on the limitations identified in the
preceding studies and literature review, the purpose of this paper was to propose a
methodology and related guidelines for the continuous capture and sharing of LL in a
format that would facilitate their reuse in ongoing and early phases of new product design
projects.

The paper is based on a case study 3 conducted at facilities of an aero-engine component

manufacturer, focusing on its design practice system. The interviews and observations
provided insights into the importance of continuous capture and reuse of LL, and
highlighted shortcomings of the current design practice system. The empirical analysis
aided identification of means to address these functional requirements for the continuous
capture and reuse of LL, and thus guided formulation of the steps and guidelines for
development of the new methodology for LL practice. Methodological and technological
enablers were further developed and tested in laboratory experiment at Luleå University
of Technology and in the industrial environment to validate the methodology.

The study derived a methodology for LL practice based on seven steps and guidelines:

1) Lesson Learned Statement

2) Working Context
3) Task Description,
4) What Went Wrong or What Went Well?
5) Lesson Learned
6) Lesson Learned Measures
7) Applicability & Delimitations

40
 Summary of Appended Papers
The proposed methodology aided better capture of contextualized information and tacit
knowledge, compared to methods described in the literature, facilitating storytelling with
video as enabling technology. The preliminary verification activities showed that such
methodology improves the preparation and formulation of LL reports with richer context
from downstream phases compared to other, traditional templates and recording means.
Moreover, the paper illustrated the conceptual mock-up of a LL video portal based on
identified Web 2.0 technology enablers, with functional interfaces, for enabling cross-
functional sharing of LL, to support current design practice management systems.

This paper contributed to the thesis by elucidating the need for a methodology for the
continuous capture of rich contextualized LL in product development, and proposing a
new methodology, guidelines and technology enablers for capturing LL.

Author’s Contribution
I conducted the research, and wrote the paper, with guidance and comments from
Johansson and Bertoni.

4.5 Paper E

Chirumalla, K., Bertoni, M. and Johansson, C. (2013). Experience Feedback using

Social Media: From the Product Lifecycle Phases to the Design Practices. In: Proceedings
of the 5th CIRP International Conference on Industrial Product-Service Systems (IPS2): Product-
Service Integration for Sustainable Solutions, ed. H. Meier, pp. 459-471, Heidelberg,
Germany: Springer-Verlag.

Summary
The purpose of this paper was to illustrate how the video-based methodology proposed in
paper D could be beneficial in capturing lessons learned from different product lifecycle
phases and feeding them back to early design practices.

Based on interviews and observations at facilities of an aero-engine component

manufacturer (study 3), the authors developed a richer understanding of current
management of experience feedback from downstream product lifecycle phases. The
empirical analysis of as-is practice in experience feedback was derived by mapping an
illustrative case from the product support phase to early design phases.

The paper illustrated a routine process flow of identifying and accessing past experiences
in a problem-solving situation during the product support phase, and spotlighted the
importance of personal networks and social connections in accessing and reusing those
experiences. Further, it illustrated the process flow of documenting lessons or experiential
learning from the problem-solving activity, and showed the difficulty in feeding them
back to various early design phases.

The paper showed that the proposed methodology is useful not only for overcoming the
identified problems, but also for improving the capture of more contextualized LL from
product lifecycle stakeholders, which is crucial for reuse situations in early phases. Tests of
the video-based methodology showed that it is beneficial for feeding manufacturing,
operational and maintenance inputs to early phases of design practices at a component
level. Further, they showed that the proposed methodology could capture a learning

41
 Summary of Appended Papers
point with more specific details and actionable recommendation for reuse by component
designers in the early phases. Thus, the methodology enables better access to more
context-specific or process-specific lessons than traditional post-project specific LL
documents. Moreover, the paper presented a conceptual mock-up of a video-based LL
sharing portal with an accompanying social platform that are intended to support design
practices and associated systems in a case company.

This paper contributed to the thesis by illustrating and mapping the current experience
feedback process at the case company. Further, it described how video-based LL capture
could support feedback of experiential knowledge to early phases of product design, in a
format that could be integrated with the company’s current design practice system.

Author’s Contribution
I conducted the research and wrote the paper. Bertoni and Johansson commented on the
paper.

42
 As-Is Lessons Learned Practice: Identification of Functional Requirements

5 As-Is Lesson Learned Practice: Identification of

Functional Requirements
This chapter combines the results from the appended papers related to the research question. It first
explains the importance of learning from experience in an engineering environment, then describes as-
is lessons learned process in relation to knowledge lifecycle stages. Based on this analysis, the
following section describes functional requirements for supporting as-is lessons learned practice.

5.1 Learning from Experience in an Engineering Environment

The environment in which a product is planned, designed and produced is constantly

changing to follow dynamic, sophisticated customer needs. Manufacturing companies,
which aim to work ‘faster, better, cheaper’ than competitors from an early design phase,
have realized that this requires not only technological improvements of products, but also
leverage of customer value and reconceptualization of business propositions. In particular,
manufacturers offering high-cost capital products such as those in the aerospace, defense
and automotive sectors, are pushing the most significant revenues downstream towards
in-service or product’s lifecycle support (Ward and Graves, 2007; Wise and Baumgartner,
1999), as their products have expected lifespans of several decades.

One of the case companies, an aero-engine component manufacturer, as a first-tier

supplier, has a design and lifecycle responsibility for components of aero-engines, sharing
development costs, risks and revenues throughout the engine program, as a risk-and-
revenue sharing partner. This means that the company now needs to design and deliver
aero-engine components with lower maintenance costs and longer lifespans while
maintaining similar performance efficiency. In early phases this poses new challenges to
the case company, as it needs to acquire and access knowledge of their aero-engine
components’ lifecycle, i.e. past experiences and LL related to design iterations,
manufacturing, serial production, use, maintenance and recycling, in order to improve
early-stage decision-making (Paper A). This knowledge, distributed among both upstream
and downstream actors such as engine OEMs (Original Equipment Manufacturers),
aircraft OEMs, process technology suppliers, technical service centers and so on, requires
novel knowledge acquisition processes that extend beyond established knowledge
domains and organizational boundaries in the earliest phases.

Moreover, the early design phases have become complex and ill-defined, as timescales of
the projects from a lifecycle perspective may be upwards of 30 years. During the
conceptual phase in such cases it is difficult to identify the effects of complexities that are
not known in advance. The development teams, which are often cross-functional and
even cross-organizational, need to make critical decisions regarding their offers by
searching for and identifying relevant knowledge and experiences internally and externally,
as advised by Cooper (2003) and Ulrich and Eppinger (2008). As the knowledge and

43
 As-Is Lessons Learned Practice: Identification of Functional Requirements
expertise are geographically distributed, it is difficult to discover people “who know” and
people “who may help” with a specific problem outside the usual network of connections.
Design stakeholders who have similar knowledge and share the same interests in solving
complex tasks or possess complementary capabilities to cope with a given ill-defined
problem, are difficult to locate in a global product development setting (Papers A and B),
as outlined by one of the interviewed IT managers:

“Our group also has a naval department. Once it developed an innovative and heavily publicized
engine model, which broke down on its first public trial. Then, at the annual corporate Christmas
party, a group of naval engineers met experts from our aerospace division and started to discuss the
incident. Plenty of issues that were not properly considered during its design popped up. They went
back to work, made the modifications, and it worked. I think that’s a great story.”

This example highlights the fact that high competence is available within companies’
groups, but finding and utilizing this competence for solving complex problems is still an
enormous task. If identifying the right expertise is difficult within a single group of
companies, the situation is even more complicated in multi-partner product development.
Thus, companies may often miss learning opportunities and could consequently pay high
prices through mistakes (as in the above example) or missing opportunities for their teams
to learn from each other. In addition, in the above example, expertise was shared in an
informal, face-to-face manner at the annual meeting, which calls for new solutions that
could help practitioners to share their complex problems in an open shared space, in order
to get feedback from large groups of experts both inside and outside the company. The
same informant on the above problem conveys a similar view: “I think we need these
Christmas parties online [here I interpret that this informant is using online as a metaphor for
informal meetings], where you can easily send out questions, and the community may give you
feedback.”

Another case company, a process technology supplier to an aero-engine component

manufacturer, has been focusing on customer working processes, in a similar fashion to
the customer relationship lifecycle described by Tan et al. (2006), in order to obtain a
clear picture of a wide variety of customer needs and identify opportunities to improve
current offers from both product and service perspectives. In such cases, as described in
Paper A, the front line personnel (sales staff and technicians) know a lot about the value of
a solution for the customer. However, this experiential, tacit knowledge is still mostly
exchanged via customer visit reports or, informally, via face-to-face meetings, phone calls
and spontaneous discussions. It is not being successfully communicated with potential
stakeholders within the company for initiating development projects. One of the
interviewed process managers explains one such example:

“Once, one of our customers was trying to optimize a blade machining process using some of our
tools in his low-power machine. After a while, a technician visited his shop floor and noticed that he
had been able to get significant process improvements by radically modifying the machining settings in
a way we did not even consider in the beginning. He made a video, which was stored in a local
database. However, several months passed before he could share what he had found with one of our
product development engineers, and it happened by chance at the margins of a training event. The
movie has been further analyzed and provided relevant knowledge for the next tools’ development.”

44
 As-Is Lessons Learned Practice: Identification of Functional Requirements
This shows that many front line personnel closely observe operational problems of their
products in their customer visits. They also often store these experiences in one of the
corporate databases with the intention to share them with others. However, it has been
observed that these situation-specific experiences are not disseminated within the
companies, or at least they do not reach potential stakeholders through corporate
databases. Thus, there is a need to analyze these experiences for the purpose of creating a
feedback loop to the development process. Since no feedback loops have been established
in the company, front line staff members have too little knowledge about who may
benefit from these insights, where can they store their experiences, and so on. This is
illustrated by the above example, embedding and internalization of the technician’s
experience into company processes took longer than expected, and then only by chance.

To summarize, expertise and experiential knowledge is distributed across different

departments and organizations. In the light of evolving trends in the manufacturing
industry, learning from past experiences in the early phases of product development is
becoming increasingly important, as companies are moving towards new and innovative
procedures. This is challenging companies to ensure that a greater breadth and depth of
experiential knowledge is available from several domains in early phases and to develop
knowledge workers with greater depth in a single discipline and breadth of knowledge
from a diverse set of disciplines. As a result, companies and knowledge workers are more
prepared to deal with the complex, ill-defined problems and better to manage risks (Paper
B).

5.2 As-Is Lessons Learned Practice

The Knowledge Lifecycle (KLC) was used as a framework (see Figure 8) in this research
to understand and analyze current organizational learning and KM practices (Paper C).

Figure 8. Knowledge lifecycle stages, adapted from Andersson (2011) and Nuzzo and
Lockwood (2006)

45
 As-Is Lessons Learned Practice: Identification of Functional Requirements
KLC was selected for this as it has proved to be a valuable tool for determining how
knowledge is treated in different stages of processes (Birkinshaw and Sheehan, 2002;
Chan and Rosemann, 2001), the main flows of knowledge (Durisova, 2011), and the key
participants involved in the process flow (Durisova, 2011). Use of KLC stages—capture,
store, share, search, access, and reuse (see Figure 8)—aided assessment of companies’
capabilities to support different stages of as-is LL practices. This analysis helped to identify
potential barriers for leveraging LL to support early product design phases, thereby
defining future functional requirements for LL practice. The key results from this analysis
are presented below in relation to the KLC stages (Figure 8):

5.2.1 Capture
It was observed during Case studies 1 and 2 that experiences of customer needs, design
rationale, as well as manufacturing, operational, and maintenance are captured primarily
in the form of static text formats such as reports, spreadsheets, meeting notes, and
presentations (Papers B and C). In addition, various departments and organizations use
different terminologies, such as lessons learned and risk reviews (in design projects),
continuous improvement activities (in the manufacturing phase), and stories of product
and summary reports (in product support and maintenance phases). Typically, these are
captured and presented in different ad hoc formats.

Traditionally, experiences have been captured most commonly in post-project review

workshops, which generate LL reports organized according to a given template that
typically includes the following sections: introduction, references, a summary of the focal
LL (solution, preconditions, customer relations and agreements, execution, finalization),
major actions taken, personnel involved and appendices. The template is flexible and may
feature various numbers of sections and sub-sections. It is not necessary for people to use
all of the sections in the template. They can choose the topics that are relevant to them
and leave the rest of it empty. This mode of capturing LL was not found to be effective in
delivering the intended results (Paper D). The problems in capturing the lessons learned
from the projects were highlighted by one of the senior design leaders interviewed:

“I think that the lessons learned report is more of an end product rather part of a continuous
activity…We are so used to that it is just another document that we need to fill to get through the
system. So you do it and it tends to be quite a thin document without much valuable information.”

This shows that reporting LL at the end of a project has low priority because the people
involved have usually already been assigned to new projects, or they are so busy writing
other reports for their customers. Only a few people involved are gathered at the end to
write a LL report and then it is difficult to recall important issues encountered during the
project, due to the delay between learning moments and capturing the experiences.

In addition, as described in Papers C and D, studies 2 and 3 showed that existing post-
project text-based approaches may be suitable for capturing explicit knowledge, but they
do not allow for capture of the unstructured, tacit, procedural knowledge typically
communicated via informal meetings and spontaneous discussions in the form of stories.
This knowledge, which may sometimes be the most useful knowledge generated in a
project, is rarely captured and updated in a homogenous, continuous manner (Paper C).
Furthermore, the lessons learned in skill-oriented downstream phases, such as
manufacturing, serial production, use, and maintenance phases, which are crucial in early

46
 As-Is Lessons Learned Practice: Identification of Functional Requirements
design phases for improving next-generation products, are even quite difficult to articulate
and structure, as described by a production lead for manufacturing startup:

“I have a lot of experience in welding sheet metal parts, but it is very difficult to capture it...I know
it and I have a feeling for it, but I can only capture some of it. The problem is that I cannot go into
it deeply because I don’t know how to express it exactly on paper … so others cannot see where, how
and why details and they will not understand what is important.”

This highlights the problem of using a structural text-based format for codifying LL
related to tacit dimensions of knowledge from skill-oriented activities such as sheet metal
forming, in accordance with the findings of Wood et al. (2009) regarding knife crafting.
These lessons from downstream phases are often highly contextual and, as concluded by
Milton (2010), difficult to express in writing. Hence, when initiating a new project,
development teams may read some LL reports before they start work, but as
acknowledged by many informants, many more lessons are learnt within the company,
but they do not seem to find them because they are not usually captured in the reports.

5.2.2 Store
As mentioned earlier, lessons learned are currently captured in ad hoc formats in different
phases of products’ lifecycles, by members of different projects and departments, and
stored as different types of documents in several repositories (Paper C). The level and
quality of the reports varies between different projects and departments, and are
influenced by several factors, for instance budget, resources and the project manager’s
interest. From a design practice perspective, the major problem with current LL practice
is that LL documents and best (design) practice documents are stored in different places, as
described by one of the experienced design leaders:

“When I open a design practice document, let’s take one on a bolted joint, telling you the company
procedure for calculating and designing a bolted joint. Then I want to have a section saying that this
is what we did in other projects, what worked, what didn’t work and so on. So you get the lessons
learned in the best practice document– that is, the best practice and the history of how we did things.”

The designers are not generally dealing with problems that are well defined in a manual
or best practice document. So, they must learn a lot while performing their tasks in each
project, as each project has unique features, and storing these documents in the same
context (or same place) would help them to easily grasp best practices as well as the
history of doing things related to that best practice. Since they are now stored in different
places, the designers are missing this opportunity.

Another problem is that the LL reports are stored as project-specific documents (Paper D),
although many LL embody a generic level of experiential knowledge that may be
applicable to other products or projects. This is an even greater problem for experiential
knowledge originating from downstream phases, where LL are not strictly related to a
particular project, but usually more specifically to a particular process or a product (Paper
E). Hence, there is a need to store and categorize the LL as generic or specifically related
to a particular type of product or project context (Paper E). As argued by a product
support leader:

47
 As-Is Lessons Learned Practice: Identification of Functional Requirements
“A lot of problems that we discovered in the product support phase are from casting processes. Since
during the production most of our products undergo casting process, many of our lessons learned are
definitely applicable to several other products and projects.”

This shows that there is huge potential to apply lessons captured in serial production,
product support and use phases in new design projects based on other product types. As
these lessons are not specific to particular design projects, they are stored in different
databases in a different format under different terminology. Hence, the opportunities to
learn in the early phases are lost, as the development teams might not be familiar with
these lessons. This is corroborated by another experienced informant, stating that there is
a need to link each LL to its context and the underlying process, as follows:

“We should store lessons learned for turning, milling, welding, sheet metal forming and so on. We
should have the lessons learned for every type of process we undertake. Because these processes are
pretty much done in the same way regardless of its product X or Y.”

This means that the LL need to be stored with indexes of their context and underlying
process in order to facilitate deep learning on a specific issue. For example, if any specific
lesson is learned that is related to cleaning small holes in complex parts, manufacturing
personnel could easily learn it if it is classified at a process-level lesson rather than a
project-level lesson. Hence, it is essential to generate and store lessons at a process-based
level.

5.2.3 Share
The LL reports from the product support phase, which are stored in the Document
Management Systems, are handled by the department responsible for quality assurance in
order to generate action lists to forward to relevant department managers (Paper E). The
study found that although this is defined as a common practice, there is no exact
information on how this knowledge should be shared and fed back to other departments
internally (see Figure 9) that might need it. In design projects development teams
sometimes use tools that are owned by collaborating customers. Thus, although a project
team might have learned lessons by taking bad decisions or solutions, they might not be
allowed to share these lessons with people involved in other projects internally within the
company. By this time, another project with the same product but different geometry
might end up choosing the same bad solution, leading to the same error. Consequently,
current feedback processes from similar design projects, as well as from the operational or
use field, are not efficient in the case company (Paper E). Designers have not been
successful in getting feedback from either similar design projects or inputs from
downstream phases such as manufacturing and operational phases. Worse, with no
indication that the knowledge they share is actually applied, people may not see the value
of sharing feedback (Paper C). For instance, one product support leader said that:

“I don’t know how these lessons learned that we identified are actually spread to other projects and
departments…of course this knowledge only comes to me because I am the one asking for it. The
lessons should be stored somewhere, so everyone can see it, right?.”

Since there is no established process for experience feedback, in particular from

downstream phases to the early phases, the people involved in the downstream phases (in
the current example a product support leader) are not really aware how to share captured

48
 As-Is Lessons Learned Practice: Identification of Functional Requirements
LL to benefit others in the company. Many informants believed that these lessons are
beneficial for informing designers in pre-study and concept study phases about products’
behavior in a lifecycle perspective (Paper E). For example, as shown in Figure 9, if a
lesson might be relevant in definition stages it should be fed back to the product’s
definition department. If no design best practice related to this LL is available, the
definition department needs to establish a new design best practice, or the lesson should
be added to the checklist in the design review process (Paper E).

Figure 9. Experience feedback process from the product support phase

The major barriers for sharing LL are the restrictions imposed to maintain the secrecy of
information. Because of this, as noted by several experienced project engineers, they often
do not know what they can share or not with others in the company. They felt that the
established mechanisms should promote intuitive lesson sharing rather than following a
strict formal procedure, but current systems demand investments of time and effort to
share knowledge, as the LL contributors need to follow set instructions to formulate their
lessons.

5.2.4 Search
It was observed in the case studies that people frequently rely on personal networks when
searching for past experiences, either through asking someone they know or seeking an
expert known to their contacts, as illustrated by one of the examples described in Paper E
(see Figure 10). As shown in Figure 10, in most cases, the solution seekers need to find
someone that knows a suitable person to find good examples (e.g., of load calculations or
stress analysis), otherwise they have to perform a new analysis. One of the senior design
leaders explained that:

“The questions we tend to get are, who can help me? Who has seen this before? Where has this been
done before? What practices can be found? What should I avoid? Are there any good examples? Etc.”

49
 As-Is Lessons Learned Practice: Identification of Functional Requirements
This shows that there is a lot of ambiguity in searching for past experiences or good
relevant examples. Therefore, people are spending a lot of time on experiential
knowledge acquisition and provision, as also found in previous research (Marsh, 1997).

Figure 10. Identifying past experiences in the product support phase

Alternatively, as shown in Figure 10, the solution seekers can search for past experiences
in the Document Management System (DMS) through a “free text search” or using
either a project or document number, if (not typically) they know it. It has been observed
that the “free text search” mechanism is frequently either inadequate or nonexistent for
locating past experiences and relevant documentation stored in heterogeneous
environments from past projects (Papers C and E). For example, if a seeker enters the
word “milling” in the search box, he/she will access all the documentation with the title
milling. If the knowledge seeker is from a similar project or department, he/she can see
details of all available reports. However, he/she has to open all the documents to identify
those that are relevant. Searching for pertinent LL inside these documents is difficult
because they are either quite long or in a thin form. If the knowledge seeker is involved
in a different project, he/she may also find that a report is available, and be able to access
its reference number and title in the DMS, but not open the report to read it. Hence,
there is a need for a mechanism to access past experiences across project and department
boundaries.

5.2.5 Access
In current practice, aggregating updated and relevant LL from heterogeneous sources is
complicated by the variety of access and security levels required (Paper C). Domain-
specific databases have restricted access, apart from staff associated with a given project or
role, and are not readily available for design teams from other projects or working
contexts (Paper D). In particular, the rationale of early design decisions in past projects is
often lost or hidden in corporate databases (Paper B). The key LL related to product non-
conformance (i.e. failures to conform to specifications) in operational phases, as described

50
 As-Is Lessons Learned Practice: Identification of Functional Requirements
in Paper E, are briefly recapitulated in a “summary report” (see Figure 9) and stored in
the DMS with references to other reports. However, people who are working on the
same project can only access these summary reports. In the worst-case scenario, even
those who have worked on a project in the past cannot access their documents without
special access. Thus, knowledge seekers who want to search for past experiences within
these documents need to make a special request to access them, which further increases
the time spent by knowledge seekers in searches. One senior design leader explained this
problem as follows:

“The biggest limitation is that you may work, for example, on product X for 10 years and
accumulate a lot of experience. Then you switch to product Y, and you are then disqualified from
looking at X documents. You are not able to search for your old experience that you built up over 10
years.”

This observation shows that solution seekers do not always even have the possibility to
search for their old documents in order to base current decisions on their past experiences
or previous job roles. They can get access to them if they ask, but not automatically. This
means that there is always a limited group of people who can see compiled documents,
depending on where they work, which is not a good practice when companies are aiming
to establish a collaborative knowledge sharing environment.

5.2.6 Reuse
The company struggles to reuse experiences from past LL reports (Paper C and D) mainly
because they often lack contextual information and root-cause analysis of problems.
Lessons are also listed in reports in a very abstract manner, notably there is often no
description of either how they may be applicable to other products or projects, or who
may benefit from them. One of the experienced manufacturing leads described this
problem as follows:

“We do not go into much detail in our lessons learned. For example, if I have a problem in the
production planning I would like to find past experiences to reuse them. In the reports I can see a few
lessons learned, but they do not have detailed information on background, analysis, generalizability
and more importantly to whom it will be applicable. Without this, it is difficult to decide whether to
reuse lessons learned or not.”

The above example shows that the captured LL reports do not synthesize and rationalize
information with relevant contextualization that clarifies their applicability to subsequent
situations. A LL report with rich contextual information about, for instance, why things
do not work, root-causes of problems and where it may be applicable, can help
participants in later projects to understand the deep context of lessons, and thus facilitate
more rapid and better decision-making.

Hence, in the case company, even if relevant documents from different systems were
identified, development teams generally turned to people they knew or trusted, or to
people they had been working with for a long time, to identify and interpret the context
of LL to validate their relevance and applicability in their particular working context
(Paper C). Thompson et al. (2001) call this process “recontextualisation”, which is
regarded as crucial for applying knowledge in another context. In companies, this
recontextualisation process currently occurs in the form of informal, face-to-face meetings,

51
 As-Is Lessons Learned Practice: Identification of Functional Requirements
where knowledge seekers usually meet a group who are working on a product relevant to
a previous documented LL. In the meeting, they consider the description of the problem
in the previous LL report, and discuss the new problem to make a final decision whether
or not to reuse the documented lesson.

Another reason for the absence of context and applicability information in LL reports is
that the records tend to be biased towards short-term needs since people have difficulty
anticipating distant future needs for experience. As argued by Markus (2001), there are
different types of knowledge reuse situations, and the purpose and content of records
often differ depending on whether the knowledge contributors are knowingly
documenting:
• only for themselves
• for others who are similar to themselves in work, or
• for others who are dissimilar to themselves in knowledge and outlook

This means that knowledge contributors should decide earlier, even before capturing a
lesson, the intended recipients of captured experience. But, in reality, this is not
happening in current practice. The problem with the current situation is explained by
one of the experienced informants as follows:

“Now it feels like, okay, someone has written something about product X and you would like to use
it for another product. But the document says that this is only applicable to product X, although we
know that we use the same kind of analysis, so it should be applicable for us as well. Then you end
up doing, maybe, a carbon copy and make a separate document rather than both learning from each
other. So I think finding forms of lessons learned that are generic and making them powerful are
crucial.”

The above statement indicates that the reuse of lessons learned is restricted in the
company, due to barriers imposed in relation to project type or product type. This leads
to people reinventing the wheel in different projects or missing opportunities to learn to
avoid costly mistakes. Hence, there is a need to rethink current LL practices in order to
identify mechanisms for capturing LL based on the reuse situations and the type of
knowledge reusers, as outlined by Markus (2001).

52
 As-Is Lessons Learned Practice: Identification of Functional Requirements

5.3 Identification of Functional Requirements

Based on the knowledge lifecycle stages analysis summarized above, the following 11
functional requirements were identified to capture LL across product lifecycle phases in a
way that enhances their reuse and supports early product design phases. The identified
functional requirements include:

(1) LL should be captured in a continuous manner without any delays, i.e. if something
is learnt today it should be captured with no delay to share with the company, and
this approach should be continuously applied to everything learnt in everyday work.
(2) LL should be captured at a generic level with a focus on process- or problem-based
lessons, i.e. good and bad examples from different processes, to boost cross-project
learning.
(3) There should be an easier, standard procedure (or method) for capturing LL with no
differences between various projects and functional departments. The procedure (or
method) should not only be applicable to design projects, but also extend to
downstream phases.
(4) LL should capture richer contextual details related to lessons rather than listing them
as bullet points, including information on background, purpose, root-cause analysis,
applicability and generalizability.
(5) LL procedures should be able to support the capture of complex, procedural
knowledge especially knowledge from downstream phases, which is predominantly
tacit.
(6) LL should be integrated with design best practices, i.e. best practice documents and
LL reports should be stored in the same place.
(7) LL capturing process should facilitate the feedback of experience to designers at a
product component level.
(8) Knowledge contributors should be able to store metadata and related information to
support the sharing of LL, i.e. the LL process should have a bottom-up approach.
(9) Knowledge workers should be able to discuss and develop networks around LL in a
shared space.
(10) Knowledge workers should be able to search for and access relevant LL with no
restrictions related to their working context.
(11) The LL process should be closely aligned with business activities and objectives.

53
 Development of a Methodology for Lessons Learned Practice

6 Development of a Methodology for

Lessons Learned Practice
By drawing on the empirical findings and prior literature, this chapter outlines the journey towards
developing a new methodology for lessons learned practice. It initially describes capabilities that are
needed to deliver the functional requirements. It then presents both the new methodology and the
prototype of a lessons learned portal.

6.1 Addressing the Functional Requirements

A systematic literature review based on the observations from the empirical studies and
outcomes of the KLC analysis was conducted to identify relevant capabilities (i.e. enabling
methods and technologies) to address the eleven functional requirements. The following
section presents the rationale and justification of these choices for each functional
requirement:

(1) LL should be captured in a continuous manner without any delays

The empirical analysis confirmed that LL practice should be a continuous, ongoing
activity rather than an end product, to benefit ongoing projects and improve the quality
of LL, because LL reports often currently end up as quite thin documents with little
valuable information. Previous authors (Kamara et al., 2003; Tan et al., 2006) found that
delays between the discovery and capture of knowledge lead to the loss of important
insights. Similarly, from a 2nd wave of KM perspective, Huysman and de Wit (2002)
asserted that organizations need to share knowledge as part of the daily work routine.
Further, Milton (2008) observed that to become “unconsciously competent”,
organizations need to continuously learn lessons and incorporate them into standard
processes and procedures. These arguments call for a standalone method for capturing LL
that enables people in organizations to continuously capture LL at the moment of
discovery with no delay.

(2) LL should be captured at a generic level with a focus on process- or problem-based

learning
During the field studies, many informants emphasized that the LL captured in their
projects could help staff involved in other projects or functional departments to avoid
repeating the same mistakes. In particular, LL from downstream phases are often specific
to a particular process or a problem, which can be beneficial for designers in early phases
to recognize properties that govern product lifecycle behavior. The example from the
product support phase also emphasized that LL from this phase could be beneficial to
others in the organization, regardless of project type, as a similar casting process is
involved in manufacture of most of the case company’s products. Several authors (e.g.,
Brown and Duguid, 2000; Orr, 1996) have also stressed the importance of problem-based
learning in stimulating experience sharing. They illustrated this by describing Xerox reps’
practices of capturing and sharing their lessons at a specific problem-base level that helps
other reps to easily connect them to their daily problems and thus learn more quickly.
55
 Development of a Methodology for Lessons Learned Practice
These arguments and examples show there is a clear need for methods that facilitate the
capture of generic level LL that could leverage a single learning point in detail.

(3) There should be an easier, standard procedure (or method) for capturing LL, which
should also be applicable to downstream phases
The current procedures for capturing LL from design projects and downstream phases
have varying ad hoc formats. The current format used for design projects is flexible,
featuring different numbers of sections and sub-section, resulting in similarly diverse
formats of LL reports from different projects. In addition, there is no harmonization
between the LL reports recorded from design projects and reports from downstream
phases such as serial production, operation and maintenance. As the companies are
exploring new business models and taking over lifecycle responsibility, the LL from these
phases is becoming increasingly crucial in early design activities.

Several researchers have reported different text-based reporting formats for capturing LL
(e.g., Kamara et al., 2003; Milton, 2010, Tan et al., 2006). For instance, the template
presented by Kamara et al. (2003) features five elements: background, an abstract,
conditions for reuse, relevant details, and references, while another presented by Milton
(2010) has four elements: context, description of the event, root causes of problems,
lessons identified, and suggested action. Study 3 revealed that the company concerned has
been using a template that includes an introduction, references, summary of the LL, major
actions taken, personnel involved, and appendices. During the field study, many
informants complained that LL reports in this format do not provide sufficiently detailed
information on the background, analysis, generalizability and (most importantly)
applicability of the LLs. Thus, people often lack details about the root causes of LL, in
particular the reports do not provide the contextualized information about LLs required
to reuse them in new situations. The existing LL formats reported in the literature do not
cover all the required steps derived from the empirical analysis. Although they provide a
few steps, the guidelines for each step are very vague, and thus do not help the LL
contributor to decide what to include or exclude in a specific report. In addition,
Fosshage (2013) argued that LL templates should clarify the guiding criteria for reuse that
is any reported LL should be significant, valid and applicable, and the report should
demonstrate its impact.

Hence, there is a need for a simple, standard format for capturing LL, along with detailed
guidelines on what to include in each step, to enable their use not only in design projects,
but also in downstream phases. Based on the literature analysis and the empirical
observations, the following seven steps were derived as a standard format for this purpose
(Paper D and E):

1) Lessons Learned Statement

2) Working Context
3) Task Description
4) What Went Wrong or What Went Well?
5) Lessons Learned
6) Lessons Learned Measures
7) Applicability and Delimitations

56
 Development of a Methodology for Lessons Learned Practice
(4) LL should capture richer contextual details related to learning rather than listing them
as bullet points
The results from the empirical analysis showed that the captured LL reports are too brief,
presenting information in a bullet format without richer contextualization, making them
difficult to understand sufficiently for later reuse. Context covers the circumstances
(physical and social) in which an event occurs (Brezillon and Pomerol, 2001), including
why, where, when, how, and by whom the knowledge is created (Ahn et al., 2005).
Several researchers have emphasized that contextual information related to LL is crucial
for their reuse (e.g., Milton, 2010; Williams, 2008). Accordingly, many researchers from
different disciplines have argued that video is an efficient medium for capturing and
recording the rich context related to an event or action (e.g., Choi and Johnson, 2005;
Daily, 1994; Harrison et al., 1989; Lewis, 2008; Minardi and Ritter, 1999; Sharif et al.,
2005; Wood et al., 2009; Ylirisku and Buur, 2007; Zender et al., 2006). Video can
convey much more of the detailed richness of a real setting than text, photos or audio
recordings (Ylirisku and Buur, 2007). With their ability to scan the external environment
and capture subtle, complex aspects of skill-oriented activities (as noted, inter alia, by
Chua et al., 2006; Wood et al., 2009), videos enrich the description of knowledge with
contextual cues. Several researchers have also highlighted the potential of videos for
capturing LL (Chua et al., 2006; Sharif et al., 2005; Weber et al., 2001). For instance,
Sharif et al. (2005) viewed videos as media that are capable of providing richer details
related to lessons, are clearly easy to understand and relate to new tasks, and thus their use
improves chances for reusing lessons (Weber et al., 2001). According to the US Center
for Army Lessons Learned (CALL), with videos “users are able to witness the events in great
visual detail and relive the experience of the actual participants” (Chua et al., 2006, p.255).

Based on the above evidence from the literature, it was recognized that video recordings
are appropriate for providing rich contextual information to LL. It was also observed in
Case study 1 that frontline personnel recorded customer insights from the operational
phase by video in order to capture machining details and the environment in which
customers were using their products. This example provides further justification for using
videos for LL activities, especially in downstream phases. Studies 2 and 3 also showed that
the case company uses videos in various ways, for instance, for providing operational
instructions and training novices. However, at present there is little evidence, either in
literature or from the practice, of the use of videos for capturing LL, especially
systematically. It should be noted that a difficulty in producing purposeful videos has been
highlighted by Corbally (2005), who found that scriptwriting was the most important
aspect. “Never having written a script before, the estimation of time required to complete this was
seriously underestimated. The development of the script can be likened to the blueprint of a building”
(p.377). To conclude, purposeful videos seem to be highly suitable for capturing LL with
rich contextual detail, but guidelines should be included in any methodology for their
production.

(5) LL procedures should be able to support the capture of complex, procedural knowledge
Observations from the empirical studies showed that practitioners from downstream
phases often find difficulty in expressing their LL related to complex tasks in which tacit
knowledge usually predominates that are difficult to express in writing. Several researchers
have shown that stories or storytelling mechanisms help organizations to capture and
leverage tacit and procedural knowledge (e.g., Buttler et al., 2011; Brown and Duguid,
2000; Cheuk, 2007; Goffin and Koners, 2011; Milton, 2010; Orr, 1996; Swap et al.,

57
 Development of a Methodology for Lessons Learned Practice
2001; Williams, 2008). Stories are useful vehicles for capturing complex situations in a
way that listeners can engage with and understand on a deep level (Goffin et al., 2010).
Orr (1996) found that Xerox’s technicians employed storytelling for sharing problems,
solutions and best practices from their day-to-day experience. “Stories are good at presenting
things sequentially (this happened, then that)…causally (this happened because of that). Thus stories
are powerful ways to understand what happened (the sequence of events) and why (the causes and
effects of those events)” (Brown and Duguid, 2000, p.6).

In addition, Williams (2008) found that capturing stories related to lessons is beneficial for
illustrating how situations occurred and their ramifications. Milton (2010) reported that a
story could support a lesson by providing valuable background and contextual
information that carry a learning point in the form of a specific, actionable
recommendation. Many informants in the case studies noted that they often share LL in
the form of stories in an informal manner, especially while explaining lessons related to
problems or successes in past projects. This calls for a method to leverage storytelling
mechanisms to structure and capture LL related to complex, procedural knowledge. The
value of rich media such as video for storytelling is emphasized by Swap et al. (2001), and
for enhancing the visual qualities of stories and conveying tacit knowledge by Panahi et al.
(2013). However, in the research this thesis is based upon it was observed that merely
making a video showing some stories from a project does not adequately capture LL
(Paper D). Any LL video must be factual, technically correct, valid and applicable to
specific tasks, processes and decisions (Paper D). Hence, appropriately structuring a video
displaying a LL story is crucial to reap the potential benefits.

(6) LL should be integrated with design best practices

In current practice, there is no possibility to access the related LL reports along with the
best practices. Embedding social functionalities linking the LL and best practices databases
could allow people to share their project experiences connected to specific design best
practices. The emerging Web 2.0 capabilities, such as bookmarking, could provide easy
sharing interfaces between the databases. Further, embedding URL (Uniform Resource
Locator) functionality could enable video links to be directly pasted into best practice
documents. However, solving this problem does not only have technical dimensions, but
also depends on the culture of the organization (Paper C).

(7) LL capturing process should facilitate the feedback of experience to designers at a product
component level
The empirical analysis showed that no direct feedback mechanism has been established in
the case company to share LL from different product lifecycle phases with designers at a
component level. Weber et al. (2001) reported five dissemination mechanisms for LL
practice: passive, active, proactive and reactive dissemination, and active casting. The
empirical analysis showed that there is a need for active dissemination of LL, i.e. pro-
active notification of relevant lessons, to potential users after uploading a new LL into the
database. Embedding social functionalities in the LL database could facilitate the sending
of alert notifications to relevant users via RSS feeds (Paper C).

(8) Knowledge contributors should be able to store metadata and related information to
support the sharing of LL
In current practice, the people who finally submit LL reports in the database add related
metadata. Chua et al. (2006) and Markus et al. (2001) claim that the people providing LL

58
 Development of a Methodology for Lessons Learned Practice
reports have good knowledge of who may benefit from them (although information
obtained in the case studies reported here conflicts with this claim). If so, this provides
possibilities for the knowledge contributors to add metadata and other related information
that would enhance the sharing capabilities of captured LL (Boeije et al., 2009). Tagging
functionalities provided by Web 2.0 technologies could allow LL contributors to
collaboratively classify and index captured LL videos in various categories to facilitate
subsequent retrieval (Paper C). The empirical analysis suggested the following tags to
improve categorization of LL videos: Role, Project, Product Type, Lifecycle phase,
Discipline, Area of Impact, Stakeholders, and Validator (see Figure 11).

(9) Knowledge workers should be able to discuss and develop networks around LL in a
shared space
The empirical analysis showed that most LL-related networking is currently based on
personal contacts on an as-needed basis. Web 2.0 technologies such as blogs, video
sharing sites and social networking sites, with their interactive conversational formats,
networking capabilities and user-generated content, significantly lower thresholds to share,
discuss and develop an informal network (Bertoni et al., 2012; Dave and Koskela, 2009;
Kosonen and Kianto, 2009; Levy, 2009; Lykourentzou et al., 2010) around LL practice.
In addition, feedback mechanisms, e.g., likes, and rating/ranking functionalities can help
in raising the awareness of key issues in organizations.

(10) Knowledge workers should be able to search and access relevant LL with no restriction
related to their working context
As discussed earlier, the empirical analysis detected several problems in searching and
accessing relevant LL from different projects. Tagging could help to form a folksonomy
or tag cloud allowing LL seekers to see visual displays of tags in an abstract manner and
thus facilitate easy browsing of LL. Another possibility is to develop a case-based LL
database that people can search and access relevant LL cases using defined filtering
mechanisms.

(11) The LL process should be closely aligned with business activities and objectives
The empirical analysis showed that LL practice has to be considered as a part of the
strategic goals in all projects. Capturing LL from projects should be given high priority
and the required resources need to be considered in every project. As stage-gate product
development procedures are currently applied in design projects LL practices should be
integrated with these procedures. In current practice, at every gate, the progress of
projects is assessed in relation to cost and time targets. It is important to consider “learning
targets” at each gate to assess how many LL are captured and internalized within the
company.

59
 Development of a Methodology for Lessons Learned Practice

6.2 Methodology for Lessons Learned Practice

As previously described, a standard format with seven steps was derived from the research
for representing contextualized LL—using videos and storytelling (Paper D). A set of
guiding questions have been formulated for each step to help users to formulate their LL
in a clear, concise, and informative manner, as shown in Table 6.
Table 6. Layout of the proposed lessons learned methodology format

No Steps Guidelines Notes

1 Lesson Learned Shortly summarize the main points about this lesson and why it
Statement is important for others to know.
2 Working Describe the background of the task:
Context Name of person, job role, product type and project name?
What is the operational level of the task within the product
development process? Who are the stakeholders?
3 Task Briefly describe the task:
Description How was the task planned/executed? What key parameters or
tools were used? What are the conditions when the task was
executed?
4 What Went Describe problems/successes that you came across
Wrong or Well? during the activity:
What was the problem/favorable outcome? Where/How did
you identify the problem(s)/favorable outcome? What is the
effect of the problem(s)/success on task execution?
5 Lessons Learned Describe the lesson that you learned:
What are the root-causes of problem/success? What steps have
you undertaken to solve the problem or to find the success?
How can the problem be avoided or how can the success be
repeated?
6 Lessons Learned Describe the measures of the improved solution of the
Measures problem(s):
How can your LL improve the problem area or success area?
How would you quantify the change/ improvement compare it
with pre-existing solutions?
7 Applicability Describe the applicability or limitations of the lesson
and learned:
Delimitations Who are the potential beneficiaries of your lesson? Where can
the lesson be applicable? What is the level of quality? What
additional activities are necessary? What are the limitations of
your lesson?

These seven steps and guidelines together represent the proposed new methodology for
LL practice (see Paper D for the rationale and detailed explanation of these seven steps):

1 - LL statement: This is a brief statement (short sentence) introducing the LL to

knowledge seekers that summarizes the main points and explains why it is important.

2 - Working context: This provides information about the background and working
situation of the task that the LL concerns, including the person’s name, job role, project

60
 Development of a Methodology for Lessons Learned Practice
name, type of product, and operational level within the phases of the global product
development process, and a list of stakeholders involved during the task.

3 - Task description: This is a short description of the task the LL concerns, including
how it was executed, the conditions and circumstances where it was executed, and key
parameters or tools that were used.

4 - What went wrong or what went well: This is a detailed explanation of successes
or failures during the activity. It pinpoints where—and how—the problem/favorable
outcome occurred as well as its effects on execution of the task or project.

5 - Lesson learned: This is a detailed description of the LL, recognizing the new or
improved solution to avoid the problem or repeat the favorable outcome, including any
additional relevant experiences. It focuses on what was learned that would benefit the
performance of a future activity or project.

6 - Lesson learned measures: This describes how effective the LL was, for instance
some measure of its effects on performance, such as a quantified change in time, costs or
quality in the process relative to previous conditions.

7 - Applicability & delimitations: This spells out the applicability of the LL in terms
of tasks and projects, including (for instance), potential beneficiaries (or target audiences),
for whom it may be applicable, its limitations, and additional activities that may be
required for further validation.

6.2.1 The process for video-based lessons learned practice

From a process perspective, the proposed methodology for LL practice consists of six
stages (adapted from Weber et al., 2001; Andersson, 2011), including (Paper D):

1. Identifying the LL during an activity

2. Preparing the LL story using the methodology (seven steps and guidelines)
3. Capturing and recording the LL using a video
4. Storing the LL video with appropriate tags and secrecy level settings for validation
5. Approving and sharing the LL video on the portal (with tags and secrecy level) by
the validator
6. Sending notification of new LL video to potential LL users based on the tags
7. Learning and reusing the LL in a new activity.

6.2.2 Prototype of a video-based lessons learned capturing portal

Based on identified capabilities in chapter 6.1, a conceptual mock-up of a video-based LL
capturing portal with the following features and interfaces was developed (Papers D and
E), as shown in Figure 11. YouTube® served as a video repository during the first round
of experiments and as a platform for testing basic tagging and annotation functionalities. A
number of other video hosting services (Wikipedia, 2013) have been further analyzed to
identify functionalities, which could cope with the addressed capabilities that emerged
from the empirical studies.

61
 Development of a Methodology for Lessons Learned Practice
The prototype contains the following functionalities and functional interfaces (Papers D
and E):

- Title of the video

- LL recorder’s name, job role and date of recording
- “Like” feature to let viewers convey their responses to the LL video
- Information on numbers of views, likes, average rating and numbers of voters
- A bookmark link to follow the LL’s recorder for networking
- Annotation links of the proposed LL methodology’s seven steps as an overlay on
top of the video in order to facilitate browsing of relevant topics to the LL to save
time.
- Six browsing pointers on the video status bar to symbolize the seven steps in the
LL to enhance browsing time.
- A “Share” bookmark link to allow an LL contributor to quickly add video clips to
the project blogs, design (best) practice system, intranet, departmental sites, and so
on.
- A “Product Lifecycle timeline” bookmark link to allow an LL contributor to add
videos to the corresponding product’s component best (design) practice within the
design practice system.
- A “Validator” bookmark link to help an LL contributor to identify and add
relevant experts on the concerned LL topic, discipline and area of relevance for a
quick validation.
- A “Secrecy level” bookmark link to allow an LL contributor to set the accessibility
of the LL video, depending on the secrecy of the LL content. Based on the study,
four secrecy levels have been defined, namely accessible by the: product function
group, internal organization, open to other business units, and suppliers.
- An “embed” feature to allow users to copy and paste the video link in documents,
best (design) practice reports, and so on.
- A “Tagging” functionality to let LL contributors collaboratively classify and index
the captured LL video under various categories to facilitate subsequent retrieval.
The following tags are currently proposed for optimal categorization: Role,
Project, Product Type, Lifecycle phase, Discipline, Area of Impact, Stakeholders,
and Validator (see Figure 11).
- A “Comment” functionality to allow other people in the organization to view the
LL video and add their reflections and insights.

62
 Development of a Methodology for Lessons Learned Practice

Figure 11. Conceptual mock-up of the video-based LL capturing portal with functional
interfaces of bookmarks, tagging, commenting and secrecy levels

63
 Preliminary Validation

7 Preliminary Validation
This chapter presents the results from preliminary validation activities conducted in the form of a
laboratory experiment, an industrial experiment and a design experiment.

7.1 Validation Activities

The validation of proposed methodology is performed at three occasions with different

set ups (see methodology chapter for details on experimental set ups): a laboratory
experiment, an industrial experiment, and a design experiment.

7.1.1 Laboratory experiment

A first experiment was conducted with two researchers at Luleå University of Technology,
who captured two LL on video. The first concerns a droplet problem that occurs in
hybrid welding, and the other a maintenance problem in railways’ mill liners. A
screenshot from the captured LL video regarding the welding droplet problem is shown
in Figure 12 and a transcript of this video is presented in Table 7.

Figure 12. Screenshot from the welding droplet problem lesson learned video

Laser welding is a highly-skilled knowledge-intensive activity with many input parameters

that needs to be managed correctly to avoid a multitude of defects arising from the
operation. Table 7 summarizes one such LL, where contextual knowledge related to the
droplet problem in welding is provided in a storytelling way with background details, and
a description of the problem, what went wrong, the LL and its applicability. It was
observed during the experiment that while explaining the LL, the researcher pointed out
the position of the droplets on the welding plate several times. Thus, using the video
medium for LL provided the participant opportunities to show the exact location of the
problem. This mode of capturing LL enables visual display of the physical location and
the contributor, which has more emotional impact than written words, as asserted by

65
 Preliminary Validation
Lewis (2008), because of its ability to connect with people more powerfully. Furthermore,
it captures more contextual knowledge related to a specific LL by capturing answers to
key questions, for instance, where the problem occurred, how it occurred, why it
occurred, and who noticed and captured it. According to Ahn et al. (2005), answers to
these questions provide knowledge with rich context.
Table 7. Captured LL story on the hybrid welding droplet problem (transcribed from the
LL video)

Lessons learned statement

This lesson learned is about how to get rid of these droplets (showing the welding plate) that
can be formed when you weld thick materials– that is, about 5 mm or so.

Working context
My name is Jan Karlsson and I work at LTU’s Production Development. We are currently
researching laser welding. To be more precise, I am doing some experiments on hybrid
welding. That is we use conventional MAG with lasers and we combine them in the same
process.

Task description
Many parameters may be wrong. We often have very inconsistent results, and don’t really
always know why. Take this for example (showing the welding plate), in this surface here we
have some undercuts at the side of the weld, but that is not a problem in this case. Rather the
problem is these droplets that have formed on the root side of the weld.

What went wrong?

Now we have discovered that if we use too low laser power, we can get these droplets
(pointing out the position on the welding plate). If we have the wrong focal position or such,
these should not be formed. But for some reason when we are using hybrid welding, we are
getting them when we are just about to get full penetration in the weld.

Lesson learned
One way to solve the problem is simply to increase the laser power. That is the lesson we have
learned.

Lesson learned measures

We have not evaluated this yet. So we need to do more research, but the key to avoiding
these droplets is simply to increase the laser power.

Applicability & delimitations

In industry, they do not want these droplets that have formed here. But they want to save
money, so they want to use as low power as they can and progress as fast as they can. They
want to have high welding speeds at low power. But in some cases that is not possible to
achieve. In this case, they really need to increase the power to have welds with sufficient
quality, because this is not acceptable in any situation.

After the experiment, both researchers stated that the seven steps and guiding questions
were helpful for easily preparing and formulating their LL, as described by one of the
researchers:

“Having a template is very helpful. It always takes time to think about the best order to tell things
and which restrictions to use. A template is a clear and very useful tool to structure a lesson learned
in a better way.”

66
 Preliminary Validation
Having difficulty in writing down their insights regarding their skill-oriented activities
such as laser welding and maintenance, they also felt difficulty in explaining the LL in a
narrative form in the video. This response is similar to the argument presented by
Corbally (2005) related to the challenges in preparing scripts for video recordings.
However, the outcomes of the experiment showed that the researchers could overcome
this problem by following the methodology with the seven-steps LL representation and
guidelines. The advantage of the methodology, as highlighted by one researcher, is that it
considerably reduced the time and effort he spent in the preparation and formulation of a
LL. The methodology allowed him to prepare the LL in advance and then he had an
opportunity to prepare the material concisely to fit the limited amount of time to convey
a sharp message. The researchers were asked how easy they found the method to use
compared to a text-based LL approach. One of the researchers said that the video-based
recording of LL is potentially useful for capturing and showing complex situations in his
domain, laser welding. He explained the advantage of using the video medium for LL
practice as follows:

“You can include audio comments while showing devices or pictures, providing more intuitive
explanations for the lessons learned. These videos also seem to take less time to make than written
reports.”

However, he noted that when capturing LL, some time is required to think about
whether the information is relevant or not, whether it will be for personal use or for
reporting and so on. So, adoption of the procedure would improve as more experience is
acquired. According to the researchers, with using methodology, video-based LL can be
easily captured and stored with abundant contextual knowledge, which is otherwise likely
to be lost as things are forgotten or not articulated. This is particularly important as laser
welding and maintenance activities are widely considered skill-oriented activities, where
expert knowledge usually resides in the heads of individuals in tacit form (Paper D).

To summarize, the aim of the experiment, to test whether the methodology is helpful for
capturing LL from skill-oriented activities, was fulfilled by producing two contextualized
LL videos in a narrative form. A screenshot from one of those videos, and transcript, are
presented here. The experiment also highlighted the improvement in adoption of the
methodology as more experience is acquired in producing video-based LL.

7.1.2 Industrial experiment

Three industrial practitioners (a quality leader, product support phase design leader, and a
stress analysis leader) tested the LL methodology. A screenshot from the resulting LL
video and a transcript is shown below in Figure 13 and Table 8, respectively. This
captured LL is from the serial production and product support phase. The design leader
prepared and explained a lesson-learned story regarding inspection criteria, following the
methodology’s steps and guidelines, as shown in Table 8. This LL from the product
support phase is context-specific knowledge, which needs to be shown and explained in a
visual manner, as shown in Figure 13. In the experiment, the practitioner pointed out the
relevant location on the product five times, as shown in Table 8, to show the
circumstances in which the problem and lesson identification occurred (as in the earlier
laboratory experiment). Thus, video-based LL can captures what happens in the field with
detailed richness, as claimed by several authors, such as Wood et al. (2009), Ylirisku and
Buur (2007) and Zender et al. (2006).

67
 Preliminary Validation

Table 8. Captured lesson learned story about inspection criteria in a serial production
(transcribed from LL video)

Lessons learned statement

During large-scale serial production of casted parts, it would be much too costly to check all
the dimensions specified in the drawings. Therefore, generally a plan for reduced inspection is
formulated in association with the first article inspection review (FAIR). This lesson learned is
basically about the criteria that must be met to accept the reduced inspection plan.

Working context
My name is Stefan Jansson. I have been working at (…) for the last five years. Currently, I
work as a design leader in the Trent 900 Intermediate Compressor Case (ICC) product
support team. This ICC is part of (….)’s Trent 900 engine, which is mounted on the (…..)
airplane (pointing to it in the video). The stakeholders related to this task will be design and
quality control personnel at the company or the casting supplier, which in this case is the
American company (….).

Task description
During visual inspection upon parts arrival, it was suspected that the front engine mount
package (pointing to it in the video) tilted somewhat. In order to check this, we decided to
thoroughly measure this front engine mount lug. During this thorough measurement it was
concluded that the front engine mount was tilted, but also these regions (pointing to them in
the video), which we call bridges, between the lugs were a bit too thin, thinner than specified
in the drawing.

What went wrong?

The problem was that the casting supplier changed the casting process after the first article
inspection review. During the first article inspection review, this dimension here between the
lugs (pointing to the location in the video) was excluded from the inspection plan. However,
what they should have done was that as soon as they changed the casting process the reduced
inspection plan should have been updated to make sure that any excluded dimensions were
still fulfilling the drawing requirements. The problem with this deficit in the mean thickness of
the bridge region is that the component’s life fatigue was not fulfilling requirements anymore
(pointing it in the video). This came to our knowledge after we went through the first article
inspection review documents and discussion with the clients.

Lesson learned
One of the root causes of this problem was that the initially accepted reduced inspection plan
was never updated after the casting process changed. In order to find this root cause, we
performed “5 times why” analysis, both here at the company and together with the casting
supplier. In addition, we performed what we call a Kepner-Tregoe exercise, which is also an
analytical procedure to find the root cause of problems such as this. To avoid this problem
occurring in the future, our quality department will send out a requirement document clearly
stating that after changing any casting process after an initial FAIR, a delta FAIR needs to be
done to ensure that all the part’s dimensions still meet requirements.

Lesson learned measures

I believe that this lesson learned will have a significant impact on both our product’s technical
requirement fulfillment and costs, because if we can identify and resolve such problems, we
won’t need to do repair work and obviously the product cost will be lower. In addition, we
won’t have to handle non-conformances that we would usually discover later in the process.

Applicability & delimitations

I believe that this lesson learned is relevant for all the company’s casted products. It should be
vital to everyone working within design, quality and production.

68
 Preliminary Validation

Figure 13. Screenshot from the serial production inspection criteria lesson learned video

From the questionnaire responses it was observed that two out of three of the
practitioners (the quality leader and design leader) found that the methodology with well-
defined steps and guidelines was helpful for structuring a LL in a meaningful way. One of
the practitioners said that:

“I think that the template is a good help to define the lessons learned generation process. If prepared,
I think this is a good way to spread information from experience.”

This means the practitioners found that the methodology is good enough to guide them
to generate LL from downstream phases, such as manufacturing and product support
phases, with more details. As they lacked a generic level format to capture process-based
LL from downstream phases, they believed that the proposed methodology is a better
choice to leverage these high-context specific lessons than current alternatives (Paper E).
The third respondent (the stress analysis leader) found it difficult to summarize the
simulation and stress analysis results in a narrative form, despite being enthusiastic about
trying new methodology. The main reason was that this LL has many technical
parameters and technical graphs, making it difficult to explain in a narrative form. In
current practice he often shares this lesson with others in a Powerpoint presentation.
However, he said that more practice would help him to structure a decent story that
would be useful to others in the organization.

The practitioners were asked how easy they found the method to use compared to the
text-based LL approach. All of them agreed that experience-based “knowing” is easier to
record with video-based LL methodology compared to the text-based approaches (Paper
D). This is described by one of the practitioners as follows:

“Using videos for lessons learned can be beneficial as it allows us to capture and highlight good or bad
examples from production such as design mistakes found in the manufacturing phase… That cannot
be easily documented to understand them. You have to see them. I mean it is easier to see someone
explaining how a fixture works than to read about how to fix it.”

69
 Preliminary Validation
This shows that video-based LL opens up new possibilities for people involved in
manufacturing and later downstream phases to provide a rich overview of processes,
especially for highlighting specific features of product components. According to the
practitioners, these videos could allow them to provide recommendations to designers at a
specific component level. For instance, if the designers are working on a casted product,
using video LL they can be shown visually that “You should think about these problems
in the design phase. In this way, video-based LL can convey a learning point with more
specific details and actionable recommendation to the component designers in early
phases, enabling them to access more context-specific lessons than traditional post-project
specific LL documents (Paper E). In addition, all practitioners agreed that it is easier to
capture people’s interest by a video than by a written document, as concluded by several
previous authors, e.g., Daily (1994), Lewis (2008), Syed (2001) and Ylirisku and Buur
(2007).

However, the practitioners also agreed that behavioral changes are required to adopt the
new methodology (Paper C). They emphasized that motivating people to appear in
videos and explain their LL would be a major challenge, but also said that this does not
apply only to videos, but also to implementation of any new procedure within the
company. Implementation of training programs and aligning the capturing process with
routine business activities are considered to be crucial (Paper C). To improve adoption of
the new methodology it will be important to provide users with detailed guidelines for
preparing, producing, editing and publishing well-structured videos. One practitioner
noted the importance of training as follows:

“I looked at it [the methodology] for the first time just 5 minutes before we started making the video,
and if I had looked at it more closely, I could have understood it better and produced a better lessons
learned video.”

This response echoes similar opinions expressed by researchers in the earlier laboratory
experiment, that more practice would help them to produce better videos, and was
corroborated by recordings of the time taken to capture an LL by the participants (Figure
14).

Figure 14. Decline in time taken for capturing video-based lessons learned in three trials

70
 Preliminary Validation
It was found that the time taken (including all the steps they took while recording the
video) substantially declined with increases in the number of trials, for instance for
industrial participant 1, from 25 minutes in trial 1 to 10 minutes in trial 3. This shows that
practitioners can produce LL videos more quickly after acquiring experience.

The case company of studies 2 and 3 currently changes process flows in its Design
Practice System based on identified lessons or experiences that lack the rationale for
reported modifications (Paper E). In such contexts, LL videos have been found to be
useful as rationale carriers to explain to novice engineers why processes are as they are and
why products are the way they are. Thematically classified LL captured by video could
provide a valuable knowledge base for tutorial-based training for novice engineers as well
as for development teams before they begin new design projects. All of the practitioners
believed that such a video-based solution would be useful for fostering a cross-project
learning environment within the company by disseminating LL from successful and
unsuccessful outcomes, for instance good and bad examples from production and
inspection, leading towards a “strategic knowledge distillation process” according to Chua
et al. (2006) and Thomas et al. (2001). From a design practice perspective, video-based
LL could complement Design Practice Systems if they were compiled with design (best)
practice documents in one place. This could substantially improve the learning capability
of the organization by providing easy access to both working instructions and the history
of doing things (i.e. good and bad examples) in the form of LL at the same time. This
could leverage problem-based learning that enhances novice workers’ deep learning on
various complex issues. In accordance with claims by Nugent (1982), Choi and Johnson
(2005) and Lewis (2008) regarding the information a person can absorb when watching
videos rather reading a lot of text, one of the senior design leaders said that:

“You know the saying that a picture is worth 1000 words. Then imagine the flow of pictures in a
video. You are seeing things happening, and then you really understand what is going on, what is it,
how it works and so on.”

This implies that using videos for capturing LL provides more background and contextual
understanding of complex issues, thereby stimulating learning and reuse in new situations,
as identified by Markus (2001) and Thompson et al. (2001).

To summarize, the experimental results showed that the methodology helped industrial
practitioners by lowering the threshold for capturing experiential knowledge from
manufacturing and product support phases with richer context. These videos proved to be
useful as rationale carriers and good training materials for novice engineers because they
capture a single learning point at a process-specific level, including specific details and
actionable recommendations to support the early design phases. It was also observed that
the time taken for capturing LL videos declines with increases in the number of trials.

7.1.3 Design experiment

A design experiment was conducted with three student groups to further test the
proposed methodology from both capture and reuse perspectives (see methodology
chapter for details of the experimental set up). On a first occasion, two teams performed
the exercise, one of which (group A) did not successfully perform the design task,
whereas the other (group B) was successful. Both groups were asked to prepare LL videos:
Group A by following the methodology (i.e. structured) and group B without following

71
 Preliminary Validation
the methodology (i.e. unstructured). Screenshots of groups A and B video-based LL are
shown in Figure 15.

Figure 15. Screenshots from captured LL videos produced in the design experiment by (a)
Group A following the methodology and (b) group B without using it

A third group (C) performed the same exercise with the help of the two captured LL
videos produced by groups A and B, and was able to design the bridge successfully. They
said that the captured LL videos from the other groups were highly beneficial for
executing the design task. One of the participants stated that:

“I like group A’s lessons learned video. It was very descriptive of things like what is the task, what
we are going to do in the task, etc. If I had seen them in the other order, I wouldn’t have understood
as well as it…By seeing how they solved the problem, I understood how they made the parts
stronger...So I didn’t have to make the same mistakes again.”

This conveys that the participant found the LL videos informative, especially the one
made according to the methodology, which helped him to understand the order of the
design task better than the other video. Three out of four participants agreed that group
A’s LL video was more useful than group B’s. After watching group A’s video, they noted
that they learned substantially faster and at least executed the “trial-and-error” task with
no error. In addition, the structured video included detailed information about the design,
which helped them to understand the right order for the design phases, as well as the
detailed solution that did not work well on the first occasion. They felt that group B’s
unstructured LL video lacked a detailed description of the task, i.e. the context of the task,
problems and lessons learnt, which is important for the reuse and applicability of the
video in a new situation. One informant explained the problem with this video as follows:

“I guess group B’s video lacks description of the task. They kind of went straight to the detailed
solution instead of giving overall details. I would probably describe the task first like group A did:
this is what we are going to do, we have these materials we can use, and then, like group B, I would
have shown the solution details.”

From the perspective of LL reuse, these statements show that the structured LL video,
produced following the proposed methodology, helped the team to understand solutions
that could work and which would not in the right order. In particular, they understood
the rationale for each decision previously made by group A. This reduced the number of
solution alternatives usually tested during initial stages of a design task. They felt that this
72
 Preliminary Validation
was the main reason why their group was able to complete the design task successfully, as
they avoided downtime at the beginning of the exercise. They said that they had taken
techniques that worked from the video and then improved the solution to build a new
bridge platform. This shows that the structured LL video helped the team to understand
the context of the previous design task more thoroughly by providing details of the task
one-by-one in the right order. In contrast, the unstructured LL video did not provide
details of the design task in an appropriate order, instead it went straight to the final
solution of the task. In general, from the perspective of LL reuse, all of the participants
agreed that the video medium is useful for recording LL.

From the LL capturing perspective, group A found that the seven-step LL methodology is
very helpful for guiding and producing structured videos. While explaining the value of
this methodology and guiding questions for video production, one informant said that:

“There seems to be a lot of pressure to say things straight away in a 3 minutes long video. Using the
methodology, we can decide let’s do this in 20 seconds, then I can choose what to say or show and so
on. Then it’s really concise when you work like this. Because you have the headline, task description,
what went wrong, lessons learned and so on.”

This conveys similar responses to those observed in the laboratory and industrial
experiments. In the above statement the informant is addressing the problem in producing
a LL-capturing video for the first time. He found that the questions in the methodology
helped him to prepare and record the LL video in a structured, sequentially ordered form.
But again, he noted that pauses between these seven steps might consume lot of time for
editing the video. He believed that more practice in using the methodology would be
helpful for remembering the whole structure and thus reducing the time required to edit
LL videos as only minor editing, e.g. when someone stops for a few seconds between
steps of the methodology, would be needed.

To summarize, the experiment’s aim was to determine whether the LL video-producing

participants (i.e. groups A and B) could transfer what they had learned and how well the
knowledge within the LL video was transferred to a new group (C) to complete a new
design task. In both situations, the seven-step methodology and videos proved to be
efficient enablers for conveying experiences from one task to another.

73
 Conclusions

8 Conclusions
This chapter summarizes the overall conclusions from the study related to research question. It then
highlights the implications of the thesis’s results as well as the academic and the industrial
contributions.

With the unprecedented speed at which customer needs are changing, the speed at which
companies learn from past experiences and ongoing initiatives is becoming critical to
bring forward innovative product solutions. In addition, as manufacturing companies are
extending their focus towards lifecycle responsibility for their products and service-
oriented offerings, the need to develop mechanisms for continuous learning from
experience is greater than ever. In order to cope with new challenges in the setting of
cross-functional and multi-partner product development, enhanced methods and tools are
needed to improve the dissemination and reuse of LL from different phases of products’
lifecycle to support early phases of product development projects.

Hence, this research has put efforts to investigate the current state of LL practices in order
to identify potential barriers in the light of emerging product development trends, and to
identify an alternative ways to improve current practices from both capture and reuse
perspectives. These efforts are guided by following research question:

RQ: How can lessons learned practice be supported to improve lessons learned reuse?

The research question is answered in three ways in this thesis. Firstly, knowledge lifecycle
stages (capture, store, share, search, access, and reuse) were used to analyze and identify
following potential barriers of as-is LL practice in the light of emerging product
development trends:

• A few people at the end of a project primarily capture the current LL reports through
a post-project review. This practice does not provide opportunities to all people
involved in the project to share their LL and the delay between learning moments
and capturing the experiences lead to the loss of important insights.
• The current post-project LL reports are often too brief and listed in a very abstract
manner as bullet points, notably there is often no description of either how they may
be applicable to other products or projects, or who may benefit from them.
• The current procedures for capturing LL from design projects and downstream phases
have varying ad hoc text-based formats, resulting in similarly diverse formats of LL
reports from different projects. In particular, they are not suitable for codifying LL
related to tacit dimension of knowledge from skill-oriented activities.
• In current practice, LL documents and design best practice documents are stored in
different places. This does not allow designers to easily grasp a best practice as well as
history of doing things related to a best practice.
• The current LL procedure is usually not storing each LL to its context and the
75
 Conclusions

underlying process. Thus, it does not facilitate process-based learning on a specific

issue to designers engaged in the early phases.
• The current LL practice is not promoting a generic level LL dissemination across
projects and departmental boundaries.
• In current practice, there is no established feedback mechanism to capture and share
LL from downstream phases with designers at a product level.
• The current searching procedure for identifying relevant past LL is more relying on
personal networks and people are usually spending a lot of time on both LL
acquisition and provision.
• In current practice, aggregating updated and relevant LL from heterogeneous sources
is complicated by the variety of access and security levels. Thus, LL are not readily
available for design teams from other projects or working contexts.
• The current LL reports do not synthesize information with relevant contextualization
(i.e. background, analysis and root causes of LL) that clarifies their applicability to
subsequent reuse situations.

Secondly, based on identification of potential barriers in as-is LL practice, I have found

that lessons learned reuse in the current practice is supported by the following 11
recommendations that are derived in the form of functional requirements:

(1) LL should be captured in a continuous manner without any delays, i.e. if something
is learnt today it should be captured with no delay to share with the company, and
this approach should be continuously applied to everything learnt in everyday work.
(2) LL should be captured at a generic level with a focus on process- or problem-based
lessons, i.e. good and bad examples from different processes, to boost cross-project
learning.
(3) There should be an easier, standard procedure (or method) for capturing LL with no
differences between various projects and functional departments. The procedure (or
method) should not only be applicable to design projects, but also extend to
downstream phases.
(4) LL should capture richer contextual details related to lessons rather than listing them
as bullet points, including information on background, purpose, root-cause analysis,
applicability and generalizability.
(5) LL procedures should be able to support the capture of complex, procedural
knowledge especially knowledge from downstream phases, which is predominantly
tacit.
(6) LL should be integrated with design best practices, i.e. best practice documents and
LL reports should be stored in the same place.
(7) LL capturing process should facilitate the feedback of experience to designers at a
product component level.
(8) Knowledge contributors should be able to store metadata and related information to
support the sharing of LL, i.e. the LL process should have a bottom-up approach.
(9) Knowledge workers should be able to discuss and develop networks around LL in a
shared space.
(10) Knowledge workers should be able to search for and access relevant LL with no
restrictions related to their working context.
(11) The LL process should be closely aligned with business activities and objectives.

76
 Conclusions

Thirdly, based on identification of capabilities to the above 11 functional requirements, I

have developed a methodology and a conceptual mock-up of a tool to support the as-is
LL practice from both capture and reuse perspective. The proposed methodology includes
a standard, seven-steps representation format for LL together with guidelines, using videos
and storytelling as enabling media. These seven-steps are:

(1) Lessons learned statement

(2) Working context
(3) Task description
(4) What went wrong or what went well?
(5) Lessons learned
(6) Lessons learned measures, and
(7) Applicability and delimitations

Preliminary validation activities have shown that the methodology with seven steps and
guidelines improves the preparation and formulation of structured lessons learned with
richer contextual information than conventional formats, in the form of stories, using a
video medium. The methodology has proved to be beneficial for capturing lessons
learned from skill-oriented activities with more detail than the text-based approach. This
is because video-based lessons learned have demonstrated capabilities to visually display
and highlight failures or mistakes in complex products, and convey related knowledge
from production, use or maintenance phases for the benefit of design engineers engaged
in early phases. In this way, video-based lessons demonstrated the abilities to capture a
single learning point with specific details and actionable recommendations, enabling more
context-specific or process-based lesson learning at a product component level compared
to traditional post-project text-based LL documents. Preliminary design experiment have
shown that the reuse of video-based LL helped the new design team in selecting possible
solutions in a shorter time for the execution of a new design task, because teams found
that video-based lessons made them aware which solution could work or which cannot in
a way improved their contextual awareness of the task. In addition, the time spent
producing LL-capturing videos declined with increases in numbers of trials, showing that
it is possible to overcome the user participation challenge with practical training.

In summary, the proposed methodology showed capability to enable the transfer of

contextualized lessons a practitioner learnt from a problem-solving activity. In addition,
the knowledge embodied in the LL videos was readily transferred to facilitate execution
of a new design task. Thus, in both capture and reuse situations the proposed
methodology proved to be efficient enablers of experience transfer from one problem-
solving task to another.

The proposed methodology for LL practice has several implications for as-is LL practice:
Firstly, it has a significant impact in leveraging tacit and procedural knowledge with richer
contextual information via a storytelling mechanism. By providing a means to capture
rich contextualized, process-based LL at a component level, the methodology enables
opportunities to feedback experiences from downstream phases to design engineers
engaged in the early phases. Such practice could improve communications and networks
between front line personnel and design stakeholders as they could see both the people in
the videos and the focal problems in a more illustrative way.
77
 Conclusions

Secondly, by leveraging and disseminating process-based LL rather than post-project LL,

for instance good and bad examples from production and inspection, the methodology
could foster a cross-project learning environment within companies. This can, in turn,
help organizations to continuously learn lessons and incorporate them into standard
processes and procedures, thereby supporting double-loop learning within them.
Finally, video-based lessons could be useful as rationale carriers to explain to novice
engineers why processes and products are as they are. Such captured LL, thematically classified,
would provide a valuable knowledge base for developing tutorial-based training for
novice engineers (as well as for development teams before they start new design projects),
which could continuously accelerate the novices’ “learning curves”, thereby enhancing
performance in dealing with spontaneous and ill-defined design tasks. Furthermore, such
practice could enhance the learning capability of organizations by providing easy access to
working instructions (i.e. best practice documents) and the history of doing things from
different projects (i.e. LL) at the same time.

8.1 Academic and Industrial Contributions

The academic contribution of this study touches upon research themes related to
knowledge management and Web 2.0 generally and, more specifically, lessons learned,
knowledge reuse and storytelling.

At a general level, this thesis contributes to 2nd wave knowledge management, where the
focus is on conditions that stimulate collective knowledge sharing, especially tacit
dimensions, as a daily routine. With increasing shifts towards lifecycle responsibility and
working in cross-functional and cross-organizational settings, this is becoming increasingly
critical. However, few methods and tools for these purposes have been published,
especially for externalization and internalization processes (according to the SECI model)
related to tacit and procedural knowledge. LL literature stresses that storytelling is an
efficient way to capture tacit, procedural knowledge, and literature on knowledge reuse
emphasizes the importance of capturing contextual knowledge in reuse process.
Nevertheless, there has been little focus on identifying a practical approach or LL template
capable of capturing such knowledge that could be applicable in product development
settings. Most relevant research has been limited to proposing recommendations for
improving the LL process (e.g., Paranagamage et al., 2012; Rhodes and Dawson, 2013;
Williams, 2008).

As an academic contribution, this study described potential barriers of as-is LL practice

using knowledge lifecycle stages and identified key functional requirements for improving
LL practice to cope with emerging product development trends in an aerospace setting.
Using knowledge lifecycle stages to understand and derive requirements from as-is
practice appears to have been a successful approach, which other researchers in the
domain could potentially apply to elucidate as-is LL practices in order to derive
supportive actions and methods. Another major contribution of the thesis is the proposed
seven-step methodology and guidelines for capturing LL based on the identified
functional requirements from the empirical studies. The experiments showed that the
methodology and guidelines provide better support than previously published methods
for the capture of contextualized knowledge related to LL. The theory and empirical
findings from the studies have also established foundations for academic researchers to
78
 Conclusions

continue investigating the tacit dimension of LL in product development. The

methodology and conceptual mock-up of a video-based LL portal could also help other
researchers in the domain to test the methodology in different settings.

In terms of industrial contributions, this thesis has explored contemporary LL practice in

an aerospace setting, and proposed a number of suggestions and methodology to improve
it. Given the inherent complexity in the aerospace industry, an important exploratory step
has been taken towards elucidating experience capture and reuse (i.e. externalization and
internalization) processes in collaborative engineering in the sector. The methodology and
conceptual mock-up of a tool from these case studies have also contributed to
understanding about studying, deriving and implementing methodology and concepts in
an industrial setting. The study may also be applicable to other industrial sectors, such as
operation and maintenance, safety systems, and emergency management, as well as for
disseminating experience-based knowledge from the field to early development phases.
Finally, the results highlight the inadequately met needs of end-users in workplaces, who
usually rely more on personal contacts than structured reports for identifying and reusing
experiences, but could draw upon the proposed methodology to support their daily work.

79
 Future Work

9 Future Work
This chapter presents potentially valuable directions for future research to address both methodological
and technological issues.

9.1 Methodological Issues

The studies focused on elucidating issues associated with as-is LL processes and
developing a supportive solution in the form of a methodology to address identified
deficiencies. Hence, preliminary evaluations have focused on testing the proposed
methodology and guidelines for capturing (i.e. preparing and formulating) LL, the
primary objective being to determine if (and if so how) the proposed methodology can
facilitate the codification of experiential knowledge in a narrative way with richer
contextual information than alternative (text-based) methods.

As highlighted in Paper C, bottom-up approaches, like the proposed methodology, pose

new challenges to organizations from both methodological and technological perspectives.
One of the major concerns is the requirement for active user participation to capture and
create a vibrant LL repository. Industrial experiments revealed that practitioners favor the
adoption of new methods and tools when assisted with a suitable process and guidelines,
and when they are integrated with routine business procedures (Paper C). Accordingly,
the proposed methodology includes a seven-step representation and guidelines for
capturing LL via a storytelling mechanism, which has proved to be efficient for leveraging
procedural knowledge from complex situations.

Further research is needed to thoroughly evaluate the methodology in terms of the time
required to (1) formulate, (2) record, and (3) edit and publish a LL, compared to the text-
based approach. The studies presented here have indicated that the time required to
record the ‘same’ lesson decreases with increases in numbers of trials, but the samples
were very small. In future studies, effects of numbers of trials on the times required for
the same people to capture ‘different’ LL, needs to be assessed to further evaluate the
‘easiness’ and ‘usability’ of the proposed methodology quantitatively.

The reuse of video-based LL in a design experiment helped teams in selecting possible

solutions for the execution of a new design task by showing which solutions could work
and which would not. However, the generalizability of the study is limited because the
sample was very small. Thus, a real industrial case with component design engineers
should be used in further studies to assess the effectiveness of video-based lessons, relative
to text-based lessons, for improving contextual awareness of past experiences, thereby
facilitating the execution of new design tasks. The following questions should be
addressed in a future comparison with text-based lessons:

81
 Future Work

• How useful is the seven-step LL methodology for understanding a lesson

context sufficiently to enable reuse in a new situation?
• How effective are video-based LL in decision-making processes relative to text-
based LL?
• What are the effects of visual appearance and storytelling on the reusability of
LL?
• What is the effect of video-based LL on design engineers’ understanding of the
lifecycle properties of a product in early phases?
• How does video-based LL affect individuals’ learning capabilities relative to
text-based lessons?

Previous researchers have asserted that stories and video-formats promote “unconscious”
learning, which helps people remember them for a long time. These effects need to be
considered in future work to address issues such as how well decision-makers can learn
over time using video-based lessons relative to text-based lessons. The results could
provide insights into how LL are reused in realistic situations, which could be helpful to
design support mechanisms for a robust LL system.

9.2 Technological Issues

Paper D and E illustrated a conceptual mock-up of a LL video portal and an

accompanying platform. During the experiments, YouTube® was used as a video
repository, in which basic tagging and annotation functionalities were tested, but not with
participants. In future research a full-scale platform should be developed, permitting
participants to access LL capturing videos, store and share them with tags, thereby
allowing other people to search for and access relevant video-based lessons for reusing in a
new design task.

To improve knowledge quality, a video-based LL process has been derived, in which

captured videos would need approval from a “validator” (i.e. an expert or specialist in the
area related to the captured LL) before being placed in repositories to ensure their quality
and reliability. To avoid the risk of knowledge leakage, four secrecy levels are proposed
along with different tagging combinations. Validation of these concepts, i.e. tagging,
secrecy levels and the validator, are related to storing, sharing, searching, and accessing of
LL, which need to be tested in an industrial environment in the future. The results of this
thesis in this respect are limited to proposing a methodology and a conceptual mock-up
of a solution based on current industrial practices, observations and state-of-the-art.

From a technology perspective, the first step is to identify ways to embed the seven-step
methodology on the top of the videos as annotation links (see Figure 11), and on the
status bar as “browsing points”. This should be simple enough to facilitate LL contributors
to transfer either full videos or seven shorter video clips to the LL portal. The portal could
then possibly combine and display the full video with the embedded seven steps on the
top of the video and on the status bar. From a user perspective, developing an iPhone
application could possibly be an easiest solution, where users could record seven shorter
video clips, and transfer them to the video portal site to create a full version of the video
with embedded features.

82
 Future Work

Nurturing a LL video-tagging practice would be the next step, i.e. encouraging LL

contributors to collaboratively add tags as defined in the studies presented in this thesis. In
literature, there is very little evidence of the effect of tagging practices within an advanced
engineering environment. Thus, future work should address their effects on tagcloud- or
keyword-mediated searches for relevant LL. The empirical observations highlighted
several bookmark links to consider for incorporation in the platform to enhance its
dissemination capability, including, but not limited to, “share”, “product lifecycle
timeline”, “validator” and “secrecy level”. These bookmark links could allow a LL
contributor to quickly add video clips to the stage-gate design process, project blogs,
intranet, departmental sites, and so on. Future work should also address the effect of
“pushing” relevant LL to the users relative to “pulling”, i.e. users searching for them
within the system.

Adding feedback mechanisms, such as likes, ratings, numbers of views, or comments, and
adding network profiles, such as follow the user, access his/her recent activities, and
expertise, to the video portal could help in raising engineers’ awareness of topics, and in
developing networking capabilities across departmental and organizational boundaries.
Future work should test the viability and performance of these approaches, by observing
and analyzing their effects through a range of experiments to determine the most effective
uses of social mechanisms to support designers by enabling LL sharing from downstream
phases in emerging product development trends such as product-service systems.

83
 References

10 References

Acha, V., Davies, A., Michael, H. and Salter, A. (2004). Exploring the capital goods economy: Complex
product systems in the UK. Industrial and Corporate Change, 13: 505-529.
Adaval, R. and Wyer, R.S. (1998). The role of narratives in consumer information processing. Journal of
Consumer Psychology, 7 (3): 207 – 245.
Ahmed, S., Wallace, K.M. and Blessing, L.S. (2003). Understanding the differences between how novice
and experienced designers approach design tasks. Research in Engineering Design, 14: 1–11.
Ahn, H.J., Lee, H.J., Cho, K. and Park, S.J. (2005). Utilizing knowledge context in virtual collaborative
work. Decision Support Systems, 39 (4): 563–582.
Alavi, M. and Leidner, D. (2001). Review: Knowledge management and knowledge management
systems: Conceptual foundations and research Issues. MIS Quarterly, 25(1): 107-136.
Amin, A. and Roberts, J. (2008). Knowing in action: Beyond communities of practice. Research Policy. 37:
353-369.
Anderson, P. (2007). What is Web 2.0? Ideas, Technologies and Implications for Education. JISC
Technology and Standards Watch, February.
Andersson , P. (2011). Support for Re-use of Manufacturing Experience in Product Development: From an
Aerospace Perspective. PhD Thesis, Luleå University of Technology, Luleå, Sweden.
Aoshima, Y. (1996). Knowledge Transfer Across Generations: The Impact on Product Development Performance in
the Automobile Industry. Unpublished PhD Thesis, Massachusetts Institute of Technology, USA.
Argyris, C. and Schön, D. (1978). Organizational Learning: A theory of Action Perspective. Reading MA:
Addison-Wesley.
Arora, A. and Gambardella, A. (1994). The changing technology of technical change: General and abstract
knowledge and the division of innovative labour. Research Policy, 23: 523-532.
Avram, G. (2006). At the crossroads of knowledge management and social software. The Electronic Journal
of Knowledge Management, 4(1): 1-10.
Baines, T.S., Lightfood, H.W., Evans, S., Neely, A., Greenough, R., Peppard, J., Roy, R., Shehab, E.,
Braganza, A., Tiwari, A., Alcock, J.R., Angus, J.P., Bastl, M., Cousens, A., Irving, P., Johnson, M.,
Kingston, J., Lockett, H., Martinez, V., Michele, P., Tranfield, D., Walton, I.M. and Wilson, H.
(2007). State-of-the-art in product-service systems. Journal of Engineering Manufacture, 221(10): 1543–
1552.
Bartezzaghi, E., Corso, M. and Verganti, R. (1997). Continuous improvement and inter-project learning
in new product development. International Journal of Technology Management, 14(1): 116-138.
Bergmann, R. (2002). Experience Management: Foundations, Development Methodology and Internet-based
Applications. Berlin: Springer.
Bertoni, M. and Larsson, A. (2011). Engineering 2.0: An approach to support cross-functional teams in
overcoming knowledge-sharing barriers in PSS design. International Journal of Product Development,
x15(1/2/3 ): 115 –134 .
Bertoni, M., Larsson, A., Ericson, Å., Chirumalla, K., Larsson, T., Isaksson, O. and Randall, D. (2012).
The rise of social product development. International Journal of Networking and Virtual Organisations.
11(2): 188-207.
Birkinshaw, J. and Sheehan, T. (2002). Managing the Knowledge Life Cycle. MIT Sloan Management
Review, Fall 2002, pp. 75–83.
Blessing, L. and Wallace, K. (2000). Supporting the Knowledge Life-Cycle. In: Proceedings of 3rd
Workshop on Knowledge Intensive CAD, Japan, Kluwer Academic Publishers, pp. 21-38.
Bloomberg, L.D. and Volpe, M. (2008). Completing Your Qualitative Dissertation: A Roadmap From
Beginning to End. London: Sage Publications.
85
 References

Boeije, R., Vries, P. D., Kolfschoten, G. L. and Veen, W. (2009). Knowledge Workers and the Realm of
Social Tagging. In: Proceedings of the 42nd Hawaii International Conference on System Sciences, 5-
8 January, Big Island, HI, pp. 1-10.
Boisot, Max, and A. Canals. (2008). Data, information and knowledge: Have we got it right? In M.
Boisot, I. MacMillan, and K. S. Han (Eds.): Explorations in Information Space. Oxford University Press,
pp. 15–47.
Bothos, E., Apostolou, D. and Mentzas, G. (2009). Collective intelligence for idea management with
Internet-based information aggregation markets. Internet Research, 19(1): 26-41
Brezillon, P. and Pomerol, J. (2001). Is context a kind of collective tacit knowledge? In: European CSCW
Workshop on Managing Tacit Knowledge, Germany, September, pp. 23–29.
Brown, J.S. and Duguid, P. (2000). Balancing act: how to capture knowledge without killing it. Harvard
Business Review. 78(3): 73–78.
Bughin, J. and Manyika, J. (2007). How business are using Web 2.0. The McKinsey Quarterly, January.
Bughin, J., Byers, A.H. and Chui, M. (2011). How social technologies are extending the organization.
The McKinsey Quarterly. November.
Bughin, J., Chui, M. and Miller, A. (2009). How companies are benefiting from Web 2.0. The
McKinsey Quarterly, June.
Buttler T., S. Lukosch. and A. Verbraeck. (2011). Frozen stories: Capturing and utilizing frozen stories for
teaching of project managers. In: Proceedings of the 3rd International Conference on Computer
Supported Education, Noordwijkerhout, The Netherlands, Vol. 1: 20-129.
Carillo, P., Ruikar, K. and Fuller, P. (2013). When will we learn? Improving lessons learned practice in
construction. International Journal of Project Management. 31(4): 567-578.
Cavaye, A.L.M. (1996). Case study research: a multi-faceted research approach for IS. Information Systems
Journal, 6: 227-242.
Cha, M., Kwak, H., Rodriguez, P., Ahn, Y-Y. and Moon, S. (2007). I tube, You tube, Everybody tubes:
Analyzing the world’s largest user generated content video system. In: Proceedings of ACM Internet
Measurement Conference, 24-26 October, San Diego, California, USA.
Chan, R. and Rosemann, M. (2001). Managing Knowledge in Enterprise Systems. Journal of Systems &
Information Technology, 5 (2): 37-54.
Chandrasegaran, S.K., Ramani,K., Sriram,R.D., Horváth, I., Bernard,A., Harik,R.F.and Gao,W. (2013).
The evolution, challenges, and future of knowledge representation in product design systems.
Computer-Aided Design, 45 (2): 204-228.
Cheuk, B. (2007). Applying sense-making and narrative techniques to capture lessons learnt. Journal of
Information & Knowledge Management. 6(3): 165-171.
Choi, H.J. and Johnson, S.D. (2005). The effect of context-based video instruction on learning and
motivation in online courses. The American Journal of Distance Education, 19(4): 215–227.
Chua, A. Y. K., Lam, W. and Majid, S. (2006). Knowledge reuse in action: The case of CALL. Journal of
Information Science, 32: 251–260.
Chui, M., Manyika, J., Bughin, J., Dobbs, R., Roxburgh, C., Sarrazin, H., Sands, G. and Westergren, M.
(2012). The social economy: Unlocking value and productivity through social technologies. The
McKinsey Quarterly. July.
Clark, K.B. and Fujimoto, T. (1991). Product Development Performance: Strategy, Organization and
Management in the World Auto Industry. Boston, MA: Harvard Business School Press.
Clayton, R.J., Backhouse, C.J. and Dani, S. (2011). Evaluating existing approaches to product-service
system design: A comparison with industrial practice. Journal of Manufacturing Technology Management,
23(3): 272–298.
Collison, C. and Parcell, G. (2001). Learning to Fly. Oxford: Capstone Publishing Limited.
Connell, N. A. D., Klein, J. H. and Meyer, E. (2004). Narrative approaches to the transfer of
organisational knowledge. Knowledge Management Research & Practice, 2: 184–193.
Cooke-Davies, T. (2002). The “real” success factors on projects. International Journal of Project Management,
20: 185-190.
Cooper, L.P. (2003). A research agenda to reduce risk in new product development through knowledge
management: a practitioner perspective. Journal of Engineering and Technology Management. 20: 117-
140.

86
 References

Corbally, M.A. (2005). Considering video production? Lessons learned from the production of a blood
pressure measurement video. Nurse Education in Practice. 5 (6): 375- 379.
Court, A.W., Culley, S.J. and McMahon, C.A. (1996). Information access diagrams: a technique for
analysing the usage of design information. Journal of Engineering Design, 7: 55–75.
Cummings, J. L. and Teng, B.-S. (2003). Transferring R&D knowledge: the key factors affecting
knowledge transfer success. Journal of Engineering and Technology Management, 20: 39-68.
Daily, B. (1994). Multimedia and its impact on training engineers. International Journal of Human-Computer
Interaction. 6(2): 191-204.
Darke, P., Shanks, G. and Broadbent, M. (1998). Successfully completing case study research: combining
rigour, relevance and pragmatism. Information Systems Journal, 8: 273-289.
Dave, B. and Koskela, L. (2009). Collaborative knowledge management: A construction case study.
Automation in Construction, 18(7), 894-902.
Davenport, T. and Prusak, L. (1998). Working Knowledge: How Organizations Manage What They Know.
Boston: Harvard Business School Press.
Denzin, N.K. and Lincoln, Y.S. (2003). Collecting and Interpreting Qualitative Materials. Thousand Oaks,
London: Sage.
Desouza, K.C., Dingsoyr, T. and Awazu, Y. (2005). Experience with conducting project postmortems:
Reports vs. Stories and Practitioner Perspective. In: Proceedings of the 38th Hawaii International
Conference on System Sciences, 3-6 January, Big Island, HI, USA.
Disterer, G. (2002). Management of project knowledge and experiences. Journal of Knowledge Management,
6(5): 512-520.
Durisova, J. (2011). Knowledge life cycle and its application in automative industry. Problems of
Management in the 21st Century, 2: 45-53.
Economist Intelligence Unit. (2007). Knowledge Management in Manufacturing. Report.
Eisenhardt, K. M. (1989). Building theories from case study research. Academy of Management Review,
14(4): 532-550.
Eisenhardt, K. M. and Graebner, M. E. (2007). Theory building from cases: Opportunities and challenges.
Academy of Management Journal, 50(1): 25-32.
Erickson, T (1995). Notes on design practice: stories and prototypes as catalysts for communication. In J.
Carroll (Ed.): Scenario-Based Design: Envisioning Work and Technology in System Development, pp. 37-58,
New York: Wiley.
Ericson, Å. (2007). A Need-based Approach to Product Development. PhD Thesis, Luleå University of
Technology, Sweden.
Ericson, Å., Nergård, H. and Larsson, T. (2005). Knowledge sharing challenges within the extended
enterprise. In: Proceedings of 15th International Conference on Engineering Design, 15-18 August,
Melbourne.
Flew, T. (2008). New Media: An Introduction. London: Oxford University Press.
Fosshage, E. (2013). Considerations for Implementing an Organizational Lessons Learned Process. Sandia report.
Sandia National Laboratories. May 2013.
Fruchter, R., Demian, P. (2002). CoMem: Designing an interaction experience for reuse of rich
contextual knowledge from a corporate memory. Artificial Intelligence for Engineering Design, Analysis
and Manufacturing, 16: 127–147.
Goffin, K. and Koners, U. (2011). Tacit knowledge, lessons learnt, and new product development. Journal
of Product Innovation Management. 28: 300-318.
Goffin, K., Koners, U., Baxter, D. and Hoven, C.V.D. (2010). Managing lessons learned and tacit
knowledge in new product development. Research-Technology Management, July-August 2010.
Goh, Y.M. and McMahon, C. (2009). Improving reuse of in-service information capture and feedback.
Journal of Manufacturing Technology, 20(5): 626-639.
Goldkuhl, G. and Braf, E. (2001). Contextual knowledge analysis—understanding knowledge and its
relations to action and communication. In: Proceedings of 2nd European Conference on Knowledge
Management, IEDC-Bled School of Management, Slovenia.
Granovetter, M.S. (1973). The strength of weak ties. American Journal of Sociology, 78(6): 1360-1380.
Hamel, G. (1991). Competition for competence and interpartner learning within international strategic
alliances. Strategic Management Journal. 12(S1): 83-103.

87
 References

Hansen, M.T., Nohria, N. and Tierney, T. (1999). What's your strategy for managing knowledge?
Harvard Business Review, 77(2): 106-116.
Harrison, A. (2006). Design for service - Harmonising product design with a services strategy. The ASME
Turbo Expo 2006, 6-11 May, Barcelona, Vol. 2, pp. 135-143.
Harrison, S. Minneman, S., Stults, B. and Weber, K. (1989). Video: a design medium. SIGCHI Bulletin,
21(2): 62-66.
Helms, M.M. and Nixon, J. (2010). Exploring SWOT analysis – where are we now? Journal of Strategy
and Management, 3(3): 215-251.
Hendriks, P. (1999). Why Share Knowledge? The Influence of ICT on the Motivation for Knowledge
Sharing. Knowledge and Process Management, 6(2): 91-100.
Hicks, B., Culley,S., Allen, R. and Mullineux, G. (2002). A framework for the requirements of capturing,
storing and reusing information and knowledge in engineering design. International Journal of
Information Management, 22: 263–280.
Hoegl, M. and Schulze, A. (2005). How to support knowledge creation in new product development: An
investigation of knowledge management methods. European Management Journal. 23(3): 263-273.
Holman, R., Kaas, H. and Keeling, D. (2003). The Future of Product Development. McKinsey quarterly.
Huysman, M. and de Wit, D. (2002). Knowledge Sharing in Practice. Boston: Kluwer Academic Publishers.
Ipe, M. (2003). Knowledge Sharing in Organizations: A Conceptual Framework. Human Resource
Development Review, 2(4): 337-359.
Isaksson, O., Larsson, T. and Ronnback, A.O. (2009). Development of product-service systems:
Challenges and opportunities for the manufacturing firm. Journal of Engineering Design, 20(4): 329-
348.
Jagtap, S. and Johnson, A.L. (2011). In-service information required by engineering designers. Research in
Engineering Design. 22: 207-221.
Jonassen, D.H. and Hernandez-Serrano, J. (2002). Case-based reasoning and instructional design: Using
stories to support problem solving. Educational Technology: Research and Development, 50(2): 65-77.
Kamara, J.M., Anumba, C.J., Carrillo, P.M. and Bouchlaghem, N. (2003). Conceptual framework for
live capture and reuse of project knowledge. In Proceedings of the CIB W78’s 20th International
Conference on Information Technology for Construction: Amor, R. (Ed.), Construction IT: Bridging
the Distance. New Zealand, 23-25 April, pp. 178-85.
Keegan A. and Turner J. (2001). Quantity versus quality in project based learning and continuous
improvement. Management Learning, 32(1): 77–98.
Kietzmann, J.H., Hermkens, K., McCarthy, I.P. and Silvestre, B.S. (2011). Social media? Get serious!
Understanding the functional building blocks of social media. Business Horizons. 54: 241-251.
Kimura F. and Suzuki, H. (1996). Design of right quality products for total life cycle support. In:
Proceedings of 3rd International Seminar on Life Cycle Engineering. 18-20 March, Zu
rich.
Kingston, J.K.C. (2012). Tacit knowledge: capture, sharing, and unwritten assumptions. Journal of
Knowledge Management Practice. 13(3). September 2012.
Koners, U. and Goffin, K. (2007). Learning from post-project reviews: A cross-case analysis. Journal of
Product Innovation Management, 24(3): 242-258.
Kosonen, M. and Kianto, A. (2009). Applying wikis to managing knowledge: A socio-technical approach.
Knowledge and Process Management, 16(1): 23-29.
Kotnour, T. (1999). A learning framework for project management. Project Management Journal, 30(2): 32-
38.
Kvale. S. (1996). Interviews: An Introduction to Qualitative Research Interviewing. CA: Sage Publications.
Larsson, A., Ericson, Å., Larsson, T. and Randall, D. (2008). Engineering 2.0: Exploring lightweight
technologies for the virtual enterprise. In: Proceedings of 8th International Conference on the Design
of Cooperative Systems (COOP’08), Carry-le-Rouet, France, 20-23 May.
Leon, N. (2005). The invisible ethnographer: Working with people, real life and up close. In:
Proceedings of the 58th Annual ESOMAR Congress, 18-21 September, Cannes, pp. 129-137.
Levy, M. (2009). Web 2.0 implications on knowledge management. Journal of Knowledge Management,
13(1): 120-134.
Lewis, J. (2008). Exploring online videos as a way to share knowledge. Knowledge Management Review,
11(1): 28-33.

88
 References

Lofland, J., Snow, D.A., Anderson, L. and Lofland, L.H. (2005). Analyzing Social Settings: A Guide to
Qualitative Observation and Analysis. Belmont, CA: Cengage Learning.
Lykourentzou, I., Papadaki, K., Vergados, D. J., Polemi, D. and Loumos, V. (2010). CorpWiki: A self-
regulating wiki to promote corporate collective intelligence through expert peer matching.
Information Sciences, 180(1): 18-38
Mack, N., Woodsong, C., MacQueen, K.M., Guest, G. and Namey, E. (2005). Qualitative Research
Methods: A Data Collector's Field Guide. NC: Family Health International.
Madhavan, R. and Grover, R. (1998). From embedded knowledge to embodied knowledge: new
product development as knowledge management. Journal of Marketing, 62: 1-12.
Manzini, E. and Vezolli, C. (2003). A strategic design approach to develop sustainable product service
systems: examples taken from the ‘environmentally friendly innovation’ Italian prize. Journal of Cleaner
Production, 11: 851–857.
Markus, M. L. (2001). Toward a theory of knowledge reuse: Types of knowledge reuse situations and
factors in reuse success, Journal of Management Information Systems. 18 (1): 57-93.
Marsh, R. (1997). The Capture and Utilisation of Experience in Engineering Design. PhD Thesis. University of
Cambridge, St. John's College, Cambridge, USA.
McAfee, A. P. (2006). Enterprise 2.0: The Dawn of Emergent Collaboration. MIT Sloan Management
Review, 47(3): 21-28.
McElroy, M. (2000). The new knowledge management. Knowledge and Innovation: Journal of the Knowledge
Management Consortium International. 1(1): 43–67.
McMahon, C., Lowe, A. and Culley, S. (2004). Knowledge management in engineering design:
personalization and codification. Journal of Engineering Design, 15: 307 -325.
Merriam-Webster. (2013). Context Definition. Merriam-Webster Dictionary. Accessed 1st November
2013.
Miles, M.B. and Huberman, A.M. (1994). Qualitative Data Analysis: An Expanded Sourcebook. CA: Sage
Publications.
Miltion, N. (2010). The Lessons Learned Handbook: Practical Knowledge-Based Approach to Learning from
Experience. Oxford: Chandos Publishing Ltd.
Milton, N. (2008). Exploring the concept of organizational learning. KM Review. 11 (4): 8-13.
Minardi, H.A. and Ritter, S. (1999). Recording skills practice on videotape can enhance learning–a
comparative study between nurse lectures and nursing students. Journal of Advanced Nursing. 29(6):
1318-1325.
Mont, O. (2002). Clarifying the concept of product-service system. Journal of Cleaner Production, 10 (3):
237-245.
Morelli, N. (2003). Product-service systems, a perspective shift for designers: A case study: the design of a
telecentre. Design Studies, 24 (1): 73-99.
Musser, J. and O’Reilly, T. (2006). Web 2.0 principles and Best Practices. O’Reilly Radar report.
Neyland, D. (2008). Organizational Ethnography. London, UK: Sage Publications Ltd.
Nissen, M. (2002). An extended model of knowledge-flow dynamics. Communications of the Association for
Information Systems, 8: 251-266.
Nonaka, I. (1994). A dynamic theory of organizational knowledge creation. Organization Science. 5(1): 14-
37.
Nonaka, I. and Konno, N. (1998). The concept of “Ba”: Building a foundation for knowledge creation.
California Management Review. 40(3): 40-54.
Nugent, G.C. (1982). Pictures, audio, and print: symbolic representation and effect on learning. Education
Communication and Technology Journal, 30(3): 163–174.
Nuzzo, P. and Lockwood, F. (2006). Knowledge Enabled Solution Components: State of the Art. VIVACE
Project Report.
O’Dell, C. and Grayson, C.J. (1998), If only we knew what we know: identification and transfer of
internal best practice. California Management Review, 40(3): 154-74.
O’Dell, C. and Hubert, C. (2011). The New Edge in Knowledge: How Knowledge Management is Changing the
Way We Do Business. New Jersey: John Wiley & Sons.
O’Reilly, T. (2005). What is Web 2.0- Design Patterns and Business Models for the Next Generation of Software.
O’Reilly.

89
 References

Oliva, R. and Kallenberg, R. (2003). Managing the Transition from Products to Services. International
Journal of Service Industry Management, 14(2): 160-172.
Orr, J.E. (1996). Talking About Machines: An Ethnography of a Modern Job. NY: Cornell University Press.
Panahi, S., Watson, J. and Partridge, H. (2013). Towards tacit knowledge sharing over social web tools.
Journal of Knowledge Management, 17(3): 379 – 397
Parameswaran, M. and Whinston, A.B. (2007). Social Computing: An overview. Communications of the
Association for Information Systems, 19: 762-780.
Paranagamage, P., Carrillo, P., Ruikar, K. and Fuller, P. (2012). Lessons learned practices in the UK
construction sector: current practice and proposed improvements. The Engineering Project Organization
Journal. 2: 216-230.
Patton. M. Q. (2002). Qualitative Research & Evaluation Methods. CA: Sage Publications.
Polanyi, M. (1967). The Tacit Dimension. London: Routledge and Kegan Paul.
Redecker, C., Ala-Mutka, K., Bacigalupo, M., Ferrari, A. and Punie, Y. (2009). Learning 2.0: The Impact
of Web 2.0 Innovations on Education and Training in Europe. Joint Research Centre, Institute for
Prospective Technological Studies, European Commission, Seville.
Rehman, F.U. and Yan, Xiu-Tian. (2010). Application of context knowledge in supporting conceptual
design decision making. International Journal of Product Development, 13(1): 47-66.
Rhodes, L. and Dawson, R. (2013). Lessons Learned from Lessons Learned. Journal of Knowledge and
Process Management, 20 (3): 154-160.
Rittel, H.W.J. and Webber, M.M. (1973). Dilemmas in a General Theory of Planning. Policy Sciences,
4:155-169.
Rowley, J. (2001). Knowledge management in pursuit of learning: The learning with knowledge cycle.
Journal of Information Science, 27(4): 227–237.
Rughase, O. G. (2002). Linking content to process: How mental models of the customer enhance the
creative strategy processes. In A. S. Huff. And M. Jenkins (Ed.): Mapping Strategic Knowledge. London:
Sage Publications.
Rumizen, M. C. (2002). The Complete Idiot’s Guide to Knowledge Management. London: DK Publishing.
Schacter, D.L. (1996). Searching for Memory. New York: Basic Books.
Schindler, M. and Eppler, M.J. (2003). Harvesting project knowledge: a review of project learning
methods and success factors. International Journal of Project Management. 21: 219-228.
Schultze, U. and Leidner, D.E. (2002). Studying knowledge management in information systems research.
Discourses and theoretical assumptions. MIS Quarterly, 26(3): 213-242.
Secchi, P., Ciaschi, R. and Spence, D. (1999). A concept for an ESA lessons learned system. In:
Proceedings of the 5th Annual International Symposium of the National Council on System
Engineering (INCOSE), St. Louis, Missouri.
Senge, P.M. (1990). The Fifth Discipline: The Art and Practice of the Learning Organization. New York:
Doubleday Currency.
Sharif, M.N.A., Zakaria, N.H., Ching, L.S. and Fung, L.S. (2005). Facilitating knowledge sharing
through lessons learned system. Journal of Knowledge Management Practice, March 2005.
Sharmin, M., Bailey, B.P., Coats, C., and Hamilton, K. (2009). Understanding knowledge management
practices for early design activity and its implications for reuse. In: Proceedings of ACM CHI, pp.
2367-2376.
Slack, N., Chambers, S. and Johnston, R. (2010). Operations Management, Essex: Pearson Education.
Small, C.T. and Sage, A.P. (2005). Knowledge management and knowledge sharing: A review.
Information Knowledge Systems Management, 5: 153-169.
Smith, D. J. (2013). Power-by-the-hour: the role of technology in reshaping business strategy at Rolls-
Royce. Technology Analysis & Strategic Management, 25(8): 987-1007.
Snowden, D. (1999). Storytelling: an old skill in a new context. Business Information Review, 16(1): 30-37.
Stewart, T.A. (1997). Intellectual Capital: The New Wealth of Organizations. New York: Crown Business.
Swap, W., Leonard, D., Shields, M. and Abrams, L. (2001). Using mentoring and storytelling to transfer
knowledge in the workplace. Journal of Management Information Systems, 18 (1): 95-114.
Syed, M.R. (2001). Diminishing the distance in distance education. IEEE Multimedia, 8(3): 18–21.
Szulanski, G. (2003). Sticky Knowledge: Barriers to Knowing in the Firm, London: Sage.

90
 References

Tan, A.R., McAloone, T.C. and Andreasen, M.M. (2006). What happens to integrated product
development models with product/service-system approaches? In: Proceedings of 6th Integrated Product
Development Workshop, Magdeburg, Germany, 18-20 October.
Tan, H.C., Carrillo, P., Anumba, C., Kamara, J.M., Bouchlaghem, D. and Udeaja, C. (2006). Live
capture and reuse of project knowledge in construction organisations. Knowledge Management Research
& Practice, 4(2): 149-161.
Thomas, J.B., Sussman, S.W. and Henderson, J.C. (2001). Understanding ‘strategic learning’: linking
organizational learning, knowledge management and sense making. Organisational Science, 12(3): 331–
345.
Thomke, S. and Fujimoto, T. (2000). The effect of “front-loading” problem-solving on product
development performance. Journal of Product Innovation Management, 17(2): 128-142.
Thompson, P., Warhurst, C. and Callaghan, G. (2001). Ignorant theory and knowledgeable workers:
interrogating the connections between knowledge, skills and services. Journal of Management Studies,
38(7): 923–42.
Tukker, A., Tischner, U. (2006). New Business for Old Europe: Product-Service Development, Competitiveness
and Sustainability. Sheffield: Greenleaf Publishing Ltd.
Ullman, D. G. (2002). The Mechanical Design Process. New York: McGraw-Hill.
Ulrich, K.T. and Eppinger, S.D. (2008). Product Design and Development. Boston, MA: McGraw-Hill.
Verganti, R. (1997). Leveraging on systemic learning to manage the early phases of product innovation
projects. R&D Management, 27 (4): 377-392.
Vianello, G. (2011). Transfer and Reuse of Knowledge from the Service Phase of Complex Products. Ph.D.
dissertation. Technical University of Denmark, Copenhagen, Denmark.
Voigt, K.-I. and Ernst, M. (2010). Use of Web 2.0 applications in product development: an empirical
study of the potential for knowledge creation and exchange in research and development.
International Journal of Engineering, Science and Technology, 2(9): 54-68.
Wagner, C. (2006). Breaking the knowledge acquisition bottleneck through conversational knowledge
management. Information Resources Management Journal, 19(1): 70–83.
Wallace, K., Ahmed, S. and Bracewell, R. (2006). Engineering knowledge management. In J. Clarkson &
C. Eckert (Ed.): Design Process Improvement: A Review of Current Practice. pp. 326-343, Springer.
Wang, L., Shen, W., Xie, H., Neelamkavil, J. and Pardasani, A. (2002). Collaborative conceptual design
—State of the art and future trends. Computer-Aided Design, 34: 981-996.
Wang, P.P., Ming, X.G., Li. D., Kong, F.B., Wang, L. and Wu, Z.Y. (2011). Status review and research
strategies on product-service systems. Journal of Production Research, 49 (22): 6863-6883.
Ward, Y. and Graves, A. (2007). Through-life management: the provision of total customer solutions in
the aerospace industry. International Journal of Services Technology Management, 8(6): 455-477.
Weber, R., Aha, D.W. and Becerra-Fernandez, I. (2001). Intelligent Lessons Learned Systems. Journal of
Expert Systems Research & Applications, 20(1): 17–34.
Wikipedia. (2013). Comparison of video hosting services. Accessed date: 10 September 2013.
http://en.wikipedia.org/wiki/Comparison_of_video_hosting_services.
Williams, A. (2007). Product service systems in the automobile industry: contribution to system
innovation? Journal of Cleaner Production, 15: 1093-1103.
Williams, T. (2008). How do organizations learn lessons from projects-and do they? IEEE Transactions on
Engineering Management. 55(2): 248-266.
Wise, R. and Baumgartner, P. (1999). Go downstream: the new imperative in manufacturing. Harvard
Business Review, 77(5): 133–141.
Wong, S.C., Crowder, R.M., Wills, G.B. and Shadbolt, N.R. (2008). Knowledge transfer: from
maintenance to engine design. Journal of Computing and Information Science in Engineering, 8(1): 11001-
11007.
Wood, N., Rust, C. and Horne, G. (2009). A Tacit understanding: The designer's role in capturing and
passing on the skilled knowledge of master craftsmen. International Journal of Design, 3 (3): 65-78.
Yin, R.K. (2009). Case Study Research: Design and Methods. Thousand Oaks, CA: Sage Publications.
Yllrisku, S.P. and Buur, J. (2007). Designing with Video. London: Springer
Zack, M.H. (1999). Managing codified knowledge. Sloan Management Review. 40(4): 45-58.

91
 References

Zedtwitz, M. V. (2002). Organizational learning through post-project reviews in R&D. R&D

Management, 32(3): 255-268.
Zender, J., Schwehm, G. and Wilke, M. (2006). The Rosetta video approach: an overview and lessons
learned so far. Journal of Knowledge Management, 10 (2): 66-75.
Zhang, D., Zhou, L., Briggs, R. O. and Nunamaker Jr, J. F. (2006). Instructional video in e-learning:
Assessing the impact of interactive video on learning effectiveness. Information and Management, 43(1):
15–27.

92
 Appendices

11 Appendices

Appendix I

Theme: Cross-Functional Knowledge Sharing in a Collaborative Product

Development Environment

Respondent Background
• What is your educational background and industrial experiences?
• When did you start working at the company?
• What kind of job roles do you have had in the company so far?
• What is your current job role and responsibilities?

Basic Questions
• What is product for you?
• What is service for you?
• What is your view on product development at the company?
• Where do you work in the product development process (if possible could you
draw a network picture)?

Main Questions
• How do you primarily collaborate in the workplace?
• Who are the people give inputs to you?
• What kind of roles do they have?
• How do you get information from them?
• Who do you want to communicate more in the future?
• What kind of collaborative tools do you use for exchanging information and
knowledge?
• How do you capture experts skills to carry forward their experiences?
• How do you collect customer needs at the moment?
• How do you document your lessons learned or project related experiences?
• Who are responsible for maintaning these documents?
• How do you make sure that these documents can be easily accessible in the future?
• How do you make it easier for new project memebers to get up-to-speed quickly?
• How the search function is working in the company?
• Approximately how much time do you spend for searching information?
• How do you access previous project experiences or documents from the databases?

93
 Appendices

• What difficulties do you face now when you would like to find relevant
information for the task at hand?
• Do you have any prior experience of difficulties in the execution of collaborative
practices?
• What problems do you face for sharing knowledge among project members?
• What are key challenges in reusing the knowledge from one project to another?
• What features the current collaborative tools are missing at the moment?
• To what extend does the collaborative tools need improvement for a better
knowledge sharing?
• Have you heard about any new tools that are trying to implement at the company?
• Have you heard about implementation of blogs or wikis?
• Are you using any social tools to share information in the workplace?
• Do you see any knowledge sharing potential in these tools compare to
PDM/PLM/CAD/CAM tools?
• Where do you think social networking can have the biggest impact?
• What are the main challenges to adopt social tools in the workplace?

94
 Appendices

Appendix II

Theme: Managing continuous experience sharing across the product

lifecycle phases

Purpose of the study is to understand as-is experience sharing, such as lessons learned
practice, and continuous improvement initiatives, from product lifecycle phases to
support early design activities.

General Questions
1. What is your educational background?
2. What is your current job role and responsibilities at the company?
3. From your perspective, what is “experience” for you?
4. From your perspective, what is “knowledge” for you?

Identifying experiences
5. How do you identify the learnings from your experiences?
6. What formal and informal methods are in place to identify the experiences?
7. Do you want to highlight any specific issues and challenges in identifying the
experiences?
8. What is your perception on ‘To-Be’ situation?

Capturing experiences
9. How do you typically capture your experiences?
10. What are the formal (or informal) ways to capture experiences?
11. Who are the typical participants in the capturing phase? What are there job roles?
How many participants in total?
12. How often do you capture your experiences?
13. Do you want to highlight any specific issues and challenges in capturing the
experiences?
14. What is your perception on ‘To-Be’ situation in capturing the experiences?
15. What is your view on using blogs, wikis, or videos for capturing the experiences?

Storing experiences
16. How do you store experiences?
17. What formal (or informal) tools do you use for storing experiences?
18. Where do you store them to provide access to others?
19. Do you add any “meta data” or “keywords” to improve the searchability?
20. Do you want to highlight any specific issues and challenges in storing the experiences?
95
 Appendices

21. What is your perception on ‘To-Be’ situation in storing the experiences?

22. What is your opinion on using tags for storing the experiences?

Sharing experiences
23. How do you share experiences with other groups?
24. What kind of tools (informal and formal) do you use for sharing experiences?
25. Do you want to highlight any specific issues and challenges in sharing the experiences?
26. What is your perception on ‘To-Be’ situation in sharing the experiences?
27. What is your opinion on using blogs, wikis or videos for sharing the experiences?

Searching experiences
28. How do you search and locate previous experiences?
29. What are the formal/informal tools available to search the previous experiences?
30. Do you want to highlight any specific issues and challenges in searching the
experiences?
31. What is your perception on ‘To-Be’ situation in searching the experiences?
32. Do you like to see experiences in a video-based medium?

Accessing experiences
33. How do you access previous experiences?
34. What are the formal/informal ways available for accessing experiences?
35. Do you want to highlight any specific issues and challenges in accessing the
experiences?
36. What is your perception on ‘To-Be’ situation in accessing the experiences?

Reusing experiences
37. How do you reuse the learnings from previous experiences?
38. What kind of precautions do you take to improve the reusability of captured
experiences?
39. Do you want to highlight any specific issues and challenges in reusing the experiences?
40. What is your perception on ‘To-Be’ situation in reusing the experiences? ?
41. How do you want to see the previous experiences to reuse it?
42. Do you think video-based medium could help in reusing past experiences?

96
 Appendices

Appendix III

Theme: Knowledge Sharing in Practice Survey

97
 Appendices

98
Appendices

99
 Appendices

Appendix IV

Follow-up questionnaire used in the industrial experiment

1. What is your experience while capturing your lessons learned using the video-based
methodology?
2. Do you think that video is better in documenting lessons learned when it is compared
to writing a lessons learned report?

A) If yes, answer:
a. Why videos are better than report?
b. How videos are better than report?

B) If no, answer:
a. Why videos are not better than report?
b. How videos are not better than report?

3. How the given lessons learned template and guidelines helped you in structuring your
lessons learned story in a video?
4. Where do you see the potential of using these lessons learned videos at your company
or domain?
5. Do you have any suggestions for improvement?

100
 Appendices

Appendix V
Design Brief: Bridge and Platform Prototypical Design Exercise

Objective:
You are requested to design a bridge and a platform for bungee jumping for our friend,
John ‘the brave” donkey (see Figure below for the exact dimensions).

Requirements:
- The bridge and the platform is able to sustain John’s weight
- The bridge is built using only paper and Lego bricks (provided by the lecturer)
- The bridge is being positioned between 2 tables that are 50 cm far away.
- The bridge is 40 cm high as minimum
- John feels safe to jump from the platform, i.e. it should not fall down during the jump.

101
 Appendices

Appendix VI
Group Reflection Questionnaire used in the Design Experiment

• What do you learn from the exercise in general?

• What is the role of lessons learned you seen in performing your task?
• What is the single most important knowledge that you got from the videos to
make this successful today?
• What is more useful to see, the lessons learned video related to successful or
failure?
• You were used the structure video last time. If you do the video again, what
would you tell something different?
• What would you suggest to other team that have made a structure video to add to
the description. Did you feel something you told was missing in other video?
• What has been the most useful thing you have learnt from the videos?
• What would be different if you might write textual lessons learned both from
capturing and reuse wise?
• If you record the text instead of video, then what would you add more of it in the
text?
• Do you face any problems in facing the video?
• You were asked to produce the video in seven steps. Would you find that helpful?
• To what extent do you think videos have helped in recording and reviewing
lessons learned compared to a textual report?

102
Leveraging Web 2.0 in New Product Development:
Lessons Learned from a Cross-company Study
Paper

A
Bertoni, M. and Chirumalla, K
Journal of Universal Computer Science (JUCS)
Vol. 17, no. 4, pp. 548-564, 2011

Social Technologies For Cross-functional

Paper
Product Development: SWOT Analysis and Implications

Bertoni, M., Chirumalla, K. and Johansson, C

In Proceedings of 45th Hawaii International Conference on System
Sciences (HICSS-45), 4-7 January, Grand Wailea, Maui, 2012 B
Managing Knowledge for Product-Service System
Paper
Innovation: The Role of Web 2.0 Technologies

Chirumalla, K
Research-Technology Management Journal (RTM)
Vol. 56, no. 2, pp. 45-53, 2013 C
Capturing and Sharing Lessons Learned across
Paper
Boundaries: A Video-based Approach

Chirumalla, K., Bertoni, M., Johansson, C., Isaksson, O

In Proceedings of 20th European Conference on Information
Systems (ECIS’12), 10-13 June, Barcelona, Spain, 2012 D
Experience Feedback using Social Media: From the Paper
Product Lifecycle Phases to the Design Practices

Chirumalla, K., Bertoni, M., Johansson, C

In Proceedings of the 5th CIRP International Conference on Industrial
Product-Service Systems (IPS2): Product-Service Integration for
Sustainable Solutions, ed. H. Meier, pp. 459-471, Springer-Verlag, 2013 E
 Journal of Universal Computer Science, vol. 17, no. 4 (2011), 548-564
submitted: 30/10/10, accepted: 12/2/10, appeared: 28/2/11 © J.UCS

Leveraging Web 2.0 in New Product Development:

Lessons Learned from a Cross-company Study

Marco Bertoni
(Luleå University of Technology, Luleå, Sweden
[email protected])

Koteshwar Chirumalla
(Luleå University of Technology, Luleå, Sweden
[email protected])

Abstract: The paper explores the application of Web 2.0 technologies to support product
development efforts in a global, virtual and cross-functional setting. It analyses the dichotomy
between the prevailing hierarchical structure of CAD/PLM/PDM systems and the principles of the
Social Web under the light of the emerging product development trends. Further it introduces the
concept of Engineering 2.0, intended as a more bottom up and lightweight knowledge sharing
approach to support early stage design decisions within virtual and cross-functional product
development teams. The lessons learned collected from a cross-company study highlight how to
further develop blogs, wikis, forums and tags for the benefit of new product development teams,
highlighting opportunities, challenges and no-go areas.

Keywords: Engineering 2.0, Product Development, Web 2.0, Functional Product Development,
Cross-functional teams.
Categories: K.4.3, L.6.1, L.6.2, M.0, M.1, M.2, M.5, M.7

1 Introduction

Engineers are no longer solving the problems they used to solve. In the aerospace
industry, for instance, the design of a new aircraft engine cannot merely be reduced
to a pure technical activity, such as the calculation of stresses on the blades or on the
intermediate case. Engineers are not longer dealing with “tame” problems only;
rather have to pay increasingly attention to “wicked” problems [Rittel, 73] as well,
such as developing a “passenger-friendly” airplane [Boeing, 06].
The information and knowledge embodied into 3D product models and data
structures, i.e. in CAD (Computer Aided Design), CAE (Computer Aided
Engineering), PDM (Product Data Management), PLM (Product Lifecycle
Management) and KBE (Knowledge Based engineering) applications, do not provide
alone a good enough basis to support decision-making activities in this emerging
context.
Whatever technical work is done it must necessarily be done in a social context –
a context that encompasses the ordinary practical decision-making processes that
individuals and teams go through, and the knowledge and skills they bring to bear on
these processes. It has been observed that engineers and scientists very often turn to a
 Bertoni M., Chirumalla K.: Leveraging Web 2.0 ... 549

person for information rather than to a database or a file cabinet, and people seem to
rely heavily on colleagues that they know and trust. Such informal, spontaneous and
relatively unstructured interactions are therefore crucial to successful collaboration.
The increasing globalization, however, has a negative influence on the knowledge
sharing performances of development teams. Effective sharing is challenged by more
distances than the geographical. Engineers are working together with more people
than ever before, but often with very limited knowledge of whom they are actually
working with, what their collaborators know, and to what extent they can be trusted.
Differences include language, culture (both ‘corporate’ and ‘local’), educational
background, government regulations and time zones, thus local knowledge [Randall,
07] tends to stay local. Issues of how to build trust, rapport, and respect to bridge
these differences are identified as crucial [Larsson, 2005].
To achieve effective global design teams, it is crucial to address and deal with
such issues of “social disconnectedness”. Social software represents a way to bridge
this gap, offering the possibility to the engineers to create and maintain a rich
network of connections with people with knowledge and experience in
complementary domains. This is particularly interesting when it comes to product
development activities, since that is a field where knowledge workers are explicitly
interested in avoiding redundancy, and instead seek novelty and innovation rather
than well-known knowledge.

2 Purpose and objectives

In this paper, the authors make the assertion that bottom-up, lightweight and Web 2.0
style technologies can have a serious potential when it comes to effectively share
knowledge between actors partaking in product development in a global and virtual
context. In spite of such an opportunity, companies find difficult to adopt and
successfully exploit Web 2.0 methods and tools in the organization.
The purpose of this paper is to define and discuss the Engineering 2.0 [Larsson,
08] concept, highlighting the context it originates from and the way it may enhance
collaboration across dislocated and cross-functional design teams. The paper
spotlights the current initiatives aiming to introduce a more bottom-up knowledge
sharing approach in the area of product development. Then, it collects application
examples and lessons learned from a cross-company study, exemplifying how tools
like e.g. blogs, wikis or forums can be applied in the everyday designers’ work, and
highlighting the major issues and the low-hanging fruits of Web 2.0 in product
development.
A delimitation of this paper is its focus on “engineers”, i.e. on the “engineering
task” and on how Web 2.0 technologies can support globally dispersed engineering
teams working in a business-to-business situation, where the available technology
support for knowledge sharing still centres heavily on comparably “heavyweight”
and top-down technologies like CAD, PDM, and PLM systems.
550 Bertoni M., Chirumalla K.: Leveraging Web 2.0 ...

3 Methodology

The research has been conducted within a Swedish Excellence Centre for Functional
Product Innovation, and has benefited from the participation to two research projects
in the European Commission’s FP6 and FP7 programmes.
More specifically, a cross-company case study [Yin, 94] has been conducted
within the Excellence Centre, in collaboration with an aircraft engine component and
a machining tool manufacturer. Data have been gathered from 37 semi-structured
interviews, two focus groups and several virtual meetings with people from the
participating companies.
The companies were chosen as the main research context because of their rich
experience with cross-functional global teams. The interview respondents belonged
to different company functions (product development, customer support, marketing,
production, IT service) and to different levels of the company hierarchy (process
owners, project managers, company specialists, system users). The interviews have
been made in six separate sessions at the company facilities between June 2008 and
May 2010. The average duration of the interviews is about 40 minutes. Each
interview was audio-recorded, transcribed, spell-checked and validated by the
respondents. The excerpts presented in this paper have been taken from these
recordings.
The interviews have been facilitated and moderated by the researchers to uncover
topics that were not anticipated beforehand [Fontana, 1994] and to build on the
findings from previous studies. An interview guide has served as a basis in the
interviews, but, in line with semi-structured interviews, additional topics that came
up in the discussion have also been followed up during these sessions.
The questions in the interview guide could best be described as open-ended
questions, i.e. questions that allow the informant to formulate the answer from his or
her point of view. One example of open-ended questions based on the topic
“knowledge work” is: “Do you share your expertise within the organization? If so,
how?”.
Four virtual workshops with the company specialists have been arranged to
validate the outcomes of the interviews and to further highlight priority areas of
intervention.
The cross-company study has been complemented by 15 questionnaires
forwarded to process owners and project managers belonging to major
manufacturing firms mostly in Sweden, but also in Germany and Italy. The
questionnaire included 13 multiple-choice questions, which aimed to gather data
about the State-of-Practice of how cross-functional global teams collaborate, and 4
open-ended questions, to collect deeper information about the knowledge sharing
barriers.
 Bertoni M., Chirumalla K.: Leveraging Web 2.0 ... 551

4 How Web 2.0 is spreading in product development: a review

Many organizations have started to investigate the use of Web 2.0 technologies in
their working environment. McAfee summarizes the rising company interest in the
use of Web 2.0 tools for generating, sharing and refining knowledge in a global
setting with the term Enterprise 2.0 [McAfee, 06]. Enterprise 2.0 is defined as “the
use of emergent social software platforms within companies, or between companies
and their partners or customers”. Shimazu [Shimazu, 07] has further discussed the
impact of Web 2.0 on knowledge management and its future orientation, introducing
a knowledge management model in the context of the Web 2.0 age that can expand
collective intelligence in a positive spiral by closely linking it to knowledge
extraction from various communication tools and job systems. The Knowledge 2.0
[Levy, 09] principles have been further explored from a generic company perspective
by many authors, such as Scherp [Scherp, 09], Sotirios [Sotirios, 09] and Richards
[Richards, 09].
For what concerns product development, the emerging interest towards bottom-
up and lightweight applications has been highlighted by a recent McKinsey [Bughin,
09] survey, showing that more than 2/3 of 1700 companies interviewed worldwide
have investigated or deployed Web 2.0 tools to support their product development
activities.
Web 2.0 tools are not completely new in product development, although their use
is limited to a comparably small part of the entire process, mainly with the intent of
gathering ideas and feedback on the product from the customer base.
Crowdsourcing [Howe, 06] represents the most intuitive way to leverage bottom-
up tools for the benefit of product development. Crowdsourcing essentially means
outsourcing a task to a large group of people or to a community (a crowd) through an
open call. The basic principle is that online consumer communities greatly add value
to new product development [Pitta, 05], thus Web 2.0 can leverage the critical role
that customers and the crowd play in the innovation process [Ribiere, 09].
Crowdsourcing is hugely popular in the software development domain. Dell
IdeaStorm [Di Gangi, 09] represents an example of how idea crowdsourcing may be
exploited in an early design stage of new products. Several top companies, such as
Microsoft, Apple or IBM, have made extensive use of social media to get feedback
from the customer and to share ideas with lead users ahead of beta testing [Smith,
09]. In manufacturing, Web 2.0 applications have been used to gather innovations for
both products and services [Awazu, 2009] [Mamgai, 09], sometime even by means
of virtual prototypes online [Füller, 06].
Web 2.0 tools have been also proposed to enable effective communication within
dis-located teams, particularly to improve collaboration and shared understanding in
the initial stages of a product development project [Walthall, 09]. A lightweight
knowledge sharing approach, based on a wiki-like annotation tool, to support
distributed software development teams has been proposed by Maalej [Maalej, 08].
The Microsoft Quest internal communications system [Patrick, 07] and the wiki-like
environment proposed by Ciavola et al. [Ciavola, 09] represent other examples of
552 Bertoni M., Chirumalla K.: Leveraging Web 2.0 ...

bottom-up collaborative platforms. Social bookmarking applications, such as IBM

Dogear [Miller, 06], have also been developed to support learning, sharing and
collaboration between researchers and professionals.
Similarly, Web 2.0 technologies have been proposed and implemented to support
product development projects’ documentation [Høimyr, 07] [Albers, 10]. Wiki-style
collaboration tools can be used to create assessment reports [Hawryszkiewycz, 07] or
to address the problems associated with maintaining rule-based systems as they grow
[Richards 2009]. Further, many companies have started to implement bottom-up
application to harvest product and process ideas from their employees, distribute
them through the organization, have them evaluated by peers or formal review teams,
and eventually to improve their offer and internal procedures [Awazu, 09].
A more collaborative approach for knowledge retrieval has been also proposed by
several authors, as a means to locate the right information just when needed.
Context-based applications [Schillit, 94] have been recently explored for the in-
context delivering of relevant knowledge from previous design activities in order to
improve future designs [Redon, 07]. The key element to successful reuse is to
understand a designer’s reuse intention, which is not merely expressed by few
keywords in a query. Significant improvement can be obtaining by providing tools
that allow users to express the applicability of a certain knowledge management to
their context, and, therefore to use such information to further refine future searches
and to provide more tailored knowledge to people with similar profiles [Redon,
2007].
Web 2.0 may also directly enhance the traditional CAD/PDM/PLM tools through
the integration of social features. PTC, for instance, is exploring how to leverage
social interaction and collaborative features, among global design teams,
complementing CAD/PDM tools with Web 2.0 applications [Shoemaker, 09]. Vuuch
(http://www.vuuch.com), a plug-in for Pro/ENGINEER or Dassault Systemes’
SolidWork, initiates, monitors, and manages design discussions directly from the
CAD environment to organize design discussions by associating them to the product
Bill of Material (BOM).

5 Rethinking Web 2.0 to cope with the emerging product development

trends
In a “traditional” product development situation, the product specifications are grown
from high-level, pre-defined archetypes (e.g. a screwdriver, a car, a washing
machine) and then refined in greater detail adding additional subsystem levels until
the system is reduced to base elements in a hierarchical, top-down, flavour. The
engineering work is typically co-located (i.e. the engineering team sits together in the
same physical space) and well supported by domain-specific applications such as, to
mention a few, CAD (Computer Aided Design), FEM (Finite Element Method),
PDM (Product Data Management), PLM (Product Lifecycle Management), and KBE
(Knowledge Based Engineering). These systems are proven to provide adequate
support in managing structured product information and formal communication, such
 Bertoni M., Chirumalla K.: Leveraging Web 2.0 ... 553

as project documents, design drawings, lessons learned, best practices records and
others.
One of the industrial drivers that causes us to reconsider the knowledge sharing
practices of product-developing organizations is the growing ‘virtualization’ of
companies, making them increasingly loosely coupled – which has serious
ramifications for the knowledge management practices and technologies that they
choose.
Taking the aerospace industry as an example, very few companies have
competences, knowledge and skills to cope with the development and supply of a
complex product such an aircraft engine, composed by thousands of parts, with an
expected lifecycle of 30-40 years.
A way to cope with such limitations is to establish a closer collaboration with a
multitude of actors across the value chain, building strategic alliances with
customers, suppliers, contractors, distributors, competitors and research centres
[Isaksson, 09] and to be able to share knowledge in an open mode with them. Virtual
Enterprise (VE) [Davidow, 92] are formed to access important information about, for
instance, the role of consumers, retailers, customer support and maintenance
[Isaksson, 09], which may allow to gain deeper insights into the basic reasoning that
makes the customer link the use of a product or service to perceived added value.
To make an example, a jet engine manufacturer, such as Rolls-Royce, might
develop engines to be used on both Airbus and Boeing aircraft, which are ordered by
different airliners, which are partners in different airline alliances, etc. Further, the
V2500 aero engine family is provided by International Aero Engines (IAE), a joint
venture including Pratt & Whitney, Rolls Royce, MTU Aero Engines and the
Japanese Aero Engines Corporation. Other examples of such virtual partnerships are
both the CFM International, a joint venture between GE and Snecma aiming to
develop the CFM56 aero engine product line, and the Engine Alliance (Engine
Alliance) a joint venture between GE and Pratt & Whitney to develop the GP7200
engines powering the Airbus A380.
Traditionally, cross-enterprise partnership are led by a single Original Equipment
Manufacturer (OEM), which can normally put its suppliers under contractual
obligation to share data, information, and knowledge through one or several
information systems of the OEM’s choice [Browne, 99]. However, in the case of a
Virtual Enterprise, the issue of what to share with others and how to share it is not as
easily resolved, since a VE is essentially a network of independent companies,
including suppliers, customers and even competitors, that are “…linked by
information technology to share skills, costs, and access to one another’s markets. It
has neither central office nor organization chart, no hierarchy, no vertical
integration.” [Byrne, 93].
Defined in logical terms, not physical, the VE is based on the idea of
organizations gaining access to more resources than they currently have available,
without having to expand. Since VEs are essentially “…networks of partners and
suppliers that work together to reach common goals. In this environment there is no
single partner that decides the infrastructure, tool set or processes to be used”
554 Bertoni M., Chirumalla K.: Leveraging Web 2.0 ...

[McAfee, 06], there is the need to find tools that have a low overhead and are easily
configured to be used by heterogeneous users. The prevailing hierarchical structure
of the PDM/PLM systems seems to contrast with the need to acquire knowledge and
obtain feedbacks from a large network of independent and geographically dispersed
peers. The development of an ad-hoc top-down collaboration platform is essentially
too costly and time-consuming in this volatile context.
The authors have also observed a move towards extending traditional product-
based offers to incorporate more intangible assets, i.e. software and services, taking
on lifecycle responsibilities (in a nutshell, an evolution of the leasing/pooling model)
to secure the aftermarket and to satisfy increasingly sophisticated customer needs.
In a Functional Products [Isaksson, 09] or Product Service Systems [Baines, 07]
perspective the manufacturer maintains the ownership over the product and becomes
responsible for the availability of the function through the entire life cycle, while
requesting the customers to pay only for the provision of agreed results.
An illustration of the new “functional product” idea is apparent in the Total-Care
Package [Shehab, 06] offered by Rolls-Royce plc. Rather than transferring the
ownership of an engine to the airliners, the provider delivers “power-by-the-hour”,
requesting the customer to pay only for the use of the product (e.g. number of flight
hours). In this way Rolls Royce can maintain direct access to the asset, enabling the
monitoring of the product performances in use and growing experience on how the
hardware is operated through the lifecycle. This information can be used later to
improve maintenance schedules, engine efficiency, upgrade the hardware and,
eventually, to increase the provision of lifecycle “value”. However, “value” refers to
different stakeholders and users, belonging to different organizations and groups,
sitting in different locations, and who may have totally different perceptions on what
“value” entails.
Intuitively, the knowledge base from which the product specifications are drawn
has to be extended to know more about the ultimate customer needs, their value
scale, and to tailor the hardware for a successful functional life. Engineers in an early
design stage need to take crucial decisions regarding the structure of the functional
offer and, consequently, they have to understand how a certain design alternative
impacts on the stakeholders’ value scale.
A jet engine could be kept in service even for several decades, thus knowledge
from the ‘later’ phases (i.e. production, use, maintenance, recycling, etc.) now needs
to be used as a knowledge foundation in the earliest design steps. A key challenge in
such boundary-crossing product development work is that, for complex products like
an aircraft engine, this value-related knowledge is dispersed across many different
VE partners and customers (e.g. aircraft manufacturers, airlines, passengers, ground
crew, airports, technical service) that use different technological systems to create,
store and share it.
The knowledge contributors may have different roles, background, computer
skills and may find cumbersome or even impossible to interact with domain-specific
applications such as CAD, PDM or PLM, leading to a situation where the vast
majority of people who might have knowledge about the emerging aspects of the
 Bertoni M., Chirumalla K.: Leveraging Web 2.0 ... 555

product cannot contribute in populating the knowledge base.

Additionally, Bell [Bell, 06] argues from his study that 80% of the organizational
knowledge is stored in people’s heads, while only one fifth is formalized in Office
documents e-mails, databases, XML data, etc. This informal knowledge exchange,
which normally takes place by means of emails, phone conversations, face-to-face
meetings or video-conferencing, is even more difficult in a VE context because the
development team, as a whole, usually does not have a previous history of working
together and there are fundamentally no ‘shared assumptions’ of how collaborative
work may proceed. Additionally, there is an inevitable flux of team members over
time in such projects, which makes even more difficult to share experiences, know-
how and feedback. All these factors represent a great obstacle when engineers
require authentic information, expert help, or when there is a need to search and
retrieve quality information.

6 Engineering 2.0: a definition

Engineering 2.0 [Larsson, 08] is an approach that promotes the use of Web 2.0 style
methods and tools to support informal knowledge sharing across functions and
companies in a Virtual Enterprise setting (Figure 1).

Figure 1: Engineering 2.0 mapped against current knowledge sharing approaches

The authors recognize that, to cope with upcoming product development trends, a
more bottom-up and lightweight (compared with traditional CAD/PDM/PLM
environments) approach for engineering knowledge management should be pursued.
556 Bertoni M., Chirumalla K.: Leveraging Web 2.0 ...

Lightweight because the purpose is to develop and implement solutions that require
little time and effort to setup, use and maintain. Bottom-up because it does not
impose a pre-defined structure, but rather lets structures evolve over time as an
almost organic response to the activities, practices and interests of the knowledge
workers that use these technologies as part of their everyday work.
The development and implementation of Web 2.0 style tools to support global,
cross-functional collaboration has been extensively discussed with the companies
involved in the cross-company study, which have pioneered the adoption of social
tools within its product development department. The discussion has outlined areas
where the benefit/risk ratio of Engineering 2.0 is particularly appealing for the
company. The major benefits are seen in the area of: new product opportunities
identification, capabilities identification and design rationale management.

7 Identification of new product opportunities

When dealing with complex products and targeting lifecycle commitments, it is

increasingly important to have a clear picture of a wide variety of customer needs
and to identify opportunities to improve the current offer both from a product and
service perspective.
The front line, the salesmen and technicians, may know a lot about the value of a
solution for the customer. This knowledge is still mostly exchanged via customer
visits reports or, informally, via face-to-face meetings, phone calls and spontaneous
discussions, as outlined by one of our informants in the matching tool industry:
“Once, one of our customers was trying to optimize a blade machining process using
some of our tools in his low-power machine. After a while, a technician visited his
shop floor and noticed that he had been able to get significant process improvements
by radically modifying the machining settings in a way we did not even expect in the
beginning. He made a video, which was stored in a local database. However, it took
several months before he could share what he saw with one of our product
development engineers, and it happened by chance at the margins of a training
event. The movie had been further analyzed and provided relevant knowledge for the
next tools’ development.”
Web 2.0 tools could be used to increase the product developers’ awareness about
what is “hot” at the customer today, facilitating the team in aggregating, filtering and
validating the heterogeneous inputs from the front line. It is not merely a matter of
forwarding the customer impressions to the engineers, rather to use the capabilities of
the Web 2.0 tools to attach the right context to this information and to better trace
how the needs originates and evolve.
The use of blogs and wikis to complement existing PDM/PLM solutions by
leveraging conversations and putting them in a more global and shared context has
been discussed with several company specialists:
“Blogs and wiki are powerful tools to pick up the coffee machine talks and to
increase the network around a certain problem area... In the same way as engineers
 Bertoni M., Chirumalla K.: Leveraging Web 2.0 ... 557

meet out in the corridor and discuss the matter, we can bring that discussion from
the corridor into the wiki and nurture a more open dialogue.”
Weblogs might be used as a platform for early feedback from external
stakeholders and employees, allowing them to engage in discussions [Payne, 08]
[Jim, 09] on product and service offers. They might provide a quick and lightweight
way to codify the front line experience, letting other people with similar interest to
rate, comment or ask for elucidations. New ideas and findings on innovation projects
could be presented to a larger audience as an entry in the weblog, lowering the
threshold for commenting and expressing opinions or document personal
experiences. Wikis, similarly might also be used as a space to collaboratively grow
ideas for future products and to define and refine best practices from the different
lifecycle phases, facilitating idea and experience sharing among the stakeholders.
Alerts might be used to update the product developers about any changes in the
global/local databases, while RSS feeds could allow design team members to
subscribe their choice of content resources to get regular updates in a standardized
format, pushing relevant information to the users at the right time in the right place.
Organizations might create RSS pages to accumulate all updates from various
databases that are specifically customized for the employees’ needs, and can help
them getting an overview of the hot topics in the organizations.
Forums could allow engineers to raise critical issues with the other partners in the
network, managing heavily moderated topical conversations over a prolonged period
[Mayfield, 09]. They can be used to scale up internal conversations and to get
feedback from experts in various domains and disciplines.
Tagging practices may facilitate the discovery of relevant knowledge outside the
product development boundaries. The knowledge codified by the VE stakeholders
may be put into different bins at a time (per customers, competitors, projects, product
types, maintenance and service offerings) making easier for others to locate and fetch
information tagged in the same way from different sources.
Microblogs might be used to spread innovative ideas, quotes, or links that may
allow others to give real-time and focused feedback on technical or service matters.
It might be possible to locate and follow experts in a VE setting, asking questions
and getting answers, ultimately creating a learning experience and fostering
professional connections.
The most evident benefits of Web 2.0 technologies relate to the possibility of
reducing the time end effort to identify knowledge owners from the front line, to
browse their inputs and to increase the awareness of the multi-functional issues
regarding a given topic. Eventually the knowledge contributors may benefit from an
increased awareness on people working in similar areas and, consequently, from the
learning opportunity offered by their continuous feedbacks.
558 Bertoni M., Chirumalla K.: Leveraging Web 2.0 ...

8 Locating the right capabilities in the organization

The study showed that social software plays a strong role in increasing the engineers’
social ties, discovering people “who knows” and people “who may help” with a
specific problem outside the usual network of connections. Design stakeholders who
have similar knowledge, that share the same interests to solve complicated tasks or
that possess complementary capabilities to cope with a given “wicked” problem, are
difficult to locate in a global product development context, as outlined by one of our
informants in the aircraft manufacturing industry:
“Our group comprises also a naval department. Once it developed an innovative and
heavily press released engine model, which broke down at his first public ride. Then,
at the annual corporate Christmas party, a group of naval engineers met experts
from our aerospace division and started to discuss the accident. Plenty of issues not
properly considered during design popped up. They went back to work, did the
modifications, and it worked. I think we need these Christmas parties online. We
have the right competences within our enterprise, but we are not good at finding
them.”
Social tools may support the discovery of people with the right expertise in the
virtual organization, thus reducing the time needed to identify and allocate resources
for a project. Moreover, they may help newcomers in exploiting the network of
connections that distinguishes more experienced engineers, finding people with the
right expertise inside and outside the company, i.e. “knowing who knows” [Groth,
04], as clearly explained by one of the project managers interviewed:
“We have tested social software functionalities with some of our competence centres
for internal questions. Instead of just talking to man next door, we can address
someone who is faster and more acknowledgeable to answer them.”
Social bookmarking, as a method to store, organize and share bookmarks of web,
may enable global engineering teams to search and find experts on specific topics, or
people with similar interests in the projects, based on informal browsing of
bookmark collections. Research engineers from various organizations can share their
research with peers and allow others to rate and review to decide on usefulness of
resources.
Nowadays it is quite common for companies to implement competence
repositories, where to store information on the “knowledge owners” within the
organization, such as the discipline they refer to or the project they have been
working on. A major drawback is that such systems are increasingly difficult to
populate and to keep up-to-date as time, as reported by one of our informants
working in human resource management:
“We tried 4-5 times to create a competence database, (a formal template) where
people were invited to describe their competences, the projects they have been
working on, etc... They have been very hard to populate... People felt they were too
structured, many fields didn't really matched... So we tried a new approach, letting
 Bertoni M., Chirumalla K.: Leveraging Web 2.0 ... 559

people to freely describe and update their personal information themselves... What
we see is that people are providing more information than before, and everything is
very visible”
Moreover, such databases mainly collect information about people working
within the reference organization, thus are useless when looking for people in the
Virtual Enterprise, such as experts in other companies or in academia. Web 2.0 tools
might be used to create cross-company “capability charts” to facilitate new design
teams’ formation. People could be more easily searchable, their profiles would be
more up-to-date, their network of connection would tell about their real interest and
experience, and it would be possible to quickly get in touch with them and verify
their availability in the beginning of a new project. The right match between people
and projects will ultimately lead to better team chemistry, higher motivations and
increased problem solving capabilities.

9 Capturing the design intent and its rationale

Web 2.0 tools offer the possibility to better capture the contextual information
that traditional systems lack to record and communicate, like the reasons why a
certain decision has been taken, by whom and under which conditions, and turning it
into public for the benefits of the team. Design rationale management is another key
area where the advantages of the lightweight and bottom-up paradigm are seen more
clearly by the industrial partners:
“People may have very personal ideas on how an engine mount or a boss should be
designed. Being able to formalize this unstructured information would mean that
very early other people could say “this is good” or “this is completely wrong”. We
have a lot of views on how to do things, that means reinventing the wheel at every
project… If we would be able to use social functionalities properly, the discussion
could rise much earlier than it happens today and we could even keep track of the
context in which information is generated.”
The rationale for decisions taken in past projects is often lost or hidden in
corporate databases that are not readily accessible by the design team once the
project is closed. The arguments on which design decisions are based may become
out-to-date, especially when the rationale comes from the later lifecycle stages and
relates to the way the product is operated, serviced, maintained, dismissed or
recycled.
To cope with the problem of keeping the design intent up-to-date, Web 2.0
technology can turn design rationale capture in a more bottom-up activity, involving
a larger stakeholders’ base in the codification of the argumentations for a certain
design decision. Wikis may be used on the top of the existing project repositories to
collect and give access to the underlying rationale regarding a solution even if the
original documentation is secured. They also are seen as a good approach to cope
with the lack of time for knowledge validation:
560 Bertoni M., Chirumalla K.: Leveraging Web 2.0 ...

“There are many lessons learned documents in the company, but it stops at that point
of being documented and nobody having time to review it. Wikis are one way to have
design practices and lessons learned better validated.”
Wikis, with their asynchronous, bottom-up and informal nature, may facilitate
experience sharing among the stakeholders, building an informal memory for the
Virtual Enterprise.
The use of Web 2.0 style tools to capture the design rationale has a deep impact
on the decision-making activity for large, complex projects. In a stage-gate process
[Cooper, 08], tools such as wikis are seen as a promising approach to speed up
decision making at the gate:
“A wiki system could support a more day-to-day process instead of waiting to a
project gate before analyzing what information we have. A Wiki could help catching
up all the potential lessons learned that support the gate passage and then co-
ordinate the information more towards process improvement… Before a meeting, we
could put in such a forum the most critical questions we want to discuss. If someone
has the response before the meeting the discussion would rise even before the
meeting starts.”
Open authorship can leverage the way best practices or lessons learned are
gathered from the different product life-cycle phases. Recommendations and context-
based filtering may help to make a more efficient use of the design rationale maps,
by supporting users in navigating their nodes and identifying the “golden nuggets”
for a particular task. Tags may be used to cross-link map nodes in different domains
and disciplines, while RSS feeds may aggregate and push real time updates to the
engineers’ desktop. Eventually, context-based filtering may be used to control the
access to the argumentation list, providing full access to a restricted group of people
while excluding others.

10 Discussion

The discussion with the industrial partners has outlined a number of issues from a
methodological and technological perspective that need to be addressed before a
wide adoption of Web 2.0 tools could be achieved. From a technological perspective,
the availability of ad-hoc mash-ups coping with the specific engineers’ tasks and
interests is needed. On the methodological end, the availability of robust guidelines,
especially concerning security and privacy issues, is seen as a major enabler for
scaling-up the approach.
The active user participation is perceived as a major constraint. Incentive policies
seem to be insufficient in a situation where engineers have to “do the job” and
deliver within strict deadlines. Finding ways to further reduce the effort for
knowledge formalization and exchange becomes an imperative, although it may not
be enough in the long term. Even the lower threshold may be seen insurmountable if
people cannot see the advantage of adopting the tools compared with traditional
systems.
 Bertoni M., Chirumalla K.: Leveraging Web 2.0 ... 561

Mass participation in bottom-up initiatives can be obtained only by increasing the

benefit/effort ratio of approach, both from the engineers’ viewpoint as well as for all
the other design stakeholders. This would mean: 1) providing customized knowledge
at the right time, using other people’s feedback to filter the query results on the basis
of their applicability and pushing information to the end users; 2) supporting
engineers in finding the unexpected, locating expertise and knowledge sources in the
organization and facilitating the serendipitous discovery of “unknown unknowns”
[Modica, 94]; 3) helping decision makers in recognizing relevant patterns, e.g.
improving information visualization and aggregating inputs from many sources via
ad-hoc mash-ups.
Knowledge validation is another critical aspect. Dealing with critical issues such
as passenger security, it is more important to base decisions on verified knowledge
rather then getting ideas, concepts and proposal from a wider base. Making the
coffee room conversation public via blogs, forums etc. exposes to the risk of building
a solution on knowledge that is not validated or tested, as outlined by one of our
informants:
“If you write down a design practice, it is validated and approved. If you write
something in a blog, it is not approved, but it is quite obvious that you cannot use it
as it is. But the wiki… if somebody writes: “you should design a mount like this”,
someone else may decide to design it on the base of such information even if no one
approves it. So, who is to blame? It is not a ranking system. Either you can design or
you cannot.”
As far as the solution is populated over time, noise, spam and duplicated
information increase as well, leading to a situation where the system is no longer
lightweight, but cumbersome to navigate and poorly retrievable. Many of the
respondents have expressed major concerns about the quality of the information
shared in such a bottom-up fashion, since social applications tend to be dominated by
the loudest and most persistent voices, exposing engineers to the risk of developing
critical solutions growing from personal opinions and interpretations rather than
facts.
The leakage of proprietary knowledge is seen as a major threat while discussing
Web 2.0 implementation in a cross-organizational setting. The possibility of letting
the information flow in an open mode exposes the company to the risk of being
drained of core know-how. Strict policies are advocated as the only means to
regulate these flows, although it is not straightforward to understand how these could
be established in practice. The lack of clear guidelines affects negatively users’
participation too. Without clear indications of what could or could not be shared,
users tend to “play safe” and rely only on the traditional CAD/PDM/PLM solutions.

11 Concluding remarks

The paper has explored the application of Web 2.0 technologies to support product
development efforts in a global, virtual and cross-functional setting, analyzing the
562 Bertoni M., Chirumalla K.: Leveraging Web 2.0 ...

dichotomy between CAD/PLM/PDM systems and the Social Web under the light of
the emerging product development trends.
The literature review as well as the cross-company study have outlined an
increasing interest towards Web 2.0 style technologies in product development,
together with a general lack of understanding on how they could be implemented to
support everyday engineering work, i.e. “socializing with a purpose”. The benefits of
using social media to cope with the engineering tasks are not evident to most of the
potential users. Today’s perception of the usefulness of mash-ups combining, for
instance, blogs, tags and RSS feeds, is particularly low, even in Virtual Enterprise
situations where the need for social functionalities might appear more evident at a
first look. Moreover, Engineering 2.0 can have negative consequences on the
preservation of company’s proprietary knowledge, e.g. pushing confidential
information to unknown subscribers. Strict policies concerning dissemination of
sensitive material are advocated as the only possible solution, although the risk of
spoiling the approach of its innovative potential becomes higher. Many concerns
about the quality and maturity of the information exchanged have also been raised.
One of the major risk is to develop a knowledge sharing solution dominated by
personal opinions and interpretations rather than verified facts.
In spite of all these potential drawbacks, the opportunity of leveraging a more
bottom-up and lightweight approach for knowledge sharing in the area of
opportunities identification, cross-functional teams composition and design rationale
capturing is widely seen. From a methodological perspective, it will be crucial in the
future to investigate how the lightweight approach may increase design teams
capabilities to prevent mistakes in design rather than correcting them. Engineering
2.0 should not merely support the design team in the classical “recognizing
symptoms - implementing corrective actions” working mode, rather it should support
designers in preventing mistakes, helping engineers in performing more effective
root-cause analysis. At this purpose, an Engineering 2.0 demonstrator is under
development to collect feedbacks on the use of lightweight and bottom-up techniques
in a cross-functional and cross-company design situation.
The field study has also highlighted that the benefits associated to a more bottom-
up and lightweight knowledge sharing approach are difficult to communicate in a
product development context, mainly because methods and techniques cannot easily
be related to dimensions relevant for the engineering teams. Currently under
development is a categorization framework [Bertoni, 10] to benchmark Web 2.0
applications, underlining similarities and differences in a meaningful way for
engineers, and to qualitatively evaluate how technology mash-ups could support the
knowledge sharing activity in a cross-functional context.

Acknowledgements
The authors sincerely acknowledge the Faste Laboratory, a
24M, 10-year,
VINNOVA VINN Excellence Centre initiative.
 Bertoni M., Chirumalla K.: Leveraging Web 2.0 ... 563

References
[Albers, 10] Albers, A., Ebel, B., Sauter C.: Combinign process model and semantic wiki, In Proc. Int. DESIGN
Conf., May 2010.
[Awazu, 09] Awazu, Y., Baloh, P., Desouza, K., Wecht, C. H., Jeffrey, K., Jha S.: Information-Communication
Technologies Open Up Innovation. Research-Technology Management, 52(1):51-58, 2009.
[Baines, 07] Baines, T.S., Lightfoot, H.W., Evans, S., et al.: State-of-the-art in Product-Service systems, Journal
of Engineering Manufacture, 211:1543-1552, 2007.
[Bell, 06] Bell, S.: Lean Enterprise Systems: Using IT for Continuous Improvement, John Wiley & Sons,
Hoboken, New Jersey, USA, 2006.
[Bertoni, 10] Bertoni, M.: Bottom-up knowledge sharing in PSS design. A classification framework, In Proc. Int.
DESIGN Conf., May 2010.
[Boeing, 06] Boeing, Technology Redefines Joy of Flight, June 2006,
http://www.boeingcapital.com/p2p/archive/06.2006/techredefinesjoy.htm.
[Browne, 99] Browne, J. and Zhang, J.: Extended and Virtual Enterprises - similarities and differences.
International Journal of Agile Management Systems, 1:30-36, 1999.
[Bughin, 09] Bughin, J.: How Companies are benefiting from Web 2.0, McKinsey Global Survey, June 2009.
[Byrne, 93] Byrne, J.: The Virtual Corporation. Business Week. Feb 8:98-104, 1993.
[Ciavola, 09] Ciavola B.T. and Gershenson, J.K.: Establishment of an Open, Wiki-Based Online Resource for
Collaboration in the Field of Product Family Design, In Proc. Int. Conf. Engineering Design, August 2009.
[Cooper, 08] Cooper, R. G.: Perspective: The Stage-Gate® Idea-to-Launch Process-Update, What's New, and
NexGen Systems. Journal of Product Innovation Management, 25:213-232, 2008.
[Di Gangi , 09] Di Gangi P.M. and Wasko M.: Steal my idea! Organizational adoption of user innovations from a
user innovation community: A case study of Dell IdeaStorm. Decision Support Systems, 48(1):303-312, 2009.
[Davidow 92] Davidow, W.H. and Malone, M.S.: The Virtual Corporation: Structuring and Revitalizing the
Corporation for the 21st Century. Harper Business, 1992.
[Fontana, 94] Fontana, A. Frey, J. H.: Interviewing: The Art of Science. In Denzin, N. K. and Lincoln, Y. S.
(Eds.) Handbook of Qualitative Research, Sage, Thousand Oaks, CA, 1994.
[Füller, 06] Füller, J., Bartl, M., Ernst, H. and Mühlbacher, H.: Community based innovation: How to integrate
members of virtual communities into new product development, Electronic Commerce Research, 6:57–73, 2006.
[Groth, 04] Groth, K.: On knowing who knows - An alternative approach to knowledge Management, Ph.D.
thesis, Royal Institute of Technology, Stockholm, 2004.
[Hawryszkiewycz, 07] Hawryszkiewycz, I.T.: Lightweight Technologies for Knowledge Based Collaborative
Applications, In Proc. IEEE Int. Conf. on E-Commerce Technology, pp. 255-264, 2007.
[Howe, 06] Howe, J.: The rise of crowdsourcing. Wired Magazine 14(6),
http://www.wired.com/wired/archive/14.06/crowds_pr.html, 2006.
[Høimyr, 07] Høimyr N. and Jones P.L.: Wikis supporting PLM and Technical Documentation, Int. Conf. of
Product Data Technology Europe, September 2007.
[Isaksson, 09] Isaksson, O., Larsson, T.C. et al.: Development of product-Service Systems: Challenges and
Opportunities for the manufacturing firm, Journal of Engineering Design, 20(4): 329-348, 2009.
[Jim, 09] Jim, B.: Going Social with Product Development, Tech-Clarity, Inc., 2009.
[Larsson, 05] Larsson, A.: Engineering Know-Who: Why Social Connectedness Matters to Global Design Teams.
Doctoral Thesis 2005:19 Luleå University of Technology, 2005.
[Larsson, 08] Larsson, A., Ericson, Å., Larsson, T., Randall, D.: Engineering 2.0: Exploring Lightweight
Technologies for the Virtual Enterprise, In Proc. Int. Conf. on the Design of Cooperative Systems, COOP 08,
564 Bertoni M., Chirumalla K.: Leveraging Web 2.0 ...

May 2008.
[Levy, 09] Levy, M.: Web 2.0 Implications on Knowledge Management, Journal of Knowledge Management,
13(1):120-134. 2009.
[Maalej, 08] Maalej, W., Happel, H.J.: A Lightweight Approach for Knowledge Sharing in Distributed Software
Teams. In T. Yamaguchi (Ed.): PAKM 2008, LNAI 5345, 2008.
[Mamgai, 09] Mamgai, A., Sanjog, J.: Web 2.0: Reshaping Organization Strategy in the Flat World, SETLabs
Briefings, 7(2), 2009.
[Mayfield, 09] Mayfield, R.: Enterprise Microblogging Whitepaper, Socialtext, September 2009.
[McAfee, 06] McAfee, A.: Enterprise 2.0: The Dawn of Emergent Collaboration, MIT Sloan Management
Review, 47(3)21-28, 2006.
[Miller, 06] Miller D.R.: Dogear: Social Bookmarking in the Enterprise, www.research.ibm.com/jam/601/p28-
millen.pd, 2006.
[Modica, 94] Modica, S., Rustichini, A.: Awareness and partitional information structures. Theory and Decision,
37(1):107-124, 1994
[Patrick, 07] Patrick, K., Dotsika, F.: Knowledge Sharing: Developing from within, The Learning Organizations
Journal, 14(5):395-406, 2007
[Payne, 08] Payne, J.: Using Wikis and blogs to improve collaborations and knowledge sharing, Strategic HR
Review, 7(3):5-12, 2008.
[Pitta, 05] Pitta, D.A. and Fowler D.: Online consumer communities and their value to new product developers.
Journal of Product & Brand Management, 14(5):283–291, 2005.
[Randall, 07] Randall, D., Harper, R., & Rouncefield, M.: Fieldwork for Design. London: Springer-Verlag, 2007.
[Redon, 07] Redon, R., Larsson, A., Leblond, R., Longueville, B.: VIVACE Context Based Search Platform. In
Proc. Int. Conference on Modeling and Using Context, August 2007.
[Ribiere, 09] Ribiere, M.V, Tuggle,, F.D.: Fostering innovation with KM 2.0, VINE: The journal of information
and knowledge management systems, 40(1):90-101, 2009.
[Richards, 09] Richards, D.: Social Software/Web 2.0 Approach to Collaborative Knowledge Engineering,
International Journal of Information Sciences, 179:2515-2523, 2009.
[Rittel, 73] Rittel, H. W. J. and Webber M.M.: Dilemmas in a General Theory of Planning, Policy Sciences
4:155–169, 1973.
[Scherp, 09] Scherp A., Schwagereit F. and Ireson T.: Web 2.0 and traditional knowledge management processes,
In Proc. Int. Workshop on Knowledge Services & Mashups, 2009.
[Schillit, 94] Schillit, B., Theimer, M.: Disseminating Active Map Information to Mobile Host, IEEE Network,
8(5):22-32., 1994.
[Shehab, 06] Shehab, E.M. and Roy, R.: Product service-systems: issues and challenges. In Proc. Int. Conf. on
Manufacturing Research, September 2006.
[Shimazu, 07] Shimazu H. and Shinichi K.: KM2. 0: Business knowledge sharing in the Web 2.0 age, NEC
Technical Journal, 2007.
[Shoemaker, 09] Shoemaker, T.: Social Networking and Product Development, Cadalyst, July 2009.
[Smith, 09] Smith, D., Valdes, R.: Web 2.0: Get ready for the next old thing. Gartner Research Paper, 2005.
[Sotirios, 09] Sotirios, P., Alya, A.S.: Determinants of Knowledge Sharing Using Web 2.0 Technologies, Journal
of Knowledge Management, 13(4):52-63, 2009.
[Walthall, 09] Walthall, C., Sauter, C., Deigendesch, T., Albers, A., Ramani, K.: Survey Of Wikis As Design
Support Tool. In Proc. Int. Conf. on Engineering Design, ICED '09 Stanford, CA, USA, 2009.
[Yin, 94] Yin, R.K.: Case Study Research: Design and Methods, 4th Edition, Applied Social Research Methods
Series, Vol. 5, Sage Publications, 2009.
Leveraging Web 2.0 in New Product Development:
Lessons Learned from a Cross-company Study
Paper

A
Bertoni, M. and Chirumalla, K
Journal of Universal Computer Science (JUCS)
Vol. 17, no. 4, pp. 548-564, 2011

Social Technologies For Cross-functional

Paper
Product Development: SWOT Analysis and Implications

Bertoni, M., Chirumalla, K. and Johansson, C

In Proceedings of 45th Hawaii International Conference on System
Sciences (HICSS-45), 4-7 January, Grand Wailea, Maui, 2012 B
Managing Knowledge for Product-Service System
Paper
Innovation: The Role of Web 2.0 Technologies

Chirumalla, K
Research-Technology Management Journal (RTM)
Vol. 56, no. 2, pp. 45-53, 2013 C
Capturing and Sharing Lessons Learned across
Paper
Boundaries: A Video-based Approach

Chirumalla, K., Bertoni, M., Johansson, C., Isaksson, O

In Proceedings of 20th European Conference on Information
Systems (ECIS’12), 10-13 June, Barcelona, Spain, 2012 D
Experience Feedback using Social Media: From the Paper
Product Lifecycle Phases to the Design Practices

Chirumalla, K., Bertoni, M., Johansson, C

In Proceedings of the 5th CIRP International Conference on Industrial
Product-Service Systems (IPS2): Product-Service Integration for
Sustainable Solutions, ed. H. Meier, pp. 459-471, Springer-Verlag, 2013 E
 2012 45th Hawaii International Conference on System Sciences

Social technologies for cross-functional product development: SWOT analysis

and implications
Marco Bertoni Koteshwar Chirumalla Christian Johansson
Luleå University of Technology Luleå University of Technology Luleå University of Technology
[email protected] [email protected] [email protected]

Abstract and expertise, which are difficult to find within a single

In product development, innovation means bringing company function or even within a single organization
together people with different expertise to develop [5]. Moreover, hardware-centered offers are
breakthrough product and service offers. In spite of increasingly complemented with different
their potential, cross-functional efforts are not yet combinations of software and services to satisfy
adequately supported from a knowledge perspective, increasingly sophisticated customer needs, as well as to
asking for a more open and bottom-up approach for secure aftermarket activities (e.g., Product Service
knowledge management. The paper aims to investigate Systems [6], Functional Products [7] and Industrial
how social technologies can enhance collaboration Product Service Systems [8]).
and knowledge sharing in complex, cross-functional In this scenario the design problem becomes
and cross-organizational product development increasingly wicked [9]. It can be adequately addressed
projects, highlighting the role of weak ties as enablers only by involving in the decision-making process
for more innovative design processes. Emerging from people from different functional areas, and with
data collected in two case studies within the European heterogeneous competencies and skills [10]. The
aeronautical industry, it applies the Strengths- development of collaborative decision-making
Weaknesses-Opportunities-Threats (SWOT) framework capabilities represents a main objective, as well as a
to highlight how wikis, blogs, forum or microblogs can
challenge, for these partnerships, which asks for
shorten lead-time and increase the quality of early
enhanced methods and tools to acquire knowledge
design decisions. Furthermore, it elaborates on how
the design team can enhance its perception of the from a large network of independent and
needs to be addressed and leverage its capability to geographically dispersed peers [11].
develop solutions for the task at hand.
2. Motivation and objectives

1. Introduction Nowadays, the existing technological support for

knowledge sharing within product development still
focuses on explicit knowledge, that is, knowledge is
In recent years, it is becoming common for embodied into 3D CAD (Computer Aided Design), and
companies in the manufacturing business to build CAE (Computer Aided Engineering) models, as well
strategic alliances with customers, suppliers, research as in PDM (Product Data Management), PLM (Product
centers [1], and even competitors [2] to radically Lifecycle Management) and KBE (Knowledge Based
develop (or even just to incrementally innovate) new Engineering) applications.
product/service solutions. In aerospace, for instance, This contrasts with what observed by Bell [12],
the V2500 aero engine family [3] has been developed who found that 80% of organizational knowledge is
by the IAE International Aero Engines AG, a multi- stored in people’s heads, 16% is stored as unstructured
national consortium led by Rolls Royce and Pratt & data, and only 4% is formalized in a structured form.
Whitney, together with the Japanese Aero Engines These figures are emphasized in cross-functional
Corporation (JAEC) and MTU Aero Engines. development efforts, and represent an obstacle when
Similarly, the CFM56 aero engine product line [4] is engineers require authentic information, expert help, or
developed by CFM International, a company joint- need to retrieve quality knowledge.
owned by the French SNECMA and General Electric Often cross-functional team members find it
Aviation. cumbersome or even impossible to interact with
The development of technologically complex domain-specific applications - such as the ones above -
products requires a wide range of skills, knowledge resulting in situations where the vast majority of

978-0-7695-4525-7/12 $26.00 © 2012 IEEE 3880

3918
DOI 10.1109/HICSS.2012.538
people who might have knowledge about the emerging chain, and details the cross-company knowledge flows
aspects of the product cannot contribute in populating analyzed during the study.
the knowledge base [11]. Hence, successful
product/service development efforts depend on the
capability to provide ad-hoc collaboration platforms,
where knowledge can flow smoothly and informally
across functional and organizational walls, establishing
personal relationships that transcend local boundaries
both socially and geographically.
The ground hypothesis of this study is that the
knowledge base for cross-functional and cross-
organizational development projects can be leveraged
(i.e., the knowledge elements on which design
decisions are taken can be improved in quantity and
quality) by complementing ‘top-down’ knowledge
sharing systems with ‘bottom-up’ solutions, to tap into
dispersed team‘s skills, capabilities, and competences -
in other words, on the ‘wisdom-of-the-crowd’ [13].
Emerging from two case studies in the aeronautical
supply chain, the paper investigates how social, Figure 1. Position of the case studies in a
bottom-up or “lightweight” (compared to the more simplified aeronautical supply chain
“heavyweight” traditional solutions) knowledge
sharing systems may supply to the increasing demand The companies were chosen as the main research
of knowledge of these teams. Accordingly, the two key context because of their rich experience with cross-
objectives of the paper are to: functional teams. The study has resulted in 37 semi-
• Discuss the role of weak ties as enablers for structured interviews and 6 focus groups with people
more collaborative and innovative cross- from the participating companies. The interview
functional development projects; respondents belonged to different company functions
• Analyze the key mechanisms introduced by (product development, customer support, marketing,
social technologies that can support these production and IT service) and to different levels of the
company hierarchy (process owners, project managers,
teams in shortening the decision making time
company specialists and system users).
and in increasing the quality of early design
The data gathering activity was performed in seven
decisions.
separate sessions at the respective company facilities
between June 2008 and January 2011. Each interview
3. Methodology was audio-recorded, transcribed, spell-checked and
validated by the respondents. The excerpts presented in
Two different industrial case studies served as basis this paper have been taken from these recordings.
for the research. The first one involved Company A, an The Strengths, Weaknesses, Opportunities, and
aircraft engine component manufacturer, which has Threats (SWOT) framework has been used throughout
pioneered, since a couple of years, the development the analysis to classify favorable or unfavorable factors
and implementation of Web 2.0 tools in its product to the adoption of social technologies within product
development environment. The study has analyzed the development, from which to define the requirements
knowledge flows between the company, its suppliers, for a system mock-up. Given the cross-functionality of
customers, and wholly owned subsidiary, to understand the project context, the SWOT has been chosen to
how cross-functional teams create, process, share, and stimulate the interaction across the functional
reuse information in their regular activities. boundaries. In spite of its simplistic structure [14] and
The second study was performed at a supplier level lack of diagnostic capacity [15], the widespread
(Company B). It analyzed the internal and external adoption and recognizability of the framework [16]
knowledge flows in relation with the existing have facilitated stakeholders who do not frequently
Document Management Systems (DMS), in the light of work together to engage in conversations [17][18] and
strengthening the connection between the company and to nurture discussions that would not have emerged in
the customers in the network. the normal course of a business struggling with short-
Figure 1 shows where the case studies are term issues [19]. The SWOT has essentially played the
positioned within a simplified aeronautical supply role of boundary object [20][21], enabling the

3919
3881
integration of knowledge across boundaries [22], that “Our group comprises also a naval
is, as a focal point around which knowing-in-practice department. Once it developed an
could arise [23]. innovative and heavily press released
engine model, which broke down at his
first public ride. Then, at the annual
4. The power of weak ties within cross- corporate Christmas party, a group of
functional development teams naval engineers met experts from our
aerospace division and started to discuss
the accident. Plenty of issues not
Within product development, it has been observed properly considered during design
that engineers and scientists very often turn to a person popped up. They went back to work,
for information rather than to a database or a file introduced a few modifications, and it
cabinet, and people seem to heavily rely on colleagues worked. I think we need these Christmas
that they know and trust [24]. However, the emerging parties online. We have the right
product development trends are pushing engineers to competences within our enterprise, but
work with more people than ever before, but often with we are not good at finding them.”
very limited knowledge of whom they are actually Nurturing weak ties becomes crucial for the design
working with, what their collaborators know, and to team to locate and exploit the hidden competencies in
what extent they can be trusted [24]. the extended organization and for the overall success
Furthermore, as highlighted by Granovetter [25], of any complex development initiative.
effective knowledge sharing is more likely to happen
through distant and infrequent relationships and ‘weak
ties’ [25], because they provide access to novel
5. Social technologies for product
information through connection to larger groups. In development: a literature review
contrast, ‘strong ties’ can only lead to redundant
information because knowledge is shared Many organizations have started to investigate the
predominantly within small groups where everyone use of bottom-up, social technologies in their working
knows what the others know [11]. Weak ties are, environment. McAfee [28] summarizes the rising
therefore, particularly interesting when it comes to company interest in the use of Web 2.0 tools for
product development activities, mainly because this is generating, sharing and refining knowledge in a global
a field where knowledge workers are explicitly setting with the term Enterprise 2.0, defined as: “the
interested in avoiding redundancy and seeking novelty use of emergent social software platforms within
and innovation. companies, or between companies and their partners or
Weak ties can support the design team in collecting customers” [28].
and interpreting the customer needs, i.e. the ‘problem’ Many authors have further discussed the impact of
to be solved. Larsson [11] has observed that the ability social technologies and bottom-up concepts on
to access and to understand needs fundamentally knowledge management. Shimazu and Shinichi [29],
depends on whom the design team talks to in the for instance, have introduced a knowledge
customer organization. The ‘customer’ is not a singe management model in the context of the Web 2.0 age
individual, but rather composed of many people, that can expand collective intelligence in a positive
typically dispersed in the customer network, who have spiral by closely linking it to knowledge extraction
different information about what the customer want. from various communication tools and job systems.
Providing means to develop ties with ‘lead-users’ [26], The Knowledge 2.0 [30] principles have been further
able to offer their advice and experience to innovate explored from a generic company perspective by
the product, can enhance the capability of the team to several authors, such as Scherp [31], Sotirios [32] and
understand how to add “value” to the customer, Richards [33].
identifying much earlier the right problem solving In the product development domain, the emerging
strategy to pursue. interest towards social and bottom-up applications has
Weak ties can also provide access to ‘hidden been highlighted by a recent McKinsey [34] survey,
experts’ around the enterprise that can support the team showing that more than 2/3 of 1700 companies
in coping with a given design problem. The foremost interviewed worldwide during 2008 have investigated
experts on the product/service might be outside of the or deployed Web 2.0 tools to support their product
official job description, not even on the company’s development activities. Hinchcliffe [35] calls this trend
payroll [27], as highlighted during the empirical study “Product Development 2.0”, a concept that embodies
at Company A: the use of social media to harness the collective
intelligence of the development team, involving all the

3920
3882
product stakeholders – users, producers, and when needed. The key element for successful reuse is
technologists - into the creation of the product. to understand a designer’s reuse intention, which is not
Online consumer communities are considered a merely expressed by few keywords in a query.
major source of inspiration for the designers [36], thus Context-based applications [55], therefore, have been
crowdsourcing [37] represents one of the most intuitive developed and used to support the in-context delivering
ways to use bottom-up tools for the benefit of product of relevant knowledge from terminated projects, as a
development. As widely acknowledged in the software means to improve future design activities [56].
domain, Web 2.0 can leverage the role the crowd plays Eventually, CAD/PDM software providers are
in the innovation process by lowering the threshold for exploring the possibility to leverage social interaction
outsourcing the design task to a community through an and collaborative features among global design teams,
open call [38]. Dell IdeaStorm [39] represents an complementing their tools with Web 2.0 applications.
example of how this concept may be exploited in an Vuuch (http://www.vuuch.com), for instance, is a plug-
early software design phase. Several top companies, in for Pro/ENGINEER or Dassault Systemes’
such as Microsoft, Apple or IBM, have made extensive SolidWork that initiates, monitors, and manages design
use of social media to get feedback from the customer discussions directly from the CAD environment by
and to share ideas with lead users ahead of beta testing associating them to the product Bill of Material.
[40]. In manufacturing, crowdsourcing applications
have been used to gather innovations for both products 6. SWOT analysis
and services [41] [42], even by means of virtual
prototypes online [43].
Similarly, many companies have started to The SWOT framework has been used to collect and
implement Web 2.0 tools to harvest product and summarize the main findings from the empirical study.
process ideas from their employees, to distribute them Strengths (S) and Opportunities (O) gather those
through the organization, to have them evaluated by factors that are favorable to the implementation of a
peers or formal review teams, and to eventually more bottom-up knowledge sharing approach, while
improve their internal procedures. The Microsoft Quest Weaknesses (W) and Threats (T) mention aspects
internal communications system [44], the wiki unfavorable to a more open strategy to knowledge
environment proposed by Ciavola et al. [45], and the management. Strengths (S) and Weaknesses (W) list
wiki-like annotation tool advised by Maalej [46] major lessons learned related to the intra-
represent examples of how a lightweight knowledge organizational implementation of lightweight tools at
sharing approach can enhance collaboration across Company A, while Opportunities (O) and Threats (T)
distributed development teams. highlight key areas of interest and inhibitors - both at
Social bookmarking applications, such as IBM Company A and B - related to the possibility of scaling
Dogear [47], have been developed to support learning, up the adoption of social technologies to a cross-
sharing and collaboration between researchers and company level.
professionals. Online forums are used to share product
knowledge with the users in the customer support 6.1. Strengths
phase [48], as well as to yield deeper insights when
measuring past and present patterns of customer
In complex and cross-functional development
experience [49]. Microblogging functionalities are also
projects social media are appreciated for their ability to
implemented to leverage connections and facilitate
leverage networking across the enterprise, supporting
knowledge sharing between different organizational
newcomers in exploiting the connections of more
areas [50].
experienced engineers. As acknowledged in the
Web 2.0 technologies can play a crucial role in
empirical study, they can reduce the time needed to
enhancing the way product development projects are
search for experts and knowledge owners outside the
documented [51] [52]. Wiki-style collaboration tools
usual designer’s range of connections:
have been often proposed to create assessment reports
[53] or to address the problems associated with “We have tested social software
maintaining rule-based systems as they grow [33]. functionalities with some of our
They have been found to enhance the team’s shared competence centres for internal
questions. Instead of just talking to man
understanding of the product to be developed, and to
next door, we can address someone who
support faster design iterations and better collaboration is faster and more acknowledgeable to
in an early stage [54]. answer them.”
Several authors promote their use to enhance
knowledge retrieval and to locate information just

3921
3883
 It has also been observed that social technologies knowledge management systems to collect ideas, needs
facilitate information reuse in a new project context and opportunities.
[24] by highlighting the ‘social’ processes related to
“In the same way as engineers meet in
information creation (e.g., by capturing the ‘know- the corridor and discuss the matter, we
why’ and linking knowledge elements to their owners), can bring that discussion from the
A major complaint against traditional document corridor into a wiki and get it more
repositories is that they are typically undecipherable to open.”
people outside the project, and even to the original
The empirical study has confirmed that blogs are
project members after time has passed [57]. People
preferably used to capture and disseminate expert
leave the organization, new members join the
insights and observations [64]. Wikis tend to be used
partnership and new requirements emerge along the
as ‘repositories’ to collect critical issues from project
way, making increasingly important to record the
meetings as well as spaces to collaboratively grow
context related to such content [58]. Social
ideas for future products and to define and refine best
technologies are seen as important enablers for
practices from the different lifecycle phases,
capturing and semi- structuring contextual and
facilitating idea and experience sharing among the
conversational knowledge [59] that traditional systems
stakeholders across the lifecycle.
usually fail to record and store [60][61].
“Blogs and wiki are powerful tools to 6.2. Weaknesses
pick up coffee machine talks and to
increase the network around a certain
problem area... they are good tools to
The empirical study has identified two major
capture information, you can put things factors inhibiting the straightforward implementation
in a more structured way than just talks... of lightweight collaborative environments in a product
It's about keeping information in order in development setting: (1) a company culture that
relation to each other, whether referring discourages working with unstructured information; (2)
to PDM or PLM.” individuals that refuse to take an active part in open
The ability of keeping existing product/service dialogues due to time concerns.
knowledge up to date has also been indicated as a Informal knowledge sharing is inhibited by a
major strength of a bottom-up strategy. The company culture that considers socializing during
establishment of self-regulating communities across working hours as a spare time activity, rather an
the extended organizations actively contributes in attempt to exploit key social capital. Younger
keeping knowledge elements active and dynamic by employees have appeared to be more acquainted with
incorporating experiences and discussions while and prone to adopt Web 2.0 tools in their everyday
applying them in specific situations [62]. activities. However, they also appeared to be the ones
Additionally, the respondents appreciate the mash- more rapidly absorbing the corporate culture when
up capabilities of these tools as means to tackle the hostile to the idea, especially when considering the tool
problem of information overload [63]. Mash-ups can not suitable for the “engineering work”.
facilitate knowledge reuse (pushing relevant Furthermore, in presence of strict deadline, the use
knowledge elements to the users at the right time in the of social tools is mostly seen as a burden for the
right place), increase the visibility of knowledge engineers. Under constant time pressure, the use of the
elements from heterogeneous sources (aggregating ‘official’ document management systems is prioritized
lessons learned and best practices from different life and knowledge capture tends to be reduced to a
cycle phases) and improve their analysis, taking minimum. Wikis, blogs and forums are thus seen as
advantage of associative processing. environments where users are forced to “duplicate”
Social technologies have also been advocated to information already existing in other sources, thus they
leverage creativity across extended organizations
tend to be ignored.
through crowdsourcing. Most of the respondents Knowledge quality was also found as a major
noticed that crucial lifecycle knowledge is rarely weakness, which strongly limits the real life
straightforwardly fed back to the engineering team. implementation of these tools:
Social technologies can enhance this process, enabling
the “front row” (e.g., salesmen, technicians, customer “If we write down our thoughts and
support) to record, share and communicate facts and opinions, people can use them as the
experiences back to the designers. Blogs, wikis or truth, as a basis for decisions… If you
write down a design practice, it is
forums are not domain- or discipline-specific, thus they
validated and approved. If you write
can be used outside the boundaries of the traditional something in a blog, it is not approved,

3922
3884
 but it is quite obvious that you cannot use ambiguities and uncertainties. By making downstream
it as it is. But the wiki… if somebody knowledge available in an earlier phase, simulation
writes: “you should design a mount like models could be populated and used much earlier than
this”, someone else may use such
information even if no one approves it. It
what happens today, which would ultimately increase
is not a ranking system. Either you can the design team capability to prevent mistakes later in
design or you cannot.” the lifecycle. Failures might be predicted - and
corrective actions put in place - even before a
A major fear is that social technologies tend to be
product/service is operated.
dominated by the loudest and most persistent voices,
Social tools might significantly contribute in
leaning towards personal opinions and interpretations
shortening the start-up time for complex development
rather than verified facts. This problem is particularly
projects as well. The team might be able to more easily
remarkable within the domain studied (the aerospace
glance through the knowledge baseline, e.g. by using
industry) because design decisions strongly affect
context-based search engines to retrieve knowledge
passenger safety and thus require a very solid,
elements relevant for the task/gate it is operating in.
objective and verified knowledge base (i.e., they must
Web 2.0 might also support a more serendipitous
not be biased by personal comments, impressions or
discovery of knowledge across applications and
unverified facts). Without clear indications of what can
domains, e.g. matching heterogeneous knowledge
or cannot be shared, users tend to play a safer game
elements together on the basis of their tag
and rely on the information from more ‘official’
commonality.
knowledge sources.
Eventually, social technologies can help the project
management in locating capabilities across the
6.3. Opportunities extended organization. Engineers and designers might
use social network applications to constantly update
In a cross-functional and cross-organizational their profile description, providing more up-to-date
setting, a more bottom-up knowledge sharing approach information on background, experience and interests
is advocated to positively impact the way information compared with more top-down competence databases.
is prepared and used in a Stage-Gate® process [65],
supporting a more collaborative and iterative process 6.4. Threats
for what concerns knowledge validation.
The study has shown that this activity is largely Knowledge leakage represents the most obvious
dominated by personal relationships and physical threat related to the implementation of bottom-up
interactions. Engineers are used to turn to people they strategy in a multi-company partnership. Mishandling
know and trust to confirm knowledge they possess. RSS feeds, for instance might push confidential
However, these people are difficult to find in product information to unknown subscribers in the network,
development setting that spans across several exposing core know-how or customer requirements.
companies and functions. Hence companies tend to be over-defensive in using
Social technologies offer a unique opportunity to these approaches, prescribing rigid set of rules
bring people together in a common forum to concerning what can be spread and what can be not,
collectively answer questions such as: What do we eventually spoiling the initiative of all its bottom-up
know from previous projects? What are we lacking? potential.
Has anything already been done related to this context? The limited longevity of the knowledge stored in
the lightweight system has been also discussed in the
“People may have very personal ideas on
study. An aircraft can be maintained in service for
how an engine mount or a boss should be
designed. Being able to formalize this more than 40 years. If problems happen, engineers
unstructured information would mean have to trace the issue back to its roots, perhaps in a
that very early other people could say: design document that is twenty years old. Important
“this is good” or “this is completely information about “why” a certain decision was taken
wrong”… If we would be able to use might be too dispersed - or hidden by other elements -
these social functionalities properly, the to be retrievable.
discussion could rise much earlier than it At a more personal level, shared spaces that allow
happens today… We could keep track of each and every individual to see what others have
the context in which information is
written or what they have commented upon might
generated.”
trigger self-censorship behaviors. Individuals might
Social technologies might enable decisions makers avoid sharing remarkable knowledge elements
to deliberate with greater awareness and fewer purposefully, or might moderate the quality of

3923
3885
knowledge elements to benefit the interests of their which the design information is produced. More in
team/company. People might also tend to not expose detail, the priority lies in the development of bottom-up
themselves openly because misinterpreted words might tools (and related guidelines) able to lower the
affect personal communication or damage professional threshold for gathering contextual information in
reputation [66]. relation with customer needs, lessons learned and best
practices.
7. Discussion The analysis also spotlights the new role played in
the modern organization by all those individuals –
from production, marketing, sales, maintenance,
The outcome of the SWOT analysis is summarized disposal, etc. – who possess relevant knowledge for the
in Table 1: development of product/service offers. When
approaching the design problem from a lifecycle
Table 1. SWOT analysis summary perspective, their responsibility is expanded to cover a
wider range of issues, thus they are increasingly asked
to play the role of ‘knowledge brokers’ in the extended
organization, making their knowledge available to a
larger network of peers.
How should their performances be evaluated? How
should incentives be established? How should this
modern ‘knowledge worker’ be trained? The Stanford
University’s ‘d.school’ ambition to create ‘T-shaped’
people [67] expresses well the need to train individuals
in different parts of the organization able to assimilate
and integrate different perspectives in their work. T-
shaped people “maintain the depth and focus of a
single discipline while adding a ‘crossbar’ of design
thinking that drives the integration of multiple
perspectives into solving real problems.” [67]. The
successful adoption of a bottom-up strategy when it
comes to product/service development strongly
depends from the ability to create a broader ‘empathy’
(the horizontal part of the T) when it comes to
respecting, valuing and embracing a diverse set of
disciplines and perspectives.
This modern knowledge workers need knowledge
sharing technologies whose structure can evolve over
time, as an almost organic response to their activities,
practices and interests. This need for flexibility is not
The analysis shows that ‘social product addressed by the current knowledge engineering
development’ is largely about providing technologies systems, but could be instead satisfied by modern Web
that facilitate the empathic discovery of knowledge in a 2.0 solutions. As observed in the study, blogs, wikis,
variety of knowledge sources spread across the many social networks, RSS feeds, tags, microblogs, instant
corners of the extended enterprise. messages, discussion forums and social bookmarks
By comparing strengths, weaknesses, opportunities seem to perfectly fit with the evolution of product
and threats, the SWOT contributes to the identification development practices, and can therefore play a crucial
of the low-hanging fruits of such a bottom-up role to enhance engineering activities across functional
knowledge sharing strategy, which can be used as a boundaries.
starting point for defining how the requirements for a
sustainable lightweight knowledge sharing system
should look like. 8. Conclusions
As shown in the SWOT, the overall purpose of
social technologies is not to straightforwardly replace The paper has discussed the role of weak ties as
CAD software and data warehouses, but rather to enablers for more collaborative and innovative cross-
provide more visibility and enrich the data contained functional development projects.
therein, by capturing and framing the conversation in

3924
3886
 The findings confirm that, although social A software demonstrator integrating some of the
technologies are not intended to replace traditional key mechanisms highlighted during the study is under
CAD/PDM/PLM systems, they can improve the development, mainly with the purpose of collecting
knowledge baseline for complex product development live feedback from engineers and designers on the use
projects, essentially providing the necessary context to of social tools as enablers for more effective and
leverage the way information is interpreted and efficient cross-functional product development
processed by the engineers to solve the task at hand. projects.
The empirical study has shown that these technologies
can support designers in capturing and semi-structuring 9. Acknowledgements
conversational knowledge from a larger stakeholders’
base, and to communicate it in a meaningful way for The research is supported by VINNOVA (Swedish
the design task. Examples have been also given in Agency for Innovation Systems), through the FASTE
terms of how social tools can be applied in a Stage- Laboratory at Luleå University of Technology.
Gate® process [65] to increase the quality of early
design decisions, that is, by collecting facts, opinions
and suggestions on how to deal with wicked design 10. References
problems before the gate meeting.
Web 2.0 tools can help engineers in finding people [1] T. Khanna, R. Gulati, N. Nohria, “The dynamics of
learning alliances: competition, co-operation, and relative
who tag items the same way they do, in identifying scope”, Strategic Management Journal, Vol. 19, 1998, pp.
hidden experts by reading comments in a blog, or in 193–210.
finding social groups with similar interests by
browsing their bookmarks collection. From a [2] G. Hamel, Y.L. Doz and C.K. Prahalad, “Collaborate
development process perspective, these mechanisms with your competitors and win”, Harvard Business Review,
Vol. 67, 1989, pp. 133–139.
can leverage the way the design team identify the
needed expertise in extended organization, the way the [3] Rolls Royce, “International Aero Engines V2500”,
“context” of the information stored in databases and available at: http://www.rolls-
repositories is captured and managed, as well as the royce.com/civil/products/largeaircraft/v2500/, accessed 12th
way knowledge assets are validated in a collaborative June 2011.
environment. [4] J. Bilien and R. Matta, “The CFM56 Venture”,
The study has also outlined a general lack of Proceedings of the Aircraft Design, Systems, and Operations
understanding of how such technologies could be Conference, Seattle (WA), 1989.
implemented to support everyday engineering [5] V. Acha. A. Davies, M. Hobday and A. Salter,
activities, that is, “socializing with a purpose”. In spite “Exploring the capital goods economy: complex product
of the increasing interest towards bottom-up concepts, systems in the UK”, Industrial and Corporate Change,
today’s perception of weak ties as enablers for more Vol.13, 2004, pp. 505-529.
innovative and effective development processes is
[6] T.S. Baines, H.W. Lightfoot, S. Evans, et al., “State-of-
particularly low, even in cross-organizational projects the-art in Product-Service systems”, Journal of Engineering
where this need might appear more evident at a first Manufacture, Vol. 211, 2007, pp. 1543-1552.
look.
The risk that proprietary know-how could pop-up [7] Å. Ericson, T. Larsson, “A service perspective on product
development: towards functional products”, Proceedings of
somewhere in the network for the benefits of the
the 12th International Product Development Conference
competitors is the major inhibitor for the (IPDM), Copenhagen (DK), 2005.
implementation of social tools at the workplace. This
asks for devising better policies and guidelines on how [8] M. Lindahl, E. Sundin, A. Öhrwall Rönnbäck, G. Ölundh,
these technologies shall be used within and across the and J. Östlin, “Integrated Product and Service Engineering –
the IPSE project”, Proceedigns of the Sustainable
design teams.
Consumption Research Exchange Workshop (SCORE!),
In the light of these findings, in the close future the Copenhagen (DK), 2006.
research will focus on three major questions arisen
from the empirical study: 1) How knowledge elements [9] M.M. Webber and H. Rittel, “Dilemmas in a General
can be aggregated in a meaningful way and managed Theory of Planning”, Policy Sciences, Vol. 4, 1973, pp.155-
169.
along the product lifecycle, taking care of trust and
security issues? 2) How their quality and maturity can [10] O. Isaksson, T.C. Larsson and A. Öhrwall Rönnbäck,
be assessed? 3) How to enhance user commitment in “Development of product-Service Systems: Challenges and
the Web 2.0 initiative? Opportunities for the manufacturing firm”, Journal of
Engineering Design, Vol. 20, No. 4, 2009, pp. 329-348.

3925
3887
[11] A. Larsson, Å. Ericson, T.C. Larsson and D. Randall, [27] R. Mayfield, “Enterprise Microblogging Whitepaper”,
“Engineering 2.0: exploring lightweight technologies for the Socialtext, 2009.
Virtual Enterprise”, Proceedings of International Conference
[28] A. McAfee, “Enterprise 2.0: The Dawn of Emergent
on the Design of Cooperative Systems (COOP), Carry-le-
Collaboration”, MIT Sloan Management Review, Vol. 47,
Rouet (F), 2008.
No. 3, 2006, pp. 21-28.
[12] S. Bell, Lean enterprise systems: using IT for continuous
[29] H. Shimazu and K. Shinichi, “KM2.0: Business
improvement” John Wiley & Sons, Hoboken, 2006.
knowledge sharing in the Web 2.0 age, NEC Technical
[13] J. Surowiecki, The Wisdom of Crowds: Why the Many Journal, 2007.
Are Smarter Than the Few and How Collective Wisdom
[30] M. Levy, “Web 2.0 Implications on Knowledge
Shapes Business, Economies, Societies and Nations,
Management”, Journal of Knowledge Management, Vol. 13,
Doubleday, New York, 2004.
No.1, 2009, pp.120-134.
[14] D.W. Pickton and S. Wright, “What’s SWOT in
[31] A. Scherp, F. Schwagereit and T. Ireson, “Web 2.0 and
strategic analysis?”, Strategic Change, Vol. 7, 1998, pp. 101-
traditional knowledge management processes”, Proceedings
109.
of the 1st Workshop on Knowledge Services & Mashups
[15] M.M. Helms and J. Nixon, “Exploring SWOT analysis – (KSM), Solothurn (CH), 2009.
where are we now?”, Journal of Strategy and Management
[32] P. Sotirios and A.S. Alya, “Determinants of Knowledge
Vol. 3, No. 3, 2010, pp. 215-251.
Sharing Using Web 2.0 Technologies”, Journal of
[16] P. Jarzabkowski and D.C. Wilson, “Actionable Strategy Knowledge Management, Vol. 13, No. 4, 2009, pp. 52-63.
Knowledge: A Practice Perspective”, European Management
[33] D. Richards, “A Social Software/Web 2.0 Approach to
Journal, Vol. 24, No. 5, 2006, pp. 348–67.
Collaborative Knowledge Engineering”, International Journal
[17] T. Hill and R. Westbrook, “SWOT Analysis: It’s Time of Information Sciences, Vol. 179, 2009, pp. 2515-2523.
for a Product Recall”, Long Range Planning, Vol. 30, No. 1,
[34] J. Bughin, How Companies are benefiting from Web
1997, pp. 46–52.
2.0, McKinsey Global Survey results, 2009.
[18] N. Worren, K. Moore and R. Elliot, “When Theories
[35] D. Hinchcliffe, “Product Development 2.0”,
Become Tools: Toward a Framework for Pragmatic Validity”
Communications & Strategies, Vol. 65, 2007, p. 105.
Human Relations, Vol. 55, No. 10, 2002, pp. 1227–49.
[36] D.A. Pitta and D. Fowler, “Online consumer
[19] R.W. Oliver, “The real-time toolbox”, The Journal of
communities and their value to new product developers”,
Business Strategy, Vol. 21, No. 2, 2000, pp. 7-10.
Journal of Product & Brand Management, Vol. 14, No. 5,
[20] S.L. Star and J.R. Griesemer, “Institutional Ecology, 2005, pp. 283–291.
'Translations' and Boundary Objects: Amateurs and
[37] J. Howe, “The rise of crowdsourcing”, Wired Magazine,
Professionals in Berkeley's Museum of Vertebrate Zoology,
Issue 14.06, 2006, 5p.
1907-39”, Social Studies of Science, Vol. 19, No. 3, 1989,
pp. 387-420. [38] M.V. Ribiere and F.D. Tuggle, “Fostering innovation
with KM 2.0”, VINE, Vol. 40. No. 1, 2010, pp. 90-101.
[21] P.R. Carlile, “A Pragmatic View of Knowledge and
Boundaries: Boundary Objects in New Product [39] P.M. Di Gangi and M. Wasko, “Steal my idea!
Development” Organization Science, Vol. 13, No. 4, 2002, Organizational adoption of user innovations from a user
pp. 442-455. innovation community: A case study of Dell IdeaStorm”,
Decision Support Systems, Vol. 48, No. 1, 2009, pp. 303-
[22] A.P. Spee, P. Jarzabkowski, “Strategy tools as boundary
312.
objects”. Strategic Organization, Vol 7, No.2, pp. 223–232.
[40] D. Smith and R. Valdes, Web 2.0: Get ready for the next
[23] S. Cook and J. Brown, “Bridging epistemologies: the
old thing, Gartner Research Paper, Stamford, 2005.
generative dance between organizational knowledge and
organizational knowing”, Organization Science, Vol. 10, No. [41] Y. Awazu, P. Baloh, K. Desouza, C.H. Wecht, K.
4, 1999, pp. 381–400. Jeffrey and S. Jha, “Information-Communication
Technologies Open Up Innovation”. Research-Technology
[24] A. Larsson, Engineering Know-Who: Why Social
Management, Vol. 52, No. 1, 2009, pp. 51-58.
Connectedness Matters to Global Design Teams, Doctoral
Thesis, Luleå University of Technology, Luleå, 2005. [42] A. Mamgai and J. Sanjog, “Web 2.0: Reshaping
Organization Strategy in the Flat World”, SETLabs
[25] M. Granovetter, “The Strength of Weak Ties”,
Briefings, Vol. 7, No. 2, 2009.
American Journal of Sociology, Vol. 6, 1973, pp. 1360-1380.
[43] J. Füller, M. Bartl, H. Ernst and H. Mühlbacher,
[26] E. von Hippel, “Sticky information and the locus of
“Community based innovation: How to integrate members of
problem solving: Implications for innovation”, Management
virtual communities into new product development”,
Science, Vol. 40, No. 4, 1994, pp. 429-439.
Electronic Commerce Research, Vol. 6, 2006, pp. 57–73.

3926
3888
[44] K. Patrick and F. Dotsika, “Knowledge Sharing: [56] R. Redon, A. Larsson, R. Leblond and B. Longueville,
Developing from within”, The Learning Organizations “VIVACE Context Based Search Platform”, Proceedings of
Journal, Vol. 14, No. 5, 2007, pp. 395-406. the 6th International and Interdisciplinary Conference on
Modeling and Using Context (CONTEXT), Roskilde (DK),
[45] B.T. Ciavola and J.K. Gershenson, “Establishment of an 2007.
Open, Wiki-Based Online Resource for Collaboration in the
Field of Product Family Design”, Proceedings of the 17th [57] J. Grudin, “Enterprise knowledge management and
International Conference on Engineering Design (ICED), emerging technologies”, Proceedings of the 39th Hawaii
Stanford (CA), 2009. International Conference on System Sciences, (HICSS),
Washington (D.C.), 2006.
[46] W. Maalej and H.J. Happel, “A Lightweight Approach
for Knowledge Sharing in Distributed Software Teams”, [58] G. Goldkuhl and E. Braf, “Contextual knowledge
Proceedings of the 7th International Conference on the analysis - understanding knowledge and its relations to action
Practical aspects of Knowledge Management (PAKM), and communication”, Proceedings of 2nd European
Yokohama (J), 2008, pp. 14–25. Conference on Knowledge Management, Bled (SLO), 2001.
[47] D.R. Miller, Dogear: Social Bookmarking in the [59] C. Wagner, “Breaking the Knowledge Acquisition
Enterprise, available at: Bottleneck Through Conversational Knowledge
www.research.ibm.com/jam/601/p28-millen.pd. Management”, Information Resources Management Journal,
Vol. 19, No. 1, 2006, pp. 70-83.
[48] J. Bernoff and C. Li, “Harnessing the Power of the Oh-
So-Social Web”, MIT Sloan Management Review, Vol. 49, [60] T. Davenport and L. Prusak, Working Knowledge,
No. 3, 2008. Harvard Business School Press, 1998.
[49] C. Meyer and A. Schwager, “Understanding Customer [61] S. Liao, “Knowledge management technologies and
Experience”, Harvard Business Review, Vol. 85, 2007, pp. applications-literature review from 1995 to 2002”, Expert
117–126. Systems with Applications, Vol. 25, 2003, pp. 155-164.
[50] J. Müller and A. Stocker, “Enterprise Microbloging at [62] Y. Barnard and A. Rothe, “Knowledge Management in
Siemens, Building Technologies division: A descriptive case engineering: supporting analysis and design processes in
study”, Proceedings of the I-KNOW conference, Graz (A), innovative industries”, In P. Cunningham, P., Cunningham,
2010. M. and Fatelnig, P., Building the Knowledge Economy,
Issues, applications, Case studies, IOS Press Amsterdam,
[51] N. Høimyr and P.L. Jones, “Wikis supporting PLM and 2003, pp. 931-938.
Technical Documentation”, Proceedings of the Product Data
Technology (PDT) Europe Conference, Geneva (CH), 2007. [63] P. Maes, “Agents that reduce work and information
overload”, Communications of the ACM, Vol. 37, No. 7,
[52] A. Albers, B. Ebel and C. Sauter, “Combining process 1994, pp. 31-40.
model and semantic wiki, Proceedings of the 10th DESIGN
Conference, Dubrovnick (HR), 2010. [64] L. Efimova and J. Grudin, “Crossing Boundaries: A
Case Study of Employee Blogging”, Proceedings of the 40th
[53] I.T. Hawryszkiewycz, “Lightweight Technologies for Hawaii International Conference on System Sciences
Knowledge Based Collaborative Applications”, Proceedings (HICSS), Big Island (HI), 2007.
of the 9th IEEE International Conference on E-Commerce
Technology and the 4th IEEE International Conference on [65] R.G. Cooper, “Perspective: The Stage-Gate® Idea-to-
Enterprise Computing, E-Commerce, and E-Services, Tokyo Launch Process-Update, What's New, and NexGen Systems”,
(J), 2007, pp. 255-264. Journal of Product Innovation Management, Vol. 25, 2008,
pp. 213-232.
[54] C. Walthall, C. Sauter, T. Deigendesch, A. Albers, K.
Ramani, “Survey Of Wikis As Design Support Tool”, [66] G. Disester, “Individual and Social Barriers to
Proceedings of the 17th International Conference on Knowledge Transfer”, Proceedings of the 34th Hawaii
Engineering Design (ICED), Stanford (CA), 2009. International Conference on System Sciences (HICSS), Big
Island (HI), 2007.
[55] B. Schillit, N. Adams, and R. Want, “Context-Aware
Computing Applications”, Proceedings of the 1st [67] T. Winograd, “Design Education for Business and
International Workshop on Mobile Computing Systems and Engineering Management Students: A New Approach”,
Applications, Santa Cruz (CA), 1994, pp. 85-90. Interactions, January + February, 2008.

3927
3889
Leveraging Web 2.0 in New Product Development:
Lessons Learned from a Cross-company Study
Paper

A
Bertoni, M. and Chirumalla, K
Journal of Universal Computer Science (JUCS)
Vol. 17, no. 4, pp. 548-564, 2011

Social Technologies For Cross-functional

Paper
Product Development: SWOT Analysis and Implications

Bertoni, M., Chirumalla, K. and Johansson, C

In Proceedings of 45th Hawaii International Conference on System
Sciences (HICSS-45), 4-7 January, Grand Wailea, Maui, 2012 B
Managing Knowledge for Product-Service System
Paper
Innovation: The Role of Web 2.0 Technologies

Chirumalla, K
Research-Technology Management Journal (RTM)
Vol. 56, no. 2, pp. 45-53, 2013 C
Capturing and Sharing Lessons Learned across
Paper
Boundaries: A Video-based Approach

Chirumalla, K., Bertoni, M., Johansson, C., Isaksson, O

In Proceedings of 20th European Conference on Information
Systems (ECIS’12), 10-13 June, Barcelona, Spain, 2012 D
Experience Feedback using Social Media: From the Paper
Product Lifecycle Phases to the Design Practices

Chirumalla, K., Bertoni, M., Johansson, C

In Proceedings of the 5th CIRP International Conference on Industrial
Product-Service Systems (IPS2): Product-Service Integration for
Sustainable Solutions, ed. H. Meier, pp. 459-471, Springer-Verlag, 2013 E
 FEATURE ARTICLE

Managing Knowledge for Product-Service

System Innovation
The Role of Web 2.0 Technologies
Web 2.0 tools can lower barriers to sharing unstructured knowledge, contextualized information, and networks of connections,
as well as facilitating the collective creation of knowledge.

Koteshwar Chirumalla

OVERVIEW: In the emerging service economy, many traditional product manufacturing companies are seeking innovative
ways to do business, focusing on product-service combinations. Development of these offerings requires the integration of
a wider span of expertise from several companies, which poses new challenges in the way knowledge is captured and man-
aged. On the basis of a case study from an aerospace supply chain, this paper first identifies the limitations of current
knowledge-management systems in such a setting and then discusses the role of Web 2.0 technologies in managing knowl-
edge across the knowledge life cycle. Web 2.0 technologies have potential to lower barriers to leveraging informal and
unstructured knowledge, contextualized information, networks of connections, and collective creation and maintenance
of knowledge assets, which could complement current knowledge-management systems in multicompany product devel-
opment efforts.
KEYWORDS: Knowledge management, Web 2.0, Product-service systems, Knowledge life cycle

In today’s competitive business environment, companies From a developmental perspective, PSS bring new chal-
are pressured to offer product-service combinations to sat- lenges for product development teams. Focusing on the
isfy increasingly sophisticated customer needs. Product- artifact’s physical characteristics is no longer sufficient; rather,
service systems (PSS) are the manifestation of a business the design team has to carefully determine and balance the
model in which manufacturers offer integrated product- properties governing product behaviors across the entire
service combinations to customers while retaining owner- product life cycle (Isaksson, Larsson, and Rönnbäck 2009).
ship of the product and responsibility for it (Baines et al. A typical aircraft engine, for instance, comprises thousands
2007). The TotalCare package offered by aircraft engine of parts and has an expected lifespan of 30 to 40 years, all of
manufacturer Rolls-Royce is an example of this emerging which must be taken into account in designing a product-
paradigm (Harrison 2006); the package offers customers a service system. This process calls for new competencies and
long-term business agreement that shifts the focus from the capabilities that are not exclusively part of the engineering
selling of physical engines to the provision of power. design team but are rather owned by several actors in the
supply chain. Hence, development teams must manage
their knowledge and experiences in a “shared context”
(Nonaka, Toyama, and Konno 2000) across functional
Koteshwar Chirumalla is a PhD student in product innovation at Luleå and organizational boundaries to deliver the desired result
University of Technology, Sweden. His research interests include Web 2.0 throughout the lifespan of the product. Knowledge sharing
and social media, product development, product-service systems, knowl- across supply-chain actors is, therefore, a key enabler for
edge lifecycle management, lessons-learned systems, and experience shar-
successful PSS innovation (Harrison 2006).
ing. He holds MSc degrees in both production engineering management
and materials processing from the Royal Institute of Technology, Sweden. To describe this phenomenon, the author explored
He was involved in the Faste Laboratory, a VINN Excellence Center aiming to knowledge-sharing networks for PSS innovation in the
develop new methods and tools for enabling functional product innovation. aerospace sector, which has pioneered PSS-oriented strate-
The main purpose of his research is to develop Web 2.0-based social tech-
nologies that can support the early stages of product innovation projects by
gies and multinational collaborations across several com-
enabling the capture and sharing of experience across the phases of the panies. A case study in the aerospace supply chain provided
product life cycle. [email protected] insight into how companies are using knowledge-man-
DOI: 10.5437/08956308X5602045 agement systems and Web 2.0 tools in their regular

Research-Technology Management • March—April 2013 | 45

activities; the analysis approached knowledge management The effectiveness of knowledge acquisition and sharing
from a knowledge lifecycle (KLC) perspective (see, for in- across the network, however, depends on the degree of
stance, Andersson 2011; Birkinshaw and Sheehan 2002). closeness and the intensity of the relationships among part-
The lifecycle perspective offers the possibility of organiz- ners (Dyer and Nobeoka 2000). PSS innovation relies on
ing and modeling knowledge through a set of stages— developing ties across partner networks in order to exploit
capture, storage, sharing, search, access, and reuse—providing existing knowledge and explore new knowledge and op-
insight into where and how knowledge might be used. In portunities (Chirumalla et al. 2012).
this way, the KLC approach can help structure a meaningful In practice, knowledge does not always flow smoothly
knowledge-management system (Birkinshaw and Sheehan in such complex environments. Information and knowledge-
2002). management systems are required to support the dis-
The KLC analysis discussed in this paper illuminates the semination, gathering, and application of knowledge
limitations of current knowledge-management systems for (Ward and Graves 2007) and to ensure that the right peo-
PSS implementation and suggests how Web 2.0 technologies ple have the right knowledge at the right time to make the
can address these issues. right decision (Molloy, Siemieniuch, and Sinclair 2009).
The prevailing domain-specific and hierarchical structure
Knowledge-Sharing Networks for PSS Innovation of traditional knowledge-management systems seems to
PSS innovations require the integration of a wider span contrast with this need to acquire knowledge from a large
of expertise into the product design than do pure product network of independent and geographically dispersed
innovations (Johnson and Mena 2008). To manage this, peers (Bertoni and Larsson 2011). The emerging social
it is helpful for the PSS innovator to reimagine its supply web, sometimes referred to as Web 2.0 and social media
chain as a supply network. The shift toward a PSS model (see “Web 1.0 vs. Web 2.0,” p. 47), may offer a way
requires rearranging transaction-based relationships to to address these barriers by facilitating more open and
create long-term relationships and reimagining tradi- bottom-up knowledge-sharing capabilities (Levy 2009;
tional relationships as dynamic networks (Lockett et al. McAfee 2006).
2011; Oliva and Kallenberg 2003). In such a model, the Despite efforts to implement Web 2.0 tools, a lack of
PSS provider is at the center of a cluster of relationships guidelines and best practices regarding where and how
connecting suppliers and partners to customers (Figure 1) these tools might most profitably be used has meant that
(Chirumalla et al. 2012). product development teams have not seen benefits from
Knowledge sharing is a key function of this relationship these initiatives. The purpose of this study is to answer this
cluster; one partner’s learning and experience can influence question: How can Web 2.0 technologies help companies
other partners in the network in developing new ideas and capture and manage knowledge for product-service system
innovations to reduce in-service and maintenance costs. development?

The Case Study

The case study was con-
ducted at an aircraft engine
component manufacturer
that is part of an aerospace
PSS network (Figure 2). The
company has pioneered the
implementation of Web 2.0
tools to enhance internal
and external collaboration
in development activities.
The study analyzed the
knowledge flows between
the company and its suppli-
ers, customers, and offshore
units to understand how
cross-organizational teams
use various knowledge-
management systems and
Web 2.0 capabilities to facil-
itate relationships in their
regular activities. (See “How
the Study Was Conducted,”
FIGURE 1. Relationship network for PSS development p. 48.)

46 | Research-Technology Management Managing Knowledge for PSS Innovation

 Web 1.0 versus Web 2.0

In the early years of the Internet, the Web was characterized by static pages that enforced a clear distinction between producer
and user. The transition of content in this model was top down and one way (Cormode and Krishnamurthy 2008). In Web 1.0
pages, users can view content but cannot contribute content. Web 1.0 pages are closed to external editing and can be updated
only by their producers. Thus, user interaction is typically not available on Web 1.0 pages.

Web 2.0: A New Way To Engage

The rise of Web 2.0 technologies and applications (Solis and JESS3 2012) marked a significant change in how people engage
with the Web to create, store, edit, access, share, and distribute content (O’Reilly 2007). In contrast to Web 1.0’s read-only interac-
tion, Web 2.0 is characterized by dynamic, decentralized pages that allow users to read and write, contribute, and add value to
content (Levy 2009; McAfee 2006; O’Reilly 2007). Web 2.0 applications are frequently referred to as bottom-up tools because they
do not impose a predefined structure, but rather let structures evolve over time in response to users’ interaction with the content
and tools. Web 2.0 includes such interactive, user-built tools as blogs and microblogs, wikis, social networks, tags, really simple
syndication (RSS), mash-ups, podcasts, and social bookmarks and media-sharing tools.

The case company, as a first-tier supplier and risk- and email conversations, and instant messaging. The company
revenue-sharing partner, is increasingly involved in design has recently deployed My Sites in Microsoft SharePoint to
projects with aircraft engine manufacturers at an early stage. enable individuals to create personal pages to manage and
Internally, in the early phases, decisions are made through a store information. My Site users can create blogs and wikis
series of physical meetings focused on commercial, technical, and invite colleagues and project members to share or
manufacturability, and quality issues during which inputs
from design, business, and production functions are consid-
ered. The main challenge for the company is to maintain an
up-to-date understanding of the design intent that is gener-
ated from customer needs; this must be sufficiently defined
to share with both on-site teams and global partners through-
out the development process.
Reusing the experiences from various projects is also a
main concern for the company. Current design practices lack
support for handling experience feedback on a routine basis,
especially from downstream phases such as manufacturing,
usage, maintenance and repair, and recycling.
The company has been using three major platforms for
knowledge management—Siemens solutions for product
lifecycle management and knowledge-based engineering,
SAP solutions for business operations and customer rela-
tions, and Microsoft solutions for collaboration and content
management. Internally, employees communicate primarily
through formal and informal face-to-face meetings, phone and FIGURE 2. Position of case study company in aeronautical supply chain

Managing Knowledge for PSS Innovation March—April 2013 | 47

 How the Study Was Conducted
The study was conducted within a Swedish Excellence Centre for Functional Product Innovation over the course of two years.
The goal was to investigate how Web 2.0 technologies can enable cross-functional knowledge sharing for PSS innovation. A
case study, undertaken with a qualitative research focus (Yin 2009), served as the basis for this research, which gathered data
through interviews and a virtual meeting with managers and engineers.
Approach Focus Participants Date
Virtual meeting Knowledge-sharing problems in Senior Company Specialist (1) May 2009
a PSS setting
Web 2.0 initiatives at the company
Possible working modes or processes
to support with Web 2.0
Interviews (10) Internal and external knowledge Process Managers (4) February 2010
management methods and tools
in product and service development IT Architect Manager (1)

Issues and challenges in managing IT Coordinator (1)

knowledge in a lifecycle perspective Development Engineers (2)
Knowledge-sharing barriers Customer Support Specialist (1)
Company experiences in using blogs, wikis, Industrial PhD Student (1)
IM, My Sites, Team Sites
Integration of Web 2.0 tools with KMS
Security concerns with Web 2.0 tools
Interviews (5) Managing knowledge flows in design Process Managers (3) January 2011
practice management between Design Engineers (2)
onsite and offshore teams
Issues with KMS from knowledge
lifecycle view
Interviews (10) Knowledge-sharing issues in Chief Engineer (1) September 2011
design practice systems Process Managers (2)
Issues in current practice from Senior Designers (4)
a knowledge lifecycle view Quality Engineers (2)
Using videos for capturing and sharing Design Leaders (2)
lessons learned across product life cycle Senior Specialists (2)
The interviews were recorded, transcribed, and reviewed by the respondents for accuracy; the author collected notes from
the virtual meeting. Data from the interviews and virtual meetings were analyzed using spreadsheets with a pattern-matching
technique (Yin 2009) to identify topics connected to data-gathering activities. Several themes were then drawn out for further
analysis based on patterns related to the stages of the knowledge life cycle. These themes were then analyzed to understand
the systems capabilities that need to be addressed in the setting of PSS implementation. Conclusions were drawn by iterat-
ing between knowledge-related problems, theory, and empirical data. The excerpts presented in this paper have been taken
from this analysis.

comment. There are about 3,000 My Sites, 250 blogs, and • Capturing and sharing customer needs,
just a few wikis, but the company does not have information • Finding the right competencies for solving problems and
about actual usage or activity on those pages or blogs. Ex- composing cross-functional teams,
ternally, the case company is using SharePoint Team Sites • Capturing design intent,
to manage collaboration with suppliers and other compa- • Providing experience feedback to designers from down-
nies. Typically, communication with suppliers and custom- stream phases,
ers occurs via phone conferencing, e-mail exchange, and • Facilitating open innovation practices, and
customer-provided tools. • Supporting knowledge validation processes.
After a pioneering phase, the company has felt the need
to better establish Web 2.0 approaches, harmonize methods Managing the Knowledge Life Cycle for PSS Innovation
and tools, and develop better practices and guidelines. From Analyzing the case company’s knowledge-management
this perspective, the case study identified six focus areas for challenges within the framework of the KLC helped to clar-
the company’s Web 2.0 knowledge-management effort: ify its knowledge-management needs and suggested methods

48 | Research-Technology Management Managing Knowledge for PSS Innovation

to facilitate the capture and circulation of knowledge in the
company and throughout the PSS network.
Blogs and wikis both represented
Capture
For the case company, knowledge regarding customer needs, powerful tools to capture unstructured
design rationale, and lessons learned, as well as manufactur-
information and make it available to
ing, operational, and service-related knowledge, is captured
primarily in the form of static text formats such as reports, other teams.
spreadsheets, meeting notes, and presentations. These for-
mats are primarily suitable for capturing explicit knowledge,
but they do not allow for the capture of the unstructured
knowledge typically communicated via informal meetings,
spontaneous discussions, phone conversations, and e-mails. social functionalities properly, the discussion could
This unstructured knowledge, which may in some cases rep- rise much earlier than it happens today.
resent the majority of the useful knowledge generated by a Web 2.0 technologies can also help practitioners to identify
project, evolves over time in a dynamic form; it needs to be individuals outside their usual networks who have specific
continually collected and regularly updated, and the context expertise, thereby building ties across organizational bound-
in which it is generated must also be captured. It is quite aries. As a side effect, such practices bring decision makers
difficult to articulate and structure this knowledge, which is from several knowledge domains into a shared space where
generated in social contexts, into the centralized, top-down they can describe what is known from previous projects, cre-
format preferred by most knowledge-management systems. ating a more collaborative and iterative process for knowl-
The case company’s early experiences in deploying Web edge validation. Furthermore, these tools allow information
2.0 tools such as blogs and wikis revealed that these tools, to be presented in multiple formats, such as image, video, or
with their interactive user-authored pages and conversational audio, allowing capture of rich contextual information.
formats, significantly lower the threshold to documenting This was found to be particularly helpful in capturing
personal insights and experiential knowledge, giving experts lessons-learned stories from downstream phases using video.
a chance to codify tacit know-how and front-line employees Videos, with their ability to scan the external environment
a forum to define customer impressions by attaching them and capture subtle and complex aspects of activities, enrich
to the right context. Blogs and wikis both represented pow- the description of lessons learned with contextual cues and
erful tools to capture unstructured information and make it allow the capture of tacit knowledge in skill-oriented activi-
available to other teams. One experienced process manager ties such as laser welding, casting, and milling. As one quality
told the author: engineer said, “the video way can be beneficial as it allows us
to capture and highlight good or bad examples, lesson-
Blogs and wikis are powerful tools to pick up the coffee
learned stories from the production such as design mistakes
machine talks and departmental/personal meetings . . .
found in the manufacturing phase.”
Then we bring the discussion into more open and shared
space, where other persons can address relevant ques-
tions, give comments, and follow more open dialogues, Storage
and moreover we can increase the network around cer- Different organizations in the PSS network utilize different
tain areas/issues. information technology policies, knowledge-management
infrastructures, system environments, and working processes,
Blogs and wikis also provided specific benefits: Blogs proved which force engineers to store documents in restrictive, top-
useful to document ideas, insights, and early informal feed- down hierarchical systems that do not allow flexibility in
back from distributed stakeholders on customer needs and articulating experiential knowledge. The case company felt
new design solutions, while wikis enabled a more bottom-up the pain of such restrictions when they attempted to develop
way to capture design intent by involving more stakeholders competence databases; as one informant described it:
in the codification of the rationale for specific design deci-
sions. The networking capabilities and feedback mechanisms We have previously tried 4 or 5 times to create a compe-
offered by blogs and wikis, such as commenting, rating, and tence database to store such information, forcing people
to fill in our forms, to indicate their skills and the proj-
voting, also allowed more participation by distributed stake-
ects they worked on. People felt that the system was
holders, although participation in these systems has been
too structured . . . [and] very hard to use. . . . They
very inconsistent. As one of the process managers put it: were forced to choose things that they didn’t really feel
People may have very personal ideas on how an en- matched.
gine mount or a boss should be designed. Being able to
At the case company, the implementation of personal
formalize this unstructured information would mean
that very early other people could say “this is good” or sites has offered an alternative to structured databases, as
“this is completely wrong.” We have a lot of views on people work to keep their profiles consistent and up to
how to do things; that means reinventing the wheel date. An IT manager noted, “Now we have a personal
at every project . . . If we would be able to use these page, where people are free to update information about

Managing Knowledge for PSS Innovation March—April 2013 | 49

 Sharing
The analysis of case study data demonstrated that current
The implementation of personal sites knowledge-sharing mechanisms are, in fact, not sufficient to
capture and communicate the unexpected design changes
has offered an alternative to structured that occur during the design process or to enable a contextual
databases, as people work to keep their understanding of the rationale for those changes. An engi-
neer from one company may not have a complete idea about
profiles consistent and up to date. how small design changes can affect the overall system. The
designer who has an idea may not know where to store and
share that information or who can benefit from it.
Integrating customers into the knowledge-management
themselves. I see that many users are taking time to add process adds complications. The case company must adapt
information and to make themselves visible throughout to its customers’ knowledge-sharing systems if it is to share
the company.” This provides better data for staffing a information outside the company. Each customer uses a
team than traditional, top-down competence manage- different system, and this creates significant barriers to
ment databases, which are difficult to populate and sharing relevant information. As a result, feedback from
maintain. the field may be lost. Worse, with no indication that the
The case company stores documents as different types information they share is actually applied, engineers may
in several databases, each of which is available to a differ- not see the use of sharing feedback. One product support
ent set of stakeholders, making it difficult to locate specific leader said, “I don’t know how these lessons learned that
documents. The company also uses metadata to create a we identified [are] actually spread to other projects and
formal filtering structure, but sometimes people forget to departments . . . It [the lesson] should be stored some-
enter metadata with a document, making it even more dif- where, so everyone could see it, right?” Similarly, front-
ficult to find that item in the databases. Unstructured in- line employees understand the value of providing solutions
formation presents additional difficulties, as it may lack a to customers; they exchange this knowledge via informal
document type or other metadata, and the systems do not interactions, e-mails, and reports, but this limits their abil-
have specific rules to accommodate such entries. In those ity to reach wider audiences and identify potential busi-
cases, the person creating the document must decide how ness opportunities.
to classify it and into which database to place it. There is a The case company’s blog implementation has demon-
clear need for a more practical, flexible approach, one that strated that blogs may serve as easy, effective tools for ar-
allows practitioners to structure information collabora- chiving and sharing experiences, as well as tracking progress
tively and store contextual data without exposing confi- and decision making throughout the development of a proj-
dential information. ect. The benefits of such open documentation were high-
At the case company, the implementation of tagging lighted by one project informant, who said that blogs
practices in blogs and on team sites has helped users to “spread the information more in the projects, so respective
collectively organize information the way they want it. designers know that first part went to workshop, manufac-
(See Smith 2008 for a complete discussion of tagging.) This turing sequences and milestones etc. It’s more about mak-
mechanism for collaborative filtering, which combines ing sure that the design team is getting the feedback about
related posts together based on user-generated tags, allows the product in later stages of product development, etc.”
practitioners to organize the content in the way that is Blogs may also offer less tangible benefits, as they allow us-
most comfortable and most useful for them. ers to share content both among colleagues closely bound
Blogs and wikis also allow for collaborative co-author- by shared interests and among more widely distributed
ing, with each contributor adding to a particular discus- stakeholders, building relationships across a wide com-
sion from his or her own experience and knowledge, munity of practitioners.
allowing a space for teams to gather potential lessons The benefit may also be seen in earlier phases, where
learned and collect important knowledge that can be front-line practitioners use open platforms such as blogs, wi-
used to improve processes for the next project. In the kis, and video sharing to communicate customers’ needs and
case company, blogs were used in a few projects to store potential business opportunities across organizational bound-
experiences from those projects, and wikis were used pri- aries. Further, the dynamic interaction possibilities provided
marily to store lessons learned. Wikis were seen as par- by Web 2.0 tools allow product support teams to respond im-
ticularly effective for this purpose, as, according to one mediately to customer questions and issues and feed such
informant, “the wiki can act more or less as an informal knowledge quickly into the development process for the
collector of different opinions and knowledge about prac- benefit of current and future projects.
tices. Therefore, having a wiki system connected to each
activity and lesson learned [is] beneficial . . . we could Search
document all design stages even better, so others can see PSS development teams need to be able to locate and combine
and share their experiences.” different knowledge elements to understand the ill-defined

50 | Research-Technology Management Managing Knowledge for PSS Innovation

problems they encounter in their daily activities, but extant
knowledge-management systems make this difficult. Case
data demonstrated that a “free text search” mechanism is fre- Web 2.0 tools encourage employees to
quently either inadequate or nonexistent for locating past
experiences and relevant documentation stored in het- collaboratively create and share content
erogeneous environments from past projects. Domain- through a more easily searchable
specific databases are access protected outside a given project
or function; in addition, they contain few explanations around knowledge base.
the processes behind decisions. One senior design leader de-
scribed the search problem in this way:
The biggest limitation is that if you work, for example, on
product X, and you work with that for 10 years and build Even those who have worked on a project in the past are
a lot of experience. Then you switch to product Y, [and] not able to access their documents without special access—
you are now disqualified to look at X documents. You are not always easy to obtain, as one project informant reported,
not able to search your old experience that you built up “We have a very rigid system to get access to, and it is
for 10 years. unclear [sometimes] who has the access to it.” Case analysis
highlighted the lack of a shared database accessible to the
People frequently turn to their social networks to find
entire organization.
solutions, either asking someone they know or seeking
In this regard, Web 2.0 tools support practitioners in creat-
out an expert. Information about who has had similar
ing easily shared workspaces. Design stakeholders see wikis
experiences is most often accessed through personal networks
as a promising tool to collect and provide access to underly-
and social connections. Relatively little support is available
ing design rationales and act as a supplement to existing proj-
to help companies or individuals identify the right people
ect repositories, allowing design rationales to be shared with
with appropriate competencies to cope with ill-defined
partner companies in a controlled way.
problems and to build effective cross-functional teams in
As many informants pointed out during case discussions,
the early phases.
Web 2.0 tools can also help when access to information is
Web 2.0 tools encourage employees to collaboratively cre-
constrained, by helping identify people who may have an-
ate and share content through a more easily searchable
swers. This is particularly valuable for newcomers, still learn-
knowledge base. Such mechanisms as tagging, comments,
ing where expertise resides inside and outside the company
and ratings create meaningful search mechanisms that allow
(that is, knowing who knows [Groth 2004]). Individual site
individuals to locate and access the information they need.
profile pages, blog posts, and team sites can all help identify
As a development engineer said, “Now, if something happens
who has worked on a particular project or problem in the
during the manufacturing, the people can go back [to the
past and can provide relevant knowledge from experience.
blog posts] through tags and read about what happened at
that time in reverse order.” Information from feedback
mechanisms, such as comments and ratings, is not only use- Reuse
ful for locating past experiences but may also improve aware- One of the key issues that arose in case study discussions was
ness of who knows what in the organization. Personal site the need for good integration among systems to support
pages provide data others can use to find individuals with the practitioners’ ability to reuse information for new situations.
right competencies to address a specific problem or staff a Stressing this point, one project manager said, “When I do a
team. An IT architect saw “a great potential in social software new project, how can I use this information that is stored
when it comes to searching for the right competencies and today? . . . The information is stored in different systems and
finding the right people.” The case company is particularly it is not presented in a way that I can use. . . . I need to collect
seeking to exploit this possibility by encouraging employees all the required data from different systems to understand
to add information on blogs and personal sites to identify the the whole issue.” For information to be reusable, it must be
people involved and their expertise. synthesized and rationalized with a relevant context that
clarifies its applicability to subsequent situations; rich contex-
Access tual information about, for instance, why things won’t work
The size and complexity of the typical PSS network make it can be reused in a later project to allow proper decisions to be
very difficult to access knowledge sources within the orga- made more quickly.
nization and across the network. Aggregating updated, rele- The case company struggles to reuse experiences from
vant information from heterogeneous sources is complicated past lessons-learned reports. The analysis found that
by the variety of access and security levels required, as well even after the relevant documents from different systems
as by the need for several partners to access the information were identified, development teams increasingly turned
both synchronously and asynchronously. In particular, the to people they knew or trusted to validate the relevance
arguments upon which early design decisions are based in and applicability of the knowledge in their particular
past projects is often lost or hidden in corporate databases working context. Hence, the current knowledge valida-
not readily accessible by design teams from other projects. tion process is dominated by personal relationships and

Managing Knowledge for PSS Innovation March—April 2013 | 51

physical interactions. This calls for technologies that al- The key element in a successful Web 2.0 implementa-
low practitioners to maintain spaces in which they can tion is the active engagement of top management. Top
control the presentation of information, share it, and re- management must take an active leadership role in foster-
use it as appropriate. ing a culture that is receptive to the informal, unstructured
Web 2.0 tools can capture information with a richer con- nature of Web 2.0 tools. Senior managers should actively
text that allows for reuse. By capturing the dynamic interac- participate, as contributors and as providers of feedback, to
tions and social processes related to the creation of knowledge, motivate employees to take an active part in two-way me-
these tools allow the context in which information is gener- dia such as blogs. Participation should be fostered through
ated to be tracked, including the details of source and rele- nonfinancial rewards, such as publicly acknowledging the
vance. For instance, the record of edits in a wiki page can contributions of participants in newsletters and manage-
provide a window into how the knowledge captured on the ment blogs, and managers must actively encourage practi-
page emerged and evolved. Comments on blogs offer a simi- tioners to access and reuse knowledge from Web 2.0 tools.
lar view, as each commenter adds his or her own perspective Finally, Web 2.0 initiatives must be widely publicized and
and experience to the original entry. Similarly, lessons- the tools and approaches integrated into regular business
learned videos from downstream phases provide an opportu- processes so that they are seen as part of mainstream work
nity for users to explain and demonstrate the root cause of a and not just venues for socializing.
problem visually and in greater detail. The benefit of using
video sharing for providing experience feedback to designers Validating knowledge quality and reliability
at a component level was explained by one design leader: Web 2.0 tools are typically dominated by the loudest and
“Videos are good . . . easier to go through and to get the clear most persistent voices, potentially impelling companies to
overview [of] what is specific to each component.” make decisions based on personal opinions rather than veri-
Web 2.0 tools, with their lightweight and intuitive inter- fied fact. As one company specialist said, “If somebody writes
faces, can also be used to combine one or more data sources to ‘You should design a mount like this’ in a wiki, someone else
create new knowledge. RSS feeds and alerts, which push a may use this knowledge as the truth, as a basis for decision,
stream of information from user-selected sites, allow practitio- even if no one approves it.” This problem is particularly con-
ners to subscribe to their choice of content so that they receive cerning in the aerospace industry, since practitioners work
new entries as they are created. In this way, it is possible to link on safety-critical issues, where key design decisions must be
various knowledge elements to related knowledge owners based on a verified knowledge base.
through informal classification, navigation, and discovery. To avoid the domination of personality over fact, manag-
ers must be proactive, implementing policies to protect
The Challenges of Adopting Web 2.0 Tools confidentiality and support the quality of the information
Analysis of the case data identified a number of methodologi- provided. Simplified guidelines should convey clear stan-
cal and technological challenges that must be addressed dards for validity of information. Beyond that, Web 2.0
before wide adoption of Web 2.0 tools can be achieved. tools must be actively monitored. Managers can appoint
These include the need for active user participation to create anonymous moderators to monitor wikis and blogs and edit
vibrant knowledge repositories; the challenge of validating or delete inappropriate content. Feedback mechanisms such as
knowledge quality and reliability; the risk of knowledge leak- rating and commenting can also leverage the power of partici-
age; and the danger of self-censoring behavior that could re- pants to monitor their own spaces, assessing the quality and
sult in incomplete documentation of knowledge. reliability of user-generated content based on users’ criteria.

Fostering active participation Managing the risk of knowledge leakage

Web 2.0 technologies are intended to create spaces in The more open and bottom-up environment fostered by Web
which practitioners grow their knowledge and under- 2.0 tools may lead to the accidental exposure of proprietary
standing through interactions with other people sharing know-how to competitors or partners. As a result, companies
the same interests. A lack of participation in these forums tend to be overly defensive in using these approaches. In-
will ultimately defeat the technologies’ innovative power. stead of resisting Web 2.0 tools, companies need to more ef-
Case study analysis suggests that managers can take specific fectively control sharing of sensitive information, for instance
actions to improve user participation. by defining various access levels. Companies should also de-
fine a Web 2.0 strategy and implement social tools in stages
to facilitate management of security. Implementing the most
prevalent Web 2.0 tools alongside traditional knowledge-
The key element in a successful Web 2.0 management systems can be a good first step. Companies can
later evolve the systems with additional tools and concepts.
implementation is the active engagement
Web 2.0 training days, workshops, and awareness cam-
of top management. paigns to prepare employees to use the systems effectively
can also set the stage for a higher level of awareness with
regard to information security. Moreover, it is essential to

52 | Research-Technology Management Managing Knowledge for PSS Innovation

define a code of conduct and guidelines to describe what Chirumalla, K., Bertoni, A., Ericson, Å., and Isaksson, O.
can and cannot be published. 2012. Knowledge-sharing network for product-service
system development: Is it atypical? In Proceedings of the 4th
CIRP International Conference on Industrial Product-Service Sys-
Moderating self-censoring behaviors tems: The Philosopher’s Stone for Sustainability, eds. Y. Shimo-
At a more personal level, Web 2.0 shared spaces that allow mura K. and Kimita, 109–114. Heidelberg, Germany:
every individual to see what others have written can trig- Springer-Verlag.
ger self-censoring behaviors. These transparent environ- Cormode, G., and Krishnamurthy, B. 2008. Key differences be-
ments can make individuals think twice about how they tween Web 1.0 and Web 2.0. First Monday 13(6), June 2.
portray themselves online, leading to self-censoring when http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/
they post or comment on others’ posts. This behavior fm/article/view/2125/1972
might result in relevant knowledge elements not being Dyer, J. H., and Nobeoka, K. 2000. Creating and managing a
shared and may affect the quality of knowledge recorded, high performance knowledge-sharing network: The Toyota
for instance if someone with relevant expertise chooses case. Strategic Management Journal 21: 345–367.
Groth, K. 2004. On Knowing Who Knows: An Alternative Ap-
not to comment on a post.
proach to Knowledge Management. Ph.D. dissertation.
Publishing clear, simple guidelines can help ameliorate the Royal Institute of Technology, Stockholm, Sweden.
tendency to self-censoring. Without guidelines regarding Harrison, A. 2006. Design for service: Harmonizing product de-
what can and cannot be shared, users tend to play it safe and sign with a services strategy. In Proceedings of the ASME Turbo
rely on traditional tools for anything they feel may be risky, Expo 2006: Power for Land, Sea and Air (GT2006), Volume 2: Air-
either to the company or to their own reputations. Explicit craft Engine; Ceramics; Coal, Biomass and Alternative Fuels; Con-
norms, guidelines, and values for these informal exchanges trols, Diagnostics and Instrumentation; Environmental and
are key factors in moderating self-censoring. Regulatory Affairs, 135–143. ASME Conference Proceedings.
Isaksson, O., Larsson, T., and Rönnbäck, A. O. 2009. Develop-
ment of product-service systems: Challenges and opportu-
Conclusion nities for the manufacturing firm. Journal of Engineering
PSS innovation presents many challenges for companies. En- Design 20(4): 329–348.
hanced tools are needed to develop relationships and enable Johnson, M., and Mena, C. 2008. Supply chain management
the seamless sharing of knowledge throughout the supply for servitised products: A multi-industry case study. Journal
network. Web 2.0 tools, which allow for collective creation, of Production Economics 114(1): 27–39.
informal sharing, capture of rich contextual information, and Levy, M. 2009. Web 2.0 implications on knowledge manage-
development of a network of connections, can complement ment. Journal of Knowledge Management 13(1): 120–134.
existing knowledge-management systems and support cross- Lockett, H., Johnson, M., Evans, S., and Bastl, M. 2011. Prod-
uct service systems and supply network relationships: An
organizational teams. Introducing Web 2.0 tools involves
exploratory case study. Journal of Manufacturing Technology
much more than simply implementing a new technology;
Management 22(3): 293–313.
rather, effective use of such tools requires a change of McAfee, A. 2006. Enterprise 2.0: The dawn of emergent col-
behaviors and values at both the individual and the organi- laboration. MIT Sloan Management Review 47(3): 21–28.
zational level. Molloy, E-M., Siemieniuch, C., and Sinclair, M. 2009. A systems
The author thanks RTM’s Board of Editors for their helpful approach to supporting decisions for the product to service
suggestions on an earlier version of this paper. The author would shift. International Journal of Computer Applications in Technol-
also like to extend his gratitude to the Faste Laboratory and the ogy 36(3/4): 272–283.
case company, and particularly to interviewees who provided the Nonaka, I., Toyama, R., and Konno, N. 2000. SECI, ba and
data on which this paper is based. leadership: A unified model of dynamic knowledge cre-
ation. Long Range Planning 33: 5–34.
Oliva, R., and Kallenberg, R. 2003. Managing the transition
References from products to services. International Journal of Service In-
Andersson, P. 2011. Support for Re-use of Manufacturing dustry Management 14(2): 160–172.
Experience in Product Development: From an Aerospace O’Reilly, T. 2007. What is Web 2.0? Design patterns and busi-
Perspective. Ph.D. dissertation. Luleå University of Technol- ness models for the next generation of software. Communica-
ogy, Luleå, Sweden. tions & Strategies 65(1): 17–37.
Baines, T. S., Lightfoot, H. W., Evans, S., Neely, A., and Smith, G. 2008. Tagging: People-Powered Metadata for the Social
Greenough, R. et al. 2007. State-of-the-art in product- Web. Berkeley, CA: New Riders.
service systems. Journal of Engineering Manufacture 221: Solis, B., and JESS3. 2012. The Conversation Prism: The
1543–1552. Art of Listening, Learning and Sharing. http://www.
Bertoni, M., and Larsson, A. 2011. Engineering 2.0: An ap- theconversationprism.com/
proach to support cross-functional teams in overcoming Ward, Y., and Graves, A. 2007. Through-life management: The
knowledge-sharing barriers in PSS design. International Jour- provision of total customer solutions in the aerospace indus-
nal of Product Development 15(1/2/3): 115–134. try. International Journal of Services Technology Management
Birkinshaw, J., and Sheehan, T. 2002. Managing the knowl- 8(6): 455–477.
edge life cycle. MIT Sloan Management Review 44(1): Yin, R. K. 2009. Case Study Research: Design and Methods.
75–83. Thousand Oaks, CA: Sage Publications.I

Managing Knowledge for PSS Innovation March—April 2013 | 53

Leveraging Web 2.0 in New Product Development:
Lessons Learned from a Cross-company Study
Paper

A
Bertoni, M. and Chirumalla, K
Journal of Universal Computer Science (JUCS)
Vol. 17, no. 4, pp. 548-564, 2011

Social Technologies For Cross-functional

Paper
Product Development: SWOT Analysis and Implications

Bertoni, M., Chirumalla, K. and Johansson, C

In Proceedings of 45th Hawaii International Conference on System
Sciences (HICSS-45), 4-7 January, Grand Wailea, Maui, 2012 B
Managing Knowledge for Product-Service System
Paper
Innovation: The Role of Web 2.0 Technologies

Chirumalla, K
Research-Technology Management Journal (RTM)
Vol. 56, no. 2, pp. 45-53, 2013 C
Capturing and Sharing Lessons Learned across
Paper
Boundaries: A Video-based Approach

Chirumalla, K., Bertoni, M., Johansson, C., Isaksson, O

In Proceedings of 20th European Conference on Information
Systems (ECIS’12), 10-13 June, Barcelona, Spain, 2012 D
Experience Feedback using Social Media: From the Paper
Product Lifecycle Phases to the Design Practices

Chirumalla, K., Bertoni, M., Johansson, C

In Proceedings of the 5th CIRP International Conference on Industrial
Product-Service Systems (IPS2): Product-Service Integration for
Sustainable Solutions, ed. H. Meier, pp. 459-471, Springer-Verlag, 2013 E
  

  
 

 
  
 
9645+'3
43,+6+3)+
43
3,462'8/43
#;78+27
#

!64)++*/3-7
#

 

 

  




 

 

!$#&"
"%





"#$
! ##!

"!
"$! 


###!

4114:
8./7
'3*
'**/8/43'1
:4607
'8 .>5'/7+1'/73+846-+)/7

"+)422+3*+*
/8'8/43
./692'11'
48+7.:'6
4.'37743
.6/78/'3
+6843/
'6)4
'3*
7'07743
1'
!$%"

#"
## #
"
" ##
 %"#

& #
!!" 
  

 !'5+6

.>5'/7+1'/73+846-+)/7  

=/7
2'8+6/'1
/7
(649-.8
84
;49
(;
8.+
9645+'3
43,+6+3)+
43
3,462'8/43
#;78+27
#
'8
#
1+)8643/)
/(6'6;
#+
8
.'7
(++3
'))+58+*
,46
/3)197/43
/3
#

!64)++*/3-7
(;
'3
'98.46/<+*
'*2/3/786'846
4,
#
1+)8643/)
/(6'6;
#+
46
246+
/3,462'8/43
51+'7+
)438')8
+1/(6'6;'/73+846-
 CAPTURING AND SHARING LESSONS LEARNED ACROSS
BOUNDARIES: A VIDEO-BASED APPROACH

Chirumalla, Koteshwar, Luleå University of Technology, 97187 Luleå, Sweden,

[email protected]
Johansson, Christian, Luleå University of Technology, 97187 Luleå, Sweden,
[email protected]
Bertoni, Marco, Luleå University of Technology, 97187 Luleå, Sweden,
[email protected]
Isaksson, Ola, Volvo Aero Corporation, 46181 Trollhättan, Sweden,
[email protected]

Abstract
In light of emerging product development trends, such as Product-Service Systems, manufacturing
organizations are obliged to collaborate across functional and organizational borders. Hence,
companies are increasingly investigating how to leverage knowledge management practices to
enhance their dynamic learning capabilities to achieve continuous process improvements. Many
researchers assert that lessons learned practices are possible ways for organizational learning, which
allows for continuous capturing and sharing of experiential knowledge across boundaries in order to
learn both from mistakes and successes. However, many organizations fall short in capturing and
sharing lessons from projects and applying them in new situations. The purpose of this paper is to
propose a video-based approach and related guidelines for capturing and sharing lessons learned in a
dynamic manner across functional and organizational boundaries. Based on laboratory experiments
as well as validation activities conducted in collaboration with an aerospace manufacturer, this paper
compares the video-based approach with a more traditional text-based approach of documenting
lessons learned from projects. The paper describes the results of testing activities conducted with a
video-based lessons learned prototype and the authors reflect on its implications for design practice
management in the aerospace industry.
Keywords: Lessons learned, Lessons learned template, Experience sharing, Web 2.0, Video sharing,
Knowledge management, Organizational learning, Product-Service Systems.
1 Introduction

To compete in the dynamic global economy, traditional product-oriented companies are searching for
new ways to differentiate their market offerings and to create unique value for the customers (Shaw
and Ivins, 2002). In business propositions such as Product-Service Systems (PSS) (Mont 2002), the
manufacturing companies offer ‘functions’ or ‘results’ instead of mere hardware, retaining ownership
and responsibility for the product throughout its entire lifecycle. For instance, aero-engine
manufacturer Rolls-Royce offer ‘TotalCare®’ packages (Harrison 2006) to its customers, long-term
business agreements centered on the provision of a function (i.e., ‘Power-by-the-hour’) instead of an
aero-engine. Development teams are therefore urged to design products and services in a more
harmonised way, being aware of those properties governing the lifecycle behavior of the hardware
since an early phase (Isaksson, Larsson & Rönnbäck 2009). This requires accessing a wide range of
skills, knowledge and expertise from different functional domains (Larsson et al. 2008), such as from
mechanical design, electrical engineering, computer science, aerodynamics, material science,
manufacturing, operations, maintenance, and service engineering. This new scenario emphasizes the
need to extend continuous learning beyond functional and organizational boundaries (Cooke-Davis
2002) and to enhance dynamic learning capabilities to achieve continuous process improvements
(Baria 2005).
As observed by several researchers (Kotnour 2000; Milton 2010; Tan et al. 2006), capturing and
disseminating lessons learned from the projects lowers the barriers to organizational learning and
knowledge sharing. However, today’s corporate culture is not very conducive for cross-team learning
(Carrillo 2005; Dixon 2004), causing learning opportunities to be missed. Lessons learned processes
are often limited to a ‘single department’, a ‘single business unit’ or to ‘specific projects’ (Thompson
2005; Williams 2008), and databases are difficult to search, further lacking support for knowledge
reuse (Marlin 2008). Furthermore, 80% of organizational knowledge is stored in people’s heads, 16%
is semi-structured and only 4% is formalized as structured data (Bell 2006). Most of the ‘working
knowledge’ (Davenport and Prusak, 1998), or ‘knowing in practice’ (Orlikowski 2002) in
organizations is therefore tacit (Nonaka and Takeuchi, 1995; Polanyi 1967) and not in a readily
available form for PSS developers.
Organizational, cultural, methodological and technological support is needed to facilitate cross-team
learning across boundaries. This is particularly evident in PSS development, where the need for a
more open, bottom-up, and “lightweight” (Bertoni, Chirumalla & Johansson 2012; Larsson et al.
2008) knowledge sharing support is emphasized. The purpose of this study is, therefore, to answer the
following research question: How to lower the threshold for capturing and sharing lessons learned
across functional and organizational boundaries? In this perspective, social computing and Web 2.0
technologies look particularly interesting to enable the sharing of individual/team ‘tacit’ knowledge or
‘knowing in practice’, as well as to improve communication in boundary-crossing collaborative
environments (Levy 2009; Lytras, Damiani & de Pablos 2008; McAfee 2006). Accordingly, the
objective of the paper is to propose a lightweight knowledge sharing approach – based on video
technologies – for capturing and sharing lessons learned across organizational boundaries in a
dynamic manner. The paper details the methodological and technological enablers, describing the
results of preliminary verification activities.

2 Research Approach

The research, which is mainly qualitative in nature (Yin 2009), is framed according to the Design
Research Methodology (DRM) (Blessing and Chakrabarti, 2009) and consists of four main phases:
Research Clarification, Descriptive Study I, Prescriptive Study, and Descriptive Study II. This paper is
a main outcome of the Descriptive Study II phase. Empirical data in the descriptive phases have been
collected from development projects in the aerospace and manufacturing tools industry, mainly
focusing on how companies use various knowledge management (KM) systems to capture and
disseminate experiential knowledge in their regular working activities. The data gathering activities
were performed at the companies’ facilities between May 2009 and June 2011, and entail 17
structured/unstructured interviews (Fontana and Frey, 1994), 3 focus groups and 3 virtual meetings.
Such data were complemented by 15 survey questionnaires. These initial findings have been
summarized using the Strengths-Weaknesses-Opportunities-Threats (SWOT) as a framework, which
describes the enabling capabilities of Web 2.0 technologies for cross-functional knowledge sharing in
early PSS design (Bertoni, Chirumalla & Johansson 2012). The SWOT has highlighted the
importance of using Web 2.0 technologies for sharing lessons learned in a continuous manner across
functions and organizations. Embarking from a theoretical review of lessons learned, descriptive study
II was started on August 2011, focusing on design practice support systems for the aerospace sector.
The design practice (DP) documents specific technical realisation instructions for each product design.
As observed in the study, DP lacks support for recording experiential knowledge from past projects,
especially concerning lessons learned from the downstream processes. Empirical data on DP-specific
issues were collected through 10 interviews with system owners, project leaders, managers, company
specialists, chief engineers, and quality assurance leaders. The findings have brought definition to the
topics/steps and guidelines for structuring lessons learned, and have highlighted videos as a preferred
means for capturing and sharing. Methodological and technological enablers were further developed
and tested in a laboratory environment by researchers and practitioners with experience in product
development projects. Small scale experiments were initially conducted to understand the underlying
mechanisms related to the capture and reuse of lessons learned using videos. In a second phase, topics
and guidelines were refined and tested in design sessions with researchers and students in the Product
Development Master Programme at Luleå University of Technology, involving 25 participants. The
test aimed both at verifying the “lightweightness” of the approach for non-expert users and the
possibility to reuse the lessons in new problem contexts. Testing activities were further conducted at
the companies’ facilities to verify the integration with the DP system. A selected number of
stakeholders were asked to record lessons learned videos related to design practices from past projects.
The findings from such verification activities are presented in the later sections of the paper.

3 Literature Review

3.1 Lessons Learned

Product development is a knowledge intensive activity, where experiential knowledge is shared across
time and space (Buttler et al. 2011) from one project to another to support decision-making. Problems
are seen in the way experiential knowledge is contextualized in real work activities (Kerr, Waterson &
Clegg 2001) as well as in that knowledge’s tacit nature (Polanyi 1967). Most of the knowledge
acquisition activities in organizations occur in an informal manner, mainly through day-to-day social
interactions with colleagues and with established networks of contacts (Kerr, Waterson & Clegg 2001;
Larsson et al. 2008). Nonaka and Takeuchi (1995) describe this phenomenon of organizational
learning in organizations as a SECI model. SECI depicts four modes of knowledge conversion,
namely: tacit to tacit (socialization), tacit to explicit (externalization), explicit to explicit (combination)
and explicit to tacit (internalization). Accordingly, tacit knowledge is made explicit so that it can be
shared, combined, and then internalized by applying it in new practical situations. Researchers claim
that metaphors and stories give the richest opportunities for articulating and sharing tacit knowledge
(Buttler et al. 2011; Swap et al. 2001) and for supporting transfer of experiential design knowledge
and design rationale (Erickson 1995). Several researchers emphasize that capturing lessons learned
stories from the projects is a way to stimulate sharing these experiences (Buttler et al. 2011; Goffin et
al. 2010). Lessons learned (LL) are knowledge artifacts that convey experiential knowledge derived
from success or failure of a task, decision, or process, that when reused, can positively impact an
organization’s performance (Weber, Aha & Becerra-Fernandez 2001). Many organizations in a variety
of sectors (e.g., military, energy, construction, and government) have deployed LL processes and
systems to prevent the ‘re-invention of the wheel’ and to avoid repetition of previous mistakes (Baria
2005; Carrillo 2005; Milton 2010; Weber, Aha & Becerra-Fernandez 2001). LL practice was the
outcome of after action reviews, which were introduced by the US Army in the mid-1970s (Weber,
Aha & Becerra-Fernandez 2001). Since then, the concept has been adopted in a number of
organizations under a number of different names, such as post-project reviews, project postmortem
review, reflection, debriefing, corporate feedback cycle, reuse planning, and cooperative project
evaluation (Disterer 2002). Major issues with post-project reviews (e.g., Goffin et al. 2010; Kamara et
al. 2003) refer to staff turnover, reassignment of people to the new projects and the time lapses in
knowledge capturing. Based on a survey of organizations that deploy and utilize LL systems, Weber et
al. (2001) not only found that LL systems poorly serve their intended goal of promoting knowledge
sharing and reuse, but also identified the essential components of a generic LL process to be: collect,
verify, store, disseminate, and reuse. A major concern is that lessons are described as a set of free-text
fields within a system and the systems are typically not integrated into an organization's decision-
making process. To address these limitations, Kumara et al. (2003) and Tan et al. (2006) propose a
methodology for ‘live’ capture and reuse of project knowledge, by using a template featuring
background information on the project, abstract, conditions for reuse, relevant details and references.

3.2 Web 2.0 and Enterprise 2.0

The term “Web 2.0” describes a significant move in the way people create, store, edit, access, share
and distribute content on the World Wide Web (O’Reilly 2005), changing the way people interact
(Levy 2009; McAfee 2006). Examples of Web 2.0 applications include blogs, wikis, social
networking, tagging, RSS feeds, mashups, social bookmarking micro-blogs, media sharing, web
applications and podcasting (McAfee 2006; O’Reilly 2005; Parameswaran and Whinston, 2007).
Anderson (2007) proposes six drivers to explain the Web 2.0 phenomenon: (1) Individual production
and user generated content, (2) Harnessing the power of the crowd, (3) Data on an epic scale, (4)
Architecture of Participation, (5) Network Effects, and (6) Openness. Chatti et al. (2007) propose Web
2.0 driven SECI model learning process, based on Nonaka’s SECI approach, which combine
formal/informal learning, knowledge management, and Web 2.0 concepts into one integrated solution
for a model of network learning through active participation in different communities. McAfee (2006)
further pointed out the rising company interest in Web 2.0 with the term “Enterprise 2.0”. He
summarizes the underlying components of Enterprise 2.0 technologies with the acronym SLATES
(Search, Links, Authoring, Tags, Extensions and Signals) (McAfee, 2006). Web 2.0 in enterprises has
its largest impact on knowledge work, innovation processes and cooperation (Fuchs-Kittowski et al.
2009), facilitating knowledge transfer in complex engineering environments (Murphy and Salomone,
2010) in relation to two key knowledge management strategies - namely, personalization and
codification (Hansen, Nohria & Tierney 1999). From an engineering point of view, Larsson et al.
(2008) have coined the term “Engineering 2.0” to describe customized and ad-hoc Web 2.0
applications able to support engineering product development in an extended enterprise setting.

3.3 Video Sharing

Video sharing is one of the most adopted Web 2.0 technologies in companies (i.e., top 3 with 38%)
(Bughin, Byers & Chui 2011). It is especially useful for scanning the external environment, finding
new ideas, and managing projects. Video has also been recognised as a useful medium to support
design activities (Harrison et al. 1989). Harrison et al. (1989) found videos to be a well-suited medium
for supporting design communication processes, as videos are experiential and involving in nature -
not detached and compartmentalized like text. In many disciplines, researchers have been using videos
to capture subtle and complex aspects of performed activities and to represent overviews of key
dynamic processes (Leon 2005; Wood, Rust & Horne 2009; Zender, Schwehm & Wilke 2006). In
ethnographic field studies, it is often termed “video-ethnography” (Leon 2005). Web 2.0-enabled
capabilities facilitate video hosting services, which could allow individuals to upload video clips to
Internet websites to capture and communicate stories with a richer and more dynamic content (Cha et
al. 2007; Parameswaran and Whinston, 2007). Additionally, Web 2.0 offers annotations, tagging,
bookmarking, commenting, editing, and ranking functionalities to increase the ability to share,
network, find and discuss videos across dispersed boundaries. Wood et al. (2009) investigated using
videos to elicit and transmit the tacit nature of skilled practices, such as crafting knives. They created a
web-based learning resource for novice craft practitioners, which offered a more flexible way of
developing and refining their crafting skills (Wood, Rust & Horne 2009). From a lessons learned
system point of view, Shariff et al. (2005) added features to lessons learned systems to allow users to
upload media files, such as pictures and videos, to support a socialization process. Similarly, Xerox
technicians are using media attachments to further promote lessons reuse (Weber, Aha & Becerra-
Fernandez 2001). Further, Zender et al. (2006) developed a video approach to knowledge
management, documenting operational procedures and preserving individual/group experiences during
space applications development. At present, however, there is little evidence available in literature on
using videos with Web 2.0 capabilities as a medium for continuous capturing and sharing lessons
learned across boundaries within the product development domain.

4 Method for Capturing and Sharing Lessons Learned Videos

The preliminary experimental results identified that videos are beneficial for capturing lessons learned
(LL) as they can capture the context of dynamic problem situations and that reduces time-consuming
manual processes while capturing lessons in a continuous manner compared to a more traditional text-
based approach of documenting LL. However, capturing an LL video is not merely about making a
video with some stories from a project. The LL video must be factual, technically correct, valid and
applicable to specific tasks, processes and decisions. Hence, the authors have developed a method for
capturing LL videos as a means to provide the structure and to lower the threshold for the people who
want to share their lessons.

4.1 Description of the lessons learned capturing template

Both laboratory experiments and industrial case study observations (hereafter referred to as the
“empirical study”) highlighted the need to structure the lessons learned (LL) videos in seven steps.
These steps are: lesson learned statement, working context, task description, what went wrong or what
went well, lesson learned, lesson learned measures, and applicability & delimitations. Each step has a
set of guiding questions to support the users in formulating their message in a clear, concise, and
informative manner for each section of the LL video as shown in Table 1.
The section below follows short descriptions and rationale for each step of the LL template:
0 - Lesson learned statement: The empirical study showed that it is important to provide the user
with a quick summary of the lessons learned to shortly recapitulate the main points about its contents
to explain why it is important. This tends to be a brief statement introducing the topic to knowledge
seekers in a shorter sentence as a caption or title of the LL video. In this way, LLs statements can
enhance browsing capabilities for the user to quickly go through several knowledge elements and thus
find the right LLs faster. Hence, this step is considered as “0” in a lesson learned story.
1 - Working context: The empirical study showed that users need to understand the background and
working situation of the task that the LL concerns. This includes person name, job role, project name,
component/product, and operational level within the phases of global product development process,
and a list of stakeholders involved during the task. On the one hand, this information provides the
background and allows the knowledge seekers to decide if it is a relevant video or not. On the other
hand, this information intends to guide the knowledge seekers to identify whom are relevant experts
and stakeholders specific to the performed task, for instance, ‘knowing who knows what’ or ‘knowing
whom to ask’. In this way, the users can benefit from seeing the people involved in the task and add
more emotional impact compared to the text-based approaches.
2 - Task description: The empirical study showed that the users are benefited from a short description
of the task the LL concerns. Descriptions include how the task was executed and what the conditions
and circumstances where it was operated were, as well as what key parameters or tools were used.
3 - What went wrong or what went well: The empirical study showed that it is important to clearly
describe the learning from successes or failures that came across during activity. It is therefore
possible to pinpoint where—and how—the problem/favorable outcome occurred as well as what the
effects were on task execution or project. This information works as a ”know-why” explanation for the
lesson learned where knowledge seekers can learn about either avoiding the same mistake again or
repeating a successful outcome.
4 - Lesson learned: The empirical study showed users need to be provided with a detailed description
of the lesson was learned, recognizing the new or improved solution to avoid the problem or to repeat
the favorable outcome including any additional experiences. At this point each lessons learned focus
should be on what was learned that would benefit the performance of a future activity or project.
5 - Lesson learned measures: The empirical study showed that it is important to describe how
effective the lesson learned was on the process, for instance by measuring the performance of an
improvement. The users should provide some quantifiable measurements of change (e.g., time, cost,
quality) in the process by comparing the performance with previous conditions. This information can
increase the credibility of the lessons learned reuse by knowledge seekers.
6 - Applicability & delimitations: The empirical study showed that it is important to describe the
applicability of the LL in terms of tasks and projects. The user identifies, for instance, who are the
potential beneficiaries (or target audience) of the LL, and where it can be applicable. This information
can help the knowledge seeker to decide on whether s/he makes use of the LL and to avoid wasting
time on LLs that are not applicable to them. Users should also offer advice on limitations of their LLs
by providing information, such as the amount of analysis and scrutiny it has undergone, what
additional activities are necessary for further validation, and how it can be institutionalized smoothly.
Though this information is based on personal experience and gut feeling, it plays a crucial role to
create a reciprocal cross-team learning environment across boundaries.

4.2 The process for capturing, sharing and validating LL videos

The study has taken a lesson learned (LL) process view, similar to Weber et al. (2001), to test and
validate the video-based approach in laboratory and industrial environments. The video-based LL
process consists of six stages, including:
1. Identifying the LL during an activity: The LLs can be identified by the individual people in day-to-
day activities or by the project team in the stage-gate process (Cooper 2008).
2. Preparing and formulate an LL story using the steps and guidelines in the above LL template: The
guidelines in the template are prepared in a way to make sure that the outcome will be the “richer”
description as a story. The “notes” column in Table 1 is left blank intentionally to show that LL
contributors take the template and prepare their lesson learned story using the template.
3. Recording the LL video, storing and sharing with proposed tags and secrecy settings: The LL
contributor records the LL video and proposes several tags on the basis of, for instance, the
applicability for other activities/projects to make the LLs searchable. Further, contributors can propose
the name of a validator or specialist in the LL area for approving their LL video in a rapid manner.
Additionally, the contributors can propose a “secrecy level” to their LL from scales 1 to 4 to enhance
privacy and confidentiality for sharing sensitive lessons from the projects across boundaries.
4. Validating and disseminating the LL with secrecy and tags settings: Following the LL contributor
request for approval of their LL video, the proposed validator gets the alert message to review the LL.
The validator can go through with the dissemination settings proposed by the LL contributor and
approve it with minor or major changes. Derived from the inherently secretive nature of aerospace
engineering working culture, the empirical study highlighted the vital role of this validation part in
disseminating the lessons from the projects.
5. Searching and retrieving the LLs using the tags: The knowledge seekers search for the LL videos
based on the tags defined in the system. From the empirical study, it was found that LL videos
codified with tagging functionalities could make it easier for knowledge seekers to search and retrieve
the lessons that are tagged in the same way from different functional and organizational boundaries.
6. Reusing the LLs in new activities: The empirical study showed that the video sharing approach to
LLs could allow cross-functional teams to add their reflections, comments and rankings after their
usage of LLs.
<Proposed video-based approach for capturing lessons learned stories>
No Steps Guidelines Notes
0 Lesson Learned Shortly summarize the main points about this lesson and why it is important
Statement for others to know.
1 Working Describe the background of the task:
Context Name of person, job role, product type and project name?
What is the operational level of the task within the product development
process?
Who are the stakeholders (internal/external) connected to the task?
2 Task Description Briefly describe the task:
How was the task planned and executed?
What key parameters or tools were used?
What are the conditions and circumstances when the task was executed?
3 What Went Describe problems/successes that you came across during the activity:
Wrong or What was the problem/favorable outcome?
Well? Where did you identify the problem(s)/favorable outcome?
How did you identify the problem/favorable outcome?
What is the effect of the problem(s)/success on task execution?
4 Lesson Learned Describe the lesson that you learned:
What are the root-causes of problem/success?
What steps have you undertaken to solve the problem or to find the success?
How can the problem be avoided or how can the success be repeated?
What is the recognized new or improved solution to avoid the problem or to
repeat the favorable outcome?
5 Lesson Learned Describe the measures to the improved solution of the problem(s):
Measures How can your lesson learned improve the problem area or success area?
How would you quantify the change/improvement compare it with pre-
existing solutions?
6 Applicability Describe the applicability or delimitations of the lesson learned:
& Delimitations Who are the potential beneficiaries of your lesson?
Where can the lesson be applicable? How it can be ‘institutionalized’?
What is the level of quality of LL information?
What additional activities (i.e., verification, validation etc.) are necessary?
What are the limitations of your lesson?
Table 1. Layout of LL capturing template in the proposed video-based approach

4.3 Technological enablers for capturing and sharing LL videos

Different video capturing equipment was tested during early verification activities, varying among
professional HD cameras, webcams and mobile phone cameras. YouTube® (www.youtube.com) has
served as a video repository during the first round of experiments and as a platform for testing basic
tagging and annotation functionalities. A number of other video hosting services have been further
analyzed to identify functionalities able to cope with the needs emergent from the empirical study.
These include annotating, tagging, editing, commenting, bookmarking, ranking/rating, aggregating,
embedding and filtering/grouping functionalities. Based on the gathered user needs, all the required
features were drawn and mapped against the list of functionalities. Eventually, this led to the mock-up
of video-based LL sharing platform with the following interfaces shown in Figure 1.
As seen in Figure 1, the LL video displays annotations of LL template topics/steps as an overlay on
top of the video and might also include information about their duration. The researchers’ observations
showed that this way of representing the LL videos allows the knowledge seekers to see a visual
display of how the lesson learned story has been structured and captured in the video. Moreover, users
can browse for interesting topics of LL instead of going through whole video. Additionally, the
experimental observation also considered having “browsing points” on the video status bar, which
symbolize the seven topics in the captured lesson-learned story. The empirical observations revealed
that these capabilities built on top of the LL video could allow the users to browse and absorb many
LL videos in a shorter time span. In this way, the new video-based approach improves the accessibility
of browsing LLs compared to the text-based approach. In addition, the proposed features enable users
to examine the individual relevant LL topics rather than displaying complete videos, and hence
improve the ‘searchability’ and ‘retrievability’ in channeling relevant LLs to the knowledge seekers.
For instance, if a stress analysis engineer is looking for “What went wrong” in the simulations from
previous projects, the platform can compile and display all the related “what went wrong” issues
specific to analysis engineers. The case study highlights the special needs in a PSS context, where
users can quickly add LL videos to the product lifecycle timeline in alignment with the DP system.
Such practice can help continuous capturing and disseminating of the lessons learned from the
downstream processes, which could help the cross-organizational teams accessing properties
governing lifecycle behavior in the early conceptual stage. The empirical observations highlighted
several bookmark links to be considered in the platform, including, but not limited to, “share”,
“validator” and “secrecy level”. The “Share” bookmark link can facilitate an LL contributor to quickly
add video clips to the project portal, intranet, functional group sites, and project blogs, and so on. The
“Validator” bookmark link can help an LL contributor to identify the relevant experts on the
concerned LL topic, discipline and area of relevance. The “Secrecy level” bookmark link can allow an
LL contributor to decide on accessibility control of the different video sections depending on the
secrecy of the LL content, and thus let only some categories of users access the entire video, while
others will have access to only a part of it. Based on the case observation, the study identified 4
secrecy levels, namely: product function group, internal organization, open to other business units, and
suppliers, as shown in Figure 1. In the illustrated scenario where the knowledge seeker belongs to a
subsidiary of the main company, information related, for instance, to Working Context, What Went
Wrong/Well and Lessons Learned Measures might be hidden due to the risk of knowledge leakage. In
such a situation, only a limited part of the video is going to be accessible and available for review. The
development of the necessary technological support to enable such a scenario is part of the research
and it is currently ongoing.
Further, the study considered another important ‘social’ and ‘bottom-up’ capability of Web 2.0—
social tagging—where users could collaboratively classify and index the LL videos based on the
proposed tags as shown in Figure 1. Another technology enabler for developing social ties across
organization is to leverage conversations around LL videos. The empirical study considered specific
commenting functionalities related to the LL videos, where other people in the organizations go
through the video and add their relevant comments specifically to the topics of the LL story, as shown
in Figure 1. The other users can then go through with these comments and rank them based on
applicability and dependability. In addition, the mock-up considered “like,” rating, follow the user and
“embed” social features in the platform in order to enhance the bottom-up and social networking
capabilities. Based on preliminary experiments, the LL video-based approach, in this way, can capture
the context of complex situations, and leverage cross-functional sharing and networking across
organizational boundaries.
Figure 1. Video-based LL sharing prototype platform with functional interfaces of tagging,
commenting and secrecy levels for enabling cross-functional knowledge sharing

5 Discussion

In a PSS early phase, engineers have to use experiential knowledge to decide on how the provision of
a function has to be solved technically. Simulation models should, in fact, emphasize operational
aspects, that often refer to the individual’s own experience with the product. The study findings
confirm that such knowledge is rarely captured in a codified form using post-project text-based
approaches; rather it is stored only in the mind of individuals and exchanged through informal
discussions and story telling (Buttler et al. 2011; Goffin et al. 2010). Although stories allow people to
share experiential knowledge more effectively, they are rarely captured in a homogenous and
continuous way in the industrial context studied. Several ad-hoc formats and recording practices have
been observed, making it difficult for the PSS team to identify and contextualize such lessons. Text-
based approaches mostly lack contextual “richness” and are too high-threshold for some users to
regularly document their activities. For these reasons, Web 2.0-enabled videos have emerged as a
preferred means for sharing stories and lessons in a virtual enterprise environment. To some extent,
the approach resembles Case-Based Reasoning (CBR) (Weber, Aha & Becerra-Fernandez 2001) in its
aim to lower the effort in capturing and displaying knowledge, as compared to a rule-based system.
The approach is based on a 7-step template, which is intended to facilitate the capturing of contextual
information compared to what is already available in literature. Preliminary verification activities have
shown such a solution improves the preparation and formulation of stories compared to other
traditional templates and recording means. Most of the respondents stated that videos are more
suitable for explaining why certain decisions were made, and to record the rationale for a given
solution strategy. They also allow picturing downstream processes with more details, such as
production or maintenance activities’ flow. Eventually, the approach was found to lower the threshold
for capturing knowledge from skill-oriented activities, such as laser welding or servicing operations.
From PSS perspective, the approach presented in the paper represents a step forward toward
supporting a way of articulating and making tacit knowledge available, for the benefit of the design
activity. The industrial discussion has also highlighted the possibility to integrate videos with other
Web 2.0 tools. For instance, the stories could be synthesized in a wiki page to provide novice
engineers or newcomers an easy to use knowledge base, from which to grow their knowledge in new
projects. Web 2.0 mechanisms, in fact, can foster a more collaborative approach in LL capturing and
sharing. For instance, social tagging capabilities could make videos with similar tags more
discoverable across functions. As a side effect, this can help the PSS designers in fostering their weak
ties, highlighting hidden experts and communities interested in discussing certain aspects of the
product across the organizational containers. Feedback mechanisms (such as: likes, rating, number of
views, comments or bookmarks) can help in raising the engineers awareness of topics particularly
“hot” in the later lifecycle phases, and that can influence the design of the hardware – or the software
and service part. Eventually, PSS designers might be able to ground early decisions on a more solid
base, being aware of behavioral aspects of the PSS in operation that are not easy to represent with
traditional knowledge management tools.

6 Conclusions and Future work

This paper has proposed a video-based approach for capturing and disseminating lessons learned
practices in a dynamic manner across functional and organizational boundaries. With respect to
complex PSS development projects, where the hardware, software and service knowledge is
distributed across functional and organizational boundaries, Web 2.0 enabled video-based systems can
facilitate the sharing of experiential knowledge in forms of lessons learned among knowledge workers.
The present study focuses mostly on methodological issues about “why and how” using videos to
record lessons learned relevant for early PSS activities. Hence, this study limits its focus on the details
of the technological enablers to develop specifications for a technology. In the future, the study will
extend to the development of a full-scale prototype system, using open-source video sharing
applications. The prototype will serve the purpose of testing the viability and performances of
approach by experimental means, observing and analysing through a range of experiments how Web
2.0 mechanisms can support lessons learned sharing across organizational boundaries in a PSS
context. A set of experiments will be designed and conducted to compare traditional and Web 2.0-
based knowledge management systems on how they leverage a cross-functional team’s ability to
capture knowledge from heterogeneous functions, to increase awareness about knowledge owners and
knowledge sources and to increase confidence and participation of new comers in design practices.

Acknowledgments
The authors would like to extend our gratitude to the case companies and the respondents of the
interviews that this paper is based on.

References
Anderson, P (2007). What is Web 2.0? Ideas, technologies and implications for education. JISC.
Baria, D (2005). A Day in the life of a Rolls-Royce knowledge manager. In Knowledge Management
Tools and Techniques (Rao, M. Ed.), p. 246-254, Butterworth-Heinemann, Burlington, MA.
Bell, S (2006). Lean Enterprise Systems: Using IT for Continuous Improvement. John Wiley & Sons.
Bertoni, M., K. Chirumalla. and Johansson, C (2012). Social Technologies for Cross-functional
Product Development: SWOT analysis and implications. Proceedings of the Annual Hawaii
International Conference on System Sciences, IEEE, p. 3918-3927.
Bughin, J. Byers, A.H. and Chui, M (2011). How social technologies are extending the organization.
McKinsey Quarterly, November 2011.
Buttler T., S. Lukosch. and A. Verbraeck (2011). Frozen Stories-Capturing and Utilizing Frozen
Stories for Teaching of Project Managers. In Proceedings of the 3rd International Conference on
Computer Supported Education, Noordwijkerhout, The Netherlands, Vol. 1, p. 120-129.
Carrillo, P. (2005). Lessons learned practices in the engineering, procurement and construction sector.
Engineering, Construction and Architectural Management, 12 (3), 236-250.
Cooke-Davis, T. (2002). The ‘‘Real’’ success factors on projects. International Journal of Project
Management, 20 (3), 185-190.
Cooper, R.G. (2008). Perspective: The Stage-Gate® Idea-to-Launch Process—Update, What's New,
and NexGen Systems. Journal of Product Innovation Management, 25(3), 213–232.
Cha, M., H. Kwak., P. Rodriguez., Y,-Y. Ahn. and Moon, S (2007). I tube, you tube, everybody tubes:
analyzing the world’s largest user generated content video system. In Proceedings of ACM Internet
Measurement Conference, New York, USA.
Chatti, M.A., R. Klamma., M. Jarke and A. Naeve (2007). The Web 2.0 driven SECI model based
learning process. 7th International Conference on Advanced Learning Technologies, p. 780-782.
Davenport, T. and L. Prusak (1998). Working Knowledge: How Organizations Manage What They
Know. 1st Edition. Harvard Business School Press, Boston.
Dixon, N. (2004). Does your organization have an asking problem? KM Review, 7 (2), May/June.
Erickson, T (1995). Notes on design practice: stories and prototypes as catalysts for communication.
In Scenario-Based Design: Envisioning Work and Technology in System Development (Carroll, J.
Ed.), p. 37-58, Wiley, New York.
Fontana, A. and J.H. Frey (1994). Interviewing: The art of science. In Handbook of Qualitative
Research (N.K. Denzin & Lincoln, Y.S. Ed.), p. 361-376, Sage, London.
Fuchs-Kittowski, F., N. Klassen., D. Faust. and J. Einhaus (2009). A comparative study on the use of
Web 2.0 in enterprises. In Proceedings of I-KNOW ’09, Graz, 2-4 September.
Goffin, K., Koners, U., Baxter, D. and Hoven, C.V.D. (2010). Managing lessons learned and tacit
knowledge in new product development, Research-Technology Management, July-August 2010.
Hansen, M.T., Nohria, N. and Tierney, T. (1999). What's your strategy for managing knowledge?
Harvard Business Review, 77 (2), 106-116.
Harrison, A (2006). Design for service-Harmonizing product design with a services strategy. In ASME
Turbo Expo 2006: Power for Land, Sea and Air (GT2006), p. 135-143, Barcelona, Spain.
Harrison, S., S. Minneman., R. Stults. and K, Weber (1989). VIDEO: a design medium. ACM SigCHI
Bulletin. Association for Computing Machinery/CHI, Vol. 21, Issue: 2, New York, October 1989.
Kerr, M.P., P, Waterson. and C, Clegg (2001). A socio-technical approach to knowledge capture,
sharing and reuse in aerospace design. In: ASME 2001 DETC and CIE Conference, Pittsburgh.
Kotnour, T. (2000). Organizational learning practices in the project management environment.
International Journal of Quality & Reliability Management, 17 (4/5), 393-406.
Isaksson, O., Larsson, T.C. and Rönnbäck, A.Ö. (2009). Development of product-service systems:
Challenges and opportunities for the manufacturing firm. Journal of Engineering Design, 20 (4).
Larsson, A., Å, Ericson., T.C. Larsson. and D. Randall (2008). Engineering 2.0: Exploring lightweight
technologies for the virtual enterprise. The 8th International Conference on the Design of
Cooperative Systems (COOP’08), Carry-le-Rouet, France, 20-23 May.
Leon, N (2005). The invisible ethnographer: Working with people, real life and up close. In
Proceedings of the 58th Annual ESOMAR Congress, p. 129-137.
Levy, M. (2009). Web 2.0 implications on knowledge management. Journal of Knowledge
Management, 13 (1), 120-134.
Lytras, M.D., E. Damiani. and P.O, de Pablos (2008). Web 2.0: The Business Model. Springer.
Marlin, M (2008). Implementing an effective lessons learned process in a global project environment.
In Proceedings of the 2nd Annual Project Management Symposium Proceedings, Dallas, Texas.
McAfee, A. (2006). Enterprise 2.0: The dawn of emergent collaboration. MIT Sloan Management
Review, 47 (3), 21-28.
Milton, N (2010). The Lessons Learned Handbook: Practical Knowledge-Based Approach to Learning
from Experience, Chandos Publishing (Oxford) Ltd.
Mont, O. (2002). Clarifying the concept of product-service system. Journal of Cleaner Production, 10
(3), 237-245.
Murphy, G.D. and S. Salomone (2010). Using Enterprise 2.0 tools to facilitate knowledge transfer in
complex engineering environments. Working Paper, QUT ePrints, ID Code: 38344.
Nonaka, I. and H. Takeuchi (1995). The Knowledge-Creating Company: How Japanese Companies
Create the Dynamics of Innovation. Oxford University, New York.
O’Reilly, T (2005). What is Web 2.0- Design patterns and business models for the next generation of
software. O’Reilly.
Orlikowski, W.J. (2002). Knowing in Practice: Enacting a collective capability in distributed
organizing. Organization Science, 13 (4), 249-273.
Parameswaran, M. and Whinston, A.B. (2007). Social Computing: An overview. Communications of
the Association for Information Systems, 19, 762-780.
Polanyi, M (1967). The Tacit Dimension. Routledge and Kegan Paul, London.
Sharif, M.N.A., Zakaria, N.H., Ching, L.S. and Fung, L.S. (2005). Facilitating knowledge sharing
through lessons learned system. Journal of Knowledge Management Practice, March 2005.
Shaw, C. and J. Ivins (2002). Building Great Customer Experiences. Palgrave, London.
Surowiecki, J (2004). The Wisdom of Crowds: Why the Many Are Smarter Than the Few and How
Collective Wisdom Shapes Business, Economies, Societies and Nations. Doubleday; Anchor, USA.
Swap, W., Leonard, D., Shields, M., and Abrams, L. (2001). Using mentoring and storytelling to
transfer knowledge in the workplace. Journal of Management Information Systems, 18 (1), 95–114.
Tan, H.C., Carrillo, P., Anumba, C., Kamara, J.M., Bouchlaghem, D. and Udeaja, C. (2006). Live
capture and reuse of project knowledge in construction organisations. Knowledge Management
Research & Practice, 4 (2), 149-161.
Thompson, A. (2005). Getting real value out of lessons databases. KM Review, 8 (5), p. 20-23.
Yin, R.K (2009). Case Study Research: Design and Methods. 4th Edition, Thousand Oaks, CA.
Weber, R., Aha, D.W. and Becerra-Fernandez, I. (2001). Intelligent lessons learned systems. Expert
Systems with Applications, 20 (1), 7-34.
Williams, T. (2008). How do organizations learn lessons from projects – And do they? IEEE
Transactions on Engineering Management, 55 (2), p. 248-266.
Wood, N., Rust, C. and Horne, G. (2009). A Tacit understanding: The designer's role in capturing and
passing on the skilled knowledge of master craftsmen. International Journal of Design, 3 (3), 65-78.
Zender, J., Schwehm, G. and Wilke, M. (2006). The Rosetta video approach: an overview and lessons
learned so far. Journal of Knowledge Management, 10 (2), 66-75.
Leveraging Web 2.0 in New Product Development:
Lessons Learned from a Cross-company Study
Paper

A
Bertoni, M. and Chirumalla, K
Journal of Universal Computer Science (JUCS)
Vol. 17, no. 4, pp. 548-564, 2011

Social Technologies For Cross-functional

Paper
Product Development: SWOT Analysis and Implications

Bertoni, M., Chirumalla, K. and Johansson, C

In Proceedings of 45th Hawaii International Conference on System
Sciences (HICSS-45), 4-7 January, Grand Wailea, Maui, 2012 B
Managing Knowledge for Product-Service System
Paper
Innovation: The Role of Web 2.0 Technologies

Chirumalla, K
Research-Technology Management Journal (RTM)
Vol. 56, no. 2, pp. 45-53, 2013 C
Capturing and Sharing Lessons Learned across
Paper
Boundaries: A Video-based Approach

Chirumalla, K., Bertoni, M., Johansson, C., Isaksson, O

In Proceedings of 20th European Conference on Information
Systems (ECIS’12), 10-13 June, Barcelona, Spain, 2012 D
Experience Feedback using Social Media: From the Paper
Product Lifecycle Phases to the Design Practices

Chirumalla, K., Bertoni, M., Johansson, C

In Proceedings of the 5th CIRP International Conference on Industrial
Product-Service Systems (IPS2): Product-Service Integration for
Sustainable Solutions, ed. H. Meier, pp. 459-471, Springer-Verlag, 2013 E
 Experience Feedback Using Social Media: From the
Product Lifecycle Phases to the Design Practices

Koteshwar Chirumalla, Marco Bertoni, and Christian Johansson

Product Innovation, Division of Innovation and Design, Luleå University of Technology,

SE-97187, Luleå, Sweden
{koteshwar.chirumalla,marco.bertoni,christian.johansson}@ltu.se

Abstract. Many companies have been using lessons learned practices as one of
their key knowledge management initiatives to capitalize on past experiences.
For product development companies, learning from product lifecycle phases
gives a true competitive advantage to improve the next generation of products.
However, companies are still struggling in capturing and sharing lessons
learned and applying them in new situations. Based on this consideration, the
paper proposes a video-based approachȂusing social media technologiesȂas a
way to leverage continuous capturing and sharing lessons learned from product
lifecycle phases to design practices. The paper presents the findings of a case
study within the aerospace industry, which investigates the current industrial
practices with regard to experience feedback, and illustrates the implementation
of a video-based approach. Further, the conceptual mock-up of video-based les-
sons learned sharing portal and its social platform that are aimed to support the
design practices are illustrated.

Keywords: Experience Feedback, Design Practice, Product-Service Systems,

Experience Sharing, Lessons Learned, Web 2.0, Social Media, Video Sharing.

1 Introduction

Learning from experience for competitive advantage has received a great deal of
attention in recent years [1] [2]. Since product development is an iterative problem-
solving process [3], many companies have been using past experiences in form of
lessons learned to guide the design of future products in order to avoid reinventing the
wheel each time by accessing its past mistakes or successes [4] [5]. Managing expe-
riences is becoming even more important as manufacturing companies are undergoing
a fundamental shift in their business operations and are increasingly moving away
from the selling of products to the provision of services or Product-Service Systems
(PSS) [6] [7]. At an extreme side of this product-service journey, companies are offer-
ing ‘function of the product’ instead of hardware, retaining ownership and responsi-
bility for the product throughout its entire lifecycle [7]. This affects the way new
products are conceptualized and designed in the early phases, wherein the focus is
shifted from satisfying artifact’s physical characteristics to reducing the overall

H. Meier (Ed.): Product-Service Integration for Sustainable Solutions, LNPE, pp. 459–471.
DOI: 10.1007/978-3-642-30820-8_39 © Springer-Verlag Berlin Heidelberg 2013
460 K. Chirumalla, M. Bertoni, and C. Johansson

product lifecycle costs while maintaining performance efficiency [8]. In this setting,
reuse of experiences from different phases of product lifecycle, such as business, design,
manufacturing, usage, maintenance, and recycling, play a key role to support design
teams to address the relevant lessons from the past issues in new designs [9] [10].
Researchers have proposed different approaches to address this gap in a PSS set-
ting. Baxter et al. [11] proposed a knowledge base structure grounded on three core
elements of knowledge such as design, manufacturing capability and service to sup-
port the design activity. Vianello [6] proposed a documentation model to reuse of
knowledge from the service phase of complex products and has identified that the
designers require in-service information at a component level to improve next genera-
tion of products through design. Further, studies, for example [12] [13], develop KBE
[12], PLM [13] based solutions to capture, analyze and reuse both manufacturing
experiences [12] and product use experiences [13] in the new designs. However, the
current research on experience feedback primarily based on explicit (objective, codi-
fied) field data e.g. condition monitoring, operation and service data and statistical
databases, there is very limited focus on utilizing experiential learning that occurs
through tacit (subjective, implicit) knowledge and social interactions. As highlighted
by Clarkson and Eckert [14], “traditionally, large amounts of knowledge and expe-
rience are never written down and are only stored in the heads of individuals
(p. 328)”. Lessons learned (here after referred as “LL” in the text) practices are there-
fore failed to deliver the intended results as lessons are identified and are often not
followed through and applied within the organization [15]. Furthermore, LL practices
are limited to a ‘single department’ or to ‘specific projects’, lacking contextualized
information for reuse it in the new situations [16]. Major issues also refer to staff
turnover, reassignment of people to the new projects, time-consumption for capturing
LL as well as the time lapses in LL capturing [4]. Hence, there is a need for practical,
easy, social-based approach that can help organizations to regularly capture and share
LL from product lifecycle phases to early design practices.
On the authors’ advice, Web 2.0 or Social Media technologies look particularly in-
teresting to enable capturing and sharing of individual/team experiences and tacit
knowledge, as well as to improve communication across functional and organizational
boundaries [17]. Accordingly, the objective of the paper is to propose a video-based
approachȂusing social media technologiesȂfor capturing LL from different product
lifecycle phases and feed that back to early design practices. The paper presents the
findings of a case study within the aerospace industry, including the current industrial
practice with regard to experience feedback and the implementation of a video-based
LL approach. Further, the conceptual mock-up of video-based LL sharing portal and
its social platform that are aimed to support the design practices are illustrated.

2 Experience Feedback and Social Media: A Literature Review

Experience Feedback is a knowledge management initiative whose objective is to

convey experiential knowledge or lessons learned applicable to an operational, tactic-
al, or strategic level such that, when reused, this knowledge positively impacts on the
 Experience Feedback Using Social Media 461

results of the organization [4]. The lessons learned from problem-solving include:
lessons about the domain, lessons about how to find information that is useful to the
problem-solver, and the information about the resources that are useful in particular
contexts [18]. Several researchers identified that narratives and story telling give the
richest opportunities for articulating and sharing tacit and experiential knowledge [5]
[16], especially when the lessons are high-context and situation specific [2]. Milton
[2] stated that a story could support a lesson by providing valuable background and
context, facilitating to understand the context when a new person reviewing the les-
son, thereby guiding the person whether it applies within the new context or not.
In this perspective, videos seem to be a well-suited medium for supporting tacit
knowledge transfer, because they bring rich contextȂnot detached and compartmenta-
lized like text [19]. A recent McKinsey study [20] found that video sharing is one of
the most adopted social media tool in companies (i.e., top 3 with 38%). Videos are
especially useful for scanning the external environment and capturing subtle and
complex aspects of performed activities and to represent overviews of key dynamic
processes [21]. Web 2.0-enabled capabilities facilitate video hosting services, which
could allow individuals to upload video clips to Internet websites to capture and
communicate stories with a richer and more dynamic content [22]. Additionally, Web
2.0 offers annotations, tagging, bookmarking, commenting, editing, and ranking func-
tionalities [17] to increase the ability to share, network, find and discuss videos across
dispersed boundaries. According to a 2010 survey among advanced manufacturing
industries [23], social media tools (such as: social networking sites, video sharing,
blogs, wikis and micro-blogs) are beneficial to share best practices and to quickly
identify experts based on content they have uploaded on their profiles or conversa-
tions held on accessible social platforms. Wood et al. [21] investigated using videos to
elicit and transmit the tacit nature of skilled practices and have created a wiki-based
learning resource for novice craft practitioners, which offered a more flexible way of
developing and refining their crafting skills. Further, Shariff et al. [24] added features
to LL systems to allow users to upload media files, such as pictures and videos, to
support a socialization process as well as to promote lessons reuse.

3 Methodology

The paper is based on a case study [25] performed in collaboration with an aero-
engine component manufacturer, which develops and manufactures components for
gas turbine-, aircraft- and rocket engines. The company usually acts as a design-make
supplier to major aero engine manufacturers, in various product and technology de-
velopment projects. The company works as an independent risk and revenue sharing
partner, and assumes responsibility for certain engine components, from design, man-
ufacturing, to maintenance services throughout the entire lifetime of an engine type.
The company has recently implemented a Design Practice (DP) System to capture and
structure product specific activities and related methods for each component against
stage-gate product development process [26]. The system encompasses flows, activi-
ties, and methods to guide design and development work. The DP flow indicates
462 K. Chirumalla, M. Bertoni, and C. Johansson

which activities to be done, in which order, within a project phase, for a specific en-
gine component. The documents related to activities and methods are stored in DMS
(Document Management Systems) and searchable in DP system. The case study has
been performed on DP system to identify solution alternatives to foster experience
and lessons learned sharing across product lifecycle phases regardless of projects and
organizational boundaries. Empirical data has been collected through observations at
the company and interviews with DP system and product lifecycle stakeholders,
which include engineers, system owner, business developer, design leaders, manufac-
turing and quality leaders, process owners, and product support leaders. The inter-
views and observations are focused on three things: First is to develop a richer
understanding on current management of experience feedback along the product life-
cycle phases. Second is to get feedback on the applicability of using video-based
approach that is proposed by the authors. Third is to perform testing activities at the
companies’ facilities to verify the integration with the DP system. This paper is based
on the case study results from testing the video-based approach and the conceptual
scenarios that were discussed to support the DP system with continuous experience
feedback.

4 As-Is Practice in Experience Feedback: An Example

Since the case company is moving forward to take over the product lifecycle respon-
sibility, the product support team is dealing with operational problems of components
wherein they have not been involved during the design of these components. The
team is therefore increasingly searching for past experiences or the answers to the
decisions that have been taken previously. For instance, what we have agreed with
the customer? Why? Who took certain decisions on what basis?
Figure 1 illustrates an example for identifying past experiences when a product
support personal received a problem from the customer. If it is an easy or known
problem, the personal knows whom to contact to resolve the problem or get some help
to know the references to old reports in the DMS. If it is an ill-defined problem, then
there are mainly three options available to resolve the situation, including: asking
seniors or colleagues in their department, searching in the DMS, or raising the issue in
the weekly department meeting. If any senior is familiar with the problem, then he/she
can send some old reports or else recommend a person X that could be helpful. The
person X could send some reports in case he/she understands the problem by phone or
email, otherwise, he/she may request for a meeting to discuss the issue further. The
meeting might be helpful to identify some past experiences. If not the knowledge
seeker will inform the project team that there was no past experience available to the
given problem and there is a need to come up with a new solution by performing an
analysis. Alternatively, the person can search for the past experiences in the DMS.
However, in the DMS, one can only search with the title names if he/she knows what
to look for in the DMS. For example, if one can type the word “milling” in the search
title, then he/she will get all the documentation that have the title name milling. The
person has to open all the documents to check if there is any relevant document.
 Experience Feedback Using Social Media 463

If there were any document outside of his/her working context, then he/she wouldn’t
have the access to open it. In that case he/she needs to make a request to access them.
Once the personal gets the access, he/she reads the documents. If there is any relevant
document, then the personal usually gives a call to the person who wrote that docu-
ment or the people who were working in that project to make sure that this past
experience would applicable in his/her context.

Fig. 1. An example for identifying past experiences in the product support phase

Figure 2 illustrates how the experience feedback is usually happened in the above
example. In case the problem is a smaller issue, the product support personal docu-
ments a short analysis report. If it is a damage or non-conformance, then the personal
has to dig into the archives in correspondence with the supplier and the customer and
summarize the results in a “summary report”, including answering questions such as
why the problems were occurred? What they were discovered? What decisions were
taken?
From this report, 10-15 lessons learned are identified in order to make a list of
actions to the different departments to avoid repeating the same mistakes again in the
next products. The audit department usually makes the follow up and is informed to
different managers to make actions in their respective departments as shown in Figure
2. According to the informant most of these lessons are useful in the pre-study and
concept study to inform the designers: “you should think about this if you design a
part that goes in to casting process”. If the lesson might have to do with the definition
work, then it needs to go to product definition department to make a new DP in case
there is no DP available, otherwise it adds to the checklist in the design review
process. If the lesson is regarding the casting manufacturing process, then it can result
in an alert report, which can be sent out to all casting suppliers with the recommenda-
tions. Eventually, this “summary report” is stored in the DMS with references to other
reports. However, people that are working in the same project can only access to this
464 K. Chirumalla, M. Bertoni, and C. Johansson

Fig. 2. Experience feedback process from the product support phase for the above example

document. Other people can see that there is a document, but they cannot open it. “I
don’t know how these lessons learned that we identified is actually spread to other
projects and departments” described the informant. By commenting on identifying
experiences he said that: “of course this knowledge is only comes to me because I am
the one is asking for it. It should be stored some where. So everyone could see it,
right?”. The problem in documenting the lessons learned report from the projects is
highlighted by one of the informants: “[I think] no one really wrote those reports
anyway. Because they thought it is not so important…we are so busy writing the re-
ports we need to, for the clients. They require certain numbers and types of reports.
That’s what we focus on. This lessons learned template is something you have to do
when you get sometime over…I would say [that] those reports have a low priority”.
The above example evidently illustrates the difficulty in documenting, identifying
and accessing the past experiences and is emphasizing the importance of personal
networks and social connections in the experience feedback process.

5 Experience Feedback Using Social Media: An Approach for

Capturing Lessons Learned through Videos

The preliminary experimental results at case company identified that videos are bene-
ficial for capturing lessons learned (LL) as they can capture the context of dynamic
problem situations and that reduces time-consuming manual processes while captur-
ing lessons in a continuous manner compared to a more text-based approach of docu-
menting LL. However, capturing an LL video is not merely about making a video
with some stories from a project. The LL video must be factual, technically correct,
valid and applicable to specific tasks and processes. Hence, the authors have
 Experience Feedback Using Social Media 465

developed a method for capturing LL videos as a means to provide the structure and
to lower the threshold for the people who want to share their lessons. The method to
structure the LL videos contains seven steps as shown in Table 1. Each step has a set
of guiding questions to support the users in formulating their message in a clear, con-
cise, and informative manner for each section of the LL video as shown in Table 1.
The video-based LLs process consists of six stages, including: (1) Identifying the
LL during an activity, (2) Preparing and formulate a LL story using the steps and
guidelines in the below LL template, (3) Recording the LL video, storing and sharing
with proposed tags and secrecy level settings, (4) Validating and disseminating the LL
with secrecy level and tags settings, (5) Searching and retrieving the LL using the
tags, and (6) Reusing the LL in new activities.

Table 1. Layout of lessons learned capturing template in the proposed video-based approach

No Steps Guidelines Notes

0 LL Shortly summarize the main points about this lesson
State- and why it is important for others to know.
ment
1 Work- Describe the background of the task: Name of per-
ing son, job role, product type and project name? What is
Context the operational level of the task within the product
development process? Who are the stakeholders?
2 Task Briefly describe the task: How was the task planned/
Descrip- executed? What key parameters or tools were used?
tion What are the conditions when the task was executed?
3 What Describe problems/successes that you came across
Went during the activity: What was the problem/favorable
Wrong outcome? Where/How did you identify the prob-
or lem(s)/favorable outcome? What is the effect of the
Well? problem(s)/success on task execution?
4 Lesson Describe the lesson that you learned: What are the
Learned root-causes of problem/success? What steps have you
undertaken to solve the problem or to find the success?
How can the problem be avoided or how can the suc-
cess be repeated?
5 Lesson Describe the measures to the improved solution of
Learned the problem(s): How can your LL improve the prob-
Meas- lem area or success area? How would you quantify the
ures change/ improvement compare it with pre-existing
solutions?
6 Appli- Describe the applicability or delimitations of the
cability lesson learned: Who are the potential beneficiaries of
and your lesson? Where can the lesson be applicable?
Delimi- What is the level of quality? What additional activities
tations are necessary? What are the limitations of your lesson?
466 K. Chirumalla, M. Bertoni,
B and C. Johansson

The LL contributor reco ords the LL video and proposes several tags on the basiss of
job role, project name, prod duct type, lifecycle phase, discipline, area of impact, staake-
holders and validator, to make
m the LL searchable. Further, contributors can proppose
the name of a validator or specialist in the LL area for approving their LL video iin a
rapid manner. Additionally, the contributors can propose a “secrecy level” to their LL
from scales 1 to 4 to enhan nce privacy and confidentiality for sharing sensitive lesssons
from the projects across bo oundaries. Based on the case observation, the study ideenti-
fied 4 secrecy levels. Follo owing the LL contributor request for approval of their LL
video, the proposed validattor gets the alert message to review the LL. The validaator
can go through with the diissemination settings proposed by the LL contributor and
approve it with minor or major
m changes. The knowledge seekers search for the LL
videos based on the tags defined
d in the system and can add their reflections, coom-
ments and rankings after theeir usage of LL.
YouTube® (www.youtu ube.com) has served as a video repository during the ffirst
round of experiments and as a a portal for testing basic tagging and annotation funcctio-
nalities. A number of otheer video hosting services have been further analyzedd to
identify functionalities ablee to cope with the needs emergent from the empirical stuudy.
These include annotating, tagging,
t commenting, bookmarking, ranking/rating, agggre-
gating and embedding fun nctionalities. Based on the gathered user needs, all the
required features were draw wn and mapped against the list of functionalities. Eventuual-
ly, this led to the concepttual mock-up of video-based LL sharing portal with the
following interfaces shown in Figure 3.

Fig. 3. Conceptual mock-u

up of Video-based LL sharing portal with functional interfacess
 Experience Feedback Using Social Media 467

As seen in Figure 3, the LL video displays annotations of LL template topics/steps

as an overlay on top of the video. The observations showed that this way of
representing the LL videos allows the knowledge seekers to browse for interesting
topics of LL instead of going through whole video. Additionally, the experimental
observation also considered having “browsing points” on the video status bar, which
symbolize the 7 topics in the captured LL story. The observations also revealed that
these capabilities built on top of the LL video could allow the users to browse and
absorb many LL videos in a shorter time span. The empirical observations highlighted
several bookmark links to be considered in the platform, including, but not limited to,
“share”, “product lifecycle timeline”, “validator” and “secrecy level”. For instance,
the “Share” bookmark link can facilitate an LL contributor to quickly add video clips
to the project blogs, intranet, departmental sites, and so on.

6 Benefit of the Approach for Industrial Use

According to the previous research [6], design teams like to access the past expe-
riences at a component level. However, the As-Is practices are majorly ad-hoc,
project- based which does not support the designer to access the past experiences at a
component level with a richer context. The company is changing the process flows
within DP system based on LL reports, eventually missing the rationale why they
have changed a certain process. As observed during the study, DP system lacks sup-
port for handling the lessons learned from various projects, especially concerning
lessons from the downstream processes such as manufacturing, serial production,
product support and maintenance. Furthermore, the study found that the lessons with
high-context such as casting and welding operations are harder to explain and report
in the text-based document. Video-based LL approach could allow product lifecycle
stakeholders to capture the lessons with an illustrated story and share it to the product
lifecycle timeline per each component as shown in Figure 4. Within the DP system,
this practice could allow designers to access related LL from various projects on the
same page together with the best practice documents. In this way, videos can carry a
learning point that is specific, actionable recommendation to the component designers
in the early phases, enabling to access more context-specific lessons compared to the
traditional project-specific lessons learned documents. Such practice can help conti-
nuous capturing and disseminating of the lessons learned from the downstream
processes, which could help the design teams accessing properties governing lifecycle
behavior in the early conceptual stage per each component.
Another technology enabler for developing social ties across organization is to le-
verage conversations around LL videos. The study found that adding commenting
functionalities related to the LL videos allow other people in the organizations go
through the video and add their relevant comments to the LL story. In addition, add-
ing “like,” rating, follow the user and “embed” social features in the portal enhances
the bottom-up and social networking capabilities across boundaries. Based on prelim-
inary experiments, the LL video-based approach, in this way, can capture the rich
context of lessons learned and feed that back to early design practices, thereby leve-
raging cross-functional sharing and networking across borders.
468 K. Chirumalla, M. Bertoni,
B and C. Johansson

Fig. 4. The conceptual view of sharing video LL from product lifecycle phases to DP systeem

Based on the proof of co oncept validation at industrial environment, the study ppro-
poses a conceptual mock-u up of video-based LL social platform—with using social
media technologies—for caapturing and disseminating the experiences across bounnda-
ries. The major functions co onsidered in the platform are video portal, network proffiles
and discussion space, inclu uding the basic interfaces such as search, tag cloud and
dashboard (See Figure 5). A Video Portal is intended to contain a variety of LL vvid-
eos, which are classified un nder the approved tags by the validators. When designners
who are seeking for speciffic experiences from past projects can access the relevvant
videos based on the tags. AsA they click on the relevant video, they can view the viideo
with annotations of LL topiics, the entire tags and comments as shown in Figure 5.
Further, the Network Pro ofiles is intended to contain the profile pages of LL conntri-
butors. Every LL contributo or can create their profile pages and user name when tthey
uploaded their first LL videeo to the platform. In profile pages, every user can see thheir
LL videos and save other reelevant LL as their favourites on basis of their job roles and
working projects. In the nettwork profile, every user asks to enter their skills and laater
these skills are tagged into the system as “expertise”. Additionally, the users can see
their social ties, recent actiivities as well as subscribe to the favourite feeds they are
interested in. This will en nhance the social networking capabilities across differrent
departments. Another funcctionality considered is a Discussion Space, which iss in
nature more of a blog and wiki combination. Blogs can be used to capture and leeve-
rage conversational knowleedge across boundaries. For instance, blogs can be usedd to
discuss the past experiences and LL search results before the gate meetings. The w wiki
functionalities in the blog can enable to combine different LL videos at the endd of
each stage-gate and to create a summary of LL practices as a Wiki page from the
specific project. The Searcch function is intended to allow the knowledge seekerss to
search for the relevant LL from
f previous projects by entering the keywords. The pplat-
form can also recommend relevant
r tags for the user based on the key words they hhave
entered in the platform. Wh hile searching for past experiences, the search function w will
be able to show the LL vid deos, network profiles and the discussion pages relevannt to
the key search word. Moreo over, the learno-meter, a Dashboard, is intended to visuaally
displays the quantify numb bers of LL capturing and reuse for estimating the perffor-
mance of the tool. Finally, the
t Tag Cloud in the platform is intended to gather variious
 Experience Feedback Using Social Media 469

tags created in the system (i.e., tags from LL videos, network profiles and discussion
pages) and present the visual display in an abstract manner. This way of structuring
knowledge in a bottom-up manner could assist both management and operation levels
to see what is the current ‘hot’ topic in the organization as well as within the platform.

Fig. 5. The conceptual mock-up of a proposed video-based lessons learned social platform

7 Concluding Remarks and Future Work

This paper has proposed a video-based approachȂusing social media technologiesȂas

a way to lower the threshold for continuous capturing and sharing lessons learned
(LL) from the product lifecycle phases to the design practices, supporting front-
loading in product development by enabling experience feedback from product life-
cycle phases. The approach encompasses a LL capturing template, guidelines, process
description and technological enablers. The approach is based on a 7-step template,
which is intended to facilitate the capturing of contextual information and tacit know-
ledge compared to what is already available in literature. Preliminary verification
activities have shown such a solution improves the preparation and formulation of LL
in a story format compared to other traditional templates and recording means. The
study identified that the video-based approach is beneficial to give manufacturing,
operational and maintenance inputs to early phases of design practices at a component
level. In the future, the study will extend to the development of a full-scale prototype
470 K. Chirumalla, M. Bertoni, and C. Johansson

system, using open-source video sharing applications. The prototype will serve the
purpose of testing the viability and performances of approach by experimental means,
observing and analyzing through a range of experiments how social media mechan-
isms can support designers by enabling experience sharing across product lifecycle
phases in emerging product development trends such as PSS.

Acknowledgments. We are grateful to Luleå University of Technology and the case

company for the financial support through the FFI Robust Machining programme and
are extending our gratitude to the respondents of the interviews and observations.

References
1. Senge, P.M.: The Fifth Discipline: The Art and Practice of the Learning Organization.
Doubleday Currency, New York (1990)
2. Milton, N.: The Lessons Learned Handbook: Practical Knowledge-Based Approach to
Learning from Experience. Chandos Publishing Ltd., Oxford (2010)
3. Thomke, S., Fujimoto, T.: The effect of “front-loading” problem-solving on product de-
velopment performance. J. Product Innovation Management 17(2), 128–142 (2000)
4. Bergmann, R.: Experience Management: Foundations, Development Methodology, and In-
ternet-Based Applications. Springer, Heidelberg (2002)
5. Goffin, K., et al.: Managing lessons learned and tacit knowledge in new product develop-
ment. Research-Technology Management, 39–51 (July-August 2010)
6. Vianello, G.: Transfer and Reuse of Knowledge from the Service Phase of Complex Prod-
ucts. Ph.D. dissertation. Technical University of Denmark, Copenhagen, Denmark (2011)
7. Tukker, A., Tischner, U.: New Business for Old Europe: Product-Service Development,
Competitiveness and Sustainability. Greenleaf Publishing Ltd., Sheffield (2006)
8. Harrison, A.: Design for Service - Harmonizing Product Design with a Services Strategy.
In: ASME Turbo Expo 2006: Power for Land, Sea and Air (GT 2006), Barcelona, Spain
(2006)
9. Isaksson, O., et al.: Development of Product-Service Systems: Challenges and opportuni-
ties for the manufacturing firm. J. Engineering Design 20(4), 329–348 (2009)
10. Chirumalla, K., Bertoni, A., Ericson, Å., Isaksson, O.: Knowledge-Sharing Network for
Product-Service System Development: Is it Atypical? In: Shimomura, Y., Kimita, K. (eds.)
The Philosopher’s Stone for Sustainability, vol. 122, pp. 109–114. Springer, Heidelberg
(2013)
11. Baxter, D., et al.: A Knowledge Management Framework to Support Product-Service Sys-
tems Design. J. Computer Integrated Manufacturing 22(12), 1073–1088 (2009)
12. Andersson, P.: Support for Re-use of Manufacturing Experience in Product Development:
From an Aerospace Perspective. Ph.D. Luleå University of Technology (2011)
13. Abramovici, M., Lindner, A.: Providing product use knowledge for the design of improved
product generations. CIRP Annals- Manufacturing Technology 60, 211–214 (2011)
14. Clarkson, J., Eckert, C.: Design Process Improvement: A review of current practice.
Springer, London (2004)
15. O’Dell, C., Hubert, C.: The New Edge in Knowledge: How knowledge management is
changing the way we do business. John Wiley & Sons, New Jersey (2011)
16. Williams, T.: How do organizations learn lessons from projects – And do they? IEEE
Transactions on Engineering Management 55(2), 248–266 (2008)
 Experience Feedback Using Social Media 471

17. Bertoni, M., Chirumalla, K.: Leveraging Web 2.0 in New Product Development: Lessons
Learned from a Cross-company Study. J. U. Computer Science 17(4), 548–564 (2011)
18. Leake, D.B., Bauer, T., et al.: Capture, storage, and reuse of lessons about information re-
sources: Supporting task-based information search. In: Aha, D.W., Weber, R. (eds.) Intel-
ligent Lessons Learned Systems, pp. 33–37. AAAI Press, CA (2000)
19. Yllrisku, S.P., Buur, J.: Designing with Video. Springer, London (2007)
20. Bughin, J., Byers, A.H., Chui, M.: How Social Technologies are extending the organiza-
tion. McKinsey Quarterly (November 2011)
21. Wood, N., Rust, C., Horne, G.: A Tacit understanding: The designer’s role in capturing
and passing on the skilled knowledge of master craftsmen. J. Design 3(3), 65–78 (2009)
22. Cha, M., et al.: I tube, you tube, everybody tubes:analyzing the world’s largest user gener-
ated content video system. In: ACM Internet Measurement Conference, New York (2007)
23. Chui, M., et al.: The Social Economy: Unlocking value and productivity throughsocial
technologies. McKinsey Global Institute (July 2012)
24. Sharif, M.N.A., Zakaria, N.H., Ching, L.S., Fung, L.S.: Facilitating knowledge sharing
through lessons learned system. J. Knowledge Management Practice (March 2005)
25. Yin, R.K.: Case Study Research: Design and Methods. SAGE Publications (2009)
26. Cooper, R.G.: Perspective: The Stage-Gate® Idea-to-Launch Process—Update, What’s
New, and NexGenSystems. J. Product Innovation Management 25(3), 213–232 (2008)
View publication stats