Conceptual framework for cross-organizational software projects

an exploratory study

PhD Student

Department of Engineering and Technology Management

Portland State University

Dragan Z. Milosevic, PhD

Department of Engineering and Technology Management

Portland State University

Proceedings of the PMI Research Conference 11-14 July 2004 – London, UK

Abstract

The importance of software development (SWD) has been rapidly increasing over the past decade. Companies and governments have allocated large amounts of resources for SWD. Information systems and information technologies are the fastest growing industries in developed countries. In 1998, the US software industry employed 800,000 people and in 2001 this figure rose to more than 2 million people. While about 560,000 high-tech jobs were lost between January 2001 and December 2002 in the US due to the economic downturn, the software services industry added 5,300 jobs.

Although the SWD industry offers immense opportunities for new and existing businesses, it presents equally big challenges. The majority of the ventures initiated by software companies in the last decade have been unsuccessful. Several studies report failures in up to three quarters of all software projects undertaken in the last decade. These failures are either total failures and cancellations or major slippages in cost, time, and quality targets. Moreover, the number of cross-organizational (C/O) SWD efforts is rapidly increasing. Such a development has brought further complications into software development projects.

Although experts have offered advice on how to approach C/O SWD projects, hard evidence grounded in empirical studies is surprisingly scarce. Moreover, existing studies on C/O SWD management do not reflect the diversity of factors that enable the successful management of projects. Instead, factors that have been studied mainly focus on SWD tools. The purpose of this exploratory study is to contribute to the theoretical foundations of C/O SWD project management (PM) by empirically establishing a conceptual PM framework based on a diversity of factors. A case study research (CSR) approach is used for this study.

Introduction

In today’s economy, the number and variety of C/O efforts have been increasing considerably (Borys & Jemison, 1989; Lei & Slocum, 1991). Herzog (2001) describes the reason companies collaborate as achieving a project or goal that they could not achieve individually. Porter and Fuller (1986) list other reasons, such as addressing rapid changes and uncertainties in technological development, achieving economies of scale, and improving learning. They contend that collaborations present certain advantages versus internal development, arm’s length transactions, or mergers. In today’s fast paced business environment, companies can reposition themselves faster by getting access to resources like distribution channels, local legitimacy, technology or innovative ability, specialized know-how, and capital. Other benefits of collaborations are listed as economies of scale, increased learning rate on how to perform an activity, and risk and cost hedging. (Herzog, 2001; Lei & Slocum, 1991; Porter & Fuller, 1986; Shaughnessy, 1994)

Similar to other industries, the SWD industry has witnessed an increase in the number of C/O efforts in the past decade (Lacity & Willcocks, 2000; Lanubile & Mallardo, 2002; Lee & Kim, 1999; Maidantchik & da Rocha, 2002; Rothstein, 1998). C/O SWD projects are becoming the new competitive weapon (Lee & Kim, 1999). However, SWD projects have had notoriously low success rates (Berinato, 2001; Jiang & Klein, 2001; Nidumolu, 1996). The increasing trend in C/O efforts has brought further complications into SWD projects. Estimates suggest that on average, 60% of C/O efforts (SWD and non-SWD) result in failure (Duysters, Kok, & Vaandrager, 1999). This percentage is likely to be higher in C/O SWD projects.

Although experts have offered advice on how to approach C/O SWD projects, hard evidence grounded in empirical studies is surprisingly scarce. Moreover, existing studies on C/O SWD management do not reflect the diversity of factors that enable the successful management of projects. Instead, individual factors have been separately researched with a focus on SWD tools. This research will try to empirically establish the link between application of a comprehensive project management (PM) framework based on diversity of factors and the outcome of C/O SWD projects. The results of this study will be a step toward establishing a theoretical framework for managing C/O SWD projects.

Conceptual Background

This section reviews the literature streams on PM frameworks and framework components for C/O SWD projects. It concludes by describing the research template that guided our data gathering and data analysis.

Project Management Frameworks

The models for ongoing PM success have been studied in the literature to a certain extent. One stream in the literature suggests that all projects go through similar life-cycle stages and that success can be achieved through successful management of these stages. Adams and Caldentey (1997) list these phases as the conceptual phase, the planning phase, the execution phase, and the completion phase.

In another literature stream, a contingency approach to PM is emphasized. In their meta-study, Balachandra and Friar (1997) review the previous success factor studies and present a contextual framework for project success. They define market, technology, environment, and organization as the four categories of success factors. Moreover, they suggest that the importance of different categories change depending on the nature of innovation, the nature of the market, and the nature of technology. Shenhar (Aronson, Lechler, Reilly, & Shenhar, 2001; Poli & Shenhar, 2003; Shenhar, 2003) proposes a strategic PM model with five main components. The main components he identifies are strategy, organization, tools, processes, and spirit. These main components are further divided into subcomponents. Kerzner (2000) identifies six components for success: behavioral excellence, integrated processes, culture, management support, training and education, and informal PM. Nicholas (1990) argues that PM is a systems-oriented approach to management since PM considers the project as a system of interrelated tasks within an influential environment.

In order to objectively determine the comprehensiveness of these models, we used Linstone’s (1999) multiple perspectives. Linstone (1999) proposes using different perspectives to look at systems in order to understand them. He contends that each perspective yields insights about the system not obtainable from the other perspectives. According to him, in order to see the system in its totality, one needs to look at it through different glasses (perspectives) in its totality rather than focusing on its parts. He proposes the technical perspective, the organizational perspective, and the personal perspective. The technical perspective has a focus on the quantitative aspects of the system, such as models, trade-offs, and data (Linstone, 1999). The organizational perspective deals with power. It looks at the system from the point of view of the affected and affecting organization (Linstone, 1999). Similarly, the personal perspective looks at the system from the point of view of individuals. It focuses on aspects of the system that relate to individuals and that cannot be brought out by the other perspectives (Linstone, 1999).

Following Nicholas’ (1990) view of a project as a system and Linstone’s (1999) suggestion to look at systems from different perspectives, we compared different PM models. A comparison of these models is presented in Table 1. This table tries to capture the dynamics within a project from different perspectives and to analyze the comprehensiveness of the different PM models proposed in the literature.

  Balachandra (Balachandra & Friar, 1997) PMBOK® Guide (A Guide to the Project Management Body of Knowledge, 2000) Shenhar (Aronson et al., 2001; Poli & Shenhar, 2003; Shenhar, 2003) Kerzner (Kerzner, 2000)
Technical perspective Technical Integration management, Scope management, Time management, Cost management, Quality management, Communications management, Risk management, Procurement management Tools, Processes Training and education, Integrated processes
Organizational perspective Organizational, Market, Environmental   Strategy, Organization Management support, Informal project management
Personal perspective Human resource management Spirit Culture, Behavioral, Excellence

Table 1: Comparison of different project management frameworks

Table 1 suggests that the Shenhar et al. (Aronson et al., 2001; Poli & Shenhar, 2003; Shenhar, 2003) and Kerzner (2000) models have components that cover all three perspectives. However, the Shenhar et al. model (see Figure 1) is broader. For example, processes include training and education. Similarly, strategy incorporates management support and informal project management (PM). Behavioral excellence is a part of culture. Therefore, the Shenhar et al. model (Aronson et al., 2001; Poli & Shenhar, 2003; Shenhar, 2003) will be used as a general framework to organize the literature review on PM. Spirit will be called Culture, and literature on metrics will be reviewed, in addition to the five areas, since it is mentioned in A Guide to the Project Management Body of Knowledge—2000 Edition (PMBOK® Guide) and not in the Shenhar et al. model (Aronson et al., 2001; Poli & Shenhar, 2003; Shenhar, 2003).

The Shenhar et al. framework for strategic project leadership

Figure 1: The Shenhar et al. framework for strategic project leadership

(Aronson et al., 2001; Poli & Shenhar, 2003; Shenhar, 2003)

Project Management Framework and Cross-Organizational Software Development

As mentioned in the previous section, a diversity of components is necessary for the successful management of projects. These components have been individually researched in the C/O SWD literature to a certain extent. However, empirical studies are almost non-existent. In this section, a review of the C/O SWD and PM literature will be presented for each of the components.

Strategy

Shenhar (2003) and Cooper (2001) define two aspects of project strategy: doing the right projects and doing projects right. According to Cooper (2001), doing the right projects refers to project selection decisions and having the right portfolio of projects. Poli and Shenhar (2003) argue that projects should be an active element in the implementation of strategic intent. Cooper (2001) defines doing the projects right as efficiency. He contends that most key-success-factor studies are focused on this aspect of projects.

Shenhar et al. (Aronson et al., 2001; Poli & Shenhar, 2003; Shenhar, 2003) list objective, product definition, competitive advantage, project definition, and strategic focus as the components of strategy. Objective is the reason the project is done. Product definition addresses the reason customers will want to buy the product and design. Competitive advantage is defined as the advantage for the customer and value for the company. Project scope and project type constitute the project definition. Finally, strategic focus is the mindset that will guide the project (Poli & Shenhar, 2003).

Oppenheimer (2002) explains that a common issue in C/O SWD is project team members not having a clear view of the project strategy. This leads to misaligned effort on the project team members’ side. Snow, Snell, Davison, and Hambrick, (1999) stress the importance of identification of the link between the team’s mission and the corporate strategy. They claim that C/O team tasks are generally very complex and the expected contributions to business strategy are seldom straightforward.

Organization

As presented in Figure 1, organization involves project structure, teams, and people.

Maznevski and Chudoba (2000) describe C/O teams as physically dispersed divisions across different countries or within the same country. These teams serve an important role for decision-making and implementing projects. These vary across several dimensions, such as number of organizations and people involved (Maznevski & Chudoba, 2000; Whitehead, 1999).

The PMBOK® Guide (2000) identifies teams and team building as critical to the project’s objectives being met. Katzenbach and Smith (1993) list complementary skills brought together, real-time problem solving through effective communication, social dimension that brings in more fun, and reinforcement of each other’s intentions to pursue the team’s purpose as the phenomena that explain what makes teams perform well. Some of the tools that the PMBOK® Guide (2000) lists to facilitate team building are team building activities, general management skills, reward and recognition systems, collocation, and training.

The people component of organization involves selection of people, training, and responsibility assignment (Aronson et al., 2001; Poli & Shenhar, 2003). Similarly, the PMBOK® Guide (2000) explains that the people aspect involves recruiting, developing, and training, as well as dealing with disputes and health and welfare issues. Sabherwal (1999) reports that team members trust each other less in C/O SWD projects because the C/O team members do not have a history together and most probably the team’s existence will not last beyond the project. This, coupled with tighter structural mechanisms (like deliverables, penalty clauses, reporting arrangements, etc.), temporal separation, lack of face to face communication, language gaps, and cultural gaps, prevent the development of trust as opposed to within organization projects, where trust ideally replaces structural control mechanisms (Kiel, 2003; Pyysiainen, 2003; Sabherwal, 1999). Some other researchers (Kiel, 2003; Oppenheimer, 2002) contend that it is crucial to make the roles and the responsibilities as well as the interfaces between roles clear in C/O SWD teams.

Process

Shenhar et al (Aronson et al., 2001; Poli & Shenhar, 2003; Shenhar, 2003) include planning, monitoring, and controlling under the process heading. According to Kerzner (2000), the implementation of life cycle stages, PM activities, product management activities, and milestones constitute the process. The PMBOK® Guide (2000) divides processes into PM and product-oriented processes. Project processes are defined as processes that describe, organize, and complete the work of the project: scope management, time management, cost management, quality management, human resources management, communications management, risk management, and procurement management.

As per the PMBOK® Guide (2000), product-oriented processes are those defined by the project life cycle and vary by application area. Sobek, Liker, & Ward (1998) add conflict management to the list, which they argue ensures synergistic rather than destructive work.

Tools

Project tools are the procedures and techniques by which PM deliverables or PM activities are accomplished (e.g., Work Breakdown Structure (WBS) or Critical Path Method (CPM) diagram). Kerzner (2000) argues that tools are the foremost enablers of the implementation of PM processes. Pinto and Slevin (1987) and The Association for Project Management Body of Knowledge (APMBOK) (2000) clarify this by pointing out that tools provide monitoring and feedback for managers and help them implement proactive responses. Sobek et al. (1998) contend that standard project tools play an important role in providing a smooth process and enable reaching project goals.

The PMBOK® Guide (2000) lists several tools for different knowledge areas and defines them as project management tools. Additionally, in the SWD literature, numerous tools are claimed to improve SWD project success (e.g., software reuse, Computer Aided Software Engineering tools, Object Oriented Analysis and Design) (Bersoff & Davis, 1991; Brooks, 1987; Cox, 1990; Fichman & Kemerer, 1993a, 1993b; Griss, 1993; Henderson & Cooprider, 1990; Jarzabek & Huang, 1998; McDonald, 2001; Orlikowski, 1989). These tools are more tailored towards the management of the product.

Metrics

Historically called project performance measures, metrics help measure and monitor project performance (e.g., schedule performance index, or % of milestones accomplished). Katzenbach (2000) contends that every good organization uses metrics to energize and motivate their workforce in addition to other paths to complement this effort. Project managers rely on metrics in order to understand how well the project strategy works (Milosevic, Inman, & Ozbay, 2001; Tipping, Zeffren, & Fusfeld, 1995). Shenhar, Levy, Dvir, and Maltz (2001) developed four success dimensions that measure project success over time, for both the short-term and the long-term: project efficiency, customer impact, business success, and future preparation.

Culture

Culture is defined as shared norms, values, and assumptions (Schein, 1996a; Schwartz & Davis, 1981; Shenhar, 1999). Hofstede (1983) defines culture as collective mental programming. Project culture can make the team members more engaged, committed, enthusiastic, and willing to support each other to accomplish project goals (Aronson et al., 2001). Schein (1996b) argues that organizational culture is one of the most powerful forces operating in organizations and can influence the implementation of strategies and organizational performance.

Research Template

The literature on C/O SWD projects is limited and our aim is to contribute to the theoretical foundations of this topic. This calls for a CSR methodology (Eisenhardt, 1989; Yin, 1985). CSR is most appropriate when how and why questions are the focus of the research, when the investigator has little or no control over the events, and when the subject being researched is a contemporary phenomenon within some real-life context (Yin, 1981, 1985).

Several researchers find it helpful to prepare an initial research template in preparation to undertake the CSR (Eisenhardt, 1989; Glaser & Strauss, 1967; Yin, 1985). Even if the existing knowledge base is poor and the literature does not provide a conceptual framework or hypotheses, the researcher needs to clearly know the topic of the exploration, the purpose of the exploration, and the criteria by which the exploration will be judged. Literature review on related areas, discussion sessions with experts in the area of focus, and clarification of the objectives and methods of the research are some of the methods to facilitate the theory’s development. The output of these efforts is a set of initial propositions. According to Yin (1985), each proposition directs attention to something that should be examined within the scope of the research. Eisenhardt (1989) refers to these points as constructs and contends that constructs can be helpful in shaping the initial design of the research. According to her, if these constructs prove important as the study progresses, the researchers have a firmer empirical grounding for the emergent theory. However, she adds, no construct is guaranteed a place in the resultant theory. Glaser and Strauss (1967) label them as a priori assumptions and add that these concepts are about the problem itself, not its situation.

Our literature review helped us shape our constructs. We prepared our initial research template (presented in Table 2) based on these constructs. The headings in our research template are the same headings we used to organize our literature review. The subheadings of our research template are a summary of our findings, as presented in the literature review section. As a whole, Table 2 presents a summary of what is to be explored by this research and it was used during our data collection as a guideline. Moreover, Table 2 also provides an initial conceptual framework to be tested and modified during the data analysis stages.

As mentioned before, we used the CSR methodology for this exploratory study. We studied three C/O SWD projects. Our main data source was interviews. Details on how we undertook this research will be provided in the next section.

Strategy Process
Objective Project management activities
Product definition Work description
Market analysis Milestones
Technology analysis Scope management
Risk analysis Conflict management
Requirements analysis Time/cost/quality management
Definition of specifications Communication
Competitive advantage Risk management
Advantage for the customer Procurement management
Value for the company Product management activities
Project definition Life cycle stages
Project scope Design and technical considerations
Project type System integration
Strategic focus Customer involvement
Guidelines for behavior and decisions  
Project policy  
Supporting behavior  
Organization Metrics
Project structure Project efficiency metrics
Number of people involved Customer impact metrics
Functional organizations involved Business success metrics
Team building Future preparation metrics
People  
Criteria for selection  
Training  
Responsibility assignment  
Tools Culture
Common project management tools Organizational culture
Specifically developed tools Project culture
Product management tools

Table 2: Template of categories and subcategories for initial research design

Methodology

Site and Case Selection

Our research took place in Portland, Oregon. We identified project managers who managed C/O SWD projects, which varied in a number of dimensions, including scope, target end user, and end products. Table 3 presents a summary of the features we studied.

  Case 1 Case 2 Case 3
Product novelty Derivative Breakthrough Platform
Technological uncertainty Medium-Tech High-Tech Medium-Tech
System scope System System Array
Pace Fast-competitive Blitz-critical Regular
Business goal Strategic Strategic Operational
Customer External External Internal

Table 3: Project classification

In Table 3, product novelty refers to its potential users. Derivative signifies improved products; breakthrough signifies new to the world products; platform signifies new generations in existing product families. Technological uncertainty is a measure of how mature the technology being used is. It changes from low-tech to super high-tech as the technology changes from mature to non-existing. System scope denotes the project complexity. System is a complex collection of interactive elements, while array is a collection of systems. Pace is a measure of the urgency associated with the project and what happens if the goal is not met. Business goals can be strategic (effectiveness) or operational (efficiency). Customers of the project can be internal or external (Shenhar, 2001).

Data Collection

The data was collected through interviews. Our data collection was guided by our initial research template (see Table 2). We prepared interview guides based on the initial research template and emailed these templates to our informants before the interviews.

The interviews took place at our informants’ sites (except for one phone interview with an informant in Germany), as per CSR‘s requirements. During the interviews, we asked our informants open-ended questions and let them freely tell us about events, actions taken, and results. We then asked them more structured questions to gather more information about the PM framework components that they had not talked about. All of our interviews were audio recorded.

Data Analysis

We performed data analysis concurrently with data collection. In CSR, the researcher jointly collects and analyzes data and decides what data to collect next and where to find it in order to develop his theory as it emerges (Glaser & Strauss, 1967). The data to collect may be selected to replicate previous cases and extend emergent theory or fill theoretical categories (Eisenhardt, 1989).

We started our data analysis by transcribing our audio-recorded interviews. We went over the transcriptions repeatedly until patterns and connections with the literature started to become clearer. Following this, using our template of categories and subcategories, we coded the data within these transcriptions. Then we compared our findings across cases and looked into similarities and differences. As a result of this iterative process, we came up with our final template of categories and subcategories, as presented in Table 4.

While Table 2 shows our initial framework components as a result of our literature review, Table 4 is the summary of the findings of our research. Our objective for this research was to see the applicability of a PM framework for C/O SWD projects. We will present our results in the next section.

First Steps Toward the Theoretical Foundations of
Cross-Organizational Software Development Projects

In this section, we will present our findings with quotes from our informants. The names of our informants will be withheld in order to safeguard their identities.

Strategy Process
Objective Project management activities
Product definition Work description
Market analysis Milestones
Technology analysis Scope management
Requirements analysis Time/cost/quality management
Definition of specifications Communication
Project definition Risk management
Project scope Product management activities
Project type Design and technical considerations
  Customer involvement
Organization Metrics
Project structure Project efficiency metrics
Number of people involved  
Functional organizations involved  
Team building  
People  
Criteria for selection  
Training  
Responsibility assignment  
Tools Culture
Common project management tools Organizational culture

Table 4: Final template of categories and subcategories emerging from data analysis

Propositions

Strategy

In the C/O SWD literature, the effect of strategy on the success of projects has not been researched. Moreover, empirical research on the influence of strategy on project success in PM literature is extremely limited.

Several components of strategy have been repeatedly mentioned in our case studies. Having a clear objective is important for project success. Additionally, in C/O projects, “the goals of the partnering organizations should be aligned with the role they play in the project.”

Product definition, particularly product requirements gathering and articulation, is “very hard to do” and “the biggest risk” that can threaten the viability of the project. In most projects, either “the appropriate research is not done” or the requirements are not “well documented and well communicated.” “The more thorough and better [the product requirements are specified], the higher [the] success rate will be.” In addition to the product requirements, “the market requirements” and “the business requirements” need to be verified. It is important to “really take [all three into account] and understand them all. And play them off against each other [for project success].” Moreover, “especially on C/O projects, getting everybody on the same page about what the requirements are” is hard.

When the strategy is being formulated, the project type (“whether [it is a] hardware or software [project], how many new systems [and] how many new technologies are brought in”) should play a role in the approach.

Based upon our learning from the case studies, the impact of strategy on the outcome of the C/O SWD projects is described by the following proposition:

Proposition 1:      Establishment and implementation of an explicit and meaningful project execution strategy will
                           impact C/O SWD project success positively.

Organization

In our research, we found evidence that organization is influential on the outcome of C/O SWD projects. Moreover, organization becomes more effective as it is aligned with the strategy (“if you have the goals of the project that everybody buys into”) and the process (“if you have a process that everybody buys into”).

A key factor is to make clear “whose responsibilities are what” and “who reports to whom.” This becomes more important in C/O SWD projects. Due to the nature of C/O SWD project, the team members are not collocated, so it becomes a necessity “to sort out” the responsibilities upfront. Several tools like Responsibility Matrix, templates, and/or handbooks can be used for this purpose.

Another important factor is who to have on the team. As one of our informants mentioned, it is important “choose carefully who you want—your designers and your architects and your key managers—who they are, and their goal.” Moreover, “two people with the same number of years of experience” may have different productivity levels.

Project structure needs to provide “lines of authority, that is, chain of command.” This becomes “especially important in C/O” projects due to the dispersed nature of these projects. It provides “a framework to resolve conflicts.” This also ties back to team member selection. “How mature and experienced [the team members] are” is a factor that affects the team performance. Our informants pointed out that the most successful C/O projects are those where “there is a manager […] who is managing [the people in the remote site]”

Therefore, we propose in formal terms:

Proposition 2:     Establishing a project organization that fits the nature of the project will have a positive influence
                          on C/O SWD project success.

Process

In our research, we found strong evidence that process affects the outcome of C/O SWD projects. In this section, we will present our findings as summarized in Table 4.

Defining the work packages—which is part of scope management—upfront, is especially important for C/O SWD projects. These work packages need to be identified “with clearly defined interfaces” and they need to be “independent”. This allows distributed teams to work more effectively. Moreover, it becomes easier to “compensate” for problems “by throwing money at them” if a crucial work package starts to run late. An example to this can be hiring “additional contactors to do some work."

Our research shows that establishing milestones is also important. These help “divide the work into phases.” Milestones constitute “synchronization points” for distributed teams.

Scope changes during the project may invalidate the “architecture, components, team selection, and the time frame”. If the scope is not frozen early in the game, it “has a down stream impact much greater than the effort required to clear upfront".

Time/cost/quality management has been mentioned as a secondary concern in our research next to customer satisfaction.

Communication is described as a major problem with C/O SWD projects. The reason for this is that “the communication challenges are amplified.” In C/O SWD teams it is often the case that team members at different sites have “different processes, different terminology, a different way of approaching issues, and different backgrounds”. When this is the case, communication related issues are different compared to when “people work in the same organization and they know each other well, and they communicate all the time.” But if you are geographically dispersed, “you may never meet the other people."

In addition to organizational risks that are inherent in C/O projects, market risks and technology-related risks have been emphasized with C/O SWD projects It is important to address the risk before Phase 1. Different methods have been mentioned as “trying to find a solution [to potential risks],” “getting help or consulting,” and “training”.

“Software architecture” is a way to define “how individual parts relate to the whole.” This is especially important in C/O SWD teams since communication is one of the biggest challenges with such projects. That is why the “software architecture has to be defined upfront.”

Our informants also mentioned the importance of involving the customer in the process. Defining the “customer requirements correctly” upfront and having “a lot of “touch points along the way” are essential for success. In formal terms,

Proposition 3:     Having a defined, documented, and communicated process will influence the success of C/O SWD
                          projects positively.

Tools

Our research shows that project managers rely on tools heavily for project success.

dOur informants mentioned that they used the:

  • “Responsibility Matrix” for communicating “responsibilities for each role and each major activity throughout a development life cycle,”
  • “Operations handbook” for “spell[ing] out as much detail [about the process] as possible,”
  • “Status reports and templates” for “alternatives analysis, requirements, risks and issues, logs, management plan, project plan estimating, statement of work, functional design, technical design, QA plan”
  • “E-mail and voice messaging” for “communication.”

Some other examples were Microsoft Project and Excel for defining schedules and work packages. UseCases were the only product management tools that were mentioned by our informants. However, this may be due to the smaller informant number and limited interview durations. In formal terms,

Proposition 4:     The deliberate selection and systematic usage of PM tools will positively influence C/O SWD
                          project success.

Metrics

Our informants stated that “if something is to be emphasized, it needs to be measured.” However, a diversity of metrics (e.g., customer impact metrics, business success metrics, and future preparation metrics) was not mentioned during our data collection. We believe that this may be due to the lack of understanding of the scope of metrics by our informants. Also, another reason may be our focus on project managers during data collection. Project managers are more focused on the efficiency of projects than effectiveness.

Based on our findings, we propose:

Proposition 5:     The use of project efficiency metrics will positively influence C/O SWD project success.

Culture

Our informants stated that “cultural differences show up all the time.” Project managers have to “deal with them upfront” because differences in the organizational culture in different C/O sites may handicap the project. These differences may cause “communication” problems and “process incompatibilities” across sites. Moreover, due to the information filtering effect of culture, parties at different sites may “talk past each other.” This may threaten the outcome of the project, especially if it happens during the initial phases where “features are being defined.” “Mistakes made at this stage may have dramatic effects down stream.”

“Having a diplomat on remote sites in order to establish communication channels” was mentioned as a remedy to communication shortcomings due the cultural differences.

Contrary to our expectations, the importance of culture was expressed only on the organizational level. This again may be due to a lack of understanding of the diversity of culture-related issues by our informants.

In formal terms, we propose:

Proposition 6:     The establishment of communication channels that will compensate for cultural differences at
                          different sites will positively influence C/O SWD project success.

Theoretical Framework

This research looked into the importance of managing different aspects of a C/O SWD project. These aspects are also the components of a systemic PM framework. As a result, their combined influence on the project outcome is more profound than the sum of their individual influences. By applying a PM framework, project managers can improve the internal dynamics of the project environment and benefit from the increased effectiveness of each of these components due to the synergy created by unification of efforts. We express the effect of PM framework components on the internal dynamics of the project environment through a set of propositions, depicted in Figure 2.

Theoretical C/O SWD project management framework

Figure 2: Theoretical C/O SWD project management framework

In order to better explain these propositions, we utilized the mediating project phases per Adams and Caldentey (1997), which include conceptual phase, planning phase, execution phase, and completion phase. First, for example, in the conceptual phase, the project is selected for implementation and its strategy (objectives, product and project definition, and competitive advantage) is conceptualized (proposition 1). It is also, during this phase, aligned with the objectives and business strategy of the parent organization. In addition, senior managers and the project manager define the concept of the project organization to match the project nature—product novelty, technological uncertainty, system scope, pace, and type of customer (proposition 2). In addition, managers perform a preliminary risk analysis (proposition 3). Some metrics are identified to serve as success indicators (proposition 5).

Second, the results of planning in the conceptual phase are used in the planning phase for the development of detailed project plans. For example, the core project team details the strategy, more specifically the objectives, product and project definition, competitive advantage, and strategic focus, which includes the policies and behaviors necessary to create the competitive advantage (proposition 1). Detailed project organization, including the core team and functional groups (which provide resources, staffing criteria, and team building procedures), are defined (proposition 2). The team, in coordination with senior mangers, decides on the project process, adapting the company’s standard process and its plan for scope (e.g., WBS and work packages), time, cost, quality, risk response, etc. (proposition 3). For example, a project with high-pace and high-risk must be approached differently from a project with a slow-pace and low-risk. A decision regarding tool selection is made and executed in the planning process (proposition 4). The team defines a detailed set of metrics to measure project performance (proposition 5).

Third, the planning phase guides the activities in the execution phase. For example, the project team operates with efficiency considerations in mind. Moreover, the specified behavioral guidelines shapes the mindset of the project members (proposition 1). The extended team and functional groups are formed, and team building activities are undertaken for the team members to work more effectively together (proposition 2). The project team executes the project per the defined project process and manages aspects related to scope, time, cost, quality, risk, etc. (proposition 3). Identified tools are used to improve the process (proposition 4). Defined metrics are used to measure project performance (proposition 5). Cultural differences in different sites are addressed (proposition 6).

Finally, in the completion phase, the project is brought to conclusion per the guidelines provided by the C/O SWD PM framework components. For example, the product is checked for completion by the initial product definition. Plans to transfer the end product to its intended user are implemented (proposition 1). Gradually, the project organization is modified and disbanded (proposition 2). In addition, the release of the end product is accompanied by necessary activities, such as transfer of the end product, creation of manuals, maintenance information, or agreements, etc. (proposition 3). Tools are used to facilitate the completion phase (proposition 4). The success of the project is judged by the predefined measures (proposition 5).

Table 5 is a summary of these interactions. The secondary effect due to the synergy created by addressing all components simultaneously was demonstrated in Figure 2. Using a PM framework helps align efforts to steer the project. Alignment of all the different categories of efforts creates a synergy which results in improved effectiveness. As mentioned before, these efforts affect mediating managerial processes (project phases), which in turn improves the outcome of the projects.

    Project phases  
  Conceptual Planning Execution Completion
Strategy Objective Product definition Project definition Product definition Project definition Product definition Project definition Product definition Project definition
Organization Team building People Project structure People Project structure People Project structure
Process Risk management process Project management activities Product management activities Project management activities Product management activities Project management activities
Tools   PM tools PM tools PM tools
Metrics Key efficiency metrics All metrics Efficiency metrics Efficiency metrics
Culture     Organizational culture  

Table 5: Project management framework/mediating project phases interaction matrix

Conclusions

Contributions to Research

This exploratory study establishes a set of propositions and a theoretical framework on the successful management of C/O SWD projects. Our propositions point out different aspects of the C/O SWD PM system that are crucial for C/O SWD project success. These propositions can be used as a starting point for further research.

The theoretical framework that we propose demonstrates how our propositions are linked to the project success through the mediating project phases. The basic premise behind this model is that each of our propositions improves the internal dynamics of the C/O SWD project system, which in turn influences the project outcome. This theoretical framework is clearer, more comprehensive, and more explicit than the ones that are currently published in the literature. With this theoretical framework, we provide direction for further research and a structure for studying the interrelatedness of different aspects of the C/O SWD PM system. Past research on this topic focuses on singular issues; the interaction with other aspects within the PM environment (or a systems approach) is overlooked.

Contributions to Practice

This research also contributes to practice. The propositions that we present here constitute a set of higher level rules that the practitioners of C/O SWD projects can use. These rules point out the different aspects of the PM system and guide the project managers as well as the executives to account for these aspects during different phases of projects.

The higher level rules also act as key success factors. For example, our third proposition, “having a documented process” and communicating it to the team members can help overcome many problems that arise due to the distributed (in time and space) nature of C/O SWD projects.

Under each proposition, we present several recommendations that can also be used as critical success factors for C/O SWD projects. For example, using tools (like the Responsibility Matrix) for designating responsibilities, as recommended under proposition 2, may be taken as a critical success factor.

Limitations and Future Research

The major limitation associated with this research is the small sample size. Although our cases were selected along the principles of theoretical sampling (Eisenhardt, 1989; Yin, 1985), the number of cases required to make analytical generalizations have not been met. However, this research was intended to be of an exploratory nature. We aim to implement a full-fledged CSR on this subject building on the starting points provided by this research.

References

A guide to the project management body of knowledge (2000 edition). Newtown Square, PA: Project Management Institute.

Adams, J. R., & Caldentey, M. E. (1997). A project-management model. In D. I. Cleland (Ed.), Field guide to project management (2nd ed., pp. 48-60). New York, NY: John Wiley & Sons, Inc.

Aronson, Z. H., Lechler, T., Reilly, R. R., & Shenhar, A. (2001). Project spirit - a strategic concept. Paper presented at the Portland International Conference on Management of Engineering and Technology, Portland, OR.

Balachandra, R., & Friar, J. H. (1997). Factors for success in R&D projects and new product innovation: A contextual framework. IEEE Transactions on Engineering Management, 44(3), 276-287.

Berinato, S. (2001). The secret to software success. CIO, 14(18), 76-82.

Bersoff, E. H., & Davis, A. M. (1991). Impacts of life cycle models on software configuration management. Communications of the ASM, 34(8), 104-118.

Borys, B., & Jemison, D. B. (1989). Hybrid arrangements as strategic alliances: Theoretical issues and organizational combinations. Academy of Management Review, 14(2), 234-249.

Brooks, F. P. (1987). No silver bullet: Essence and accidents of software engineering. IEEE Computer, 20(4), 10-19.

Cooper, R. G. (2001). Winning at New Products (3rd ed.). Cambridge, MA: Perseus Publishing.

Cox, B. J. (1990). Planning the software industrial revolution. IEEE Software, 7(6), 25-33.

Duysters, G., Kok, G., & Vaandrager, M. (1999). Crafting successful strategic technology partnerships. R&D Management, 29(4), 343-351.

Eisenhardt, K. M. (1989). Building theories from case study research. Academy of Management Review, 14(4), 532-550.

Fichman, R. G., & Kemerer, C. F. (1993a). Adoption of software engineering process innovations: The case of object orientation. Sloan Management Review, 34(2), 7-22.

Fichman, R. G., & Kemerer, C. F. (1993b). Object-oriented and conventional analysis and design methodologies: Comparison and critique. IEEE Computer, 25(10), 20-39.

Glaser, B. G., & Strauss, A. L. (1967). The Discovery of Grounded Theory. New York, NY: Aldine Publishing Company.

Griss, M. L. (1993). Software reuse: From library to factory. IBM Systems Journal, 32(4), 548-565.

Henderson, J. C., & Cooprider, J. G. (1990). Dimensions of I/S planning and design aids: A functional model of CASE technology. Information Systems Research, 1(3), 227-254.

Herzog, V. L. (2001). Trust building on corporate collaborative project teams. Project Management Journal, 32(1), 28-37.

Hofstede, G. (1983). The cultural relativity of organizational practices and theories. Journal of International Business Studies, 14, 75-89.

Jarzabek, S., & Huang, R. (1998). The case for user-centered CASE tools. Communications of the ACM, 41(8), 93-99.

Jiang, J. J., & Klein, G. (2001). Software project risks and development focus. Project Management Journal, 32(1), 4-9.

Katzenbach, J. R. (2000). The metrics path to peak performance. Quality Focus, 4(2), 34-45.

Katzenbach, J. R., & Smith, D. K. (1993). The wisdom of teams. New York, NY: HarperBusiness.

Kerzner, H. (2000). Applied project management: Best practices on implementation. New York, NY: John Wiley & Sons, Inc.

Kiel, L. (2003). Experiences in distributed development: A case study. Paper presented at the International Workshop on Global Software Development, Portland, OR.

Lacity, M. C., & Willcocks, L. P. (2000). Relationships in IT outsourcing: A stakeholder perspective. London, UK: Templeton College, Oxford Institute of Information Management.

Lanubile, F., & Mallardo, T. D. (2002). Preliminary evaluation of tool-based support for distributed inspection. Paper presented at the International Workshop on Global Software Development, Orlando, FL.

Lee, J.-N., & Kim, Y.-G. (1999). Effects of partnership quality on IS outsourcing success: Conceptual framework and empirical validation. Journal of Management Information Systems, 15(4), 29-61.

Lei, D., & Slocum, J. W. (1991). Global strategic alliances: Payoff and pitfalls. Organizational Dynamics, 19(3), 44-62.

Linstone, H. A. (1999). Decision making for technology executives: Using multiple perspectives to improve performance. Boston, MA: Artech House.

Maidantchik, C., & da Rocha, A. R. C. (2002). Managing a worldwide software process. Paper presented at the International Workshop on Global Software Development, Orlando, FL.

Maznevski, M. L., & Chudoba, K. M. (2000). Bridging space over time: Global virtual team dynamics and effectiveness. Organization Science, 11(5), 473-492.

McDonald, J. (2001). Why is software project management difficult? And what that implies for teaching software project management? Computer Science Education, 11(1), 55-71.

Milosevic, D. Z., Inman, L., & Ozbay, A. (2001). Impact of project management standardization on project effectiveness. Engineering Management Journal, 13(4), 9-16.

Nicholas, J. M. (1990). Managing business and engineering projects: Concepts and implementation. Upper Saddle River, NJ: Prentice-Hall, Inc.

Nidumolu, S. R. (1996). A comparison of the structural contingency and risk-based perspectives on coordination in software development projects. Journal of Management Information Systems, 13(2), 77-113.

Oppenheimer, H. L. (2002). Project management issues in globally distributed development. Paper presented at the International Workshop on Global Software Development, Orlando, FL.

Orlikowski, W. J. (1989). Division among the ranks: The social implications of CASE tools for system developers. Paper presented at the Tenth International Conference on Information Systems, Boston, MA.

Pinto, J. K., & Slevin, D. P. (1987). Critical factors in successful project implementation. IEEE Transactions on Engineering Management, EM-34(1), 22-27.

Poli, M., & Shenhar, A. J. (2003). Project strategy: The key to project success. Paper presented at the Portland International Conference on Management of Engineering and Technology, Portland, OR.

Porter, M. E., & Fuller, M. B. (1986). Coalitions and global strategy. In M. E. Porter (Ed.), Competition in Global Industries (pp. 315-344). Boston, MA: Harvard Business School Press.

Pyysiainen, J. (2003). Building trust in global inter-organizational software development practices: Problems and practices. Paper presented at the International Workshop on Global Software Development, Portland, OR.

Rothstein, A. J. (1998). Outsourcing: An accelerating global trend in engineering. Engineering Management Journal, 10(1), 7-14.

Sabherwal, R. (1999). The role of trust in outsourced IS development projects. Communications of the ACM, 42(2), 80-86.

Schein, E. H. (1996a). Culture: The missing concept in organizational studies. Administrative Science Quarterly, 41(2), 229-240.

Schein, E. H. (1996b). Three cultures of management: The key to organizational learning. Sloan Management Review, 38(1), 9-19.

Schwartz, H., & Davis, S. M. (1981). Matching corporate culture and business strategy. Organizational Dynamics, 10(1), 30-48.

Shaughnessy, H. (1994). The practice of collaboration management. In H. Shaughnessy (Ed.), Collaboration Management. New York, NY: John Wiley & Sons.

Shenhar, A. J. (1999). Strategic project management: The new framework. Paper presented at the Portland International Conference on Management of Engineering and Technology, Portland, OR.

Shenhar, A. J. (2001). One size does not fit all projects: Exploring classical contingency domains. Management Science, 47(3), 394-414.

Shenhar, A. J. (2003). Strategic Project Leadership. Paper presented at the Portland International Conference on Management of Engineering and Technology, Portland, OR.

Shenhar, A. J., Levy, O., Dvir, D., & Maltz, A. (2001). Project success – A multidimensional, strategic concept. Long Range Planning, 34(6), 699-725.

Snow, C. C., Snell, S. A., Davison, S. C., & Hambrick, D. C. (1999). Use transnational teams to globalize your company. Organizational Dynamics, 24(4), 50-67.

Sobek, D., Liker, J., & Ward, A. (1998). Another look at how Toyota integrates product development. Harvard Business Review, 76(4), 36-49.

Strauss, A., & Corbin, J. (1998). Basics of qualitative research: Techniques and procedures for developing grounded theory (2nd ed.). Thousand Oaks, CA: Sage Publications.

The Association for Project Management body of knowledge. (2000). UK: The Association for Project Management.

Tipping, J. W., Zeffren, E., & Fusfeld, A. R. (1995). Assessing the value of your technology. Research Technology Management, 38(5), 22.

Whitehead, J. (1999). The future of distributed software development on the Internet. Web Techniques, 4, 57-63.

Yin, R. K. (1981). The case study crisis: Some answers. Administrative Science Quarterly, 26, 58-65.

Yin, R. K. (1985). Case study research: Design and methods (2nd ed.). Beverly Hills, CA: Sage Publications.

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.

Advertisement

Advertisement

Related Content

Advertisement

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