Searching for knowledge management practices in the PMBOK® guide
Siew Yong Wee, M.Cert (PM), PMP
Simon Fraser University, Canada
In a world in which turbulence is the norm, organizations are continually reinventing and refining their strategies. Increasingly, they are relying on projects to design and implement significant change. Projects are used to reinvent business processes, support customer-focused global strategies, and coordinate information and decision flows between organizations. The success of individual projects, and the creation of organizational project competency, is often critical to organizational renewal, survival, and success.
In some types of projects, notably information technology (IT)-focused projects, success has proved to be elusive. Although IT expenditure accounts for at least one-third of capital spending, the success rate of IT projects is historically less than 30% (Standishgroup.com). This shortfall is costly, both in resources and in the loss of business benefits. In this research program, we seek to identify theory and practice to increase their success rate.
One relatively new research stream conceptualizes IT projects through a knowledge management lens – viewing projects as sites in which knowledge is shared, integrated, created, stored, and used. There is empirical proof that knowledge practices contribute to successful project outcomes (Faraj & Sproull, 2000; Yoo & Kanawattanachai, 2001; Tiwana, Bharadwaj, & Sambamurthy, 2003).
In order to connect this research approach to existing practices, we are investigating the use of knowledge management theory and practice by project managers and team members. Although many project managers do not have formal training, there is an increasing trend towards obtaining the Project Management Professional certification (PMP®) designation and, through this effort, understanding the principles incorporated into A Guide to the Project Management Body of Knowledge (PMBOK® Guide). The PMBOK Guide is truly the foundation upon which all formal knowledge of project management rests.
This research study has identified knowledge management practices embedded within the PMBOK Guide tools, techniques, and processes. In order to classify these practices, we use Zack’s knowledge typology (Zack, 2000). We also use the concept of knowledge flows from Snider and Nissen (2003). In addition, we examine ways in which other knowledge management concepts (e.g., the Nonaka SECI model, transactive memory, collective mind, and mutual understanding) are represented within PMBOK Guide.
From this work, we have identified two major types of knowledge that are present within a project: project management knowledge and project domain knowledge. Each is important to the successful completion of the project, and each is useful during different PMBOK Guide processes. We used this simple typology throughout our analysis.
It is our hope that this research will identify areas in PMBOK Guide could be augmented with a knowledge-based approach, and that future versions of this important guidebook will incorporate such a view. Through these changes, we strive to improve the success rate of projects.
There were four major steps in our methodology to extract the elements of knowledge management practices from PMBOK Guide. They are summarized in Exhibit 1 and discussed below.
Exhibit 1 - Steps in Research Methodology
In the first step, we looked for a way to clearly identify the knowledge management content of PMBOK Guide. Since PMBOK Guide is itself an explicit, codified knowledge object, we decided to use Zack’s taxonomy, which described various kinds of codified knowledge. Zack distinguishes between knowledge objects and knowledge processes and identifies three types of codified knowledge - declarative, procedural, and causal. These two concepts – knowledge objects and knowledge processes - formed the framework for this research study.
We also recognized that the concept of knowledge processes had been used in the context of PMBOK Guide in a recent article (Snider & Nissen, 2003) and presented to the PMI Research conference attendees. Therefore, we used their framework, which consists of three kinds of knowledge flows – knowledge as solution, knowledge as experience, and knowledge as socially created.
In this step, we readied our research frameworks for their role in parsing PMBOK Guide. We examined the Zack framework and then looked for similar concepts in PMBOK Guide, to ensure that we were applying the concepts fairly. There were several steps in this process, with each step being prompted by our own lack of clarity about the concept or our process.
First, we applied the following definition of knowledge, differentiating knowledge from data and information as follows (Zack, 1999, p. 46):
- “Data represent observations or facts out of context, and therefore not directly meaningful.
- Information results from placing data within some meaningful context, often in the form of a message.
- Knowledge is that which we come to believe and value based on the meaningfully organized accumulation of information (messages) through experience, communication or inference. ”
To clarify the ways that Zack asserts that we gain knowledge, we assumed that experience involves learning through active engagement; communication involves talking, listening, and reading; inference involves cognitive processes such as reasoning.
We note that the way PMBOK Guide uses the term information includes information as well as knowledge as defined by Zack.
Second, we differentiated between knowledge objects and process by applying Zack (1999, p. 46):
- “Object is a thing to be stored and manipulated.
- Process - simultaneously knowing and acting - that is, applying expertise.”
We noted that PMBOK Guide states that a process “is a series of actions bringing about a result” (PMI, 2000, p. 29) and concluded that these two definitions are fundamentally the same. They both apply actions to inputs and produce outputs.
We further applied the following “acid test”: if an expert and a regular practitioner were to do the same thing (e.g., create a project charter), would there be a discernable, important difference between the two outputs? If so, then we are dealing with knowledge process or object.
Third, we applied the above framework to PMBOK Guide, reviewing the major processes in the nine Knowledge Areas and examining the inputs, tools, and techniques and outputs of each process. For each of these items, we applied the above definitions and acid test to identify the knowledge objects and processes. We did not attempt to be comprehensive in this application of the framework – we selected the knowledge objects and processes which are central to PMBOK and which exhibited some variety for more detailed analysis.
In this application of the framework, we differentiated between tacit and explicit knowledge objects and processes by using Zack (1999, p. 46):
- “Tacit knowledge is subconsciously understood and applied, difficult to articulate, developed from direct experience and action, and usually shared through highly interactive conversation, story-telling and shared experience.”
- “Explicit knowledge, in contrast, can be more precisely and formally articulated. Therefore, although more abstract, it can be more easily codified, documented, transferred, or shared.”
We assumed that tacit knowledge is shared in formal and informal interactions such as meetings and in situations where people learn through copying, listening, or observing; and that explicit knowledge would be found in objects and processes created during the project – such as reports, minutes, and documentation.
We further categorized the knowledge objects and processes into the following three types of knowledge (Zack, 1999, p. 46):
- “Knowledge about something is called declarative knowledge. A shared, explicit understanding of concepts, categories, and descriptors.”
- “Knowledge of how something occurs or is performed is called procedural knowledge.”
- “Knowledge of why something occurs is called causal knowledge.”
It should be noted that Zack’s definitions and explanations assumed that the goal is always to make tacit knowledge explicit and to make it shared. In our analysis of PMBOK Guide, we assumed that knowledge can be explicit or tacit, individual or organizational, and that not all knowledge will be transformed to being shared and explicit.
Throughout our analysis of PMBOK Guide, we felt the need for a broader classification than the one provided by Zack. To this end, we distinguished between project management knowledge and project domain knowledge. We use the following definitions:
- Project Management knowledge is the knowledge (as defined in PMBOK Guide) as the knowledge needed to initiate, plan, execute, control, and close a project (e.g., knowledge of what is a generic Work Breakdown Structure and how to create one).
- Project Domain knowledge is the business, industry, company, and technical knowledge needed to complete the deliverables of a project (e.g., to know what must be included in an actual Work Breakdown Structure of a housing construction project). This type of knowledge is called application area-specific knowledge in PMBOK Guide (PMI, 2000, p. 181).
We then took the knowledge objects and processes previously identified and related them to Nissen and Snider’s (2003) categories of knowledge flows. For each of the knowledge objects and processes chosen, we traced its references in PMBOK Guide to see if:
- It flows across organizational and geographical space (Knowledge as Solution). In this view, knowledge is created and used by other stakeholders or processes.
- It flows across time (Knowledge as Experience). In this view, knowledge is created and stored and then used at a later time.
- It is created through the interaction of people (Knowledge as Socially Created).
Recognizing that the Zack framework was focused mainly on codified explicit knowledge, we decided to broaden the review by exploring mainstream knowledge management concepts and practices. Some of these practices have been proven to positively influence project performance. For example, Faraj and Sproull defined expertise coordination as the coordination of specialized skill and knowledge and administrative coordination as the formal or pre-specified mechanisms used to assign tasks, allocate physical and economic resources, mange resource dependencies, and integrate outputs. For business application software development projects, their study demonstrated that expertise coordination has more impact on the effectiveness of project performance than administrative coordination. (Faraj & Sproull, 2000). We used this study and the further definition of expertise coordination by Yoo and Kanawattanachai (2001) to justify looking for transactive memory and collective mind within PMBOK Guide.
Other concepts which are commonly used in knowledge management research were also investigated. The end result was that we reviewed PMBOK Guide to identify instances where each of the following concepts were used or mentioned:
- Nonoka’s SECI model of knowledge creation (Nonoka & Konno, 1998).
- Project-based learning (DeFillippi, 2001; Smith & Dodds, 1997).
- Transactive memory (Wegner, 1987).
- Collective mind (Weick & Roberts, 1993).
- Mutual Understanding (Majchrzak & Beath, 2003)
In the following three sections, we show instances of where PMBOK Guide contains 1) explicit knowledge objects and processes, 2) tacit knowledge objects and processes, and 3) other knowledge management concepts.
Explicit Knowledge Objects and Processes from PMBOK Guide
We have selected the Project Charter, the Work Breakdown Structure, the Project Plan, and the Cost Control process to show instances of explicit knowledge objects and processes within PMBOK Guide. These are not an exhaustive list; they were chosen because of their importance within PMBOK Guide and because they illustrate the different classifications and knowledge flows in our framework. Each of these three objects and one process is shown in detail in Exhibits 2 through 5.
The Project Charter, discussed in Exhibit 2, is an explicit knowledge object, containing mostly declarative and causal knowledge – in other words, what the project is designed to do and why the project is being initiated. Its main content is project domain knowledge (e.g., business knowledge). We applied all of the Snider and Nissen knowledge flow classifications, finding that the Project Charter is being socially created, used immediately by the project manager, and stored for use by other PMBOK Guide processes.
Exhibit 2 – Project Charter
The Work Breakdown Structure, shown in Exhibit 3, is a declarative knowledge object – it shows what is to be done, but not how or why. It contains both project management knowledge (e.g., the cost and resources for the work package.) and project domain knowledge (e.g., the scope of the project). It is passed to many of the other processes in PMBOK Guide.
Exhibit 3 - Work Breakdown structure (WBS)
The Project Plan, as shown in Exhibit 4, is classified as a declarative and procedural knowledge object, in that it tells the reader what to do and how to do it (e.g., do project task x before task y). It contains both project domain knowledge (e.g., project charter) and project management knowledge (e.g., milestones and target dates).
Exhibit 4 - Project Plan
Cost Control (discussed in Exhibit 5) is a knowledge process, containing declarative, procedural, and causal knowledge. It contains information about the project management knowledge (e.g., knowing that the cost baseline has changed) as well as the project domain knowledge (e.g., corrective actions). Its outputs are used in the following processes, as well as stored.
Exhibit 5 - Cost control
Tacit Knowledge Objects and Processes from PMBOK Guide
We have chosen two tacit knowledge objects within PMBOK Guide to discuss - Stakeholder Risk Tolerance and Expert Judgment. They are both important to PMBOK processes and illustrate the different classifications and knowledge flows in our framework. Most of the tacit knowledge objects occur at points in the project life cycle where PMBOK Guide states that project management professionals should consult tacit knowledge sources (e.g., experts) to ensure project success.
PMBOK Guide does not define any tacit knowledge process as part of the nine Knowledge Areas of project management, but does mention mentoring (PMI, p. 107) as a part of Project Human Resource Development. In knowledge management literature, mentoring has been identified as a process for transferring tacit knowledge from one individual to another.
Stakeholder Risk Tolerance (discussed in Exhibit 6) is a tacit knowledge object, embodied in an individual stakeholder, and is used as input in the Risk Management Plan. This object is considered to contain declarative (what) and causal (why) types of knowledge about the project domain (e.g., the business). Stakeholder Skill and Knowledge (PMBOK Guide 126.96.36.199) for Project Plan Development is another tacit knowledge object and similar classification and rationale can be applied to it.
Exhibit 6 – Stakeholder Risk Tolerance
Expert Judgment is used in many of the 39 PMBOK Guide processes. In Exhibit 7, it is shown in the context of Project Initiation. We have classified it as a knowledge object, embodied in an expert, which is used as an input to a project process. Experts bring project domain knowledge to the project and use it in declarative, procedural, and causal forms. Experts are external to the project team, but can be from within or external to the organization. Expert Judgment is used in seven other PMBOK Guide processes, besides Project Initiation. In other instances, it may bring project management knowledge to the processes.
Exhibit 7 - Expert Judgment
PMBOK Guide and Other Knowledge Management Concepts
The SECI model
Nonoka defined the SECI model (see Exhibit 8) to demonstrate the four phases in the conversion of tacit knowledge to explicit knowledge and back to tacit knowledge. It contains Socialization (which is tacit to tacit knowledge transfer between individuals), Externalization (tacit to explicit transformation), Combination (explicit to more complex forms of explicit knowledge transformation) and Internalization (explicit to tacit knowledge transformation).
Exhibit 8 – SECI Model from Nonaka and Konno (1998)
As mentioned above, although PMBOK Guide refers in passing to mentoring (PMI, p. 107), which might be considered a socialization process, it does not explicitly build it into tasks or processes. Other than mentioning mentoring, PMBOK Guide has no direct reference to socialization.
Eleven PMBOK Guide processes translate the tacit knowledge of the organization, experts, and customers into explicit forms. None of these refer to tacit processes among team members. There are three types of externalization processes:
1) The eight processes which use expert judgment to help produce explicit knowledge objects as outputs:
- Project Initiation (PMBOK Guide 5.1)
- Scope Planning (PMBOK Guide 5.2)
- Activity Definition (PMBOK Guide 6.1)
- Activity Duration Estimating (PMBOK Guide 6.3)
- Resource Planning (PMBOK Guide 7.1)
- Quantitative Risk Analysis (PMBOK Guide 11.4)
- Procurement Planning (PMBOK Guide 12.1)
- Solicitation Planning (PMBOK Guide 12.2)
2) The processes that use stakeholders’ skill, knowledge, and risk tolerance to help produce explicit knowledge objects as outputs:
- Project Plan Development (PMBOK Guide 4.1)
- Risk Management Planning (PMBOK Guide 11.1)
3) The process that uses a highly interactive forum to clarify tacit knowledge that was not clearly explicated in the original procurement document:
- Bidder Conference (PMBOK Guide 188.8.131.52)
Most of the processes in PMBOK Guide have explicit knowledge objects for inputs and produce more complex explicit knowledge objects for outputs. The outputs are the evolution of the knowledge stored in the inputs. An example is the Project Plan Development process (PMBOK Guide 4.1). So the Combination part of the SECI model is highly evident in PMBOK Guide. If a process produced at least one knowledge output that involved the combination of more than one input, we deduced that that combination had taken place.
Of the 39 PMBOK Guide processes, there were only seven in which the outputs were (a) information only, or (b) updates of knowledge objects, or (c) not new complex knowledge objects.
Internalization is generally interpreted as an individual experimenting, learning through doing, using explicit information as input. An example might be a person who reads the instructions as to how to make a puff pastry and then proceeds to try and create the same result as shown in the cookbook. Using Information Technology terms, internalization might mean a programmer who reads detailed specifications and tries to produce the desired results. We could not find any direct references in PMBOK Guide to this means of knowledge conversion.
Summary - SECI model
PMBOK Guide has a strong emphasis on the Externalization and Combinations portions of the SECI model, because it has a strong bias towards explicit knowledge. The exact count of occurrences of the four types of knowledge transformations are shown in Exhibit 9.
Exhibit 9 – Occurrences of SECI transformations in PMBOK Guide
In the introductory article in a special issue of Management Learning, DeFillippi (2001) suggested this definition of project-based learning: “The theory and practice of utilizing real-world work assignments on time-limited projects to achieve mandated performance objectives and to facilitate individual and collective learning” (Smith & Dodds, 1997). The most common form of project-based learning discussed in this issue was the creation of “lessons learned” – a compilation of learning that could be passed on to the next phase or the next project.
PMBOK Guide contains a knowledge object called Lessons Learned. There are five processes, which facilitate project-based learning by adding to the Lessons Learned knowledge object:
- Integrated Change Control (PMBOK Guide 4.3)
- Scope Change Control (PMBOK Guide 5.3)
- Schedule Control (PMBOK Guide 6.5)
- Cost Control (PMBOK Guide 7.4)
- Administrative Closure (PMBOK Guide 10.4).
The term “transactive memory” is used by researchers who are investigating the cognitive arenas within a project. A definition of transactive memory from its initiator is “The set of knowledge possessed by group members, coupled with an awareness of who knows what.” (Wegner, 1987). We found this definition to be too all-encompassing for our purposes, and limited our interpretation of collective mind to the cognitive map that is possessed by an individual or a group. In other words, the knowledge of “who knows what.” We excluded any actual domain or project management knowledge from this definition. It is this more limited definition that has been tested in research (Yoo & Kanawattanachai, 2001).
We could find no reference to the concept of transactive memory in PMBOK Guide.
The concept of “collective mind” builds on the concept of transactive memory. One definition states that “individuals develop shared understandings of the group’s tasks and of one another that facilitate group performance.” (Crowston & Kammerer, 1997, from Weick & Roberts, 1993). Another definition contains more action, and says that collective mind is a “social cognitive system in which individuals heedfully interrelate their individual actions.” (Yoo & Kanawattanachai, 2001). Thus, using the terminology developed previously, we would say that individuals develop transactive memory (i.e., who knows what) and project management knowledge (i.e., what each person is doing on the project) and then heedfully coordinate their actions.
PMBOK Guide makes no direct reference to building collective awareness or to any kind of self-management within the project team. Although it has no direct reference to this knowledge-management concept, there are several PMBOK Guide processes that could be used to build collective mind within the project team.
- Status Review Meetings (PMBOK Guide 184.108.40.206).
- PMBOK Guide 220.127.116.11 talks of the need to have face-to-face meetings to encourage team members to interact and enhance their ability to perform as a team.
- Project Communication Management (Chapter 10) contains 3 processes that all support the development of the collective mind to ensure that effective and efficient communication takes place for all project stakeholders:
• Communication Planning (PMBOK Guide 10.1).
• Information Distribution (PMBOK Guide 10.2).
• Performance Reporting (PMBOK Guide 10.3).
The definition of Mutual Understanding is “mutual appreciation and knowledge of each other’s expertise, assumptions, interests, contexts, and constraints as they contribute to the project”(Majchrzak & Beath, 2003, from Nelson & Cooprider, 1996).
One section of PMBOK Guide, the Contract Negotiation process (PMBOK Guide 18.104.22.168), acknowledges the need for mutual appreciation and knowledge of each other’s interests and constraints, specifically to reach mutual agreement between the buyer and the seller on the structure and requirements of the contract. There are no references to mutual understanding within the project team.
Summary of Knowledge Management Concepts as Reflected in PMBOK Guide
To summarize, the concept of project-based learning, as instantiated in lessons learned knowledge object, is the best representation of the knowledge concepts investigated. The findings are shown in Exhibit 10.
Exhibit 10 – Occurrences of KM Concepts in PMBOK Guide
Summary – Knowledge Management in PMBOK Guide
We have two types of knowledge that are created, shared, stored, and used within a project--project management knowledge and project domain knowledge. Because PMBOK Guide is a handbook for project managers, it is necessarily focused on project management knowledge, which is to say the knowledge needed to control the project. Project domain knowledge is implied mainly in the Project Initiation process and when experts join the project processes to bring an outside perspective.
PMBOK Guide itself is an explicit knowledge object and has a strong emphasis on the creation and usage of explicit knowledge, often showing plans and documents flowing from one process to another. Within the realm of explicit project management knowledge, PMBOK Guide mainly consists of declarative and procedural knowledge – that is, what to do and how to do it. Being a parsimonious document, it does not contain much causal knowledge.
PMBOK Guide recognizes the need for tacit knowledge in the context of external stakeholders, experts, and potential bidders. In other words, people outside the project are recognized for their tacit knowledge. Interestingly, there is no recognition that the members of the project team bring valuable knowledge to the project. In general, PMBOK Guide is quite silent on the subject of who is involved in various processes. In summary, while PMBOK Guide recognizes the importance of bringing in external tacit knowledge to the project processes at the right time, it does not acknowledge:
- The creation of tacit knowledge within the team.
- The importance of transferring tacit knowledge--which has been socially created in the earlier part of the project life cycle but may not be explicated--to the later part of the project life cycle.
- The difficulty of the explication and transfer of tacit knowledge.
We have demonstrated that while PMBOK Guide does not explicitly talk about knowledge flows as defined by Snider & Nissen (2003), project management and project domain knowledge flows do take place within PMBOK Guide processes.
- “Knowledge as Solution” flows occur when the knowledge objects produced by the project processes are used by stakeholders outside the project team or by future project teams through Lessons Learned and Project Archives.
- “Knowledge as Experience” flows are particularly well demonstrated because of the emphasis on documentation of process outputs, which are used in the later part of the project life cycle.
- “Knowledge as Social Creation” flows are demonstrated where expert judgment, expert knowledge, and stakeholders’ skills and knowledge are used in processes which produce knowledge objects.
Therefore, the concept of knowledge flows, especially between processes, and between external individuals and the project, are well represented. As mentioned above, however, there is very little attention paid to knowledge flows within the project team.
Other Knowledge Management Concepts
PMBOK Guide does not have direct references to any of the four knowledge management concepts that have been reviewed in this research. However, the creation or transformation of explicit knowledge objects (e.g., the externalization and combination quadrants of the SECI model) can be mapped to many PMBOK Guide processes.
PMBOK Guide also recognizes the need to pass learning to succeeding projects through the Lessons Learned knowledge object, in support of project-based learning.
While PMBOK Guide is clear about coordinating the knowledge from external sources, it is silent on the subject of knowledge coordination within the team. The handbook takes a command-and-control stance with respect to project management knowledge, with a “need to know” focus. Whereas the development of transactive memory and collective mind might encourage a team to manage itself more effectively, PMBOK Guide seems uninterested in the participation of team members in the project management process. Presumably, they are present at planning, team status meetings and communication meetings, but PMBOK Guide seems to portray these as one-way communications, intended to inform and update, but not involve. Again, because PMBOK Guide is fairly silent on the “why” and the “who” of many processes, the foregoing are inferences by the research team.
Our overall conclusion is that PMBOK Guide is very clear and comprehensive on the creation, storage, and usage of explicit knowledge objects and on the usage of expertise. The PMBOK Guide structure could and should be adapted to recognize the importance of tacit knowledge, especially of team members. As projects move from routine to transformational, all of the knowledge resources within a project must be mobilized.
Crowston, K., & Kammerer, E.E. (1998). Coordination and collective mind in software requirements development. IBM Systems Journal 37(2): 227-246.
De Fillippi, R. (2001). Introduction: Project based learning, reflective practices, and learning outcomes. Management Learning 32(1): 5-10.
Faraj, S., & Sproull, L. (2000). Coordinating expertise in software development teams. Management Science, 46(12) December: 1554-1568.
Majchrzak, A., & Beath, C. (2003). A framework for studying participation and mutual understanding in software projects. Working Paper.
Nelson, K. M., & Cooprider, J. G. (1996). The contribution of shared knowledge to I/S group performance. MIS Quarterly 20(4): 409-429.
Nonoka, I., & Konno, N. (1998). The Concept of “Ba”: Building a foundation for knowledge creation. California Management Review, 40(3) spring: 40-54.
PMI. (2000). A guide to the project management body of knowledge (PMBOK guide). Newtown Square, PA: Project Management Institute.
Smith, B., & Dodds, R. (1997). Developing managers through project-based learning. Aldershot/Vermont: Gower.
Snider, K.F., & Nissen, M.E. (2003). Beyond the body of knowledge: A knowledge-flow approach to project management theory and practice. Project Management Journal, June: 4-12.
Tiwana, A., Bharadwaj, A., & Sambamurthy, V. (2003). Antecedents of IS capability. Proceedings of the 24th International Conference on Information Systems, Seattle, WA: 246-258.
Wegner D.M. (1987). Transactive memory: A contemporary analysis of the group mind. In B. Mullen & G. R. Goethals (Eds.), Theories of group behavior, New York. Springer-Verlag: 185-208.
Weick, K.E., & Roberts, K.H. (1993). Collective mind in organizations: Heedful interrelating on flight decks. Administrative Science Quarterly, 357-381.
Yoo, Y. & Kanawattanachai, P.. (2001). Developments of transactive memory systems and collective mind in virtual teams. International Journal Organizational Analysis, 9(2): 187-208.
Zack, M.H. (1999). Managing codified knowledge. Sloan Management review, 40(4) summer: 45-58.