Lessons (Really) Learned? How to Retain Project Knowledge and Avoid Recurring Nightmares
Knowledge Management and Lessons Learned
Knowledge Management and Lessons Learned
National Bank of Abu Dhabi
Most companies have institutionalized the process of identifying and documenting lessons learned, but, even when these lessons are correctly identified and documented, they often get lost in a database, preventing companies to really learn from experience and repeating mistakes. This paper looks at the relevance of knowledge management (KM) as a means of improving business performance through lessons learned and through a case study in the construction industry.
Keywords: knowledge management, lessons learned, construction industry
Modern industrial economics continue to shift from economies driven by natural resources to economies driven by knowledge. This focus change brings a number of challenges to business, such as how to realize the knowledge, use it, store it for future reference, transfer it, and secure it. In order to overcome these challenges, the researchers identified the emerging need for defining knowledge management frameworks, developing new systems, and designing compliant knowledge management processes.
There is no universal definition of knowledge agreed upon in respect to academic studies investigating knowledge management (KM). Taking a social constructivist perspective, according to Davenport and Prusak (1998), “Knowledge is a fluid mix of framed experience, values, contextual information, and expert insight that provides a framework for evaluating and incorporating new experiences and information. It originates and is applied in the minds of knowers. In organizations, it often becomes embedded not only in documents or repositories but also in organizational routines, processes, practices, and norms”. Within the same epistemological paradigm, Boudreau and Couillard (1999) describe knowledge as “things that are held to be true in a given context and that drive people to action,” (p. 24) whilst according to Alavi and Leidner (1999), “Knowledge is a justified personal belief that increases an individual capacity to take effective action” (p. 5).
As KM is a multidisciplinary field of study, agreeing a single definition of KM is as problematic as defining knowledge. Girard (2016) lists over 100 definitions of KM. This is not surprising given knowledge is an integral part of most businesses and that a single, non-segment specific, definition might not be meaningful or relevant to all. The paper defined KM as the creation, transfer, and exchange of organizational knowledge to achieve a competitive advantage. Similarly, Stankosky (2008) cites that “Knowledge management consists of leveraging intellectual assets to enhance organisational performance” (p. 9). On the other hand, researcher Hislop (2013) offers a perspective focused more on the process, and break KM down to multiple subprocesses: creating, capturing, storing, sharing, applying, and reusing.
In slight contrast, Broadbent (1997) argues a corporate integrated approach that, “Knowledge Management is understanding the organization's information flows and implementing organizational learning practices which make explicit key aspects of its knowledge base. It's about enhancing the use of organizational knowledge through sound practices of informational management and organizational learning” (p. 6).
Understanding various perspective provides researchers with an indication of the sheer range of definitions available, and although it would be interesting to explore this in more detail, it is beyond the scope of this literature review and research study.
HOW DO THE KNOWLEDGE MANAGEMENT FRAMEWORKS WORK?
In our projects, we produce data at every process group. As per the project management framework, the data elements come together and form information (Exhibit 1).
Exhibit 1: Transforming data to information.
The information is observed by the person or group of people, and it becomes knowledge. Knowledge is later transferred to other stakeholders in different forms: such as peer assist, review, mentoring coaching, workshop, training and seminars, knowledge fairs, reports, and so forth (Exhibit 2).
After the transfer of knowledge is completed, the KM process restarts from the beginning.
Exhibit 2: Continuity of KM.
That is why KM is referred as a continuous activity.
WHY KNOWLEDGE MANAGEMENT IS IMPORTANT
Considering today's competitive world, knowledge is the most valuable asset for companies. Thousands, millions, are spent to retain knowledge by patenting, retaining core staff, e-documenting. KM become one of the core activity of business.
Knowledge management can benefit organizations in a number of ways:
- Reducing risk and uncertainty
- Facilitates decision-making capabilities to make decisions better and faster
- Builds learning organizations by making learning routine
- Making it easy to find relevant information and resources
- Reusing ideas, documents, and expertise
- Avoiding redundant effort
- Taking advantage of existing expertise and experience
- Avoiding making the same mistakes twice
- Taking advantage of existing expertise and experience
- Promoting standard, repeatable processes and procedures
- Stimulates cultural change and innovation.
- More optimized business processes
- Foster innovation
- Providing methods, tools, templates, techniques, and examples
- Making scarce expertise widely available
- Improve customer relationships and service
- Enabling the organization to leverage its size
- Making the organization's best problem-solving experiences reusable
KNOWLEDGE MANAGEMENT FRAMEWORKS
Exhibit 3 summarizes different KM frameworks.
Exhibit 3: KM frameworks.
Common to all models and frameworks are a number of activities or processes coupled with enablers that help drive (or hinder) successful implementation. The table above summarizes practitioner models, which all have very similar enablers with a slight variation in terms of the activities.
The SECI model shown in Exhibit 4 explores knowledge creation through the conversion between tacit and explicit knowledge. Tacit knowledge is stored in the heads of individuals and is difficult to communicate externally or to share (Robinson et al., 2005). Explicit knowledge is captured or stored in an organization's manuals, procedures, information systems, and is easily communicated or shared with other people or parts of an organization (Robinson et al., 2005).
Exhibit 4: SECI model.
The European Committee for Standardization (CEN, 2004) conceptualizes KM as cyclical framework (Exhibit 5). The model was conceived from a study of over 150 knowledge management frameworks and models with the intention to create a European standard KM framework and terminologies. Because of this overarching, global approach to forming the model, the research team found it particularly relevant for use as our conceptual model framework. It links personal knowledge capabilities with organizational knowledge capabilities; and furthermore, it links the cycle of KM process with key stakeholders in the business network as well as linking to our proposed KM unit of analysis.
Exhibit 5: European committee for standardization conceptual framework (CEN).
The model consists of three layers
- Business Focus
- Core Knowledge Activities
It represents the critical knowledge and value-adding processes and highlights the organizational context in which knowledge is created and applied. The business networks relate to inter-organizational relationships between suppliers, partners, and clients.
CORE KNOWLEDGE ACTIVITIES
The knowledge activities of identify, create, store, share, and use are the most widely used activities. In order to be successful, these processes require support by the correct KM methods and tools/enablers (CEN 2004).
The final layer of the model is split into two forms of complementary enablers: personal and organizational knowledge capabilities. Personal knowledge, links with personal capabilities such as ambition, skills, and behavior, coupled with experience and relevant tools. The organizational capabilities include the mission, vision, strategy, design of structures and processes, and company culture.
Lessons learned are a typical way to gather and retain knowledge from projects: But what are “lessons,” and how can we judge if we have really “learned” something?
A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition (PMI, 2013) refers to lessons learned as:
- the knowledge gained during a project: lessons learned are knowledge gained through a project and a project is, aftermost, a form of “experience” (p. 544)
- which shows how project events were addressed or should be addressed in the future: lessons learned show ways to do things in certain circumstances, so they are, namely, good “patterns” to follow
- with the purpose of improving future performance: lessons learned have the goal to improve the way we do things.
So we can say that, to truly “learn” a lesson, you need three “ingredients”:
- An experience to learn from (by observation or by direct participation)
- A pattern of doing things in similar situations
- A goal to improve something.
THE LESSONS LEARNED SHORTCOMINGS
The traditional process of developing lessons learned is generally is made up of three steps:
- Collection: where experience is analyzed and lessons are identified
- Documentation: where identified lessons are documented and archived
- Communication: where documented lessons are communicated to the people that should use them
Most companies have institutionalized this process, but, even when lessons are correctly identified, documented, and communicated, they often get lost in some sort of “lessons learned database”—as in, a “black hole” (Dalton, 2013)—that nobody ever looks at, preventing companies to really learn from experience and running the risk to repeat the same mistakes again and again.
The traditional process of identifying and documenting lessons learned has proven to be highly ineffective, because most of the time companies fail to “assimilate” the lessons they have identified, so people don't change their ways of doing things and the whole culture of companies fails to evolve from experience.
THE LESSONS LEARNED PROPOSED PROCESS AND IMPLEMENTATION TIPS
To make a better use of project experience, the authors propose a process based on the following five steps:
As we can see, two more steps are introduced in the proposed process: “Prioritization” and “Assimilation.” For each of the five steps, some typical traps and some useful implementation tips will be presented.
In the collection step, lessons are captured and identified, as said before, through a collective effort to analyze facts from past experience.
- The common practice: lessons are usually gathered directly from project stakeholders, through workshops, meetings, and so on.
- The trap: eliciting lessons can be a hard job because people are normally reluctant to admit failures.
- The remedy: the practice of collecting lessons in moderated sessions in which every participant can contribute anonymously to the identification of the problems encountered is very effective. Techniques like the “Delplhi method” can be applied to collect lessons anonymously.
Information overload and loss of focus are some of the causes of the ineffectiveness of the traditional process. For example, one reason why the NASA “official” agency-wide repository for lessons learned was not widely used, was because its lessons covered so many topics that it was difficult to search for an applicable lesson and it was difficult to weed through all the irrelevant lessons to get to the few “jewels” needed (Li, 2002).
- The common practice: normally all the lessons identified by the “post project review” participants are documented and subsequently stored for future retrieval, independently of the participant role or contribution to the project
- The trap: “quantity” does not always mean “quality,” because every stakeholder has the tendency to assign a higher importance to the lessons that improve the processes in which they are directly involved. The result is normally a big mess of disarticulated lessons, that fails to concentrate on the few main issues that jeopardize projects
- The remedy: while it is a good practice to collect lessons from a wide array of stakeholders, it is best to restrict the subsequent prioritization process only to the key project team members, using a scoring system to identify the most effective lessons
The aim of the documentation step is to document the prioritized lessons in a consistent and standardized format to facilitate future retrieval.
- The common practice: it is a common practice to describe the lessons in a textual format, linking each lesson to the problem it should prevent
- The trap: often lessons are documented in a “not-actionable” format, with no practical instruction on how to implement the lesson. General terms are used, like “be careful when…” or “we will strive more to…”, and so on
- The remedy: if you don't think about the way to change the current processes, you are deemed to encounter the same problems, so you should try to identify the practical changes in the way of doing things. For example, you could further detail the lesson “be careful when” into “check this and that when…” or you could transform “we will strive more to…” into “you will need at minimum two people to…” and so on
The communication step refers to the publishing of lessons to the people that are intended to use them.
- The common practice: it is a common practice to communicate the lessons publishing them in some sort of “lessons learned database”
- The trap: when the next project begins, no one looks into the huge lessons learned database, because it is very time consuming to find the right lesson learned for the specific work you have to do at the moment.
- The remedy: a very effective practice is to link every lesson to a specific type of “deliverable” (e.g., lessons for time plans, lessons for budget, lessons for risk response plans, etc.), so that before start working on a specific deliverable, it'll be very easy to retrieve all the lessons related to the deliverable.
The real “digestion” of the lessons by the organization happens here: this is where most organizations fail.
- The common practice: before starting a new project, it should be a good practice to consult the lessons learned database to find any applicable knowledge
- The trap: when the next project begins, it is time consuming to search for any applicable lesson and to adapt any lesson found to the particular situation you have to face, so often this step is skipped, making useless all the previous efforts to gather lessons
- The remedy: to truly assimilate lessons in the organization, it is a very good practice to create a checklist for each type of deliverable (e.g., time-plan checklist, budget checklist, risk-response plan checklist, etc.) and to incorporate the lessons learned in these checklists, in a readily actionable way (see Exhibit 6 from Gawande, 2011).
Exhibit 6: Checklist as a way to apply knowledge and experience (reproduced from Gawande, 2011).
Make a habit to add items in these checklists with the lessons identified in every project. Do the same with templates, procedures, and KPIs. So we can say that the only way to assimilate lessons is to incorporate them into process assets (Midha, 2005). One could say that “if a lesson is not into the right checklist, you have not learned it!”
CASE STUDY: FINDINGS OF IMPLEMENTATION OF KNOWLEDGE MANAGEMENT IN CONSTRUCTION INDUSTRY + BENCHMARKING
In this case study, the project team has selected four major players in the construction industry in the United Arab Emirates and conducted more than 10 interviews with C-level executives and program directors, conducted over 30 surveys and reviewed over 50 documents, including project plans, databases, reports, and memorandums.
Exhibit 7 shows our findings in the case study.
Exhibit 7: Case study findings.
THE WAY TO IMPROVE
The recommendations to successfully design and implement a knowledge management system in the case companies are as follows:
- Keep it simple
- Retain key staff wherever possible—protect the core of your business
- Clearly define the knowledge that generates value
- Clearly define and publish KM strategy and objectives
- Benefit from various IT solutions to store, archive, track knowledge
- Promote KM internally across business functions and externally to wider network
- Incorporate lessons learned into process assets
ABOUT THE AUTHORS
Marco Negri is an IT manager with more than 16 years of working experience with Italy's major national infrastructure companies (Italferr, Italy's leading national railway engineering company, and Anas, Italy's national administrator of the network of roads and highways). He is specialized in enterprise project management and enterprise content management, specifically tailored for the civil works environment. He is a Project Management Professional (PMP)®, and is CBAP®, COBIT®, and ITIL® Transition certified.
Mustafa Dülgerler has managed IT projects across industries ranging from intelligent transportation and healthcare to manufacturing and banking. Mr. Dulgerler specializes in leading mid-sized teams of highly skilled engineers to solve some of the most pressing challenges in enterprise IT. As an enterprise architect at National Bank of Abu Dhabi, he is responsible for defining the technology and business platform to execute strategy. He is also a widely recognized project management trainer in the Middle East.
Mustafa has been invited to various international events as a speaker, including PMI® Global Congress 2015 and IRM UK Enterprise Architecture Congress 2015 in London, Middle East Forum 2015, and Big 5 Dubai Congress in Dubai.
CONNECT WITH US!
Alavi, M., Leidner, D.E. (1999). Knowledge management systems: Issues, challenges and benefits. Communications of the Association for Information Systems, 1(7).
American Productivity and Quality Centre. (2000). Successful implementing knowledge management executive summary: Consortium learning forum best practise report. Houston, TX: APQC. Retrieved from www.apqc.org
Boudreau, A., Couillard, G. (1999). System integration and knowledge management. Information Systems Management, 16(4): 24–32.
Broadbent, M., (1997). The emerging phenomenon of knowledge management. Australian Library Journal, 46(1), 6–24
CEN. (2004). CEN Workshop Agreement 14924-1: European guide to good practice in knowledge management. Brussels, BE.
Covey, S. R. (1990). The 7 habits of highly effective people. New York, NY: Fireside Books.
Dalton, Jeff. (2013). Can CMMI save us from the black hole of lessons learned? Retrieved from http://askthecmmiappraiser.blogspot.it/2013/10/can-cmmi-save-us-from-black-hole-of.html
Davenport, T., & Prusak, L. (1998). Working knowledge: How organizations manage what they know. Boston, MA: Harvard Business School Press.
Gawande, A. (2011). The checklist manifesto. New York, NY: Picador.
Girard, J. (2016). Knowledge management (KM) definitions. Retrieved from www.johngirard.net
Hislop, D. (2013). Knowledge management in organizations: A critical introduction. Oxford, England: Oxford University Press.
Li, A. (2002). Better mechanisms needed for sharing lessons learned. Washington, DC: U.S. Government Accountability Office.
Midha, A. (2005). How to incorporate “lessons learned” for sustained process improvements. Wayne, NJ: CNIR.
Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK®guide) – Fifth edition. Newtown Square, PA: Author.
Robinson et al. (2005). Knowledge management practices in large construction organisations. Engineering, Construction and Architectural Management, 12(5), 431–445.
Stankosky, M. (2008). Keynote address to ICICKM. Proceedings of the International Conference on Intellectual Capital, Knowledge Management and Organisational Learning.
Thomas, Willis H. (2015) The basics of project evaluation and lessons learned (2nd ed.). Boca Raton, FL: CRC Press.
© 2016 Mustafa Dülgerler, Marco Negri
Originally published as part of the 2016 PMI® Global Congress Proceedings – Barcelona, Spain