Searching for Knowledge Management Practices in the PMBOK Guide
Blaize Horner Reich, PhD, CMC, ISP
Siew Yong Wee, M.Cert (PM), PMP
Simon Fraser University, Canada
Introduction
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.
Methodology
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
Step 1 Decide on the classification scheme – selected Zack (1999) and Snider & Nissen (2003) frameworks.
Step 2 Identify and classify knowledge objects and process in PMBOK Guide using Zack’s definition of knowledge. We also apply an overarching knowledge typology consisting of project domain knowledge and project management knowledge
Step 3 Apply Snider & Nissen typology of knowledge flows to the objects and processes.
Step 4 Review PMBOK Guide to look for instances where other knowledge management concepts are illustrated.
Step 1
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.
Step 2
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).
Step 3
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).
Step 4
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
Definition “A document that formally authorizes a project. It should include: (a) the business
need that the project was undertaken to address and (b) the product description (PMI, p. 204). ”
PMBOK Guide Reference Project Initiation PMBOK Guide 5.1.3.1
Knowledge classification Declarative and causal, explicit knowledge object containing project domain
knowledge
Knowledge flows Rationale
Knowledge as Solution “It is issued by a manager external to the project. It provides the project manager with the authority to apply organizational resources to project activities” (PMI, p. 54).
Knowledge as Experience It is the main output from Project Initiation (PMBOK Guide 5.1) and is a major input to:
• Scope Planning (PMBOK Guide 5.2).
• Risk Management Planning (PMBOK Guide 11.1.). Knowledge as Socially
created This knowledge object is socially created by the experts who are brought in to assess the inputs of the process (PMBOK Guide 5.1.) 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)
Definition “A deliverable-oriented grouping of project elements that organizes and defines the
total work scope of the project" (PMI, p. 209).
PMBOK Guide Reference Scope Definition PMBOK Guide 5.3.3.1
Knowledge classification Declarative explicit knowledge object containing project management and project
domain knowledge
Knowledge flows Rationale
Knowledge as Solution “The WBS is often used to develop or confirm common understanding of project scope.” “The lowest level of the WBS is used for “assign the scope of the work to another organization" (PMI,, p. 60).
Knowledge as Experience It is the main output from Project Scope Definition (PMBOK Guide 5.3) and flows through the whole project planning cycle. It is a major input to many PMBOK Guide project processes.
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
Definition “A formal, approved document used to guide both project execution and project
control" (PMI, p. 205).
PMBOK Guide Reference Project Plan Development PMBOK Guide 4.1.3.1
Knowledge classification Declarative and procedural explicit knowledge object containing project
management and project domain knowledge
Knowledge flows Rationale
Knowledge as Experience It is the main output from Project Plan Development (PMBOK Guide 4.3) and flows through the whole project execution and control cycles.
Knowledge as Social
Creation The many team members socially create the Project Plan knowledge object as it is created using the cumulative outputs of all of the Project Planning processes (PMI, p. 33).
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
Definition A project management process “concerned with (a) influencing the factors that
create changes to the cost baseline to ensure that the changes are agreed upon, (b) determining that the cost baseline has changed and (c) managing the actual changes when and as they occur"(PMI,, p. 90).
PMBOK Guide Reference Cost Control PMBOK Guide 7.4
Knowledge classification Declarative, procedural, and causal explicit knowledge process containing project
management and project domain knowledge
Knowledge flows Rationale
Knowledge as Solution This process produces the knowledge object of Corrective Action. The knowledge is passed to other team members and stakeholders, who use this knowledge object to make appropriate changes to ensure project success.
Knowledge as Experience “The “whys” of both positive negative variances” (PMI, p. 91) from the cost baseline are determined and captured in Lessons Learned, which will be used by future project teams.
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 4.1.2.2) for Project Plan Development is another tacit knowledge object and similar classification and rationale can be applied to it.
Exhibit 6 – Stakeholder Risk Tolerance
Definition “Different organizations and different individuals have different tolerance for risks.
These may be expressed in policy statements or revealed in actions" (PMI, p. 129).
PMBOK Guide
Reference Risk Management Planning PMBOK Guide 11.1.1.4
Knowledge classification Declarative and causal tacit knowledge object containing project domain and project management knowledge
Knowledge flows Rationale
Knowledge as Solution This tacit knowledge object is one of the main inputs used to produce the Risk Management Plan, which transfers the knowledge to the team members and other stakeholders.
Knowledge as Experience The portion of the tacit knowledge of the stakeholders that is explicated and documented in the Risk Management Plan is used in many PMBOK Guide project processes
Knowledge as Social Creation
Risk Management Plan is socially created by the stakeholders using the Stakeholders Risk Tolerance as one of the critical inputs.
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
Definition “Expertise provided by any group or individual with specialized knowledge or
training…is available from many sources, including: (a) other units within the performing organization (b) consultants (c) stakeholders, including customers, (d) professional and technical associations and (c) industry groups" (PMI, p. 54).
PMBOK Guide
Reference Project Initiation PMBOK Guide 5.1.2.2
Knowledge classification Declarative, procedural, causal, tacit knowledge object containing project domain knowledge
Knowledge flows Rationale
Knowledge as Solution Expert judgment is used to assess the various inputs and some of the tacit knowledge is explicated and stored in Project Charter. This knowledge is transferred to project manager.
Knowledge as Experience The portion of the tacit knowledge of the experts that is explicated and documented in the Project Charter is used in the other project processes in the later part of the project life cycle.
PMBOK Guide and Other Knowledge Management Concepts
The SECI modelNonoka 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)
tacit knowledge tacit knowledge
tacit k
no
wled
ge
Socialization: “The sharing of tacit knowledge between individuals through joint activities rather than through written or verbal instructions” (p. 42).
Externalization: “The expression of tacit knowledge and its translation into
comprehensible form that can be understood by others” (p. 43). ex plicit knowled ge tacit knowl edge Internalization “Conversion of explicit knowledge into the organization’s tacit knowledge. This requires the individual to identify the knowledge relevant for one’s self within the organizational knowledge.” (p. 45)
Combination “Conversion of explicit knowledge into more complex sets of explicit knowledge” (p. 44). exp licit k no w led ge
explicit knowledge explicit knowledge
Socialization
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.
Externalization
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 12.3.2.1)
Combination
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
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
Socialization
0 of 39 PMBOK Guide processes
Externalization
11 of 39 PMBOK Guide processes Internalization
0 of 39 PMBOK Guide processes
Combination
32 of 39 PMBOK Guide processes
Project-based learning
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)
Transactive memory
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.
Collective mind
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 4.2.2.4).
• PMBOK Guide 9.3.2.4 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).
Mutual Understanding
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 12.4.2.1), 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
Project-Based Learning 5 of 39 PMBOK Guide processes
add to Lessons Learned
Transactive Memory 0 of 39 PMBOK Guide processes
Collective Mind 5 of 39 PMBOK Guide processes
provide the opportunity
Mutual Understanding 1 of 39 PMBOK Guide processes
Summary – Knowledge Management in PMBOK Guide
Knowledge Objects
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.
Knowledge Flows
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.
References:
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.
