Modeling the knowledge perspective of IT projects

Faculty of Business Administration, Simon Fraser University, Vancouver Canada

CHRIS SAUER, PHD

Saïd Business School, Oxford University, Oxford, UK.

Introduction

IT projects often enable organizational change. Therefore, successfully implementing an IT-enabled change is crucial for organizational success. IT projects consume a large share of organizational capital expenditure and have been undertaken for over 40 years. While researchers and practitioners have reported various levels of IT project performance (Jørgensen & Moløkken-Østvold, 2006; Sauer, Gemino, & Reich, 2007; Standish Group, 1994), it can be argued that IT projects are usually delivered over budget and past deadline. More troubling though is the perception that IT-enabled change does not generate the organizational value that is anticipated (Brynolfsson & Hitt, 1998; Roach, 1989).

Much of the research over the past 20 years on IT projects has focused on identifying and managing the risk factors that are inherent in implementing these projects. Some of these identified risk factors include size, complexity, organizational support, use of methodologies and change management. Prescriptions for achieving project success focus on the behaviors of project managers and project sponsors and encourage them to manage change, engage more fully, use methodologies carefully, and govern wisely. This advice seems to have been heeded, and project success has improved somewhat over the past decade (Hartmann, 2006; Standish Group, 1994). This research perspective considers an IT project as an arena in which action is paramount and in which tasks, budgets, people, and schedules must be managed and controlled to achieve expected results. This is a useful view, as it encourages the project manager to scope work, manage time and budget, and monitor progress.

Another perspective that is gaining momentum views a project as place in which learning and knowledge is paramount. In this view, projects function as conduits for knowledge which enters through people, methodologies, and prior learning. During the project, knowledge must be transferred, integrated, created, and exploited to create new organizational value. Learning and teaching are occurring at every level of the project: the executive sponsor, the project manager, and the business and technical teams. During the project, knowledge is created and knowledge can be lost.

Within an IT project, this focus on knowledge yields new insights because IT projects are primarily knowledge work. Furthermore, today's IT projects are often more about the integration of systems than the construction of software. In this environment, the project manager's primary task is to combine multiple sources of knowledge about technologies and business processes to create organizational value.

These and other views of the IT project are complementary. Each brings insights into the factors that impact project performance. In this article, however, we focus only on the knowledge perspective, leaving aside other views. We also bring together the empirical literature which has investigated the impact of knowledge perspectives on IT project performance and suggest a temporal model of this perspective.

In the first section of this paper, we examine the knowledge-based view of an IT project and suggest definitions and a typology of knowledge. Then we use the Knowledge Risks model (Reich, 2007) as a framework within which to collect and examine the empirical data which supports the knowledge-based view of an IT project. In the long term, with additional data, we should be able to refine the model, so it can be more parsimonious and focus only those areas of major importance to project outcomes.

In this paper's third section, we consider the problem of modeling knowledge and learning within IT projects. We start with the Temporal Model of IT Project Performance (Gemino, Reich, & Sauer, 2008) because it has elements of knowledge embedded in it. We also discuss the evidence showing how its knowledge-based constructs and subconstructs are influential.

We end by proposing a preliminary model of the knowledge perspective of an IT project. This stream of work is at its early stages. We hope that this presentation will convince researchers that further investigation into knowledge and learning within projects is warranted because it has the potential to impact both the theory and the performance of IT projects.

A Knowledge-Based View of IT Projects

Many research projects have investigated aspects of knowledge and learning in projects. (See Reich [2004] for a review.) This research emanates from a variety of sources, including software engineering, project management, management information systems, and organizational learning disciplines. This research is fragmented at present, with little convergence on constructs, measures, and models of learning. Most studies focus on a single aspect of knowledge management (Reich, 2004), such as integration, transfer, lessons learned, or knowledge systems.

Although research into knowledge and learning in projects is at an early stage, a model has been proposed which attempts to provide a repository for all of the existing work (Reich, 2007). This model of knowledge-based risks in IT projects suggests that there are 10 areas of risk occurring within an IT project's four parts: inputs, processes, outputs, and governance structure. The model was generated from previous research and has been supported by indepth interviews with project managers in North America and New Zealand. It remains largely conceptual at this point. However, research studies over the past decade have shown support for different elements of it.

In this section, we briefly introduce the conceptual Framework of Knowledge and Learning in IT Projects. Then, we show the empirical support for elements in this model.

The conceptual framework for the knowledge and learning perspective within IT Projects contains three parts:

  • A typology of knowledge that is critical to IT project success
  • A definition of knowledge management in the context of IT projects
  • A model that identifies the knowledge-based risks in an IT project.

What Kinds of Knowledge need to be Managed?

Reich (2007) proposes that four kinds of knowledge are important within IT projects. Much of the research on knowledge and learning in projects has focused on the first two types—process knowledge and domain knowledge. This emphasis will be reflected in the empirical evidence shown later in this article.

The first type of knowledge—process knowledge—is the knowledge that team members and sponsors have about the project structure, methodology, tasks, and time frames (Chan & Rosemann, 2001; Meehan & Richardson, 2002).

The second type of knowledge is domain knowledge, the knowledge of the industry, firm, current situation, problem/opportunity, and potential solutions (including technology and business process). This knowledge encompasses three types of knowledge identified in Chan and Rosemann (2001): business, technical, and product knowledge. Domain knowledge is spread widely within and outside the project team. The project sponsor may be the most knowledgeable about the industry and the problem or opportunity being addressed. Technical experts inside and outside the company have knowledge about the technologies that could be brought to bear. Project members will have deep knowledge about the company and its business processes. Many researchers have discussed domain knowledge as it relates to the issues of knowledge integration (Majchrzak & Beath, 2003; Nelson & Cooprider, 1996; Walz, Elam, & Curtis, 1993) and coordination (Crowston & Kammerer, 1998; Faraj & Sproull, 2000) as well as learning (Stein & Vandenbosch, 1996), and project governance (Henry, Kirsch, & Sambamurthy, 2003).

There are also two other kinds of knowledge. The third is institutional knowledge. This knowledge is a mix of an organization's history, power structure, and values; this knowledge is transferred via stories or anecdotes by organizational insiders and observers. The fourth kind of knowledge necessary in an IT project is cultural knowledge. This is the knowledge that project managers need to lead teams comprised of individuals from differing disciplines and cultures.

What is Knowledge Management in IT Projects?

We developed the following definition from our prior research into knowledge and learning within IT projects. It emphasizes the temporary nature of knowledge (i.e., knowledge loss) and the need to create and integrate the knowledge from different sources.

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, minimizes knowledge losses, and fills knowledge gaps throughout the duration of the project.

What Knowledge-Based Risks exist in IT Projects?

The ten knowledge-based risks in IT projects have been organized into a four-component model composed of knowledge inputs, project governance, project operational phases, and project outputs. This model is outlined below in Figure 1. Each component is discussed below.

Inputs

There are two main knowledge risks at the beginning of a project: the failure to learn from past projects and the failure to meet the project's knowledge needs during team selection.

Without access to lessons learned from comparable projects, the team will lack important domain or institutional knowledge. If this knowledge were available to the project, it could impact the emergent process knowledge and shape how the project manager plans and monitors the project (Thomas & Tjader, 2000).

Finding the right team members is important because the project manager will want all relevant knowledge areas included in the team or available to the team when they need it (Grant, 2006; Walz et al., 1993). When the team selection process is flawed, the project manager will not know what the team knows collectively or more important, what it does not know.

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.

Volatility risk in governance 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 are important institutional, domain and process knowledge losses that may cause targets to be missed and benefits to go unrealized (Gemino et al, In press).

Another risk is an executive sponsor's lack of role knowledge (Henry et al., 2003). First-time project sponsors may not know when to support the project and when to tighten up the reins, or they may fail to differentiate between those project issues that are serious and those that are easily addressed.

The Knowledge Risks Model of IT Projects (Reich 2007)

Figure 1. The Knowledge Risks Model of IT Projects (Reich 2007)

Operational Processes—Plan, Design, Build, and Implement

Within the main body of an IT project are five knowledge risks: knowledge integration, knowledge transfer, loss of team members, lack of a knowledge map, and loss between phases.

Knowledge integration is the process of bringing different specialist forms of knowledge (e.g., business and technical domain knowledge) together to address an identified issue and to create knowledge that is greater than the sum of its parts: a new idea, a shared understanding, or an integrative model (Garrety, Robertson, & Badham, 2004; Huang & Newell, 2003;). Poor decisions can result when specialist knowledge is not integrated. For example, a technical specialist configuring an enterprise system may not understand clearly how the business process works. Some research (Postrel, 2002; Tiwana, 2003) has tried to determine how much knowledge needs to be integrated for optimum results.

Within a project that is implementing packaged software or new hardware, domain knowledge transfer from vendor or consultant to the internal project members is critical (Boh, 2003; Sense, 2003; Volkoff, Elmes, & Strong, 2004; Walz et al, 1993). Apart from the difficulty in explaining the inner workings of technology, there are problems of agency inherent in this risk.

When key members of the team leave the project, knowledge is lost (Eskerod & Blichfeldt, 2005; Gable, Scott, & Davenport, 1998; Schindler & Eppler, 2003). Although project managers conceptually understand that losing key team members results in knowledge gaps, they often fail to create a plan to mitigate such losses.

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—showing 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 (Grant, 2006; Von Stamm, 2005).

Because team composition often changes from phase to phase in IT projects, there is a significant risk that the domain knowledge generated by one phase will be inadequately transmitted to the next phase. This problem is exacerbated in long projects and within virtual project teams (Rus, Lindvall, & Sinha, 2001).

Project outputs

The knowledge risk at the end of the project is that lessons learned are rarely satisfactorily captured (Middleton, 1967; Williams 2004, 2006).

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

Empirical Support for Knowledge-Based Risks in IT Projects

Over the past decade, researchers have been trying to estimate the impact of knowledge-based risks on project performance. Some risks (e.g., lack of a knowledge map) have been studied more intensively than others (e.g., knowledge loss between phases). In this section, we present a sample of the empirical work done to date, showing only research that measured the impact of knowledge and learning on project outcomes. First we use a table format; then we discuss the major findings.

Table 1. Empirical Support for Elements in the Knowledge and Learning Model

K Risk Empirical Studies linking this K Risk to Project Performance
Lessons learned not brought in Williams (2006), in a survey of 522 PMI members, found that only 36% of respondents felt that lessons learned were transferred to other projects. However, 65% of respondents reported that lessons learned were sometimes or routinely incorporated into processes.
Knowledge of team members and networks Nidumolu (1995), in a survey of 64 projects, showed that project uncertainty has a direct effect on project performance.
Wallace and Keil (2004) showed that a lack of knowledge within the project team (e.g., inadequately trained, inexperienced, unfamiliar, lack specialized skills) and project manager (i.e., inexperienced) can impact both project processes and project product outcomes. Gemino et al. (In press) showed that knowledge resources significantly impacted project management practices and organizational support, which in turn impacted project performance.
Loss of a member of governance team Parker and Skitmore (2005) surveyed 67 project managers in the aerospace industry. Respondents felt that the turnover of a project manager—during a project—negatively impacted both team and overall project performance.
Sauer et al. (2007) surveyed 421 projects and found that the loss of a project manager (which happened, on average, on one in every two projects) resulted in a total negative impact on project schedule, budget, and scope of 17%. They also showed that changing the executive sponsor (which happened, on average, on one in every four projects) caused a 6% reduction in scope delivered.
Gemino et al. (In press), in a survey of 194 projects, showed that volatility has a very significant negative impact on process performance. The most important component within volatility was the loss of a project manager or executive sponsor.
Executive Sponsor role knowledge Karlsen and Gottschalk (2003), in a survey of 68 projects, showed that strategic knowledge transfer (the knowledge that is transferred from the executive sponsor) has a direct impact on project outcomes relating to implementation and client benefits.
Gemino et al. (In press), in a survey of 194 projects, showed that knowledge resources significantly impacted project management practices and organizational support, which in turn impacted project performance. An influential component of the knowledge resources construct was executive sponsor knowledge.
Knowledge integration Tiwana, Bharadwaj, and Sambamurthy (2003) studied 133 projects and reported that the level of knowledge integration within the team was more important to project success than a preexisting positive relationship between business and IT.
Tiwana (2004), in a survey of 232 software projects, showed that knowledge integration (domain and technical knowledge) was associated with higher software development efficiency, greater development effectiveness, and fewer defects.
Knowledge transfer Karlsen and Gottschalk (2003), in a survey of 68 projects, showed that serial transfer (within teams) and expert transfer (from outside experts) had a direct impact on project outcomes relating to attainment of targets and system quality.
Loss of team members
Knowledge map (i.e., expertise coordination) Theoretical bases come from transactive memory and collective mind theories. Crowston and Kammerer (1998) studied a group of requirements engineers and were able to use theories of transactive memory (Wegner, 1987) and collective mind (Weick & Roberts, 1993) to explain software requirements that were complete, accurate, and consistent.
Faraj and Sproull (2000) surveyed project team members and stakeholders working on 69 software development projects. They found that by coordinating expertise, teams could improve their performance an additional 25% above applying 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.
Akgün, Byrne, Keskin, Lynn, and Imamoglu (2005), in a survey of 69 projects, showed that transactive memory systems (i.e., people accessing knowledge through their network of contacts) affect project outcomes, especially when the task is complex. Gemino et al. (In press), in a survey of 194 projects, showed that project management practices significantly influenced both project and product performance. Expertise coordination was the most influential component of project management practices.
Loss between Phases
Lessons not Learned Williams (2006), in a survey of 522 PMI members, found that only 47% of lessons learned were transferred from the individual to the project team.

Summary of the Empirical Evidence To Date

From the empirical research published to date, we have identified several observations:

Although lessons learned is often considered to be the most important element of knowledge and learning within and across projects, the empirical evidence suggests that the principle of gathering and disseminating lessons learned is well understood in most project-oriented organizations but that the practices for gathering and disseminating lessons learned are immature.

Expertise coordination is the most widely studied type of knowledge management and shows a very strong influence on IT project performance. This expertise coordination can be thought of as complementary to administrative coordination; both are necessary in complex projects. What is missing from the literature is advice to the practitioner about how to go about managing expertise. Research connecting the concept of expertise location management in organizations (Smith & McKeen, 2006) may be helpful in this regard.

Volatility in the governance team has only recently emerged in research but shows promise with respect to having a significant impact on project performance. Research needs to be done to determine the causes of turnover and to investigate the varying impacts of these causes (i.e., voluntary versus forced departure).

It has been accepted for some time that the impact of the executive sponsor on IT project performance is significant. Gemino et al. (2008) have separated the action and knowledge perspectives to show that this impact is made up of at least two components: what the executive sponsor knows (e.g., about project role, project management, technology, and the business domain) and what the executive sponsor actually does during the project. Because the impact of role knowledge has only recently been investigated, we cannot say that one influences the other. More research is needed to explore these connections.

Several studies have shown that the knowledge possessed by team members impacts team performance. This needs more study, since we do not yet know what aspects of knowledge are influential or under what conditions these aspects affect performance. Gemino et al. (2008), however, have shown that knowledge resources do not directly impact project performance; rather, these are mediated by project management practices and organizational support.

Can We Model Project Performance Using a Knowledge Lens?

As far as we know, there is no model which fully incorporates both the action and the knowledge perspectives of IT projects and attempts to predict or explain the variances in project performance. For this discussion, we draw upon a Temporal Model of IT Project Performance (Gemino et al, In press). This model includes some knowledge elements as well as the action perspective; it can be used as a starting point for the discussion.

In the Temporal Model of IT Project Performance (see figure 2 below), the risks and resources in a project are modeled over time. These time elements are very simple: T-1 (the time before the project starts), T-2 (the time during which the project is conducted), and T-3 (the end of the project).

Two elements are modeled at T-1: the structural risks of the project (size, duration, budget, schedule, technical complexity) and the knowledge resources associated with the project (knowledge of the team, the executive sponsor, the client manager, and the project manager as well as the uncertainty involving the requirements). Therefore, at T-1, the model separates out knowledge resources from other risks.

At T-2, there are three constructs of interest: organizational support resources, project management practices, and volatility risk. These constructs contain elements from both the action and knowledge perspectives.

The organizational support resources construct is drawn from a pure action perspective and measures the support and commitment behaviors of the executive sponsor and client manager.

The project management practices construct considers the administrative actions of the project manager (use of methodologies, use of tools), process integration (within the team and with the users) and expertise coordination (knowledge mapping and sharing of knowledge).

Volatility risk contains three sub-constructs: exogenous change (i.e., changes in industry, company strategy), project target change (i.e., changes to budget, schedule, or scope), and knowledge loss (i.e., loss of the project manager or executive sponsor).

At T-3, there are two aspects of project performance: process performance (budget and schedule attainment) and product performance (organizational benefits and quality). There are no knowledge outputs explicitly contained in this model.

Temporal Model of IT Project Performance (Gemino, Reich, and Sauer, 2008)

Figure 2. Temporal Model of IT Project Performance (Gemino, Reich, and Sauer, 2008)

This model was tested via a survey of 194 projects from 194 different project managers. We used data from a survey of PMI chapters in three different United States cities, all located in Ohio. We used a formative approach to estimate the constructs, an approach that involved using a number of sub-constructs. To analyze this data, we then used a partial least squares (PLS) approach. PLS is a structural equation modeling technique utilizing a principal component-based approach to estimation. We selected PLS because it is preferred over covariance-based techniques when developing theories and using formative constructs (Gefen, Straub, & Boudreau, 2000).

The significant relationships are shown in Figure 2 with arrows and a positive or negative sign. If there are no lines between 2 constructs, it means that there was not a significant relationship between these in the sample data.

The findings show partial support for the knowledge perspective of IT projects. This support is shown both at the construct level (i.e., Knowledge Resources) and at the sub-construct level (i.e., expertise coordination within Project Management Practices and knowledge loss within Volatility Risk). Each is discussed below.

Influence at the Construct Level: Knowledge Resources

At T-1, a project starts with an initial allotment of knowledge resources. Higher levels of this knowledge resource positively influence both organizational support and project management practices. Project management practices and organizational support influence each other positively in a type of virtuous cycle. Following the model, project management practice is seen as affecting product performance directly and process performance both directly and indirectly, through organizational support.

Through this perspective, a project manager can be viewed as leveraging knowledge resources to manage the project through project management practices so as to positively influence organizational support and eventually, both product and process performance. From this perspective, knowledge resources help the project manager take the necessary actions that will help the team achieve the project's goals.

Another way of thinking about the value of initial knowledge resources is that high levels of knowledge resources enable high levels of organizational support and project management practices, and that in this environment, organizational support can make its full impact on project success.

The Temporal Model of Project Performance therefore suggests a strong role for initial knowledge resources.

Influence at the Sub-construct level: Expertise Coordination and Knowledge Loss

The story of the impact of knowledge continues as the sub-constructs underlying the larger constructs are considered.

Each construct in the model shown in Figure 2 above was formed by considering a number of independent sub-constructs. The sub-constructs should therefore not be viewed, as is traditionally the case, as reflective measures of the major construct. Instead, we viewed the major construct as being formed by separate and largely independent contributions from several sources. For example, requirements uncertainty was viewed as being an important part of the knowledge resources construct but was not expected to depend on or co-vary with other sub-constructs such as the knowledge of the team, the project manager, or the sponsor.

Table 2 shows the loadings of the sub-constructs from the constructs in Figure 2, which contain knowledge perspectives.

Table 2. Loading for Selected Sub-constructs in the TMPP Model

Construct Loading
Sub construct  
Knowledge Resources  
Requirements Uncertainty 0.578
PM Knowledge 0.320
Executive Sponsor Knowledge 0.464
Team Knowledge 0.845
Project Management Practices  
Administrative coordination 0.779
Expertise coordination 0.901
Process Integration 0.370
Volatility Risks  
Project Target Volatility 0.791
Knowledge Loss - of PM or Exec Sponsor 0.856
External Volatility 0.281

We have already discussed the impact of Knowledge Resources at the construct level. It is interesting to look inside this construct and see that each element, but most especially requirements uncertainty and team knowledge, is a significant contributor.

We have seen from Figure 2 that Project Management Practices positively influence both aspects of Project Performance—process and product performance. When we looked inside the components of project management practices, we saw that expertise coordination, the knowledge component, has more influence than both administrative coordination (i.e. task and time monitoring) and process integration.

In the lower part of Figure 2, we found that Volatility Risk negatively influences Process Performance. Examining the components of volatility risk, we observed that the loss of a project manager or executive sponsor is the most influential part of this construct.

At this point in our investigation, we cannot be more specific about the impact of knowledge components on project performance, but there is a strong indication that they have an important role to play.

A Preliminary Model of the Knowledge Perspective of IT Projects

It is interesting to note that two relatively independent efforts to model IT projects (Gemino et al, 2008; Reich, 2007) both resulted in temporal models. At present, we have only a very simplistic understanding of the impact of time within a project on knowledge and risk. Future research is needed to explore the impact of time at a more granular level.

We have shown the potential of the knowledge perspective to inform our understanding of IT project performance. We now move to consider how to model this perspective so that more empirical work can be done to evaluate which aspects are the most influential. There are several changes that should be made to the temporal model so that it can fully specify the knowledge and learning risks considered in Reich (2007):

  • At T-1, add elements to the Knowledge Resources construct such as lessons learned.
  • At T-2, model knowledge creation through transfer and integration.
  • At T-2, separate expertise coordination from the other project management practices which manage tasks and time. This might create overlaps between the action and knowledge activities of the project manager. Obtaining conceptual clarity could prove to be a difficult task.
  • At T-2, add the within-project learning that is generated when teams debrief between phases, examine their assumptions at critical decision points, and learn as they go.
  • At T-2, model knowledge loss between phases and knowledge loss due to the loss of team members.
  • At T-2, separate the aspects of volatility that deal with knowledge loss due to turnover of governance roles from other aspects of volatility such as exogenous change and target change.
  • At T-3, add the knowledge outputs of an IT Project. A first step could involve modeling individual learning and organizational learning as knowledge outputs.

Figure 3 below shows a preliminary knowledge-based model for IT Projects. We acknowledge that this model considers only the knowledge risks shown in Reich (2007). This model admittedly does not consider the impact of cultural and institutional knowledge on project success and also may fail to capture the client's knowledge needs and contributions. These and other shortcomings are left for future research.

A Preliminary Model of the Knowledge Perspective of IT Projects

Figure 3. A Preliminary Model of the Knowledge Perspective of IT Projects

In this model, we suggest that five constructs be used to model the knowledge perspective within IT projects:

  1. The first construct would contain the initial level of knowledge resources available to the project. This would be measured at T-1 through the knowledge inputs (e.g., knowledge of team members, project manager, executive sponsor, client manager, knowledge networks, lessons learned) and the knowledge holes (e.g., requirements uncertainty). Knowledge resources would be expected to positively influence knowledge creation, since a higher level of knowledge within the project would enable more advanced measures of knowledge integration, transfer, and coordination.
  2. The second construct would represent the knowledge lost during T-2. This might include the loss of people such as the project manager, project sponsor, and team members as well as other key sources of knowledge such as vendors and consultants. Knowledge loss would be expected to vary indirectly with knowledge creation as higher levels of learning might encourage project participants to remain on the project, while significant knowledge loss might slow or cripple the creation of new knowledge. Knowledge loss would be expected to negatively influence both project and knowledge outcomes.
  3. The third construct would represent efforts taken by the project manager (and other project leaders) to create new knowledge through integration, transfer, and coordination. It would also represent the within-project learning accomplished by the project participants. Knowledge Creation would be expected to positively influence both project and knowledge outcomes.
  4. The fourth construct would contain the traditional measures of project success: the attainment of targets (process performance) and the attainment of organizational value (product performance).
  5. The fifth construct would model the knowledge outputs of the project. At the individual level, this would involve assessing increases in process, domain, institutional and cultural knowledge stocks. At the organizational level, this would involve measuring the overall capacity of the organization to execute projects successfully (both by attaining targets and by obtaining value).

There is much more work to be done in order to understand the knowledge perspective of IT Projects. In this paper, we have discussed the empirical support for such a view and proposed a preliminary model. We hope that this work stimulates future discussion and further exploration.

References

Akgün, A., Byrne, J., Keskin, H., Lynn, G., & Imamoglu, S. (2005). Knowledge networks in new product development projects: A transactive memory perspective. Information & Management, 42(8), 1105–1120.

Boh, W. F. (2003). Knowledge sharing mechanisms in project-based knowledge work: Codification versus personalization. The 24th International Conference on Information Systems, Seattle, USA.

Brynolfsson, E., & Hitt, L. (1998). Beyond the productivity paradox. Communications of the ACM, 41(8), 49–55.

Chan, R., & Rosemann, M. (2001). Managing knowledge in enterprise systems. Journal of Systems and Information Systems, 5(2), 37–53.

Crowston, K., & Kammerer, E. E. (1998). Coordination and collective mind in software requirements development.

IBM Systems Journal, 37(2), 227–246.

Eskerod, P., & Blichfeldt, B. S. (2005). Managing team entrees and withdrawals during the project life cycle.

International Journal of Project Management, 23(7), 495–503.

Faraj, S., & Sproull, L. (2000). Coordinating expertise in software development teams. Management Science, 46(12), 1554–1568.

Gable, G. G., Scott, J. E., & Davenport, T. D. (1998). Cooperative ERP life-cycle knowledge management. The 9th. Australasian Conference on Information Systems, Sydney, Australia, 227–240.

Garrety, K., Robertson, P. L., & Badham, R. (2004). Integrating communities of practice in technology development projects. International Journal of Project Management, 22(5), 351–358.

Gefen, D., Straub, D. W., & Boudreau, M. C. (2000). Structural equation modeling and regression: Guidelines for research practice. Communications of the Association for Information Systems, 4(7), 1–80.

Gemino, A., Reich, B.H., and Sauer, C. (2008). A Temporal Model of Information Technology Project Performance. Journal of Management Information Systems, 24(3), 9–44.

Grant, K. P. (2006). Leveraging project team expertise for better project solutions. Paper presented at the PMI Research Conference 2006, Montreal, Canada.

Hartmann, D. (2006). Interview: Jim Johnson of the Standish Group. Retrieved August 22, 2007, from http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS

Henry, R. M., Kirsch, L. J., & Sambamurthy, V. (2003). The role of knowledge information technology project governance. The 24th International Conference on Information Systems, Seattle, USA, 751–758.

Huang, J. C., & Newell, S. (2003). Knowledge integration processes and dynamics within the context of crossfunctional projects. International Journal of Project Management, 21(3), 167–176.

J0rgensen, M., & Moløkken-Østvold, K. (2006). How large are software cost overruns? A review of the 1994 CHAOS report. Information and Software Technology, 48(4), 297–301.

Karlsen, J. T., & Gottschalk, P. (2003). An empirical evaluation of knowledge transfer mechanisms for it projects.

Journal of Computer Information Systems, 44(1), 112–119.

Majchrzak, A., & Beath, C. (2003). A framework for understanding participation and mutual understanding in software projects. Unpublished manuscript.

Meehan, B., & Richardson, I. (2002). Identification of software process knowledge management. Software Process Improvement and Practice, 7(2), 47–55.

Middleton, C. J. (1967). How to set up a project organization. Harvard Business Review, 45(2), 73–82.

Nelson, K. M., & Cooprider, J. G. (1996). The contribution of shared knowledge to I/S group performance. MIS Quarterly, 20(4), 409–429.

Nidumolu, S. (1995). The effect of coordination and uncertainty on software project performance: Residual performance risk as an intervening variable. Information Systems Research, 6(3), 191–219

Parker, S. K., & Skitmore, M. (2005). Project management turnover: Causes and effects on project performance. International Journal of Project Management, 23(3), 205–214.

Postrel, S. (2002). Islands of shared knowledge: Specialization and mutual understanding in problem-solving teams. Organization Science, 13(3), 303–320.

Reich, B. H. (2004). Managing knowledge within IT projects: A review of current literature and directions for future research. Unpublished manuscript.

Reich, B. H. (2007). Managing knowledge and learning in it projects: A conceptual framework and guidelines for practice. Project Management Journal, 38(2), 5–17.

Roach, S. S. (1989). America's white-collar productivity dilemma. Manufacturing Engineering, August, 104.

Rus, I., Lindvall, M., & Sinha, S. (2001). A state of the art report: Knowledge management in software engineering. Data and Analysis Center for Software, ITT Industries.

Sauer, C., Gemino, A., & Reich, B. H. (2007). The impact of size and volatility on IT project performance. Communications of the Association for Computing Machinery, 50(11), 79–84.

Schindler, M., & Eppler, M. J. (2003). Harvesting project knowledge: A review of project learning methods and success factors. International Journal of Project Management, 21(3), 219–228.

Sense, A. (2003). Learning generators, project teams re-conceptualized. Project Management Journal, 34(3), 4–12.

Smith, H. A., & McKeen, J. D. (2006). Developments in practice xxii: Expertise location and management: Hope or hype? Communications of AIS, 2006(18), 2–23.

Standish Group. (1994). The CHAOS report, 1994, the Standish Group. Retrieved January 12, 2007, from http://www.standishgroup.com/sample_research/chaos_1994_1.php

Stein, E. W., & Vandenbosch, B. (1996). Organizational learning during advanced system development: Opportunities and obstacles. Journal of Management Information Systems, 13(2), 115–136.

Thomas, J. L., & Tjader, J. (2000). On learning and control – Competing paradigms or co-existing requirements for managing projects in ambiguous situations. The 4th Biannual Conference, International Research Network on Organizing by Projects, Sydney, Australia.

Tiwana, A. (2003). Knowledge partitioning in outsourced software development: A field study. The 24th International Conference on Information Systems, Seattle, USA, 259–270.

Tiwana, A., Bharadwaj, A., & Sambamurthy, V. (2003). Antecedents of IS development capability: A knowledge integration perspective. The 24th International Conference on Information Systems, Seattle, USA, 246–258.

Tiwana, A. (2004). An empirical study of the effect of knowledge integration on software development performance. Information and Software Technology, 46(13), 899–906.

Volkoff, O., Elmes, M., & Strong, D. (2004). Enterprise systems, knowledge transfer and power users. The Journal of Strategic Information Systems, 13(4), 279–304.

von Stamm, B. (2005). Exploiting the km-innovation connection. KM Review, 8(4), 28–31.

Wallace, L., & Keil, M. (2004). Software project risks and their effect on outcomes. Communications of the ACM, 47(4), 68–73.

Walz, D. B., Elam, J. J., & Curtis, B. (1993). Inside a software design team: Knowledge acquisition, sharing and integration. Communications of ACM, 36(10), 63–77.

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(3), 357–381.

Williams, T. (2004). Identifying the hard lessons from projects – easily. International Journal of Project Management, 22(4), 273–279.

Williams, T. (2006). How do organizations learn from projects? Paper presented at the PMI Research Conference 2006, Montreal, Canada.

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.

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.

© 2008 Project Management Institute

Advertisement

Advertisement

Related Content

Advertisement