Introduction
Information technology (IT) is one of the principal investment areas of American companies (Brynjolfsson & Yang, 1996). At the same time the returns from investments have not reached their expected level. Recent research has found that technological investments combined with related investments like employee training, new work practices and structural change, could lead to higher productivity. In essence, firms that invest in IT without investing in up-to-date work practices, such as improved project management, could be worse off in the end (Brynjolfsson & Hitt, 1998).
In the area of project management (PM), the use of information technology tools is also increasing. A survey of IIE Solutions readers indicated, that 20% of respondents used PM software; however, most of them used only the simplest features (Bounds, 1998). At the same time the spectrum of the available software solutions is very wide and diverse. A recent survey of PM software vendors included more than 120 different software packages (Project Management Software Survey, 1999). Software packages differ based on their features, complexity, compatibility and at last but not least—price. However, the efficiency of the software use does not depend only on the functional characteristics of the software. Brynjolfson and Hitt (1998) suggest that half of IT benefits come from the unique characteristics of the firm and the other half is related to the software in general. So the firm can control how to capture 50% of the possible benefits of software use. Choosing appropriate software, as well as, providing training and facilitating efficient PM team processes are some of the activities that can be undertaken to increase the benefits of PM software use and the success of the project in general.
This research will investigate the antecedents of PM software satisfaction and consequent software use practices. More specifically the attention will be devoted to the project characteristics, PM team characteristics and software training satisfaction as determinants of PM software use. Further this paper will investigate how the satisfaction with PM software affects the individual productivity and project success.
Theoretical Background
Research related to the subject of this study, can be divided in two streams. One research stream is related to PM and the other to information system use and its ensuing organizational impact.
The project management discipline incorporates and uses the concepts and theories from many other management disciplines. However, the distinguishing feature of project management is captured by the project definition itself—“a project is a temporary endeavor undertaken to create a unique product or service” (Duncan, 1996, p. 4). Projects, by their very nature are subject to the contextual vagaries of different environmental, organizational and internal factors and constraints. Combined with the increased attention projects receive in the organizational setting, the main focus of PM research concentrates on different factors that affect project success (Bryson & Bromiley, 1993; Deutsch, 1991; Ford & McLaughlin, 1992a, 1992b; Ford & Randolph, 1992; Fusco, 1997; Gobeli & Larson, 1987; Larson & Gobeli, 1989; McCollum & Sherman, 1991; Might & Fischer, 1985; Nicholas, 1989; Pinto & Slevin, 1987; Pinto & Prescott, 1988). While most of the above-mentioned studies looked at direct impact of different factors on project success, none of them has investigated the information system role in project success.
Exhibit 1. PM Software Use Model
On the software side, attention has been devoted to the information system implementation projects in other organizations (Deutsch 1991; Kwon & Zmud, 1987; Standish Group, 1995), rather than how the PM software could be used to improve project execution. Only recently, have studies looked at software use in project management practice (Fox 2000; Pollack-Johnson & Liberatore, 1998). At the same time considerable amount of attention is devoted to the comparisons of different PM software packages. For example, the Project Management Software Survey (1999) published by Project Management Institute is one of the most extensive. The survey compares different software packages in six categories (scheduling, cost management, risk management, resource management, communications management and process management), that are consistent with A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (PMI, 1996). Conversely, De Wit and Herroelen (1990) grouped the software management features in three levels based on their complexity: Level I is planning features, Level II is project updating and reporting features and Level III are resource scheduling features, permitting planning and scheduling of multiple projects with shared resources.
From the project perspective, the software implementation can be compared to the information system implementation in the organization. Aside from project management issues of the information system implementation, the user acceptance (satisfaction) of the system is by far the most critical factor in information system success (DeLone & McLean, 1992; Garrity & Sanders, 1998). The overall information system success is determined by three factors—Task Support Satisfaction (includes Decision-Making Satisfaction), Quality of Worklife Satisfaction and Interface Satisfaction. User satisfaction with increased software use leads to increase in individual productivity, which in turn affects the information system's organizational and/or project impact. The impact represents added efficiencies, effectiveness and/or quality (Sherman, 1997, p. 43). User involvement, user participation, and training satisfaction have been identified as determinants of information system success (Sherman, 1997, p. 52).
PM Software Use Model
Many factors and constraints determine successful and efficient information system use. The next challenge comes from determining the efficiency of software use. The Garrity and Sanders (1998) model is based on the premise that the information system use is determined by user task, quality of work-life and interface satisfaction (see Exhibit 1). For instance, when users are satisfied with the software they will be more likely to use it to increase their individual productivity and consequently increasing the efficiency of the project. Project characteristics and PM team characteristics are two new variables added to the model as determinants of the PM software satisfaction. Project characteristics include project's scope, size and complexity. PM teams characteristics are comprised of the team's member's individual characteristics (e.g., knowledge skills, values) and team's design characteristics (e.g. team's size and composition, team's roles, rules and procedures). Training Satisfaction variable is adopted from Sherman's Expanded model of Information System Success (Sherman, 1997, p. 55) and describes the users satisfaction with formal, informal or self-training he has received to use the software. Next few sections will provide more detailed review of different components of the PM Software model and their interaction.
Task Support Satisfaction
Task support satisfaction is the degree to which the software use satisfies the requirements of the tasks and activities the software user has to accomplish. For PM software, this relates to how well the package can satisfy particular project's planning, scheduling, analysis, control and other activities. Sherman (1997) identified three dimensions of the Task Support Satisfaction: Information Quality, Task-Technology fit and Decision-Making Satisfaction. In a project setting Task support satisfaction is affected by Project Characteristics, PM Team Characteristics and Training Satisfaction. Project characteristics cannot be changed and determines the task and activities necessary to be performed and available and necessary information. PM team characteristics determine the information processing process, that in turn affects information quality and decision making satisfaction. Finally training satisfaction affects the features used by the user. If the user is not comfortable with the different features, he will be very unlikely to use and consecutively will be dissatisfied with the software.
Quality of Worklife Satisfaction
Software use affects the way people perform their tasks and as a result affects their job satisfaction. One of the best examples of how software and technology affects worklife is the introduction of electronic mail in the workplace. Relatively straightforward and simple network feature, that has a profound affect on the way people work. Everybody expects short e-mail turnaround time and this forces workers to interrupt whatever he or she is doing. E-mail demands can lead to decreased worklife satisfaction.
Similarly PM software use coupled with PM team expectations affects the following previously identified constructs: task interdependence, schedule ambiguity, control over work, flexibility in scheduling hours of work, work method ambiguity, task specialization, autonomy, task significance and time pressure (Sherman, 1997, p. 96). Like to Task Support Satisfaction, the Training Satisfaction affects how comfortable a person feels with the software. If the software is providing difficulties for the user, because of inappropriate training, worklife satisfaction will decrease.
Interface Satisfaction
Interface satisfaction refers to the interaction between technology and user. Sherman (1997, p. 81) identifies two underlying dimensions of interface satisfaction system quality and service quality. System quality refers to the PM software interface that is used to enter, analyze and retrieve (output) the information. Service quality refers to the service associated with the software. Service quality includes vendor support, manuals as well as onsite support. As most of the PM of-the-shelf software has manuals and vendor support (PMSS, 1999), system quality would be a more important feature.
PM Software Use
The Project Management Software Survey (1999) provides a remarkable tool in consolidating information about different PM software features. The various software packages are grouped based on their support for different PM tasks: scheduling, cost management, risk management, resource management, communication management, and process management. Somewhat different PM software classification scheme is based on feature complexity levels (De Wit & Herroelen, 1990). Both schemes together provide the way to classify the wide spectrum of software features. Based on the classification, the frequency of feature use can be measured and used to determine software use patterns.
Project Characteristics
The mentioned literature of project success factors identifies many variables; however, in most cases there is no distinction between project internal and external factors. For efficient PM software use, this paper's interest is concentrated on project's internal characteristics (inherited from project's tasks and activities). Two distinct dimensions of project characteristics can be identified: qualitative and quantitative. Qualitative factors are associated with the project activities in terms of task complexity, diversity, rate of change (Ford & Randolph, 1992); task character and technology development (degree of new technology) (Deutch, 1991). Larson and Gobeli (1989) identify project complexity in terms of different departments involved and intricacy of project design. They also introduce the novelty of new methods and procedures used as a project difficulty measure. By combining these variables for an entire project, we can distinguish complexity and novelty of project logistics (project network logic) and technological methods and procedures. Although it is rather intuitive that logistically and technologically complex and novel projects are much more difficult to execute, than their simpler counterparts, the actual performance will depend on the previous experience of PM team. So the project planning of complex (logistically) projects will be more likely to use PM software, because task satisfaction will increase. This doesn't hold for technically complex and novel projects, because PM software could not address project's technical details.
Proposition 1: PM software use will increase with the increase of the logistical complexity of the project.
However, if the projects are similar to each other then the project-to-project comparisons can be used to improve the new project performance. The project similarity also provides opportunities for template reuse. However, only teams who are repeatedly working on such projects would be able to exploit these possibilities.
Proposition 2: PM teams historically working on similar projects will use more decision support/analysis tools than PM teams historically working on different projects.
Quantitative project characteristics involve total costs (Might & Fisher, 1985), project length and personnel time consumed (Ford & McLaughlin, 1992) are used as the descriptive of project size. Although they are used as control variables in nearly every empirical study, there is no very strong evidence of their impact on project success (Might & Fisher, 1985).
Team Characteristics
Recently the project teams are becoming more and more common. Bounds (1998) reports more than 94% of projects are run by project teams. That is consistent with Brynjolfsson and Hitt's (1998) observation that positive relationship exists between the use of information technology and self managed (directed) work teams (SMWT). Although not widely addressed in the project management literature, there exist major differences between teams in general and SMWT. SMWT “members have the authority, as a team, to make decisions about the work and to handle internal processes as they see fit to generate a specific team product, service or decision” (Yeatts & Hayten, 1998, p. 24). Yeatts and Hayten (1998) also reviewed the main models of SMTW and their characteristics. As a result they identified team characteristics that includes team member characteristics (knowledge, skill, abilities, personality, values interests and needs) and team design characteristics (goal clarity, job design, team size and composition [role and personal diversity, stability], decision-making methods, work norms, team roles and team leader). In the study of cross-functional team cooperation Pinto, Pinto, and Prescott (1993) found that goals, member accessibility, team rules and procedures, and cross-functional cooperation are positively correlated to team performance, which is measured both as task and psychosocial outcomes. However, as team size increases project efficiency decreases, because of more complicated communications, decreased interpersonal processes and required administrative burden (Yeatts & Hayten, 1998, p. 258). Thus, larger team size reduces the communication effectiveness among PM team members. Theoretically, larger teams will use more communication features to streamline the communication process and counterbalance the potential loss of communication effectiveness. That leads to the following proposition.
Proposition 3: Increase in project team size will have positive impact on the use of communication features.
As the team size increases the team members will share only common information and each individually will become more specialized. So all team members together will use simpler software features at the level of lowest common feature complexity.
Proposition 4: Larger project teams will use simpler software tools.
As already noted a team's rules and procedures positively relate to project success. Part of such procedures consists of constant monitoring of a team's activities and performance. In the PM environment, this can be achieved by constantly monitoring project performance. Most PM software packages allow project updates and performance monitoring. However, these features will be more extensively used if the project team has an established team charter of rules and procedures.
Proposition 5: PM teams with established charter of team roles and procedures will be more likely to use project performance monitoring features than teams without charter.
A study of R&D team longevity and communication impact on project performance (Katz, 1982) revealed that project performance and team communications (internal and external) have bell curves with respect to team longevity. In other words, team communication increases after the team is formed and starts to decrease over time. A similar pattern would be expected in PM software use.
Proposition 6: Long tenure PM teams will use significantly less communication features than younger PM teams.
Previous research of team heterogeneity suggests that a team's diversity have positive effects on the quality of decision-making provided that the team can establish productive working relationship (Yeatts & Hayten, 1998, p. 263). Team heterogeneity tends to increase the amount of different information exchange resulting in the team's engagement in more thorough decision-making process. Many PM software packages include analysis capabilities to facilitate the decision support process. Accordingly, highly diverse teams will use more analysis and decision support features.
Proposition 7: The PM team member heterogeneity is positively related to PM software decision support and analysis feature use.
Training Satisfaction
Training satisfaction refers to the software user's satisfaction with training provided to use a particular software. Due to the diverse backgrounds software users, and their different training preferences, the training satisfaction is considered more important than actual training provided (Sherman, 1997, p. 109). Satisfactory training will allow users to feel more comfortable with the software, so they will be more likely to use and be satisfied with it. If the user is not satisfied with the training, he or she will be less motivated to investigate and use different features.
Project Success
Despite the rather large volume of research done to investigate project success, there is not a consensus as to the measurement that comprises or describes successful project. Use of quantitative project performance matrix, such as cost, time, and quality, fail to capture qualitative dimensions of project performance, such as perceptions of project success. For instance, the project can be substantially over budget, but it is still perceived as success taken into account project's success in achieving the expected goals. An alternative approach is to focus on perceived project success by different stakeholders (Ford & McLaughlin, 1992; Katz, 1982; Larson & Gobeli, 1989). Inherent in this approach are the stakeholders’ considerations of quantitative and qualitative success factors. For this study, the second approach will be used as the determinant of project success.
Following the PM software use model, project performance is related to the PM software use satisfaction. If the users are more satisfied with their software their productivity will improve. That leads to the following proposition:
Proposition 8a: User satisfaction with PM software will be positively related to user productivity.
Proposition 8b: User satisfaction with PM software will be positively related to project success.
Conclusion
The paper has developed a theoretical model to investigate the effects of project characteristics, PM team characteristics and user training satisfaction on the PM software uses. This framework can further be used for empirical research to investigate the significance of the derived propositions. Such research would provide valuable insight into one of the PM tools—software and would be useful both for PM practitioners and PM software developers.
PM practitioners will be able to better choose the best software for their needs, based on theoretical considerations of the model and empirical evidence collected. As this research examines the entire information system implementation in project management setting, it provides an outline of other investments and activities necessary for successful implementation of project management software in different project and organizational environments.
For PM software developers the research provides insights into the tools PM practitioners actually use in different project settings. PM software developers could use this to further advance PM software.
