CHAPTER 4

Integrating Knowledge Management

The purpose of integrating knowledge management (see Figure 4.1) is to align HybridP3M with ProwLO guidance. This chapter also covers “integrating knowledge.” To support this process the state-of-the-art Knowmadic steps technique is introduced. Knowledge management is becoming increasingly recognized as important to project success.

Organizing KM Brief

In order to integrate knowledge management processes successfully buy-in is required from the project management team as a whole, including the project board. Also awareness from technical specialists is beneficial as knowledge processes reside in all types of work. To this end, the project knowledge manager should organize a KM brief in alignment with the project manager. It is essential that long-term organization knowledge management goals are embedded in the project or program, in addition to conventional project or program goals. The goal of the KM brief is to popularize knowledge management practices, raise awareness, and introduce process implications related to adopting ProwLO, the key project knowledge management methodology. The outcome of this activity is an introduction to knowledge management, which, in practice, could be a PowerPoint presentation.

Figure 4.1 Integrating knowledge management PDD

Executing KM Brief

Once an introduction has been prepared, a meeting with the project management team, project board, and key technical specialists is scheduled and executed. Dialogue and discussion are important aspects. This meeting will foster understanding and acceptance of key knowledge management processes. One specific outcome is the realization that knowledge processes—from knowledge creation to knowledge evolution—affect all people involved in the project, and understanding that a management framework (in the name of ProwLO) is required to facilitate these processes adequately. Facilitating a meeting like the KM brief is mainly people work, requiring people skills, and based on adequate theory to support practices.

Adopting ProwLO Methodology

If formally approved by the project board, in the context of initiating a project or defining a project or program, the ProwLO methodology is adopted as a solution for missing knowledge management processes. There are many roles involved in the application of ProwLO, but the main role is that of the project knowledge manager. He or she is responsible for promoting ProwLO and raising awareness of the role implications for other people on the project management team, project board, and outside of the project/program (situated in other functions of an enterprise), such as, the PMO. ProwLO consists of eight processes, which run in parallel to the PRINCE2 process model (except post-project knowledge control). These processes are designed in such way that knowledge processes are managed effectively and efficiently, taking into consideration knowledge management problems like knowledge/experience gaps, reinventing the wheel, and repeating of mistakes. The importance of ProwLO is based on project as well as organizational benefits. ProwLO enables systematic learning, and therefore, is a condition for optimized processes. Based on ProwLO knowledge and personal experience of key actors, the project approach gets refined. For example, gained from experience, implications of ProwLO are added to the overall project approach.

To adopt the ProwLO methodology in the context of integrating knowledge management is a matter of commitment, not a matter of project or program definition. In the context of project and program definition, the same activity by name is meant to shape the management environment thanks to definition. In this context, however, ProwLO is integrated and internalized by relevant actors in order to successfully execute knowledge management processes as defined in ProwLO.

Executing ProwLO Process Model

The ProwLO manual contains process descriptions, including tables that capture various role implications of the various processes. Armed with this knowledge, the project knowledge manager, supported by the project manager, should be able to execute knowledge management practices in the right manner. Communication with other roles is essential in order to establish social contracts. Knowledge management is not designed to be an isolated process; it requires input from various actors. So process compliance is only one aspect, the other one is to sell knowledge management. For the detailed process model of ProwLO, please see the manual titled Knowledge Management for Project Excellence.

Continuously Integrating Knowledge

Continuously integrate knowledge is a parallel activity to “execute ProwLO process model.” It involves, on the one hand, validated knowledge with reuse potential, and on the other hand, unvalidated socially generated knowledge. Both cases may include knowledge from projects (newly developed, captured, or gained knowledge). The former type of knowledge demands life cycle support and is the responsibility of the project knowledge manager, taking control of content management. The latter type of knowledge supports team creativity and contributes to expertise status of individual project team members. It also provides a feedback mechanism on validated knowledge fostering knowledge evolution. In order to effectively and efficiently integrate knowledge, of any type, a technique was developed called “Knowmadic steps.” This technique is applied in the context of this activity and introduced in the next section.

Knowmadic Steps Technique: Introduction

The Knowmadic steps technique, first conceptualized by Lukasz Rosinski in 2008 as a knowledge structuring approach, comprises five steps in order to integrate knowledge effectively and efficiently (see Figure 4.2). It takes into account specificity of knowledge and utilizes a mechanism to facilitate knowledge distribution, namely a scope and distribution mechanism. This mechanism, and the technique as a whole, is state of the art and a best practice. Knowledge specificity is two-dimensional. The first dimension is project level versus product level, in other words, high level versus low level in terms of scope. The second dimension is project model specific versus project model generic/product specific, in other words, generic or specific knowledge in terms of scope. With regard to the first dimension, the conceptual knowledge needs are either on the project or product level, or a combination. With regard to the second dimension, the conceptual knowledge needs at the project level are either project model specific or project model generic, while the conceptual knowledge needs at the product level are either project model specific or product specific. The difference between “project model generic” and “product specific”—besides the level—is that in case of the former, knowledge objects (at the project level) are generic for all project models within a domain, whereas in case of the latter, knowledge objects related to a particular product are generic for project models that share the product in question (also within a domain). Hence, distribution is dualistic in its essence. The supporting mechanism takes these two dimensions into account.

The first step according to the technique is to make knowledge explicit. This involves knowledge capture, like writing something, or developing knowledge artifacts, which are knowledge container objects. Depending on the type of knowledge and organizational processes, validation may follow.

The second step is to decide whether the knowledge in question is high level or low level. In the context of projects, high level corresponds to the project level, whereas low level corresponds to products. Products, including management and technical products, are a dominant concept in project work and relate to more specific areas of organization and delivery.

The third step is to decide whether the knowledge in question is generic or specific knowledge. This type of assessment relates to how applicable knowledge is in different contexts. It is a measure but practically applied. With regard to the product level, consider, for example, two project models which have a product in common (e.g., a project plan). It is possible that these project models have different templates related to the same product. If that is the case, then we are dealing with knowledge objects that are project model specific—and not product specific. Conversely, other common products of these project models may share particular knowledge objects (implying that they are product specific). The outcome of steps 2 and 3 combined results in a distribution. It should be noted that knowledge objects that are on both the project and product level are complex. Such knowledge objects are much less common because it is unusual to have two different scopes at the same time. An important characteristic of such combination is the dependency between the project and product level. The simple rule is that it is not possible to select a project model—in the act of knowledge structuring—that does not have a selected product in common. So there is a strong relationship between the project and product level.

Step 4 is to determine the distribution. Given a universe of domains and project models (types of projects within a bounded domain), the user has to determine the exact distribution. This act depends on how domains and project models are structured. Project model management, a sub-function (of content management) and preliminary work, is the responsibility of the project knowledge manager.

The final step 5 is to distribute the knowledge, digitally, on a corporate knowledge base that takes advantage of the Knowmadic steps technique and associated mechanism for distribution. In the following section, three realistic scenarios are provided to better illustrate practical use.

Figure 4.2 Knowmadic steps

The Knowmadic steps technique is performed by the project knowledge manager regarding knowledge objects with claimed reuse potential. These types of knowledge objects are generally files and documents (container knowledge known as tools to support processes). Second, this technique is performed by any project team member regarding socially constructed knowledge in the form of social messages. Regarding the latter, the project knowledge manager should encourage other team members to share knowledge via social messages. An environment characterized by knowledge sharing fosters knowledge creation and development in general.

Applying Knowmadic Steps

The practical application of the Knowmadic steps technique relies on the use of a twofold mechanism for effective and efficient knowledge integration. The following subsections illustrate this mechanism with three examples. Currently, the only software built on this mechanism is KnowledgePlace and the companion platform Insight Intranet.

Project Model Specific Versus Product Specific: The Example of Social Messages

Case A: Project Model-Specific Social Message

Consider a project member who has discovered a best practice from external sources and wants to notify other organizational members—organization-wide—by means of a social message. The claimed best practice is a method (or technique) for the activity of estimating as part of the planning process—in this case the Delphi method (see Wikipedia). However, the appropriateness of a method for estimating depends on the type of project and the present knowledge and experience (Onna and Koning 2002). Taking into account these situational factors, the project member decides that this social message is only relevant for a particular Domain A, and within this domain for three out of four existing project models. Furthermore, he decides that the social message is related to the product of a “project plan.” The mechanism to represent this kind of logic in a graphical user interface is shown in Figure 4.3. Note that Product 2 corresponds to the project plan.

Figure 4.3 Project model specific

Case B: Product-Specific Social Message

The Project Support Office wants to notify organizational members of a recently updated standard template for an issue log in Domain A by means of a social message. In this case, the knowledge object is product specific. In other words, all project models in Domain A that share this product have the same template related to this product. This kind of logic requires a different mechanism as compared to the previous case (Case A), as presented in Figure 4.4. Note that Product 3 corresponds to an issue log and that not all project models in Domain A have this product in common.

Figure 4.4 Product specific

Project and Product Level: The Example of Experiences

It is not unthinkable that a particular knowledge object is on both the project and product level. Consider, for example, a lesson learned related to the project organization. A model of the project organization is not merely one of the many deliverables (i.e., products) of a project; it is an essential part of the project as a whole. Therefore, one may decide that such lesson learned, which is related to the project organization as a product, is also significant at the project level. Furthermore, the lesson learned at the product level is considered as project model specific. The mechanism to represent this kind of logic is based on the mechanism of the first case (Case A) in the previous example and is depicted in Figure 4.5. Note that Product 1 corresponds to the project organization.

Figure 4.5 Project and product level

Evaluating ProwLO

ProwLO is a complex methodology with deep impact on project processes. At key decision moments and the end of the project the effective use of ProwLO should be evaluated. This involves an analysis of process compliance. At the same time best practices should be established from the viewpoint of various involved actors. The roles and responsibilities elaborated in the ProwLO manual (compressed in tables) provide the foundation for the latter. Evaluation is mainly a responsibility of the project knowledge manager and project manager, but it is recommended to involve other roles as well and everyone on the team has a stake in knowledge management. The analysis should also cover to what extent knowledge needs are satisfied, and hence, input from the team is essential. Realization of organizational benefits that can be accredited to the use or ineffective use of ProwLO should be communicated to the chief knowledge officer or similar by the project knowledge manager, in the form of a report or verbal communication.

Suggesting Follow-On Actions/Recommendations

Following evaluation of ProwLO, the project knowledge manager or project manager should identify follow-on actions/recommendations related to ProwLO. Ideally, ProwLO should evolve into a corporate standard with high process compliance and consistency across projects. In practice, however, a lot depends on the knowledge level of involved actors. So one potential improvement area is sufficient training in the methodology. Change management is also a key aspect. If team members embrace learning, there will be less resistance to ProwLO. As ProwLO does not recommend tailoring and automatically scales (depending on the volume of knowledge needs, project and organizational wise), only minor improvement of the process model itself can be expected, notwithstanding evolution of best practices. However, in practice, depending on the organizational culture and specific organizational problems, some ProwLO processes may become more dominant than others. This is not necessarily a bad thing as long as process goals are recognized and a coherent approach is not compromised.

Process Aspects

Figure 4.6 captures the knowledge nature of integrating knowledge management.

Figure 4.6 Tacit–explicit continuum of integrating knowledge management

Integrating knowledge management depends on both explicit and tacit knowledge. For example, in order to execute the ProwLO process a lot of explicit method knowledge is required, as assembled in the ProwLO guide. At the same time, in order to execute ProwLO processes effectively and efficiently tacit knowledge gained from experience is required as well. Similarly, in order to integrate knowledge effectively and efficiently, explicit knowledge about the Knowmadic steps technique is required. But practical experience, and thus tacit knowledge, enables to make the best use of this technique. Overall, tacit knowledge plays arguably a slightly greater role than explicit knowledge in integrating knowledge management.

Figure 4.7 captures the manageability of integrating knowledge management.

Figure 4.7 Step-by-step process versus skilled activity continuum of integrating knowledge management

Integrating knowledge management is more a skilled activity than step-by-step process. It requires experience and broad knowledge management knowledge. Since knowledge management in the context of projects is a rather new phenomenon, great attention should also be paid to people skills, including the skill to sell or popularize knowledge management. However, since the companion ProwLO methodology is also process based, a lot of knowledge can be reduced to process activity steps, which help to make integrating knowledge management more manageable.

Figure 4.8 captures the specialization level of integrating knowledge management.

Figure 4.8 Management–specialist continuum of integrating knowledge management

Without any doubt, integrating knowledge management is a specialist process performed by a project knowledge manager. The project knowledge manager is an exceptional role who has both domain knowledge of project management and knowledge management.

Figure 4.9 captures IT support in relation to integrating knowledge management.

Figure 4.9 Available IT support for integrating knowledge management

The only application area of IT in the context of integrating knowledge management is the activity of continuously integrating knowledge. Ideally, IT should support the Knowmadic steps technique like KnowledgePlace. Alternatives to integrating knowledge organization-wide may exist but only the Knowmadic steps technique is state of the art, for the best kind of knowledge integration, most effective and efficient.

Figure 4.10 captures the complexity of integrating knowledge management.

Figure 4.10 Task complexity scale of integrating knowledge management

The complexity of integrating knowledge management can be evidenced by various means. For example, the ProwLO methodology is very complex. For example, there is a natural tension between ordinary project management with short-term goals and long-term knowledge management, each demanding time and resources. Knowledge management in the context of projects is recently understood but not yet widely practiced. Also the Knowmadic steps technique is quite complex—at least it may appear to be abstract—at first sight and requires some learning for personal knowledge mastery.

MAIDEO Requirements

Table 4.1 lists MAIDEO requirements related to integrating knowledge management.

Table 4.1 MAIDEO requirements related to integrating knowledge management

Requirement	Level	Dimension
The project organization has a designated project knowledge manager role.	1	Process and organization
The project knowledge manager is ProwLO certified.	1	People and culture
The project management team is familiar with ProwLO.	2	People and culture
The project knowledge manager applies ProwLO processes from the ProwLO process model.	2	Process and organization
The project board promotes knowledge management.	2	People and culture
The ProwLO process model is consistently applied across projects and programs.	3	Process and organization
The project team shares knowledge via social messages.	3	People and culture
ProwLO is established as a corporate standard.	4	Process and organization
ProwLO compliance is assessed in the context of project assurance.	4	Process and organization
Organization uses Knowmadic steps software.	5	IT
The project knowledge manager is content manager for project knowledge.	5	IT