Abstract
Knowledge flows within projects, between parallel running projects, in and between the project and the customer or partners. To optimize these knowledge flows it is important to understand the drivers of effective project management, such as collaboration, project organization etc., and the knowledge management framework or toolbox that exist and can easily be transferred to the context projects.
Knowledge Management in projects starts with improved collaboration methods and ends in the enriched project management process that includes e.g., debriefing sessions etc., including such domains such as the combination of Knowledge Management and project management tools.
While projects naturally include different types of people and different resources, all the activities described are also framed by a deep understanding of the cultural environment, possible barriers and challenges, and foster a culture change program as part of the knowledge management initiative.
Introduction
In any organization, projects play an important role. It does not matter if a company's or organization's business involves many projects, or projects are only used internally – those projects are an unparalleled source of knowledge.
The use, the management and the leverage of this source is the challenge of KNOWLEDGE MANAGEMENT within projects. But to understand the instruments and the right tool set, it is quite important to take the elements apart and to structure the way we look at it systematically. The first step after the identification of PROJECTS as our focus area for today's session is to answer the question:
How does the knowledge within projects look alike?
The knowledge in projects can be structured in different clusters, so called knowledge domains. Those domains could be knowledge about customers, partners, competitors, methodologies, technical / non-technical solutions components etc. Following the perspective of the Knowledge Management pioneers Nonaka / Takeuchi the knowledge within the knowledge domains follows different criteria (Nonaka, I., 1995). The most important differentiation could be made based on the distinction between implicit (tacit or personnel) and explicit knowledge. The difference can be explained by means of an example: (Exhibit 1)
Exhibit 1: Illustration of different types of knowledge (Own source)
While the score is the described knowledge of, for example, a Mozart violin concerto, and could be easily transferred and stored etc. (explicit knowledge), to play a violin requires certain experience and a good deal of practice and - most important – a certain level of talent (tacit / implicit knowledge). In addition the CD recordings of music by the same composer, but under the direction of different conductors, sound different, because the original score still provides room for interpretation. Transferred to our context, this means that in each project there is plenty of virtuosity and many pages of “score” to manage. This example also indicates that the knowledge of projects could not only be stored, for example, in documents or document management systems, which indicates that Knowledge Management is more than just an IT –based system, but also a socio-technical system with a holistic view of processes, roles, structures, organizational issues and – last but not least – IT system support such as Collaboration or document management systems (O`Dell, C., Grayson, C., 1997).
As an example, please have a look at the Knowledge Management Framework of Siemens Business Services, called knowledgemotion:
Exhibit 2 – Knowledge Management Framework (Davenport, T., 2002)
But what are the essentials of a Knowledge Management framework such as the one mentioned above, that are the basis of an effective knowledge sharing with and between projects? And how will they help to optimize projects? The next chapter explains the project-specific tool set, and will introduce methods of implementation as well as key performance indicators to measure the success of the toolset.
The toolset of knowledge sharing in and between projects
Understand the loop
USE and CREATION of knowledge
There is also the possibility of this being a chicken – egg discussion (we will discuss later how to get started with Knowledge Management Implementation). We start with the phase: USE and CREATION of knowledge (Probst, G. et al., 1999).
The most important point within this phase is that, before anyone starts preparing any problem/customer solution, it is necessary to check whether there is already an existing solution. The answer to this question could prevent people from reinventing things (such as the wheel) and/or from wasting time and resources because possible solution paths have already been evaluated.
While this sounds logical, one of the two major Knowledge Management barriers is already arising: the so-called “not invented here” phenomenon. Besides the possible problem that they are not aware of somebody else working in the same area, people ignore existing solutions, because of a lack of trust (maybe based on bad experiences). Reflecting on new findings, and/or the combination of existing knowledge and experiences, is another major part of this phase. Reflection should take place in “lessons learned” sessions during the project (as part of weekly Jours Fixes) or on a milestone-oriented basis, or at the end of a wider project debriefing session. A large selection of publications relating to the methodology of lessons learned are highlighted at the end of this paper.
The result of this project reflection might be knowledge assets and / or re-usable material. Both types include added value, because they follow certain templates, standards and formal criteria, such as classifications, and could easily be identified and re-used. The range stretches from simple templates (that have been created during a project) to very complex models (business model descriptions of a whole industry). (Exhibit 3)
Exhibit 3: The knowledge flow in a learning organization.
COLLABORATION
Another important driver for the establishment of knowledge sharing is the reduction of barriers within the team. Therefore, knowledge sharing within projects starts with collaboration within the project. Transparency about the status of the project concerned, a common base of knowledge about the customer requirements, or customer-specific decision making processes or a stakeholder landscape might be essential to the project's success.
On a global basis this requires a great deal of standardization. This standardization includes standardized project file structures and the provision of templates. To enable this collaboration, organization-wide multipliers have to be trained to support the operational projects.
While knowledge sharing on an organizational basis (discussed in the next chapter) has to follow centralized concepts, the provision of a collaboration base or platform is decentralized.
SHARING and ASSESSMENT of knowledge
The phase of SHARING and ASSESSMENT of knowledge is the second major milestone in this loop. Based on the reflection results provided, the so-called knowledge assets are made available to everybody in the organization or to specific groups only. These specific groups could be either special interest groups or Communities of Practice. The most important aspect is that the results are not limited to explicit knowledge, such as documentation and records, but that the method of sharing also allows pointers to the experts and competencies behind the documents. If for any reason (e.g. contractual, legal), full sharing is not suitable, it is important that, as a minimum requirement, a project overview – like a door sign – is created that shows some basic project information.
The content of the different knowledge domains is now stored in the technical basis of our holistic framework, which could be a document management system or a groupware solution. It is important that the storage is, itself, a challenging process, because the phase of USE is related to the fact that project team members identify the document as coming from possibly different contexts or being in different languages.
The ASSESSMENT of the content happens either via feedback form the people that have reused a document or Communities and / or by Corporate Functions that are responsible for a certain knowledge domain. While without this check, members of project teams still have to invest time in their own checks and validation of the documents they have found, after checking by a Community or corporate function, the documents are standardized, condensed and their quality improved, and perhaps packaged at standard or guideline level. They show the way to go.
URGENT REQUEST
The URGENT REQUEST is a very efficient instrument to create trust and to implement the loop already described. The urgent request works like an emergency call, but you do not have to know whom you should call. It is a market place (with electronic support) that people with the organization can use to ask questions, as they may already have searched the knowledge base or their personal network unsuccessfully. The questions might take the form “Who has done this or that before?”, “Do we have experience of…”, “Who know something about product xyz…?”. The answers are not 100% what the people looking for, but they indicate people within the organization with the required competence or experience. Once the market place is established and people have understood the benefit, the response time goes down to a couple of hours. Today in Siemens Business Services, 95% of all urgent requests are answered within one working day (8 hours). If people ask a question in the evening, the mechanism “follows the sun”, so that those returning to the office next morning have an answer from overseas colleagues at work during the period concerned.
To optimize the volume of questions, it is not necessary that all questions have be been read by everybody, but people can profile their interest areas and receive certain notifications by email or SMS (Short Message Service) that there might be a question they could answer, with people looking forward to check the system.
While the whole loop is subject to a chicken – egg phenomenon, the URGENT REQUEST is also ideal for getting started with the process, and allowing people to understand the benefit of knowledge sharing even with people they will never meet personally.
In many cases there is more than one answer to an urgent request; the set of answers might therefore also be a starting point for a Community of Interest or Practice.
Community of Practice
A Community of Practice or Interest is a group of persons who, based on a shared interest in a subject area of relevance to the business, exchange and develop knowledge and provide mutual support beyond the boundaries of organizational units. The participants pursue both individual and business goals through forms of cooperation that are not subject to any time constraints, and may be either virtual or face-to-face in nature. Communities of Practice affect the projects of an organization in different ways. (Exhibit 4)
A community of all project managers, or other specific roles within the project organization, is the clearest case of the application of the Community of Practice concept in the area of project management. If many projects are involved, e.g. standard software implementation such as SAP, the establishment of a SAP community will certainly make sense. In addition you will find communities of people in the same organizational role (commercial clerk) working in distributed organizations or firms.
Communities of practice and the question of “how to set them up” is another very important issue in Knowledge Management, but cannot be discussed here. See special literature references at the end of this paper.
It is most important to understand the role of Communities within the area of Project Management. While the role relating to the validation of content has been described before, another important role is to connect projects with the “outside” world, in many cases other projects or groups of experts outside the project. The benefit is that the project team can act as the interface between the entire organizational knowledge and the customer.
To establish trust in the organization is a major challenge that takes years, but to establish trust in a community can be achieved at short notice.
Exhibit 4: Logic of Communities of Practice
Cultural Issues
Besides the “not invented here” syndrome, the second important barrier might distilled in the claim “knowledge is power”.
The experiences of a project, incorporated in the person of the project manager or any individual project team member, might help to win the next assignment. This might be true at first glance, but is not if examined in greater detail. To share knowledge and experiences shows more competence than any experience, which is kept, confidential and treated as a secret. Any experience shared with the organization, or other projects team that prevents the organization from making the same mistake or misjudgement twice, empowers the organization.
Is any additional incentive necessary?
As in many chemical reactions, a catalyst may be helpful in getting started with the knowledge marketplace, because at the outset sharing knowledge means investing additional time, while taking into account that the marketplace is empty.
In the long run, any method that helps to control a project and reduce the project risks should be considered by the project members and their team. To avoid making the same mistake again, or to learn from others, saving time and budget, should definitely be part of the basic toolbox of successful project managers. And knowledge sharing should therefore be covered by the incentives of the project manager, which are related to the project's success.
Success factors
If you start thinking about the ideas of knowledge sharing, you will, at first glance, not find any logical barriers. Nevertheless, your colleagues will give you hundreds of excuses for not sharing. To implement a knowledge sharing program or to establish knowledge sharing in projects, is highly complex, and will require much longer than initially estimated. Therefore, it is important to start with a “friendly environment”, to create a pilot first, and to communicate the results. Success stories and real project successes (“I won that deal, because of…”) are the key for the success of your knowledge management story.
Based on these successes, a rollout can expand the Knowledge Management idea across the complete organization. It is important for knowledge sharing to become a natural activity rather than an extra action. The instruments or methods of Knowledge Management should subsequently be made mandatory by means of a guideline.
In addition to the discussion of incentives, it is also important to escalate situations in which project managers have obviously ignored existing solutions, as well as known risks and have made the same mistake again.
Conclusion
The goals of any Knowledge Management activity within or between projects are to:
- Optimize the project processes,
- Improve the efficiency, effectiveness and quality of all project participants,
- Reduce costs and risks,
- Improve customer satisfaction,
- Minimize internal transaction costs and interfaces,
- And avoid reinvention within projects.
All the arguments mentioned above could be used as key performance indicators for the implementation of Knowledge Management within your project environment.