Improving Knowledge in Projects

This post is an excerpt of a recent paper titled “Improving Knowledge in Projects.” If you’d like to read the full paper, click here for the PDF version of Improving Knowledge in Projects.

In the project management world, a considerable amount of research exists to describe the reasons behind the success or failure of projects in the information technology space. Most of this research focuses on failures being caused lack of executive sponsorship, lack of project management methods, lack of change management processes, project scope size and/or project duration (Reich, 2007).

While these causes of failure are quite common, a large and overlooked stumbling block that causes failure in IT projects is the lack of proper knowledge management methodologies throughout the project management lifecycle.

This paper provides a brief review of the literature within the knowledge management space, and more specifically, how to manage knowledge transfer, sharing and application in projects. The main question that is initially asked (but not really answered) in this paper is that following: Can a framework containing “best practices” be developed that can be use to improve knowledge transfer and sharing in project based groups and organizations?

Brief Literature Review
Although most project management methodologies claim to be interested in knowledge management, none offer any real guidelines or practices for gathering and maintaining knowledge throughout the project lifecycle.

Disterer (2002) argues that traditional project management methods are overly concerned with efficiency and effectiveness of project team members, which in turn makes the act of capturing knowledge a lower priority during a project (Disterer, 2002). This is compounded by the fact that the knowledge needs of future projects doesn’t lie within the context of the current project requirements therefore project managers and leaders do not focus on these efforts (Disterer, 2002).

Leseure & Brookes (2004) take this claim a step further by stating that knowledge transfer is one of the largest issues in projects today when they write “Knowledge is generated within one project and then lost. Failure to transfer this knowledge. leads to wasted activity and impaired project performance” (Leseure & Brookes, 2004, p. 103). Leseure & Brookes’ designed a research project that would attempt to benchmark knowledge management practices within projects to help provide a broader and more qualitative evidence of knowledge management methods in projects. The results of this research pointed to two main areas that could improve knowledge management in projects: collecting knowledge in projects; and managing tacit knowledge (Leseure & Brookes, 2004, p. 106). By focusing on these two areas, organizations can help to improve project knowledge management.

Kasvi, Vartiainen, & Hailikari (2003) performed research on how knowledge is managed in projects and what knowledge management capabilities are required for proper knowledge management in projects (Kasvi, Vartiainen, & Hailikari, 2003). The researchers used interviews to gather data on knowledge management capabilities and practices in various organizations. The results provided interesting feedback on organizational knowledge practices in projects and led the authors to observer that “knowledge management practices were weak and unsystematic” (Kasvi et al., 2003, p. 578) and that paper documents and interactions with colleagues were the most important sources of knowledge.

Research by Karlsen & Gottschalk (2004) addresses the factors that affect knowledge transfer in projects (Karlsen & Gottschalk, 2004). The authors used surveys to gather information from project managers and organizations on knowledge transfer in projects. The survey results showed that organizational culture plays a key role in knowledge transfer within projects and should be the main area that organizations focus when looking at knowledge transfer methodologies capabilities.

Research by Slaughter & Kirsch (2006) extends the concept of the importance of organizational design and culture on knowledge management with the introduction of Knowledge Transfer Portfolios. This research, which was conducted as a field study in the area of Software process improvements, provides some very interesting ideas on organizational design and knowledge transfer and outlines the following three items as being key for knowledge transfer within organizations: Proximity, Frequency of Interactions and Relationships (Slaughter & Kirsch, 2006).

The Framework

Blaize Horner Reich, an Associate Professor at Simon Fraser University and Visiting Associate at Templeton College, Oxford University has developed a framework for knowledge management within IT Projects which seems promising. This framework, published in the Project Management Institutes’s Project Management Journal in an article titled “Managing Knowledge and Learning in IT Projects: A Conceptual Framework and Guidelines for Practice“, proposes a three level model that addresses the following topics:

  • Describes what “knowledge management in IT projects” is
  • Provides a typology of critical IT project knowledge
  • Identifies the top ten knowledge-based risks found in IT projects. In addition, key principles for knowledge management in IT projects are provided for use in helping build strong knowledge management capabilities within IT projects.

Reich’s framework is a good place to start as it provides a model built upon sound principles and research in the IT project space.

The first ‘level’ in Reich’s framework defines IT Project knowledge management as:

Knowledge management in the context of a project is the application of principles and processes designed to make relevant knowledge available to the project team. Effective knowledge management facilitates the creation and integration of knowledge losses and fills knowledge gaps throughout the duration of the project (Reich, 2007, p. 8).

The second ‘level’ in Reich’s framework consists of a typology of IT Project knowledge. This typology contains four distinct types of knowledge: process, domain, institutional and cultural. A brief definition of these types of knowledge follows:

  • Process Knowledge: knowledge that project team members have regarding the project (tasks, methodologies, timelines, structure, etc) (Chan & Rosemann, 2001; Meehan & Richardson, 2002; Reich, 2007).
  • Domain Knowledge: knowledge that a project team or member has about the industry, technology, processes, current situation, business and products (Chan & Rosemann, 2001; Reich, 2007).
  • Institutional Knowledge: knowledge that a project team or member has about the organization (Reich, 2007).
  • Cultural Knowledge: knowledge about the organizational culture as well as cultural backgrounds of the project team members (Reich, 2007).

The third ‘level’ of Reich’s framework consists of knowledge-based risks in IT projects. The author has listed ten risks that can affect knowledge in IT projects. These risks are:

  • Lessons aren’t learned
  • Flawed team selection
  • Changes in the project leadership team
  • Lack of knowledge of project team roles
  • Poor knowledge integration
  • Poor knowledge transfer within projects
  • Changes in project team
  • Determining “who knows what” (knowledge maps)
  • Project team changes between phases
  • Failure to Learn

Building Upon Reich’s Framework

Using the knowledge contained within Reich’s framework, and knowledge generated during a literature review, the following seven topics must be considered as key pieces of this framework in order for it to address project knowledge management:

  • Continuous Learning / Lessons Learned - Ensures that all “lessons learned” are documented and shared throughout the organization and applied in future projects.
  • Organizational Design – Develops proper project teams to ensure that the necessary knowledge transfer mechanisms can be implemented per Slaughter & Kirsch’s (2006) research
  • Organizational Culture – Works toward building a culture that is pre-disposed to sharing knowledge.
  • Human Capital Management practices – Covers the human capital management aspects to ensure proper motivation for project teams.
  • Project Selection – Covers proper project selection as well as team member selection.
  • Risk Management – Covers the aspects of project risk management as well as knowledge-based risk management as described in Reich (2007).
  • Knowledge Typology Management – Covers the four types of knowledge outlined in Reich (2007) including Domain, Process, Institutional and Cultural Knowledge.

There is a considerable amount of research and thought that needs to be done to further develop this framework but an initial model can be found in Figure 1. This model provides a high-level overview of the areas that must be considered when developing project knowledge management practices.

Click for Figure 1: Project Knowledge Management Model

The model is separated into three “sections” plus feedback loops. The three sections are: Project Leadership, Project Teams and Projects. Each section contains the areas of focus for that particular project entity and outlines the areas of responsibility. A description of each section as well as the feedback loops follows.

  • Project Leadership – the project leadership section covers the higher level “strategic” aspects of project knowledge management and contains Organizational Design, Culture, Human Capital Management Practices, Project Selection and Management, Risk Management and Knowledge Management.
  • Project Teams – the project teams section covers the individualistic aspects of project knowledge management and contains the knowledge types (Domain, Process, Institutional and Cultural) as well as project management methods and processes.
  • Projects – the projects section contains the more “tactical” aspects of project knowledge management and includes Knowledge Transfer, Lessons Learned and Continuous Interaction.
  • Feedback Loops – In addition to the three sections, the model contains feedback loops that are used to ensure that continuous feedback is provided from each layer of the project knowledge management model. For example, project teams will continuously communicate with each other throughout projects regardless of which projects they are working on. Project Leadership will always be “kept in the loop” on all projects.

This framework provides an easy to recognize area of responsibility for the seven key topics that must be considered to ensure proper knowledge management in projects. As an example, let’s consider Slaughter & Kirsch’s (2006) research on Knowledge Transfer Portfolios. One of the key outputs of that research was to show that organizational design plays a key role in knowledge transfer. Using the model shown in figure 1, it is easy to see that organizational design lies solely on the shoulders of the organization’s leadership to consider.

There is still a considerable amount of research that needs to be completed in order to create supporting data to support this framework. Although not complete, the model does show areas in which organizations can begin to consider making changes to improve project knowledge management.

Conclusion
The extent of knowledge management in most project management methodologies begins and ends with the “lessons learned” document that is created after the completion of a project. This document is a good exercise, but doesn’t do much to manage knowledge during the project or ensure that knowledge is transferred between project members because project members must know to read the document to receive any value from it.

It is widely reported that project failure rates are still very high (Ahn, Joo, Cho, & Park, 2005; Owen, Burstein, & Mitchell, 2004; Pawlowski & Robey, 2004; Reich, 2007; Scarbrough, Bresnen, Edelman, Laurent, & et al., 2004). Industry research shows fifty to sixty percent of all projects are considered failures (IT-Cortex, 2007). While most research blames these failures on poor project management and/or lack of executive sponsorship (Reich, 2007), the fact that there is very little knowledge transfer and sharing between project teams has to play a key role in allowing these failures to occur.

By building a framework that can be used to help improve knowledge transfer within project teams, it is hoped that the failure rate due to knowledge-based issues will drop significantly. This framework, which still is the early development stages, should help organizations understand the underlying requirements for project knowledge management, provide best practices for knowledge management in projects and provide a way to build a corporate culture that is focused on sharing knowledge.

References

  • Ahn, H. J., Joo, L. H., Cho, K., & Park, S. J. (2005). Utilizing knowledge context in virtual collaborative work. Decision Support Systems, 39(4), 563.
  • Chan, R., & Rosemann, M. (2001). Managing knowledge in enterprise systems. Proceedings of the Americas Conference of Information Systems.
  • Disterer, G. (2002). Management of project knowledge and experiences. Journal of Knowledge Management, 6(5), 512.
  • IT-Cortex. (2007). Statistics over IT Failure Rate. Retrieved 3 May 2008, from http://www.it-cortex.com/Stat_Failure_Rate.htm
  • Karlsen, J. T., & Gottschalk, P. (2004). Factors Affecting Knowledge Transfer in IT Projects. Engineering Management Journal, 16(1), 3.
  • Kasvi, J. J. J., Vartiainen, M., & Hailikari, M. (2003). Managing knowledge and knowledge competences in projects and project organisations. International Journal of Project Management, 21(8), 571.
  • Leseure, M. J., & Brookes, N. J. (2004). Knowledge management benchmarks for project management. Journal of Knowledge Management, 8(1), 103.
  • Lytras, M. D., & Pouloudi, A. (2003). Project management as a knowledge management primer: The learning infrastructure in knowledge-intensive organizations: Projects as knowledge transformations and beyond. The Learning Organization, 10(4/5), 237.
  • Meehan, B., & Richardson, I. (2002). Identification of Software Process Knowledge Management. Software Process: Improvement and Practice, 7(2), 47-55.
  • Mitchell, V. L. (2006). Knowledge Integration and Information Technology Project Performance. MIS Quarterly, 30(4), 919.
  • Owen, J., Burstein, F., & Mitchell, S. (2004). Knowledge Reuse and Transfer in a Project Management Environment. Journal of Information Technology Cases and Applications, 6(4), 21.
  • Pawlowski, S. D., & Robey, D. (2004). Bridging User Organizations: Knowledge Brokering and the Work of Information Technology Professionals1. MIS Quarterly, 28(4), 645.
  • Reich, B. H. (2007). Managing Knowledge and Learning in It Projects: A Conceptual Framework and Guidelines for Practice. Project Management Journal, 38(2), 5.
  • Rice, M. P., Oconnor, G. C., & Pierantozzi, R. (2008). Implementing a Learning Plan to Counter Project Uncertainty. MIT Sloan Management Review, 49(2), 54.
  • Santhanam, R., Seligman, L., & Kang, D. (2007). Postimplementation Knowledge Transfers to Users and Information Technology Professionals. Journal of Management Information Systems, 24(1), 171-199.
  • Scarbrough, H., Bresnen, M., Edelman, L. F., Laurent, S., & et al. (2004). The Processes of Project-based Learning: An Exploratory Study. Management Learning, 35(4), 491.
  • Slaughter, S. A., & Kirsch, L. J. (2006). The Effectiveness of Knowledge Transfer Portfolios in Software Process Improvement: A Field Study. Information Systems Research, 17(3), 301.

  • Will Pearce

    This reminds me of a meeting that I held with two programmers during my long-ago tech documentation days. The purpose of the meeting was to clarify some points about the functioning of a particular piece of software that was being developed by our company. Both of the programmers were involved in the project and related to the specific areas I had questions about (their areas of responsibility were separate but interdependent).

    As the conversation progressed, it became apparent to me that I was getting contradictory answers. I pointed this out to the two programmers, being very specific in my analysis as to why they both could not be right. After I finished, the two looked at each other, looked at me, then excused themselves to go fix a problem they had caused but were totally unaware of–because they had never had any “boundary consistency” conversation between themselves.

    It’s sort of like the NASA Mars probe that crashed because one team programmed in metric and another programmed in English units, only we found our error before going “splat!”

  • Eric D. Brown

    Will – Thanks for the comment.

    Perfect example of knowledge sharing/transfer gone wrong in projects!

  • http://ravenyoung.spaces.live.com Raven

    Eric – more good stuff from “the intellectual PM”, a phrase I coined just for you! You’re writing is always top notch and really makes me think.

    Thanks for sharing more excellent insights!

  • Eric D. Brown

    Thanks! I appreciate the comment and compliment!

  • http://www.betterprojects.net Craig Brown

    Hey Eric
    Great post. Thanks for sharing.

    Craig

  • Pingback: Line Meets Curve » How is Commercial Construction Like Developing Software?()

  • mohan.d

    i wish to your comment.this is very useful to me because i dont know any project detail but now i want more detail in project.

    so if u have any free time free send your advice to my email id.

    thanking you

    mohan.d

  • Pingback: سیاره مدیریت پروژه فارسی » Blog Archive » Mining for knowledge in a social word()

%d bloggers like this: