Avoiding knowledge traps in project management
Blaize Horner Reich
Professor, Technology and Innovation Management
University of British Columbia Okanagan
Project managers working in the information technology (IT) field are engaged in a rather intense battle for self respect. Much of the value that we deliver to organizations is accomplished through projects, yet we often struggle to accomplish positive outcomes. History has shown us that it is a difficult quest to demonstrate the value generated from organizational spending on IT projects (Brynolfsson & Hitt 1998; Heller, 2000). According to a recent Standish Group study, IT projects have a 66% failure rate; such projects have either missed the targets or failed to deliver the required business functionality (Standish Group 2003). These failed IT projects are a major stumbling block to companies which are trying to innovate through new processes and services.
Other reports show that the rate of project success is increasing, caused perhaps by the recent proliferation of project management methods and by a heightened concentration on controlling project size and scope (Sauer, Gemino, & Reich, 2006). However, recent discussions with project managers have indicated that the goalposts are still moving: IT projects are becoming more ambitious, more organizationally complex, and more time-to-market focused. Despite the fact that an increasing number of organizations are adopting traditional project management methods, project professionals need new perspectives (Sauer & Reich, 2006).
Hirscheim and Klein (2003) suggest that research in information systems (IS) suffers from fragmentation, that it disconnects researchers and practitioners. My goal in writing this paper is to help connect the current theory with actual practice. In doing so, I propose a knowledge approach to studying and managing projects, one that may contribute to project management research and practice in three ways.
- To identify the unexamined knowledge-based risks that project managers routinely face
- To organize these risks into a holistic framework and categorize each type of knowledge-based risk
- To begin the process of finding solutions, both at the level of principle and of practice.
I identify ten places—called, collectively, Knowledge Traps—in a project where project managers can lose, misuse, or fail to create knowledge. I also propose five Knowledge Guidelines that project managers can use to both manage knowledge-based risk and create innovative, self-organizing project teams.
Focusing on Knowledge within a Project
Although many continuing organizations invest in attempts to create, codify, store, and re-use knowledge, there has not been much research or practice focus on knowledge management within the domain of projects. However, a project presents a difficult knowledge problem. Teams of strangers work together under time and budget constraints to produce a new product, process, or service. From this perspective, one might say that a project manager’s primary task is to manage the knowledge bases of the team members and stakeholders so that they combine in the best possible way to successfully accomplish their assignment.
Other reasons to support a knowledge approach are found in academic research. Three recent studies have shown that managing knowledge can add to the probability of project success.
- A survey of project team members and stakeholders working on 69 software development projects (Faraj & Sproull, 2000) found that by coordinating expertise, teams could improve their performance by 25% more than had they just used traditional project management practices.
- Yoo and Kanawattanachai (2001) tracked the progress of 38 virtual project teams and found that project success was strongly influenced by each team member’s knowledge of other team member’s areas of expertise and by the team’s ability to harness this knowledge to achieve the project’s goals.
- A recent study of 133 projects (Tiwana, Bharadwaj, & Sambamurthy, 2003) reported that the level of knowledge integration within the team was more important to project success than a pre-existing positive relationship between business and IT.
Although these studies present good evidence that knowledge and learning matters to project performance, the literature which examines the relationship between knowledge and project performance is diverse and fragmented (Reich, 2006). In this research, I use information from both the literature and a field study to create a holistic view of the ways that knowledge impacts the outcome of IT projects.
In related research, I have also examined the current professional practice standards of managing risk in projects. Our findings suggest that project managers currently lack the guidelines they need to successfully manage knowledge-based risk (Reich & Wee, 2004). In this research, I propose a process for tying knowledge issues to risk and suggest solutions to fit within the framework of existing risk management practice.
In conducting this research, I used a methodology comprised of five major steps. These steps are summarized in Exhibit 1 and discussed below.
Exhibit 1 - Steps in Research Methodology
Step 1: Literature Search
I reviewed the literature on managing IT projects, using a three-step approach.
- Research assistants searched the literature on IT project, using keywords such as project management, project, software development, and knowledge.
- I expanded this search to include the literature on organizational behavior and the keyword list to include terms such as teams and learning.
- I selected only those articles that discussed learning or knowledge within a project or team environment and limited the search to articles published prior to January 2004.
In using this approach, I found 43 articles to review. These articles involved four disciplines: project management (12 articles), learning in teams (8 articles), software engineering (6 articles), and MIS (Management Information Systems) (17 articles). I then wrote a working paper that reviews these articles (Reich, 2006).
Step 2: Model Building
I found several ways to aggregate the selected literature to reveal the overlaps between disciplines as well as to systemically develop and test common concepts and assumptions. Rosemann and Chan (2000) suggest three dimensions with which to examine knowledge management in projects: the system life cycle, the knowledge life cycle, and the knowledge content taxonomy. I chose the first option—the system life cycle—and generalized it using the model outlined in Arthur, De Fillippi, and Jones (2001).
I then developed a simple model to show where the application of knowledge could affect IT project success (Reich, 2004). This model mirrors the familiar Input-Process-Output model commonly discussed in IS development literature. For example, a project’s knowledge inputs include people, methodologies, and lessons learned from other projects. A project’s process involves a governance element and four typical project phases: plan, design, build/configure, and implement. A project’s output is the handover of the project/system to the client/users as well as wrapping up the project. Superimposed on this model are ten traps that the research literature identifies. Each of these traps represents a stage in the project where knowledge is unavailable, lost, or simply not created.
Step 3: Taking the Model on Tour
During this step, I took the model and the literature review on-tour. This enabled me both to gauge the interest it generated among academics and to test its salience with project managers. I spoke at conferences (e.g., PICMET (Portland International Center for Management of Engineering and Technology), IPMA (International Project Management Association), to PMI audiences in Canada and New Zealand and to CIOs. These discussions generated ideas that I added to the model. I found that general support was strong, with many project managers suggesting that they routinely faced knowledge-based risks but lacked a formal process for acknowledging or mitigating these risks.
Step 4: Data Gathering
Using the initial Knowledge Trap model, I designed an interview guideline and assembled a group of senior project managers that I then interviewed. The search for interview participants was focused on finding project managers who were interested in knowledge and learning and who had developed practices around these topics. Some participants referred me to other potential participants. I also asked for volunteers among the various PMI communities I had previously worked with. In all, I interviewed 15 senior project managers: These individuals—working in either North America or New Zealand—were employed by either for-profit organizations or government departments. Some were in-house project managers, others consultants. The interview focused on four areas:
- Their unprompted ideas about knowledge management within a project.
- Their experiences in resolving each of the 10 knowledge traps.
- Their suggestions for making additions/changes to the model.
- Other knowledge-based challenges they have confronted in managing each of the project life cycle stages.
Step 5: Analysis
I qualitatively analyzed the interviews, using Atlas.ti software to facilitate the evaluation and the interview questions to structure the assessment. The data confirmed that the traps do exist. This information allowed me to also see that each trap posed different levels of project risk. I summarized the common concepts and solutions deployed and found that the original Knowledge Trap model, as derived from the literature, only needed minor modifications. Below I outline the enhanced Knowledge Trap model and guidelines for implementing it.
What is Knowledge Management?
This research identified that there is a lack of common understanding about what knowledge management means within a project context. Some interviewees focused on explicit knowledge and various ways to store and distribute such artifacts as project web sites and common folders. Many mentioned Lessons Learned as the way they grounded the concept of knowledge management. Others understood knowledge management as a more complex concept, ranging from efficiently using experts tacit knowledge to actively planning a project team’s knowledge needs.
From the interviews, I found evidence to support the idea that some project managers do consider their team as an accumulation of knowledge capital (Arthur et al., 2001), but the participants reported difficulty in harnessing this capital because they lacked a systematic knowledge-based methodology. From research in both knowledge management and project management, I propose the following definition:
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 creates and integrates knowledge, minimizes knowledge losses and fills knowledge gaps throughout the duration of the project.
The next section outlines the knowledge traps and uses quotes from our interviewees to illustrate the issues they face.
I use the term Knowledge Trap to identify those times or events within an IT project in which there is a loss of project-specific knowledge (Schindler & Eppler, 2003), where the project lacks some relevant knowledge, or where knowledge is not created or applied optimally.
My interviews confirmed that many accomplished project managers know intuitively about the knowledge traps detailed in this article. One participant explained it this way: “I would say we saw all kind(s) of instances where knowledge caused challenges, and the challenges typically manifested themselves in a piece of functionality being developed, which totally missed the mark of what it should have delivered. In some cases, at the technical level, we’d … develop a piece of code which basically didn’t work.” Another project manager noted that knowledge issues had caused problems on almost every single project she had worked on.
It was difficult to get respondents to quantify the impact of knowledge traps since many had not explicitly considered this impact before our interview. The final interviewee, however, estimated that in his recent (US)$60 million project, knowledge issues added about 10% to the final cost.
Figure 1 illustrates the four parts of my Knowledge Traps model.
- Inputs: A project’s knowledge inputs
- Process: A project’s governance
- Process: A project’s operational phases—plan, design, build/configuration, and implementation.
- Outputs: A project’s delivery and its closeout.
Fig 1. Knowledge Traps in IT Projects
There are two main knowledge risks at the beginning of a project: the failure to access information and learn from past projects as well as the failure to meet the project’s knowledge needs during team selection.
Trap #1: Lessons learned
Project teams often contain individuals from many different organizations and units. These professionals may or may not have attempted a project similar to the one they are about to start. Without access to lessons learned from comparable projects, the team will lack both important knowledge of the project’s risks and the opportunity to share information about the ways these risks could impact the project’s plan and targets.
While Kotnour (1999) concluded that lessons learned are conducive to learning within and across projects, my research confirms other research showing that many organizations continue to fail to learn from projects (Thomas & Tjader, 2000).
In the study sample, most participants reported that they did not systematically use the lessons learned from prior projects. Most participants said something similar to “We normally are so anxious about getting the thing going that we just do whatever seems to come to hand.” Because everyone felt pressure imposed by time constraints, they put their emphasis on go-forward activities and did not take the time to look reflectively back into their shared history. However, when asked about the potential impact of learning from past projects, one interviewee suggested that his most recent project would have seen “a 10 to 15% change.”
Trap #2: Team selection
Finding the right team members is important since the project manager will want all relevant knowledge areas included in the team or available to the team when they need it. Of the project managers I interviewed, all reported thinking about the knowledge and the skills they needed for each project. Some had very systematic ways to document these needs.
They noted, however, that problems arose when they lacked influence over team selection. Also, knowledge profiles of team members were often not available during the selection process. As one senior project manager reported that he knew what he needed, but “identifying the resources to meet those skill sets was a whole different ballgame.”
When the team selection process is flawed, the project manager won’t know what the team knows collectively or more importantly, what it doesn’t know.
Project Governance Processes
Project governance is the responsibility of several key positions: executive sponsor, project champion, project manager, and project steering committee. From a knowledge perspective, effective project governance involves two issues—volatility and role understanding.
Trap #3: Volatility in the governance team
After a project begins and the governance structures are put in place, there is a gradual knowledge building process among the key stakeholders. This knowledge trap refers to the loss of any member of the governance structure who controls or influences project resources and direction. Whether moving a project manager or other executive away from a project is done for strategic reasons or whether it is totally unplanned, there is a knowledge loss which may cause targets to be missed and benefits to go unrealized. Empirical research shows that a change of project manager is the most important governance volatility issue affecting project performance (Sauer et al., 2006).
One respondent estimated that on his most recent project, losing the project sponsor “probably delayed the project by a year.” Another respondent, commenting on the loss of a project manager, said, “If we had given whatever we could, reasonably, to bring this person back, even half a year’s salary or bonuses or whatever, it would have been worthwhile. At the end of the day, the cost, I believe, is proportionate to the stakes that we were managing.”
Trap #4: Lack of role knowledge among the governance team
Gaps in project-governance knowledge endanger the success of projects. When senior executives assume the roles of project sponsor or project champion, they do so because the outcome of the project is important—to them and to their organization. Although many researchers acknowledge that there is a difference between managing the static nature of business operations and the dynamic state of projects, organizations frequently neglect to provide their executives with the training they need to function as project sponsors and project champions.
A first-time project sponsor may not know when to support the project and when to tighten up the reins, may fail to differentiate between those project problems that are serious and those that are temporal. One interviewee recognized this by noting, “They don’t know [that] …if they do not make a decision, they are wasting a hundred thousand dollars [as] things churn for another week.”
One of the key problems that emerged from the interviews was the difficulty project managers have when attempting to “educate” a project sponsor since they possess very different levels of authority and power within the organization. A related issue may well be the difficulty a project sponsor has in admitting that they need additional training or that they do not know how to oversee a project.
Project Processes—Plan, Design, Build, and Implement
Within the main body of an IT project are five knowledge traps: knowledge integration, knowledge transfer, loss of team members, lack of a knowledge map, and loss between phases.
Trap #5: Knowledge integration
Huang and Newell (2003) examined the issues that project managers face when integrating knowledge in cross-functional team environments. In interviews, participants confirmed that for a project which is building a custom application, knowledge integration between users and analysts as well as between team members is critical for achieving a successful outcome.
The participants talked about the several dimensions involved in this issue. One noted a project team problem: “How the team feeds information amongst themselves. Especially in a huge project in a larger organization, invariably what happens is one team over here starts to solve a problem that another team is already solving.”
Another project manager noted the challenge of integration at his level: “It’s all about the transfer of knowledge from them to me. If they can’t illustrate, in some way, how that works, then I can’t get it in my mind and make decisions that are good for the company.”
Another noted the issue of between-team understanding: “You create all these specifications up front…but specification is language. I have to translate it into words and then some other dude is going read my words and is going to say, yes I agree with you. And then we go away, and we are developing and then …after a year we come back together and of course it is not the same interpretation.”
Trap #6: Knowledge transfer
Within a project which is implementing packaged software or new hardware, knowledge transfer from vendor or consultant to the internal project members is critical. Many researchers have explored this area and documented their findings in the wider project and innovation literatures.
The project managers I interviewed noted a conflict of interest that results when clients ask vendors to transfer knowledge. For most vendors, their intellectual property represents a future revenue stream and they are reluctant to sell it, even if they could determine a price. One participant explained it this way: “The last project we worked on, one of the things that needed to be planned for was continuity, in terms of what happens when the contracted services come to an end. If the incumbent vendor is not re-appointed, then how do they transfer knowledge to a competitor - that’s always a touchy subject for an outgoing vendor.”
In general, the participants recognized misaligned goals as a troubling project problem. Although as project managers they could see both sides of the issue, they often needed to obtain more control over the vendor’s intellectual property in order to fully understand and manage the project. Another issue they noted involved measuring the knowledge transfer. Although project managers may include in the project plan activities to support knowledge transfer, they often have no objective way to measure how effectively these activities were performed.
Trap #7: Exit of team members
Although project managers in general understand that losing key team members results in knowledge gaps, they often fail to create a plan to mitigate such losses. As one respondent noted about her planning: “It’s very reactive, and when somebody is leaving, then you kind of put a plan in place to keep him a little bit longer, or coach somebody, or whatever.”
Experience teaches that the longer the project, the greater is the risk that key people will leave through planned and unplanned events. One participant noted that on a project lasting more than three years, he lost more than 100% of the project team complement. “We tried to reduce the impact for scheduled moves, we tried to do a shadow activity for a few weeks, or a few days, or sometimes no days. The less time we had to shadow, the worse the outcome was.” To train new team members, this project manager relied on archived documents. “The methodology had a simple filing method, which helped to store documents. But they were of uneven quality and currency. People were fighting to find the material.”
Trap #8: Lack of a knowledge map
IT project managers and team members make a multitude of interrelated decisions. The more difficult the domain problems are, the more important it is that team members possess a knowledge map—information on the knowledge within the team (i.e. who knows what) and the knowledge available to the team—that enables them to address complex problems efficiently and effectively.
In their qualitative study, Crowston and Kammerer (1998) studied a group of requirements engineers to find out how they created requirements that were complete, accurate, and consistent. By using theories of transactive memory (Wenger, 1987) and collective mind (Weick & Roberts, 1993), they were able to explain their findings. Faraj and Sproull (2000) provided quantitative support for Crowston and Kammerer’s findings using expertise coordination theory. Put in layperson’s language, these studies suggest that creating a knowledge map and a knowledge network within a project team may prove more effective than focusing on knowledge integration. In a survey-based study, our interviewees agreed that this knowledge trap was important. One project manager said that he wants a methodology “that would identify who knows what and make a mental map of the team.”
Trap #9: Loss between phases
Because team composition often changes from phase to phase in IT projects, there is a significant risk that the knowledge generated by one phase will be inadequately transmitted to the next phase. Traditional methods of documentation—models, state diagrams, and use cases—rarely capture the “why” of design choices. As the next team interprets these artifacts, they may introduce errors into the project or slow it down trying to understand the meaning of previous decisions. This problem is exacerbated in long projects and within virtual project teams.
As one project manager noted: “There is always the arch from analysis to design. A touch of magic, and this analysis becomes that design. That’s an ongoing thing. I just … had this big confrontation about how the analyst thought that the people were going off and designing something that has nothing to do with the requirements, and the designers thought that the analysts weren’t talking to them.”
The most important knowledge risk at the end of the project is one that many participants said topped their list – that lessons learned are rarely satisfactorily captured.
Trap #10: Failure to learn
As organizations become more reliant on projects for transformation and renewal, the outcome of a particular project may be less important that an overall increase in the future ability of an organization to implement projects successfully. An incomplete debriefing during and at the end of a project leaves team members with a fragmented idea of what was learned and why things went wrong or right. When project managers fail to capture lessons learned, they prevent team-level learning and hinder opportunities to improve organizational competency in managing and completing projects.
Besides the time pressure identified by Kegan and Turner (2001), my research found cultural reasons causing the lack of lessons learned activity. One project manager explained it this way: “I’ve never worked in an environment where they are interested [in lessons learned] or where it is a safe environment.”
Knowledge Principles and Practices
Projects will differ in their need for knowledge-based management risk management. Projects in which 1) the future state of the organization is clearly documented, 2) a low level of innovation is required and 3) there will be a stable governance and project team, may be successful by focusing on traditional project management – managing scope, time, and cost. However, when the organization or project is undergoing significant change, principles and practices of knowledge management become important.
By examining information obtained from my review of the research literature and interviews with the participating project managers, I identified five broad principles of knowledge management within projects. These principles relate to a climate for learning, knowledge levels, knowledge channels, team memory, and knowledge risks. These principles are preliminary – more research and empirical testing is needed to determine their importance and impact. Each is discussed below.
Establish a Learning Climate
Realizing this principle requires a significant change for most organizations. The project manager needs to establish a climate of trust, where it is safe to make mistakes, where sharing knowledge is the norm and helping others is promoted. My research findings echo the findings of De Souza (2003), who warned against an over-reliance on technology without building a climate that supports knowledge sharing and provides incentives. This nurturing and safe climate is essential for implementing even simple activities such as collecting accurate and meaningful lessons learned. It is a critical part of project-based learning. One interview participant noted “it is a rarity that any organization learns anything from projects themselves.”
Creating a learning climate can be more difficult in a project team environment than in a permanent organizational unit. Project-based knowledge-sharing is limited by pressures of time, conflicts of interest, and hierarchical project structures. The goal is to create a project climate of learning together, one that cuts across the individual norms and practices that accompany project members from different organizations and disciplines. My research suggests that the project team should develop processes to share, generate, and integrate knowledge and that from these processes, the team should create a body of collective project learning (Fong, 2003).
To build a climate for learning, project managers can implement five practices suggested by our respondents:
- Engage the team when you build a risk register, and encourage team members to identify the lessons they learned from their previous projects. This early knowledge-sharing technique can set the tone for a project that recognizes risks and does not seek to ignore them.
- Communicate that mistakes are a natural part of the team’s growth and learning.
- Practice using desired team behaviors on minor issues. This provides team members with the opportunity to refine creative and supportive behaviors before a big issue emerges.
- Speak the truth.
- Reward behavior that supports a learning climate, not just behavior that results in the right answer.
One interview participant explained an approach to implementing this concept: “Instead of rewarding the creator of a cool and smart design, reward the person who spent a couple of hours; even though he didn’t know the area, helping someone else solve a problem. That is rewarding the desired behavior. That’s pretty powerful.”
Establish and Maintain Knowledge Levels
At the beginning of the project, the project manager identifies the skills and experience that s/he will need on the team or available to the team. Most project managers will select individuals they have successfully worked with in the past. Some will select individuals with extensive networks as a means to access external knowledge.
Once the team is selected, the project manager will need to fill the remaining knowledge gaps by making project methodology and domain knowledge available to the team. This can be done individually or collectively, through training courses or workshops or joint tasks, but it should be done systematically.
When team members leave the project, the knowledge that they brought to the team and the knowledge they accumulated while working on the project is potentially lost to the team. To prevent such loss, the project manager must anticipate and fill knowledge gaps.
From interviews, I found five practices that can prevent knowledge loss.
- Back up or duplicate key roles: Explicit role shadowing—or understudying—helps junior people acquire senior-level skills.
- Use Swiss-army-type team members” These individuals can perform a multitude of roles throughout the project’s life cycle.
- Use a core team that stays together throughout the project.
- Use retention bonuses and/or opportunities for learning to entice team members to stay on the project.
- Delegate work and responsibility downward to diffuse knowledge across the team: This prevents a knowledge bottleneck.
One interview participant had this to say: “For leadership positions where key decisions have to be made, have a backup for the team member. The backups have to be qualified enough to be able to make decisions … should that person not be around.”
Another added: “Ideally, the majority of people who we used through the phases were the people who were in the previous phase and basically we would keep key core team players in pretty much every stream through design, build, test, and implement.”
Create Channels for Knowledge Flow
The project manager needs to establish channels which encourage sharing of knowledge to benefit the project. Channels can be created that serve varied purposes – for example, channels to bring knowledge to the team from outside, channels to create communities of practice within disciplinary groups, channels between disciplines and between organizational units, channels between phases of the project and between levels of authority. Each project will have its own unique challenges that require differential need for channels.
There are many ways and places to share knowledge: web sites, repositories, team meetings, industry associations, brainstorming sessions, and visiting experts are examples. The important issue for the project manager is to deliberately and systematically create channels that are interactive, easy to activate, and effective.
A benefit of using active knowledge channels is that these help project teams solve tough problems quickly while avoiding the dangers of “group think” about a key issue. I suggest establishing such channels early in the project. Used in conjunction with other principles of knowledge management, the the project team can become self-organizing and effective in finding, creating, and transferring the knowledge required to accomplish project goals.
From our interviewees, we learned how some project managers create knowledge channels. In general, many project managers used informal socialization among team members as a way to enhance team knowledge sharing (Fernie, Green, Weller, & Newcombe, 2003). Another broad tactic was to increase the frequency but shorten the duration of team meetings when the project is under a lot of pressure. Some specific practices included:
- Co-locate team members.
- Design open office spaces so team members are encouraged to communicate.
- Establish lunch-and-learn sessions.
- Encourage informal gatherings.
- Develop a team newsletter listing both project and social information.
- Conduct daily, 15-minute huddle sessions, where key team members meet during crucial project periods to share knowledge on key issues and suggest solutions.
- Assign project knowledge connectors: These individuals know where the expert knowledge resides and can point the team in the right direction when a knowledge need arises
One interview participant explained that: “at start-up time, I established the life lines that we are going to need. These are virtual people I know out there, that I could bring in if we get into trouble.”
Develop Team Memory
One of the most important resources a team has is the content of its collective memory. Some of this shared memory takes the form of stories and experiences; some involves more explicit lists and lessons. Creating and updating shared memory is an important team activity at the beginning, during and at the end of the project.
When starting a project, the project team should gather to discuss the lessons they learned from similar projects. Everyone will learn something different during these sessions, but the result should be a shared understanding of how (and why) the current project will be designed and managed.
During the project, as key decisions are made, team members need to be kept informed about progress and about outstanding problems, both in the project process and the project domain. Updates to the project design need to be documented so that follow on steps and phases have the benefit of the rationale. Changes in key constraints, goals, and assumptions need to be shared by all stakeholders who might be affected.
After delivering the project, project teams capture the lessons learned for two purposes:
- To give individuals the opportunity to provide input, listen to others, and through this process to increase their learning and their competency as project members
- To create a shared story about the project, enabling learning to be aggregated into a whole, providing some closure and organizational learning for the team and the organization.
- To pass these lessons learned to other project teams to help them meet their goals more efficiently and effectively.
The interview participants use the following practices to support the building of team memory:
- Capture lessons learned throughout the course of the project – don’t wait until the end. Doing so enables project managers to integrate the knowledge and experience of those team members who will leave the team before it ends. By widely and openly discussing lessons learned, project managers can reinforce their commitment to knowledge sharing (i.e. the climate for learning) and capture more reliable knowledge than they could via post-project meetings.
- Use journals to record decisions made and the reasons behind these decisions. This technique creates a document or set of documents that helps project managers brief new team members and governance members. Project managers must ensure that journals are widely available and current.
- Assign a project knowledge integrator, someone who formally manages and integrates project knowledge. This is a more senior role than the project administrator, but could be used as a learning vehicle for a person in this role.
One interview participant said that “[I create] a record over the life cycle of the project. I call it a State of the Nation document and it gives kind of a historical record of the project. I use it also as an instrument for bringing new people on board. I’ve encouraged teams and clients to do it more because sponsors change, and everybody forgets who made what decision.”
Use the Risk Register
Although senior project managers are familiar with many of the traps identified in this research, they lack an established methodology for managing or mitigating them. My suggestion is to conceptualize the most important knowledge traps for a particular project as risks. By presenting knowledge traps as risks, a project manager can explicitly place them within the risk register, bring them to the attention of the project sponsor or steering committee, and put in place plans to monitor and control them. This suggestion to use the risk register as a focal point to mitigate knowledge traps is based on information obtained from the interview participants, several of whom have put a high priority risk (e.g. the risk of key vendor personnel being unavailable when needed) in the register and obtained the money needed to mitigate this risk.
These risks are different than risks normally found in a risk register because they focus on internal team resources, not external events. This research suggests, however, that protecting key project team members and their accumulated project knowledge is just as important as protecting the project against exogenous shocks. Our general recommendation is that project managers look for ways to include knowledge risks into the project risk register and into the project plan; to establish contingencies and secure resources.
Our participants identified several practices around the use of a risk register for knowledge based risks:
- Integrate lessons learned from earlier projects and use this information to build the risk register. Project managers can accomplish this from within the team and by using outsiders who have completed similar projects.
- Anticipate the departures of key team members and put resources in place for seconding and training successors.
- Identify key knowledge gaps in the team and put resources in place for external assistance. The same principle can be used for key knowledge transfer requirements.
- If the team is not co-located, the risk is that they will not create shared knowledge around goals, constraints etc. Build events and processes into the plan to mitigate this risk
One interview participant explained that: “With the vendor, we were very aware of this knowledge management risk. So what we paid the vendor to have an understudy. That was done within the risk management part of the project.”
In this research, I outlined a model comprised of 10 knowledge traps common to IT projects. These traps are grounded in the literature and supported by interview with 15 senior project managers. From this data, I developed five Knowledge Principles along with a set of associated practices.
While this research is in its early stages and requires further elaboration and validation, it is my hope to begin a comprehensive dialogue about the effect of knowledge and learning on project success and the ways in which project managers can mitigate knowledge-based risks.
Arthur, M., De Fillippi, R., & Jones, C. (2001). Project-based learning as the interplay of career and company non-financial capital. Management Learning, 32(1), 97 – 117.
Brynolfsson, E., & Hitt, L. (1998). Beyond the productivity paradox. Communications of the ACM, 41(8), 49 – 55.
Crowston, K., & Kammerer, E. E. (1998). Coordination and collective mind in software requirements development. IBM Systems Journal, 37(2), 227 – 246.
Desouza, K. C. (2003). Barriers to effective use of knowledge management systems in software engineering. Communications of the ACM, 46(1), 99 – 101.
Faraj, S., & Sproull, L. (2000). Coordinating expertise in software development teams. Management Science, 46(12), 1554 – 1568.
Fernie, S., Green, S. D., Weller, S. J., & Newcombe, R. (2003). Knowledge sharing-context confusion and controversy. International Journal of Project Management, 21(3), 177 – 187.
Fong, P. S. W. (2003). Knowledge creation in multidisciplinary project teams: An empirical study of the processes and their dynamic interrelationships. International Journal of Project Management, 21, 479 – 486.
Heller, M. (2000, December). The ROI of IT. CIO Executive Research Center. Retrieved from http://www.cio.com/research/executive/edit/value.html
Hirscheim, R., & Klein, H. (2003). Crisis in the IS field? A critical reflection on the state of the discipline. Journal of the Association of Information Systems, 4(5), 237 – 293.
Huang, J. C., & Newell, S. (2003). Knowledge integration processes and dynamics within the context of cross-functional projects. International Journal of Project Management, 21(3), 167 – 176.
Keegan, A., & Turner, R. (2001). Quantity versus quality in project-based learning practices. Management Learning, 32(1), 77 – 98.
Kotnour, T. (1999). A learning framework for project management. Project Management Journal, 30(2), 32 – 38.
Reich, B. H. (2004, November – December). Knowledge “traps” in IT projects. Project Management World Today. Retrieved from http://pmforum.org/library/papers/2004/1112papers.htm#02
Reich, B. H. (2006). Managing knowledge within IT projects: A review of current literature and directions for future research. Manuscript in preparation.
Reich, B. H., & Wee, S. Y. (2004). Searching for knowledge management practices in PMBOK. Paper presented at the PMI Research Conference 2004, London.
Rosemann, M., & Chan, R. (2000). Structuring and modeling knowledge in the context of ERP. Proceedings of the PACIS (Pacific Asia Conference on Information Systems) 2000 Conference, Hong Kong, 623-640.
Sauer, C., Gemino, A., & Reich, B. H. (2006). Managing projects for success: The impact of size and volatility on IT project performance. Manuscript in preparation.
Sauer, C., & Reich, B. H. (2006). From process to value - The changing face of IT project management. Manuscript in preparation.
Schindler, M., & Eppler, M. J. (2003). Harvesting project knowledge: Review of project learning methods and success factors. International Journal of Project Management, 21(3), 219 – 228.
Standish Group. (2003, March 25). Latest Standish Group CHAOS Report shows project success rates have improved by 50% [Press release]. West Yarmouth, MA.http://www.standishgroup.com/press/article.php?id=2
Thomas, J. L., & Tjader, J. (2000). On learning and control - Competing paradigms or co-existing requirements for managing projects in ambiguous situations. Paper presented at the 4th Biannual Conference, International Research Network on Organizing by Projects. Australia.
Tiwana, A., Bharadwaj, A., & Sambamurthy V. (2003). The antecedents of IS development capability: A knowledge integration perspective. Proceedings of the 24th International Conference on Information Systems. Seattle, WA, USA, 246-258.
Wegner, D. M. (1987). Transactive memory: A contemporary analysis of the group mind. In B. Mullen & G. R. Goethals (Eds.), Theories of group behavior (pp. 185 – 208). New York. Springer-Verlag.
Weick, K. E., & Roberts, K. H. (1993). Collective mind in organizations: Heedful interrelating on flight decks. Administrative Science Quarterly, 38(2), 357 – 381.
Yoo, Y., & Kanawattanachai, P. (2001). Developments of transactive memory systems and collective mind in virtual teams. The International Journal of Organizational Analysis, 9(2), 187 – 208.
©2006 Project Management Institute