نقش مهارت حل مشکل تیم در پروژه های توسعه سیستم اطلاعات

Organizations are justifiably concerned about the quality of the information system that will drive the operations of an organization. The vagaries of the environment and multiple stakeholders create uncertainty in the requirements for an information system product that impedes development of a high quality product along common dimensions of efficiency, flexibility and responsiveness. The ability of a team to solve problems that arise before and during the course of the project can help overcome uncertainty of requirements. A project can be designed with both reactive and anticipatory mechanisms that heighten problem solving competency and improve product quality of the resulting information system. We develop a model based on work in new product development and test it with a sample of 119 information system (IS) development professionals to examine the expected relationship. The confirmed relationships indicate that IS development project managers should consider problem solving expertise when building a team that considers elements that prepare for the development environment creatively as well as coordinate effectively to achieve a quality IS product.

Information systems are most often developed within a project structure and seem particularly prone to failure (Schwalbe, 2009). The root of many failures is the inability to map the requirements of the users to the final product delivered (Robertson and Robertson, 2006). This is particularly difficult in the information systems development arena because of an inordinate amount of uncertainty in the desired information system on the part of the clients (Lee and Xia, 2005). Conversion of client needs into a final product is complicated by complexities based in ambiguity of information requirements, evolving business practices, and changing technologies (Hoorn et al., 2007 and Lee and Xia, 2005). The diversity of desires held by the eventual users of the system can prohibit development of sound specifications and interfere with effective communication of requirements between users and developers and even among project team members responsible for delivering a system meeting quality expectations, where quality considers flexibility, operational efficiency, and responsiveness (Davidson, 2002 and Nidumolu, 1995). Further, information system (IS) development is compounded by the complexities of having to organize the multiple components of hardware, software, infrastructure and trained personnel to facilitate business processes such as planning, control, coordination, and decision making (Schwalbe, 2009). In all, these conditions result in a moving target of requirements that are perceived differently by each individual and communicated across functional boundaries where different backgrounds and terminologies are in use (Chen et al., 2005). Just how these difficulties can be overcome is a large issue for IS development projects. Two major perspectives from the development literature are explored as to how to address the problem. Requirements engineering rose from the computer science side to define the best techniques to elicit requirements from the system's stakeholders (Robertson and Robertson, 2006). The processes are directed at acquiring the best specifications possible and how to modify the specifications when conditions change (Hickey and Davis, 2004). Much of the information system project research examines this issue through studies on risk and control (Jiang et al., 2009 and Wang et al., 2008). The thought here is that if risks can be identified then a portfolio of controls can be selected to be certain that the product tracks the specifications and that the specifications still represent the evolving needs of the stakeholders (Nieminen and Lehtonen, 2008). These two views consider procedures, techniques, climates and cultures that can improve the project process and outcomes. Recently, other disciplines have proposed a different strategy where managing projects is a matter of enabling the crossing of functions and knowledge bases (Soderlund, 2002). This perspective considers the skills and competencies of the project team members and argues that handling changes in a project environment can enhance the achievement of project success (Aladwani, 2002, Byrd et al., 2004 and Hoegl and Parboteeah, 2006). In particular, one set of competencies is required at the start of a project to generate the needed flow of ideas and creativity (termed centrifugal forces), while a second set of competencies are required during the course of the project to connect all of the essential elements and keep the project moving toward its goals (termed centripetal forces) (Sheremata, 2000). Centrifugal forces are those that gather the essentials for a project while centripetal forces are those that transform potential into action through integration. These forces are directed at solving the problems at distinctly different times and may require different sets of contradictory structural elements that must coexist. Unfortunately, empirical studies of this concept are not evident in the literature. The purpose of this study is, therefore, to examine the relationship between uncertainty and project outcomes by focusing on one of the most crucial meta competencies of a software development project team, that of being able to make decisions (Aladwani, 2002). By examining the link between the more problematic elements of achieving a high quality product and the actual product quality of the information system, we are able to address an important question: What is the relationship between problem solving competency held by an IS development project team and the quality of the system in light of uncertainties? The quality of the system considered consists of three dimensions: operational efficiency, responsiveness, and flexibility (Nidumolu, 1995). Further, which mechanisms contribute to the development of problem solving competence in an IS development project? Based upon the centrifugal and centripetal forces concepts we propose that anticipation mechanisms and reaction mechanisms are two determinants of a team's problem solving competence. Reaction mechanisms refer to a collection of actionable items to handle unexpected constraints and opportunities during product development. Anticipation mechanisms refer to actionable items that develop capabilities to anticipate changes and identify critical knowledge areas in the early phase of product development.

The purpose of our study was to examine the impacts of an IS development team's problem solving competency on the relationship between requirements uncertainty and system outcomes. Furthermore, based upon the Sheremata's (2000) centrifugal and centripetal forces model, we proposed that anticipation reaction mechanisms are two antecedents of developing the team's problem solving competency. Problem solving competency was found to contribute positively to product quality of the IS development projects as well as to reduce the negative impact of requirements uncertainty on the quality of the information system. Furthermore, anticipation mechanisms were observed to heighten the teams' problem solving competency. Further, a reaction mechanism was found to have a significant relationship with problem solving competency since anticipation mechanisms enable the teams to be prepared for possible changes and reaction mechanisms have the capability to implement an appropriate solution to solve the emerging problems. As suggested by conventional wisdom, requirements uncertainty detracted from product quality. However, the negative impact of requirements uncertainty on product quality is moderated by the IS development team's problem solving competency. The results suggested that problem solving competency may be essential to produce a quality IS product. It is costly to implement anticipation and reaction mechanisms on the IS development teams due to the requirements of experienced project team members, redundant resources and overlapping activities. When requirements uncertainty is low, the investment in problem solving competency might not yield much return. However, when requirements uncertainty is high, the teams with problem solving competency have substantial effect on product quality and the investments in problem solving competency can reap great benefits. What differentiates our study from previous efforts was that this study particularly examined a meta-competency in the project team and its impact on lessening the negative effects of requirements uncertainty. Team competency has not been well explored in the development literature (Kauffeld, 2006); however, researchers in other disciplines have suggested the enhancement of team competence as an alternative strategy for coping with a constantly changing environment (Hoegl and Parboteeah, 2006 and Soderlund, 2002). Requirements uncertainty is a unique problem in the IS development context. The high risks of changing requirements hinder the likelihood of IS development project success. While past researchers have examined the possible strategies in reducing requirements uncertainty (such as user involvement, prototyping and pre-project partnering) the ultimate goal is to have an effective IS development project team capable of handling changes and achieving the project goals on time and within budget (Jiang et al., 2002). This study adopts a different lens of competence development suggested by other disciplines to include both preparatory and reactive strategies (Sheremata, 2000 and Hoegl and Parboteeah, 2006) and argues that the ultimate goal should be to develop the team's problem solving competency so that IS development teams can deal with situation-specific changes and challenges to develop the products as planned. Other studies have considered the presence of organizational conditions as the antecedents of problem solving capabilities, while we consider actionable items. It is more than likely that both impact competencies, perhaps in an interactive fashion. Future studies should consider this possibility as value can be gained from both setting appropriate environmental conditions and taking effective actions. For the IS development project manager, this study points out the importance of team problem solving competency for IS product quality. In order to perform a project successfully, a project team requires a specific team competence of working together to solve problems as they arise. The team problem solving competency reflects one of the critical success factors of quality management – employee responsibility (Vitharana and Mone, 2008). The development team is empowered, committed to quality and rewarded for quality. Both total quality management (TQM) and ISO 9001 emphasize the value of employee contribution to quality. This study also provides possible actions to practitioners for developing team problem solving competency. The product development process is prone to tensions. Both anticipation mechanisms and reaction mechanisms should be implemented. IS development project managers should take actions to coach and direct the project team to develop team competence based upon these implemented anticipation and reaction mechanisms (Kauffeld, 2006). While anticipation mechanisms and reaction mechanisms bring opposing strengths to the development team in problem solving, the pattern of effects of these mechanisms has on problem solving under time pressure is the most important. The development team should have a positive attitude towards change and learn to anticipate changes in the early phases of IS development. Experienced designers and developers who have similar project experiences are valuable assets. This appears to be a keystone for facilitating anticipation (Verganti, 1999). Early involvement of the whole team and stakeholders can be critical for collecting information and expecting changes (Jiang et al., 2009 and Jiang et al., 2002). The project manager should also develop flexible resources in the development process such as highly skilled designers and utilize flexible and integrated design technology such as rapid prototyping and simulation. Overlapped development activities and additional allocation of resources can lessen the impact of late problems in the development phase and allow alternatives for the solutions. Flexible technologies and modular product architecture should be strongly preferred because they can restrict single changes only to minor parts of the product. When the development team can anticipate changes, they should be able to handle unexpected constraints and opportunities with minimal resource usage. When requirements are diverse because of multiple stakeholders involved in the development process, the standards of the quality of an IS can be problematic. The team problem solving competency enables the team to involve the diversified stakeholders early and utilize various techniques to reconcile the diversified requirements and reach an agreement on requirements and consequent quality standards. When requirements are unstable and likely to fluctuate in the process, the IS development project team should design modular structures and develop a range of alternatives for possible changes of requirements. However, IS development managers should be cautious in investing in project team competency since the team problem solving competency is needed primarily in high-risk projects which have large uncertainties and ambiguous objectives. The results of this study are also consistent with current practices of agility methodologies such as scrum and XP. Agile development emphasizes open communication, intense interaction and collaboration with customers, the delegation of decision-making authorities to development teams, and other tactics that encourage the gathering of required resources and the integration of a breadth of ideas. These practices can be categorized into anticipation and reaction mechanisms. The ultimate purpose is to cultivate a frame of mind, an attitude towards change, and a competence to anticipate and react to changes in an efficient and effective way. There are a number of limitations to this study. First, the sample frame used in this study is not random because the target is an alumni database of a single university in China. Potential bias may exist that restrains generalizability of the findings due to cultural influence and localized business practices. Second, although power tests indicated there was enough power to test the proposed hypotheses, the relatively small sample size is a limitation. Third, cross-sectional surveys as used by this study have limitations in attributing and substantiating affirmative causality. Fourth, the measure of team level constructs did not use aggregated responses from multiple team members. To an extent, this constrains the generalizability of the empirical results. Finally, although the results of this study were encouraging, the perception-based metrics might differ from an objective measure, or across stakeholders. This sample focused on the project team which might include a variety of stakeholders, but certainly not a full sample of those impacted by any new information system. Future studies are encouraged to adopt objective measures and reach a broader sample to validate and generalize the findings of this study.