Selling knowledge management to project stakeholders

Abstract

This paper represents the latest step of a knowledge journey that our organization began in 2007. Previous steps refer to specific papers presented at PMI® EMEA Global Congresses, including: Uncovering tacit knowledge in projects (Meloni & Villa, 2007), Project Tales (Meloni, 2008), Towards a Project Management Maturity Model (Villa, 2010) and Alice in Projectland (Meloni, 2011). The journey explores and enhances applications of knowledge management in project-based organizations. The key assumption is that projects are unquestionably a dramatic source of knowledge. Every project offers several learning opportunities to generate knowledge and increase both individual competencies and organizational assets. However, knowledge is not yet as formally considered and well managed as other project management main themes. Project stakeholders' awareness towards the knowledge dimension is usually very low. Therefore, they must be better engaged in providing answers to these three questions : “Why is knowledge is important for me?”; “What should I know about knowledge management?”; “What must I do to support knowledge management in projects?” The knowledge engagement depends on the stakeholder profile. For example, a project sponsor and project board will support knowledge management on condition that it improves business results declared in the project charter. Similarly, project team members will be more committed towards the knowledge dimension if it enriches their professional and organizational development. This paper is aimed at analyzing specific strategies that the project manager could apply for selling knowledge management to project stakeholders—particularly to four main categories of stakeholders: Project Board/Project Sponsor; PMO – Project Management Office; Project Team Members; and Customers. nalysis will also include the combination of selling strategies.

Foreword

People may decide to buy a product only if they understand what they are buying. If not, they will not probably buy. To sell knowledge management to project stakeholders, the first thing you must do, as the seller, is to give them a working definition of knowledge. For example, you must explain to them that knowledge is something quite different from data or information. This could be a big obstacle, since organizations today speak a lot about knowledge but often don't really know what they are speaking about. Before starting to sell knowledge management, check how much your project stakeholders are familiar with terms such as knowledge, tacit vs explicit, processes of knowledge conversion, Ba, knowledge crew, knowledge workers, knowledge management maturity model, knowledge assets, personal knowledge management, and community of practice. The selling of knowledge management discussed in this paper assumes that the seller is the project manager. Indeed, the project manager's profile encompasses some specific competencies focused on knowledge: “promotes team learning and advocates professional and personal development; establishes mentoring relationships for team members ‘ development; applies lessons learned to solve current project issues; enables a change-friendly environment by fostering continuous learning; respects the intellectual property of others; learns from mistakes to improve future performance; creates an environment of confidence and respect for individual differences” (PMI, 2007, pp.28,29,32,35,36,37). Moreover, this paper assumes that the project manager truly believes in the value of knowledge and he or she is personally committed to apply knowledge management in projects.

Knowledge fundamentals: meaning, dimensions, value in projects

Traditionally, knowledge is defined as a “justified true belief.” This definition points out the “absolute, static and nonhuman nature of knowledge, typically expressed in propositions and formal logic” (Nonaka, I. & Takeuchi, H., 1995, p.58). However, knowledge is a more complex matter: “knowledge is a dynamic human process of justifying personal belief toward the truth. Knowledge is essentially related to human action. Knowledge is about beliefs and commitment” (pp.58-59). This wider perspective of knowledge encompasses its epistemological (nature of knowledge) and ontological (space of knowledge) dimensions. The epistemological dimension underlines the distinction between tacit and explicit knowledge: “tacit knowledge is personal, context-specific, and therefore hard to formalize and communicate. Explicit or codified knowledge, on the other hand refers to knowledge that is transmittable in formal systematic language. Knowledge that can be expressed in words and numbers represents only the tip of the iceberg of the entire body of knowledge” (p.59). This is exactly what happens in the project environment. Explicit and tacit knowledge are “the basic building blocks of a complementary relationship” (p.ix): Both are essential for creating and managing knowledge within a project-based organization. The ontological dimension refers to different entity levels. The individual level is the essence: “in a strict sense, knowledge is created only by individuals. An organization cannot create knowledge without individuals” (p.59). The group level is a wider space of interaction for sharing and exploiting individual knowledge. In turn, organizational level supports individuals and groups in creating and managing more complex patterns of knowledge. Finally, the inter-organizational level provides contexts for additional development and diffusion of knowledge. Projects encompass all four ontological levels.

Knowledge is a Critical Success Factor (CSF) for project value. A planned management of knowledge, along the project life cycle, strongly improves project performance. For example, knowledge produced in real time is a precious resource for the progressive elaboration of the remaining part of the project (WBS updates; cost and time estimates; analysis of performance measurements and forecasts, assessment of change requests; responses to priority risks, issues resolution). In addition, the knowledge dimension of the project offers daily opportunities to project team members, such as sharing points of view, acquiring a wider understanding of the project, “learning by intrusion,” and testing and improving personal competencies. Knowledge is also a key driver for business results: The knowledge developed accomplishing the project is the basis for settling and implementing an effective change business process. Knowledge acts as a bridge from project deliverables to business results. Finally, project knowledge, if well managed, feeds the organizational knowledge base. Starting from positive and negative project events, lessons learned are documented. In turn, lessons learned from single projects supply helpful insights for developing company projectized best practices.

Knowledge Management vs Knowledge Creation

Generally speaking, Knowledge Management (KM) is intended to be the approach and techniques employed by an organization for capturing, managing, and optimizing existing knowledge assets. KM focuses on the explicit dimension of knowledge and emphasizes the use of knowledge-based technologies, measurement tools, and control procedures. KM deals with “capturing lessons learned, avoiding past mistakes, sharing what organization already knows” (Wellman, J., 2009, p.19). KM is a part of the wider Knowledge Creation (KC). During the mid-1990's, Nonaka and Takeuchi (1995) developed the Theory of Organizational Knowledge Creation. This theory presents a spiral model for creating and managing knowledge, based on the iterative conversion between tacit and explicit knowledge at individual, group, organizational, and inter-organizational levels. This paper assumes that the Nonaka – Takeuchi model fits the project environment and its knowledge topics well. Moreover, the paper will use the term KM with the wider meaning of KC, because KM is commonly used when speaking about knowledge.

The Key Assumption for Selling Effectively Knowledge Management to Project Stakeholders

The performance of an organization in delivering projects is strongly related to its knowledge management maturity. The higher the knowledge maturity, the higher will be the project performance, particularly when projects are people-based and individuals, alone or working in teams, make the difference. Project knowledge management maturity may be defined as “the level of ability of a project-based organization to effectively create and manage knowledge inside and among its projects” (Villa, T., 2010, p.2). In order to cope with this kind of maturity, a Project Knowledge Management Maturity Model (PKMMM) must be used. PKMMM is a framework (a structured collection of elements) aimed at defining, assessing, and improving the project knowledge management practices of a project-based organization. An example of PKMMM “is based on a logical configuration, divided in 5 maturity levels, 6 knowledge domains and 20 knowledge components. Maturity levels depict the evolutionary stages a project-based organization may reach during its knowledge journey. Each stage provides a high-level description of the overall project KM maturity” (p.3).

The key assumption for effectively selling knowledge management to project stakeholders may be summed up this way: “Knowledge management maturity and project stakeholders are strongly related, influencing each other positively or negatively.” On the one hand, the maturity in a specific knowledge domain might be successfully increased only by engaging a specific stakeholder category; on the other hand, a specific stakeholder category is mainly interested in achieving benefits from a specific knowledge domain. In summary, we can state that knowledge maturity is fishing for project stakeholders and project stakeholders are fishing for knowledge benefits. For example, the maturity of the domain “project knowledge strategy” clearly depends on the awareness and commitment shown by the project board/project sponsor towards knowledge management. Well-committed executives ensure a vital support in formulating and communicating goals and guidelines concerning knowledge in projects. At the same time, project boards/project sponsors, and more generally the executive roles, are looking for solutions that assure the return on investment in projects. From this perspective, project knowledge strategy is a sound solution in which to invest to enhance business results deriving from projects. On the contrary, a weak commitment by executives hinders the evolution towards higher levels of maturity in project knowledge strategy. In addition, projects bring a poor contribution to business results, making the company's management unsatisfied with knowledge as a strategic asset.

Exhibit 1 sums up the main relationships among the project knowledge domains of the PKMMM and the main categories of project stakeholders. Each relationship points out the project stakeholder category that, on the one side, primarily influences the maturity growth of a specific project knowledge domain, and, on the other side, is interested in achieving benefits through a higher maturity of the same domain. As mentioned before, project knowledge strategy and the project board/project sponsor are closely linked; meanwhile, project knowledge roles is a domain mainly related to project sponsor and PMO. Project knowledge processes encompass a vital contribution of PMO, accountable for designing, implementing, and supporting knowledge management processes across the different ontological levels of the project-based organization. Project knowledge technologies represent the means through which project team members share explicit knowledge, and PMO acts as a knowledge hub. Project knowledge attitudes are embedded into individuals who truly share knowledge under certain conditions, such as personal autonomy, acknowledge of intellectual capital, and communities of practices. This domain involves project team members and customer's representatives. Finally, the domain of project knowledge enablers is related to all project stakeholders, regardless of their roles.

Project Knowledge Domains vs Project Stakeholder Categories

Exhibit 1: Project Knowledge Domains vs Project Stakeholder Categories

Selling knowledge management must be focused on these relationships in order to exploit the right domain towards the right stakeholder. Different ways of communication should be used to support this selling, according to the stakeholder profile. For example, face-to-face business-oriented presentations for project boards/project sponsors, rather than peer-to-peer knowledge workshops for project team members.

Project Sponsor and Knowledge: the business perspective

“Why is knowledge important for project board/project sponsor?” This first question calls for a sound answer in order to truly engage executive roles in the journey towards higher knowledge management maturity levels in projects. Project sponsors, and in turn project boards, are accountable for the project business case, balancing the single project among the wider project portfolio throughout the project life cycle. Because of this, the challenge is to demonstrate the improvement of project performance and to follow business results, which comes from an intentional application of knowledge management in projects. To cope with this challenge, you might present to project boards/project sponsors outcomes from research and benchmarks that underline the value of knowledge management in projects. This action could focus executives' attention on knowledge, but not enough for them to issue a special budget for the application of knowledge management in your project. This option is a good icebreaker, but it's not the turning point because it doesn't avoid objections such as these: “Our business is unique,” “Our organization is quite different,” “We are already focused on knowledge,” “We have few large projects and many small projects,” “It's no time to put in place long-term initiatives,” “We are strongly committed to short-term results.” The challenge must be played in-house, implementing four main steps, closely involving project boards/project sponsors.

The first step consists in clustering the active projects of the company project portfolio, according to a knowledge perspective. Clustering the projects could be based on two complementary criteria: stability and complexity. “An organization's environment can range from stable to dynamic. A variety of factors can make an environment dynamic, including unstable government, unpredictable shifts in the economy, unexpected changes in customer demand. Dynamic means unpredictable, not variable; variability may be predictable, as in steady growth of demand. An organization's environment can range from simple to complex. Note that rationalized knowledge, no matter how complex in principle, is here considered simple because it has been broken down into easily comprehended parts” (Mintzberg, H, 1993, p.136). Some projects could be stable and simple, others dynamic and complex. The more dynamic and complex a project, the more knowledge management is indispensable for project success. Indeed, a dynamic and complex project feeds largely on a rich flow of tacit knowledge. The “one-size-fits-all approach” doesn't work: Project sponsors could be willing to spend for knowledge management only for projects that entail high levels of dynamism and complexity—in other words, for projects that are very difficult to carry out successfully. Therefore, it's important to explain to executives when and how much to spend for knowledge management, especially if the organization is at a low knowledge maturity level.

The second step consists in dividing the cluster of dynamic and complex projects into two parts: the eligible projects (to be carried out with the application of knowledge management) and the non-eligible projects (to be carried out without knowledge management). The two parts should be similar in the number and type of projects in order to allow a reliable comparison of the results achieved by the eligible and non-eligible projects. This is a way to point out the expected better performance of the eligible projects. By the way, the application of knowledge management to a limited number of projects keeps the additional budget at an affordable level: Executives pay great attention to costs, especially for innovative initiatives, such as initial applications of knowledge management in projects.

For the eligible projects, the third step consists in presenting to the project board a Cost-Benefit Analysis (CBA) focused on knowledge management. On the one hand, additional direct costs for the project, due to specific knowledge management activities, must be clearly estimated. The knowledge management activities must be included in the “project management” branch of the Work Breakdown Structure (WBS) and accurately planned and controlled through detailed work packages. The total cost of knowledge management should be broken down into different cost categories according to the project Cost Breakdown Structure (CBS)—for example: workload, services, tools, licenses, materials, T&L, compensation, etc. Overhead costs must be taken into account, for example the cost of a project knowledge engineer to be shared among eligible projects, or the operating cost of an Internet-based knowledge technology. On the other hand, benefits deriving from the execution of knowledge management activities must be identified and estimated. Benefits should be classified according to three main categories: a) project results in terms of better performance achieved by eligible projects against projects traditionally managed (e.g.. the higher probability of carrying out the project on scope, on time, on budget); b) business results for the performing and/or the customer organization, achievable beyond the delivery of the project, such as lower operational costs or higher revenues due to a new solution delivered by the project; and c) knowledge assets developed carrying out the project, that's to say, what we know after the project that we didn't know before the project. Knowledge asset is “any type of knowledge held or in use by an organization. It has three components: knowledge content contains what the knowledge is about; knowledge structure is how the knowledge is organized; knowledge reasoning is the active process that uses the content to complete a cognitive task, such as problem solving or decision making” (Clemmons Rumizen, M. 2002, pp.230-231). Examples of knowledge assets are a database of best practices, a number of experienced individuals, or a new patent. Knowledge assets are a type of intangible assets. The measurement system of knowledge assets is a vital topic, but it's out of the scope of this paper.

Finally, the fourth step consists in monitoring and evaluating the actual cost/benefit ratio performed by eligible projects. Moreover, this step should investigate the reasons underlying the actual cost/benefit ratio, regardless whether it's positive or negative. The outcomes of this step (positive or negative) establish the level of engagement (high or low) of the executive roles in advocating knowledge management as a common practice for delivering projects. Every step entails a tight collaboration between the project manager, who aims to promote the application of knowledge management, and the project boards/project sponsors who should take decisions about investments in knowledge management.

“What should a project board/project sponsor know about knowledge management?” The answer to this second question is: “nothing more than five knowledge management principles!” These five principles can dramatically foster executives' commitment towards the application of knowledge management in projects.

Principle 1 – Knowledge in projects is mainly tacit, particularly when projects are people-based. It may be useful to underline that “many researchers, and many informed executive alike, agree that about 80 percent of what an organization knows is tacit, rather than explicit. The tacit knowledge is difficult to recognize, to capture and thus to apply efficiently. The caution is to not succumb to the temptation to work on only the explicit 20 percent of what an organization knows merely because it is visible and can be documented” (Wellman, J., 2009, p.174).

Principle 2 – Knowledge flow is more important than knowledge stock. Knowledge makes the difference if available in the right place, in the right moment, and for the right people, regardless of its format. Creating an intentional redundancy of data, information, insights, opinions, and cues is better than storing accurately formal pieces of explicit knowledge. It's always better to choose informal over formal, free connections over institutional channels, “here and now” over “whenever and everywhere”, and communicating vessels over organizational silos.

Principle 3 – In-progress knowledge sharing influences project results. Final results strictly depend on how knowledge is managed throughout the project life cycle, particularly tacit knowledge. Even so, it's hard for the project team to find the time for sharing knowledge on a regular basis, because the project schedule is usually aggressive and everyone is focused on its short-term responsibilities. Still, the project team needs to make a special effort to share knowledge, which happens when it is viewed not an additional cost but a warranty for project success.

Principle 4 – Lessons learned are worthless if individuals cannot internalize them. Project management standards often entail procedures and templates for developing lessons learned at the end of the project, at the end of each phase, or whenever lessons occur. The focus is on capturing project experiences and transforming them into pieces of explicit knowledge to be stocked and made available for future reuse. Unfortunately, the focus is not on allowing individuals to transform lessons learned into new tacit knowledge, through private reflection, personal understanding and adaptation, on-field experimentation.

Principle 5 – Effective knowledge needs its own Ba. “Ba is a Japanese term whose general meaning is a shared space of interaction. Referring to knowledge, Ba is the right context for knowledge creation and fosters relationships between individuals, inside groups, and within and among organizations. Ba can be physical (e.g., office), virtual (e.g., group-ware) and mental (e.g., mindset)” (Meloni, G. & Villa, T., 2007, p.1). In the project environment, things don't happen by chance, particularly the development of new knowledge. For example, the PMBOK® process “Create WBS” needs an interactive Ba, that's to say a joint space for a collective meaning, where the project management team can transform personal tacit knowledge into project explicit knowledge through dialogue, peer-to-peer interactions, and figurative language, and without the obligation of directly producing rational outcomes (i.e. the codified WBS, documented with a project management tool).

“What must project boards/project sponsors do to support knowledge management in projects?” This third question for project boards and sponsors entails that executives really work around the project knowledge strategy. “The project knowledge strategy is aimed at fostering individuals' commitment to create and share knowledge within and among projects. This knowledge domain may be broken down into three components: Project knowledge strategy definition: the process of conceptualizing a picture of the future (vision), formulating goals and guidelines (strategy) concerning knowledge in projects, realigning the project knowledge strategy, in response to feedbacks emerging from single projects. Project knowledge strategy communication: the process of presenting, deploying and supporting the organizational knowledge intention towards project stakeholders. Project knowledge strategy evaluation: the process of monitoring and controlling the impacts on project value due to the application of knowledge management in projects, and rewarding project knowledge management best practices” (Villa, T., 2010, p.4).

PMO and Knowledge: the optimization perspective

“Why is knowledge important for the PMO?” The PMO should be a knowledge hub. Sometimes it happens, sometimes not. Project knowledge management must be a key function of a modern PMO. “The project knowledge management function enables the PMO to: develop an approach to project performance reporting; construct an effective project management information system; facilitate collaboration among project managers, project teams and project stakeholders; manage activities of virtual and geographically dispersed project teams; implement a robust project management knowledge reference library; capture and utilize individuals' wisdom, perspectives, intuitions, and experiences; promote a learning organization among project managers” (Hill., G. 2008, pp. 109-110). The PMO should be strongly committed to managing both explicit and tacit topics, according to its competency level. A basic PMO assures essential knowledge management capabilities, mainly explicit, such as performance reporting, project management information system, and standards for lessons learned. An advanced PMO expands its influence to design, promote, and support a full project knowledge management system based on tacit topics, such as knowledge management spaces, communities of practice, informal networks, and figurative language. An advanced PMO should sell the value of knowledge management, whereas the basic PMO should be engaged by a project manager in supporting the application of knowledge management. The PMO perspective is the optimization of project resources within the single project and among projects. Primarily, an intentional short-term knowledge sharing during the project life cycle should improve the effectiveness and the efficiency of project management processes—for example, in terms of consistency of project scope, reliability of cost and time estimates, significance of identified risks, full evaluation of change requests, deep understanding of project trends and forecasts, radical solutions of key issues, and straight lessons learned. In summary, through knowledge management activities, the project management team should develop a better project management plan at a lower cost. This also applies to executing and monitoring and controlling the plan. Additionally, intentional long-term knowledge sharing should enhance the synergies among projects, for examples in terms of reuses of current solutions, previous experiences, development of best practices, and continuous improvement of the company's project management standards.

“What should the PMO know about knowledge management?” and “What must the PMO do to support knowledge management in projects?” The two questions are tightly related. The PMO should be familiar with knowledge management roles, processes, and technologies—in sum, with the pillars of the project knowledge management system. Usually knowledge management roles are qualified under the general term “knowledge-creating crew”: “all the individuals engaged in knowledge creation within the company” (Nonaka I., & Takeuchi H., 1995, p.151), otherwise named “knowledge activists” or “mayor players in the knowledge creation steps” (Von Krogh G., Ichijo K., & Nonaka I., 2000, p.147). The PMO should guide the definition and the implementation of specific knowledge roles, such as: “Project knowledge catalyst: it is a temporary role, responsible for creating an effective project knowledge context and for facilitating the regular execution of knowledge management processes, inside the project team and towards project stakeholders. This role may be held directly by the project manager or may be delegated to a project team member, a PMO specialist or an external consultant. Project knowledge engineer: it is a permanent role, responsible for developing the organizational project management framework (model and techniques), spreading its application in projects, verifying the real uses, updating the framework (continuous improvement or redesign) based on feedbacks from projects, strategy changes and new trends in knowledge management. This role is usually held by a senior specialist from central staffs (PMO, etc.). Project knowledge officer: it is a permanent role, responsible for optimizing the overall value of project KM for the organization or part of it. Specifically: promoting the organizational knowledge strategy, fostering knowledge cross-fertilization among projects, coordinating knowledge-creation initiatives, evaluating business benefits deriving from project KM investments. This role is typically held by a senior manager (Head of PMO, Business Unit Director, Portfolio Manager, etc.)” (Villa, T., 2010, pp.4-5).

Project knowledge processes are the places where “human knowledge is created and expanded through social interaction between tacit knowledge and explicit knowledge” (Nonaka I., & Takeuchi H., 1995, p.151). According to the spiral of knowledge creation, the PMO should guide the definition and the implementation of four main processes: “Socialization: the process of sharing tacit knowledge among individuals. It happens through face-to face interactions; Externalization: the process of translating tacit knowledge into explicit knowledge. It happens through dialogue and collective reflection; Combination: the process of merging different explicit objects into a more complex explicit knowledge system. It happens through media, such as databases, IT communications infrastructures and organizational networks; Internalization: the process of transforming explicit knowledge into tacit knowledge. It happens through personal learning by doing” (Villa, T., 2010, p.5). The PMO should support the creation of different types of Ba, one for each knowledge management process (originating Ba, interacting Ba, cyber Ba, exercising Ba).

Project knowledge technologies must be active to support the spiral of knowledge creation, especially the externalization and combination processes. The PMO should guide the selection and the implementation of these technologies, but remembering that a technology “is a tool rather than a solution. The deployment of an IT database is not a substitute for understanding the obstacles to knowledge flow across the organization” (Wellman, J., 2009, p.169). The PMO should avoid substituting technological contacts for human interfaces. No matter how powerful a collaborative technology, it cannot generate knowledge by itself and replace the richness derived from personal contacts among individuals working on projects. “There is a widespread tendency to validate significant investment in IT by reference to its contribution to developing and leveraging knowledge in new and effective ways, Unfortunately technology contacts is equated with face-to-face dialogue. Knowledge is primarily a function and consequence of a meeting and interaction of minds” (Fahey, L. & Prusak, L., 1998, p.273). On the contrary, the PMO must be strongly engaged in guiding the application of knowledge management technologies, according to its users' profile (i.e. the profile of project team members). In the same breath, the PMO should put in place the technology and reinforce the team buy-in towards the technology. It's not enough to present the powerful functionalities of the project knowledge database to project team members, inviting them to load pieces of knowledge into the database. The PMO should be able to sell individuals on the advantages to them in using knowledge technologies.

Project Team Members and Knowledge: the development perspective

“Why knowledge is important for Project Team Members?” We can answer by stating that: “developing the project deliverables, you develop yourself!”—occasionally without knowledge management, much more and more surely with knowledge management. Projects are the realm of knowledge, in that your personal knowledge is daily opened to other types of knowledge, and vice versa. A project is a collective effort towards a common result, through a wide web of connections, contacts, relationships, exchanges, points of view, changes in perspective, alignments, and disagreements. Projects offer unbounded opportunities for proving, sharing, and enriching your personal knowledge. Some opportunities can be planned, the most happen by chance. Sharing knowledge really works: No matter what how good a professional you are, others can give you much more than you can give others (this is indisputable because you are one and others are many). You can fully catch these opportunities on condition that you truly believe in them and in the application of knowledge management. It's proven that, in dynamic and complex projects, individuals learn in teams, mainly through peer-to-peer interactions. Sharing knowledge with other project team members produces meaningful personal benefits such as “faster learning, collaborative innovation, better networking, less time looking for information, more information available for consideration, greater sense of connection with peers” (Clemmons Rumizen, M. 2002, p.95). Additional benefits are: higher seniority, new job opportunities, ad-hoc rewards, more power inside the organization, and more visibility across professional communities. To really achieve these personal benefits, the project team member must act as a “knowledge worker.”

Peter Drucker, who first coined the term “knowledge worker,” depicts it through six features: “Knowledge worker productivity demands that we ask the question: What is the task? It demands that we impose the responsibility for their productivity on the individual knowledge workers themselves. Knowledge workers have to manage themselves. Continuing innovation has to be part of the work, the task and the responsibility of knowledge workers. Knowledge work requires continuous learning on the part of the knowledge worker, but equally continuous teaching on the part of the knowledge worker. Productivity of the knowledge worker is not — at least not primarily — a matter of the quantity of output. Quality is at least as important. Finally, knowledge worker productivity requires that the knowledge worker is both seen and treated as an asset rather than a cost. It requires that knowledge workers want to work for the organization in preference to all other opportunities” (Drucker, P. 1999, p.142).

According to these features, we can argue that knowledge workers are individuals who bring valuable tacit knowledge to the project. The more tacit knowledge you bring, the more you should be considered a knowledge worker. Projects are full of knowledge workers. The Project Manager is an example of a knowledge worker in that he or she brings tacit knowledge for guiding the project, including balancing constraints, interests, resources, options, risks, and issues towards the project's solution. The Business Analyst is another example of a project knowledge worker, in that he/she brings tacit knowledge for exploring the project environment, eliciting stakeholders' needs, and translating them in project requirements. Technical Leader, Subject Matter Expert, Trainer are other examples of project knowledge workers. Their common trait consists of a personal presence that makes the difference. Projects are a place where, simultaneously, project takes benefits from knowledge workers and knowledge workers take benefits from the project. At the end of the project, we should have a better project performance and more experienced and satisfied knowledge workers. If not, something went wrong.

“What should Project Team Members know about knowledge management?” and “What must Project Team Members do to support knowledge management in projects?” These two questions are tightly related. Project Team Members should be familiar with, and should practice the concept of knowledge worker. Regardless of the knowledge management solutions implemented by the organization, a knowledge worker must assume a personal responsibility for knowledge. That's to say, “taking initiative and responsibility for what you know, do not know and need to know, as well as who you know or need to know” (Barth, S., 2004, p.5). This is called PKM – Personal Knowledge Management. Each knowledge worker, as an entrepreneur, should invest in improving his or her own knowledge, according to a specific PKM plan. This personal development plan could be implemented through teamwork, networking, and communities of practice.

Teamwork, such as working in a project team, aims at achieving a common and challenging goal through deep interactions among individuals. In this environment, knowledge workers share insights, options, and priorities and joint deliverables individually produced. The nature of collaborative work “puts more responsibility on every individual, not less. It requires more of the individual, not less” (p.5). Teamwork is regulated by organizational rules and constraints, for example, the project management standards the project team must apply for developing the project management plan, or the schedule and budget limits issued by the project charter. The knowledge worker should be able to take advantages of project rules and constraints for implementing his or her PKM plan, in order to improve personal motivation, professional development, and organizational power.

Networking is the development and the maintenance of a set of different personal relationships with other individuals. Networking means to have something in common. The common thing varies from individual to individual: It may be a professional experience, a common history, a personal interest, or a common language or culture. Networking is more flexible than teamwork, in that the knowledge worker, with respect to the organizational policies, can choose which personal relationships to begin and nurture. Networking could bring to the knowledge worker valuable benefits: “information, new ideas, answers to problems, new business and social relationships, support in hard times, encouragement, new opportunities” (Clemmons Rumizen, M. 2002, p.279). Networking, to be effective, entails the application of some golden rules, such as: “give today for getting tomorrow”; “face-to-face relationships as much as you can”; “diversity of connections beyond usual functional and geographical boundaries”; “listen actively, starting from others' points of view”; and “appraisal for the mentoring you receive.”

The concept of Communities of Practice (CoP) is an emerging topic in knowledge management, particularly in project-based organizations. CoP are “natural living human institutions. They go through times of promises, trial, doubt and dormancy. Because they are voluntary, successful communities are vibrant” (McDermott, R. 2000, p.16). CoP differ from project teams in that: a community is formed by volunteers; its members share common interests and willingness to work together; members are moved by their passion towards the area of interest they would like to develop; connections among members cross the formal organizational channels; a member can choose and change over time his or her level of engagement inside the community; a community refers to declared vision and mission but not to short-term goals to achieve or deliverables to carry out; the domain of a community changes over time, with respect to external trends and its internal history; many projects could be launched inside a community, promoted directly by individuals and carried out by teams of members; a community changes its configuration according to its dimension; its duration cannot be planned in advance in that it depends on the natural development of the community; and, finally, a community, to be effective, should be guided by a qualified coordinator, accountable for the big picture. During its life, a Community of Practice typically goes through five stages: “Planning, Start-up, Growth, Sustain, Close” (pp.17-19). Each stage offers remarkable opportunities for a knowledge worker to implement his or her PKM plan. During the Planning stage, a knowledge worker could uncover an existing network and catalyze it into a community. Moreover he or she could contribute to define the initial configuration of the community in terms of vision/mission, code of conduct, membership requirements, roles, operational rules, and company's sponsorship—in sum, to become a charter member of the community. During the Start-up stage, a knowledge worker could take part in the launch of the community, managing or contributing to its initial events. Moreover he or she could promote the community towards its stakeholders, selling the quick wins achieved during this stage—in sum, to become a member of the community's core group. During the Growth stage, a knowledge worker could benefit greatly from the expansion of the community. Growth entails the exposure to an increasing number of new ideas and connections, which must be exploited as a newcomer or as a mentor—in sum, to become a focal point of the community. During the Sustain stage, a knowledge worker could promote new topics and changes of perspective, beyond the boundaries settled in the previous stages. Moreover he or she could create links with other communities for developing common projects—in sum, to become an innovator of the community. Finally, during the Close stage, a knowledge worker could contribute to guide a timely and intentional closure of the community, treasuring history and outcomes ripened by the community throughout its life—in sum, to become a witness of the past community.

The effectiveness of a PKM plan depends on some abilities that the knowledge worker should put in place, through teamwork, networking and CoP. These abilities refer to learning by intrusion, curiosity, and storytelling. Learning by intrusion means, “to enable individuals to invade each other's functional boundaries and offer advice or provide new information from different perspectives”(Nonaka, I. & Takeuchi, H., 1995, p.81). “That is to say, relying on more cues, points of view, suggestions. An intentional redundancy enables individuals to better understand the big picture and consequently to be more proactive in developing informal non-hierarchical communication channels where Tacit Knowledge can move around easily” (Meloni, G. & Villa, T., 2007, p.4). Curiosity should be embedded in project knowledge workers. “Although curiosity and/or being curious is not explicitly mentioned in any of the current PMI® standards, in the Performance Criteria of the Personal Competences in the PMCDF® we often find close synonyms such as observe, seek, look for, signifying not only the need to uncover and use valuable information and different kinds of data, but also the skill to extract meaning from the natural redundancy, diversity and serendipity of the project environment” (Meloni, G., 2011, p.1). Finally, storytelling should be a common practice for a knowledge worker to share knowledge, mainly the tacit side. “Figurative language, and storytelling in particular, have recently became quite popular and stories have been quoted to be among the best techniques not only for sharing knowledge but also for promoting change, persuading and sparking action. Regardless of their current popularity, stories are a useful tool to capture individual experiences in projects, particularly so for Project Mangers who are called to delve into “project lore” during several Project Management processes, i.e. scope definition, time and cost estimating, risk identification and developing and managing the project team through narrative” (Meloni, G., 2008, p.2).

Customer and Knowledge: the quality perspective

Projects are undertaken to respond to business needs. A project is a bridge for passing from the current business condition (As Is) to a new better business condition (To Be). “As Is” and “To Be” are conditions of the customer organization (client, if the customer is internal). For complex and dynamic projects, it's quite difficult to map and update the “As Is” and the “To Be” conditions. As a matter of fact, business needs are more implied than stated, in that customers can't translate consistently their tacit expectations into explicit requirements. Project performance is evaluated according to its conformance to requirements, whereas the real project value for the customer is fitness for use and, in turn, better business results. A good project performance does not necessarily mean value for the customer. Why? Because the tacit knowledge of the customer was only partially elicited. The knowledge boundaries of the projects should be reconsidered, in that “it's not only about what your organization knows, but how it can make the best use of the knowledge of its partners and customers” (Lesser, E. & Prusak, L., 2004, p.141). Knowledge and knowledge management flow through the organizations involved into the project, fostering them to share information, insights, and mental models.

“Why is knowledge important for the Customer?” The answer: to get a solution that satisfied his or her business needs! It encompasses a quality perspective founded in customer satisfaction: “this requires a combination of conformance to requirements (to ensure the project produces what it was created to produce) and fitness for use (the product or service must satisfy real needs)” (PMI, 2008, p.190). The knowledge owned by the customer organization is indispensable for assuring the expected quality. Unfortunately, too often the customer doesn't consider its knowledge as a CSF, assuming that the price it pays to the performing organization is enough to get a valuable solution.

“What should the Customer know about knowledge management?” and “What must the Customer do to support knowledge management in projects?” The two questions are tightly related. The customer's stakeholders, particularly business focal points and end-users, should be actively engaged in those project management processes where the “voice of the customer” makes the difference. According to PMBOK®, these processes are: Identify Stakeholders, Collect Requirements, Identify Risks, Control Scope, Verify Scope, Monitor and Control Risks, Close Project or Phase. These processes entail a sound elicitation of customer tacit knowledge. By the way, elicitation is a specific knowledge area of de-facto standards in business analysis: “elicitation describes how business analysts work with stakeholders to identify and understand their needs and concerns, and understand the environment in which they work. The purpose of elicitation is to ensure that a stakeholder's actual underlying needs are understood rather than their stated or superficial desires” (IIBA, 2009, p.7). Elicitation is implemented through specific techniques such as brainstorming, focus groups, interviews, expert judgement, observation, and facilitated workshops. These techniques are people-based, in that their effectiveness depends on trust, active listening, mutual understanding, physical proximity, and the openness of individuals involved. Individuals of the customer organizations should be familiar with and practice these techniques.

The combination of knowledge selling strategies

Each selling strategy discussed in this paper is focused on a particular project stakeholder (i.e. the optimization perspective on PMO). These strategies, if well performed, present positive side effects on other stakeholders. The project manager, as the seller of knowledge management, should identify and enhance these side effects.

An intentional knowledge strategy issued by Project Sponsors/Project Boards foster the engagement of the PMO in that the PMO is asked to implement specific knowledge roles (i.e. knowledge catalysts) and processes (i.e. combination through collaborative technologies) for supporting the knowledge strategy. This way, the PMO works harder to create the operational conditions for sharing knowledge inside and among projects. In return, a more knowledge-oriented PMO should submit to the Project Sponsor/Project Board a roadmap for achieving a higher level of knowledge management maturity. Thus, the synergy between the business perspective and the optimization perspective is really exploited.

The more specific knowledge roles, processes, and technologies are in place within the project environment, the more Project Team Members should be disposed to take personal responsibility for knowledge. This way each of them, as a knowledge worker, may better develop and execute his or her PKM plan. In return, Project Team Members, more committed towards knowledge topics, should give the PMO feedbacks for improving the knowledge management system. Thus, the optimization perspective and the development perspective influence each other positively.

Carrying out the project, Project Team Members closely interact with customer's stakeholders, for example in collecting requirements, identifying business risks, and testing project deliverables. Because of this, the individuals of the customer organization should be regularly exposed to knowledge management practices. Elicitation, for example, should become a common pattern for sharing tacit knowledge among knowledge workers, regardless the organization to which they belong. In return, a customer more “knowledgeable in knowledge” should play an active role in carrying out a solution of the expected quality (conformance to requirement and fitness for use). Thus, the development perspective and the quality perspective feed each other.

When the customer organization realizes that the application of knowledge management in projects improves its business results (i.e., lower costs, higher revenue, better profits), it should strengthen the partnership with the performing organization. This way, the performing organization and the customer organization should learn more by intrusion and achieve higher maturity levels in knowledge management. Knowledge should become a CSF for investing together in future projects. Thus, the quality perspective and the business perspective mutually reinforce the exchange of knowledge among organizations.

Final Words

Albert Einstein stated that “the things which are not measurable are more important than those which are measurable”—in other words, intangible over tangible, tacit over explicit. This is the real challenge for an effective application of knowledge management in projects. Projects are the realm of tacit knowledge, difficult to map, capture, and store. Individuals remain the originating source and the final destination of knowledge creation, particularly for dynamic and complex projects. This paper is mainly aimed at providing practical rules to implement knowledge management in projects through a true engagement of project stakeholders. Knowledge management in projects is first of all sharing, collective reflection, learning by intrusion, curiosity, trials and errors, flow over stock, elicitation, storytelling, celebration of successes and failures. This is why knowledge management is becoming indispensable for project-based organizations.

References

Barth S. (2004). Self-Organization: Taking a personal approach to knowledge management. UK: Butterworth-Heinemann.

Clemmons Rumizen M. (2002). The complete idiot's guide to knowledge management. Madison, WI: Alpha Books

Drucker P. (1999). Management challenges for the 21st century. New York: Harpercollins.

Hill G. (2008). The complete project management office handbook. Boca Raton, FL: Auerbach.

Fahey L., Pruzak L. (1998, Spring) The eleven deadliest sins of knowledge management. California Management Review 40(3), 27265-280.

International Institute of Business Analysis (2009). A guide to business analysis body of knowledge (BABOK Guide) Version 2.0. Toronto Canada: International Institute of Business Analysis.

Lesser E., Pruzak L. (2004). Creating value with knowledge. New York: Oxford University Press.

McDermott R. (2000, November). Community development as a natural step. Knowledge Management Review 3(5), 16-19.

Meloni G., Villa, T. (2007, May). Uncovering tacit knowledge in projects. PMI Global Congress 2007, Europe, Budapest, Hungary.

Meloni G. (2008, May). Project tales: Sharing tacit knowledge in projects. PMI Global Congress 2008, Europe, Malta.

Meloni G. (2011, May). Alice in projectland: The adventures of a curious project manager. PMI Global Congress 2011, Europe, Dublin, Ireland.

Mintzberg H. (1992). Structure in fives, designing effective organization. Englewood Cliffs, NJ: Prentice Hall.

Nonaka I., & Takeuchi H. (1995). The knowledge creating company: How Japanese companies create the dynamics of innovation. New York: Oxford University Press.

Project Management Institute. (2007). Project manager competency development framework, second edition. Newtown Square, PA: Project Management Institute.

Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK® Guide) Fourth Edition. Newtown Square, PA: Project Management Institute.

Villa T. (2010, May) Towards a project knowledge management maturity model. PMI Global Congress 2010, Europe, Milan, Italy

Von Krogh G., Ichijo K., & Nonaka I. (2000). Enabling knowledge creation: How to unlock the mystery of tacit knowledge and release the power of innovation. New York: Oxford University Press.

Wellman J. L. (2009). Organizational learning. New York; Palgrave McMillan.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2012, Tiziano Villa, PMP® CMC®
Originally published as a part of 2012 PMI Global Congress Proceedings – Marseille, France

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.