Creating high-performing software development teams Jason M. Pattit and David Wilemon Innovation Management Program, Martin J. Whitman School of Management, Syracuse University, Syracuse, NY 13244, USA.
[email protected]
With software development (SD) constituting one of the largest portions of corporate capital expenditures, an organization’s capability to manage the SD process is a key success factor. Additionally, SD is increasingly an important driver of successful technology-based products as evidenced by the interdependence of software and hardware in telecommunications equipment, computers, medical devices, measurement/monitoring equipment, and industrial controls equipment. Building high-performing SD teams that utilize state-of-the-art development processes increases the likelihood that firms can compete and meet the ever-expanding expectations of stakeholders. We first introduce the generic process models of SD and then address a number of major issues that can arise in the course of building highly effective SD teams. We then identify a number of best practices that can improve SD teams, both in terms of technical and intragroup aspects, and the role that senior management can play in reinforcing effective project team behaviors. Finally, we address the concept of capturing learning from SD project teams and advance several areas for future research.
1. Introduction
S
uccessfully managing software development (SD) projects is critical for many firms regardless of size. Additionally, SD is increasingly an important driver of successful technology-based products as evidenced by the interdependence of software and hardware in telecommunications equipment, computers, medical devices, measurement/monitoring equipment, and industrial controls equipment. According to a Standish Group study, many commercial software projects are so poorly planned and managed that in 2000 almost one-fourth were canceled outright, creating no final product (Mann, 2002). These canceled projects cost firms $67 billion, while overruns on other projects accounted for another $21 billion (Mann, 2002). Mann (2002) states that 80% of a software project’s budget is dedicated to repairing bugs, which does not even include the costs related to post-release service and patches. Norris et al. (1993) report that surveys of large SD
project effectiveness show that 62% of hightechnology companies suffer at least one major failure over a 5-year period. The prominence of software in society and in corporations is rivaled only by the difficulty encountered in its development (Sawyer and Guinan, 1998). Sawyer and Guinan (1998) report that about 40% of US corporate capital expenditures are directed toward software, offering an indication of how vital software is to the economy. Recent efforts to implement enterprise software (i.e. software developed within a company for internal use) demonstrate just how critical it is to successfully manage SD projects. High-profile examples of Enterprise-Resource Planning system installations that went awry at firms such as Whirlpool Corporation, FoxMeyer Corporation, and W.L. Gore & Associates, puts a very public face on the importance of successful SD and implementation (Caldwell, 1998; Montoya, 1998; Boudette, 1999; Diederich, 1999; MacDonald, 1999).
R&D Management 35, 4, 2005. r Blackwell Publishing Ltd, 2005. Published by Blackwell Publishing Ltd, 9600 Garsington Road, Oxford OX4 2DQ, UK and 350 Main Street, Malden, MA 02148, USA.
375
Jason M. Pattit and David Wilemon According to Norris et al. (1993), there is a 30% chance of any major software project becoming a runaway – and the larger the initial project budget, the more prone it is to overrun and overspend. It is important to gain an understanding of why SD projects encounter problems such as overruns and delays. One perspective can be found in an observation from Brooks (1975): ‘How does a project get one year late? One day at a time.’ A second quote echoes this sentiment: ‘Projects don’t slip a month at a time – they slip an hour at a time’ (Norris et al., 1993). Michiel van Genuchten (1991) notes the following major reasons for cost overruns and schedule delays: Over-optimistic cost estimation Frequent changes in design and implementation Poor planning Lack of SD tools van Genuchten’s (1991) study suggests that the reasons for overruns and delays are not only technical in nature. In fact, product and toolsrelated reasons represent most of the technical reasons, but they comprise only one-third of all of the reasons for overruns and delays (van Genuchten, 1991). van Genuchten (1991) concludes that this finding concurs with Thamhain and Wilemon’s (1986) investigation of the reasons for delays in new product development projects. Their study indicates that a significant number of overruns and delays can be attributed to organizational, managerial, and human aspects. SD encompasses managing the technical aspects (i.e. coding), as well as teamwork issues. SD needs to be examined as both a social/behavioral as well as a technical process (van Genuchten, 1991; Norris et al., 1993; Whitaker, 1994; Carmel and Bird, 1997; Gobeli et al., 1998; Sawyer and Guinan, 1998; Jiang and Klein, 2000; Mann, 2002; Sheremata, 2002).
2. Focus Our study focuses primarily on the major process and teamwork issues encountered during the development of enterprise software. We also address a gap in the literature between the technical guidelines provided to programmers, and the literature geared toward middle or senior management that is often too simplistic to be of much value in creating and maintaining effective SD teams and repeatable SD processes. This study is also directed to vendors contracted to provide 376
R&D Management 35, 4, 2005
enterprise software, as they frequently experience the same problems faced by in-house development teams. We begin with a brief discussion of SD process models, and put technical activities into a managerial context. We then examine the major technical and ‘people’ issues development teams often encounter from a managerial perspective. We offer several ‘best practices’ identified from the literature, and then propose a diagnostic tool that management and SD project leaders can use to evaluate the performance of their teams. We offer several suggestions regarding what senior management can do to facilitate more effective and efficient SD projects, as the situational nature of SD projects often prohibits the use of rigid, ‘outof-the-box’ solutions. Finally, we examine how SD provides numerous opportunities for organizational learning, synthesizing some of the most important thinking from this area of the literature.
3. The SD Process One way to define the SD process is as a mechanism for tying together the numerous and often complex tasks necessary to create software products. Superior performance is facilitated by having a process for organizing the many people and tasks involved in SD development. SD processes need to be understood in order to allocate responsibilities and activities among team members and track performance as the product is being developed. This section examines different models of the SD process and the role that they play in shaping and resolving technical and people issues. The literature notes numerous generic models outlining the SD process, including code-and-fix, waterfall, incremental, and iterative (Whitten, 1995; McConnell, 1996; Cantor, 2002). Simple schematics highlighting the general steps in each model are presented in Figures 1–4, respectively. There are also advanced SD models, but essentially the origins of these models can be traced to one or more of the generic models. Each model has distinct advantages making it useful for specific circumstances. The following provides a short explanation of the context under which each model excels: Code-and-fix: small projects with loosely defined goals. Waterfall: medium-to-large projects with welldefined requirements. Incremental: large projects with pieces that can be developed in parallel. r Blackwell Publishing Ltd. 2005
High-performing software development teams Iterative: large projects where the product is not fully defined, and the need exists to begin development more quickly and create a very early version that will demonstrate the look and feel of the product (Whitten, 1995).
Coding
Testing
Delivery Figure 1. Code-and-Fix Model. Sources: Whitten (1995), McConnell (1996).
Requirements
Definition Design Coding
Testing
Delivery Figure 2. Waterfall Model. Sources: Whitten (1995), McConnell (1996).
Ideally, the process model chosen will provide guidelines for how the SD product will be developed without being overly restrictive. The process model should be seen as a flexible tool used to help define the interactions between developers and customers, developers and developers, and management and developers (Whitten, 1995). Whitten (1995) offers a comprehensive list of key factors, which need considering as a project leader searches for the right model, including the following: Project size; degree that product components are documented and understood; need for customer involvement during development; single or multiple customers; available SD and product management tools; experience and skills of project members, including management; physical proximity of project members to one another; number of locations and departments involved (author added italics to indicate change, de-
Requirements
Definition
Design
Low-Level Design
Low-Level Design
Coding & Testing Unit Component Testing
Delivery
Low-Level Design
Coding & Testing Unit
Coding & Testing Unit
Component Testing
Component Testing
System Test
Figure 3. Incremental Model. Sources: Whitten (1995), McConnell (1996).
r Blackwell Publishing Ltd. 2005
R&D Management 35, 4, 2005
377
Jason M. Pattit and David Wilemon Iteration 1
Iteration 2
Requirements
Iteration 3
Requirements
Requirements
Definition
Definition
Definition
Design
Design
Coding & Testing Unit Component Testing
Design
Coding & Testing Unit Component Testing
Coding & Testing Unit
Component Testing System Test
Delivery
Figure 4. Iterative Model. Sources: Whitten (1995), McConnell (1996), Cantor (2002), Humphrey (2000).
partments are more relevant to this study than the original companies); magnitude of anticipated changes during development; staffing profile; strategic focus of project. Taking a closer look at the generic models, each is comprised of similar activities. Once Whitten’s key factors are considered, the requirements of the project help dictate the activities that are vital and need to be implemented by the project leader. Once the activities are selected, the project leader must determine how the activities are interconnected (i.e. Does one activity require a prior activity to be completed? Can they be done in parallel?). The specific order of the activities in the process can be tailored to fit the situation (i.e. product size and type), and the project team should examine and document the circumstances leading to the decisions behind the specific project organization. It is also useful to document how each activity is typically carried out (i.e. Is a formal approval necessary to move to the next step? Is a formal document the outcome of a step?). In order to capture project learning, it is critical to document how to improve the process. This can be done through the use of change requests, deviation requests, and ‘post project review’ sessions (Whitten, 1995). Once a process map is created, it is necessary to obtain buy-in by management of the process as it is not only a technical roadmap, but also a roadmap for ap378
R&D Management 35, 4, 2005
praising performance. In order to reinforce support for the process, it should be used and improved, and frequently reviewed by management to determine if it meets expectations. There are a number of activities needed to build a roadmap or lifecycle for a SD project. We define these activities in a simplified manner, in an effort to make the interface between programmers and managers more transparent, which can facilitate effective, informed communication. While not all of the activities are needed for every SD project (Hoch et al., 2000), generally the following are included (Whitten, 1995): Requirements: description of the customer and/or market problems that need to be solved, not the particular solution to the problem. Objectives: solution to the problem or set of problems described in the requirements. Specifications: detailed description of the externals (i.e. what the product will look like to the users). High-level design: how the components (major pieces) work with one another, with the surrounding hardware and software environment, and internally. Publication and content plans: describe the content and design of each publication to be included in the product. Test plans: documents that describe the who, what, when, where, and how for a designated test. r Blackwell Publishing Ltd. 2005
High-performing software development teams Low-level design: required to understand how modules within each component will work technically with one another, and how the modules will be internally designed (i.e. program path). Coding: act of writing instructions that are immediately computer recognizable or can be assembled or compiled to form computerrecognizable instructions. Unit and function test: first time the code and each function from one or more modules is tested. Component test: first test in which all components are tested together. First-draft publications: first release of user documentation available for review by project group. System test: major functions of product are tested in user’s environment. Second-draft publications: release of revised user documentation for final review and approval. Regression test: final testing of the product. Package: the entire collection of the product, such as code and publications. Delivery: final product is distributed to the customer. These activities can be grouped into three phases that make up the project lifecycle: Requirements Capture (bullets 1 and 2), Design and Testing (bullets 3–12), and Customer Engineering (bullets 13–16). Figure 5 shows the typical allocation of time to each phase, based on several hundred SD projects, as development progresses from initiation to implementation (Norris et al., 1993). McConnell (1998) subscribes to a similar understanding of how projects progress from problem definition to solution delivery. The inclusion of the Requirements Capture Phase and the funnel shape in Figure 5 is more accessible than McConnell’s graph (1998, p. 51), making it more useful to SD participants. The Customer Engineering Phase in either representation indicates that the technical aspects of SD are only one part of the project lifecycle. The arrows entering the left of the funnel are the drivers, or inputs, to the process. These inputs provide the information needed to develop project requirements by bringing together customer needs, management priorities and competitive pressures. Norris et al. (1993) state that the Requirements Capture Phase is represented by the broad side of the funnel to indicate that a range of options is open at this phase. They also note that because a shared view of what the r Blackwell Publishing Ltd. 2005
project should be focused on is key here, attention to people/team issues are crucial in this phase. A general observation is that the process is seldom linked to the people (Norris et al., 1993). Defining project roles and establishing the purpose and structure are just a few of these crucial team management issues. Norris et al. (1993) report that the typical split of activity in the Requirements Capture Phase, from the projects studied, is as follows:
40% establishing the scope of the project; 25% defining exactly what the need is; 25% writing the business case; 10% establishing and analyzing a formal statement of requirements.
The Design and Testing Phase is narrower in Figure 5 than the requirements phase, indicating that it is typically better understood and has numerous tools and methods to help expedite most of the technical aspects. The typical split of activities found in the Design and Testing Phase is as follows (Norris et al., 1993):
20% 20% 30% 30%
specification and design; prototyping and testing of ideas; implementation; test and rework.
The final phase, Customer Engineering, is the narrowest in Figure 5. While this suggests that the least amount of time is allocated to activities in this phase, it does not indicate that spending less time in this phase will make the project more successful. In fact, Norris et al. (1993) state that this phase is ill covered by conventional theory, with new problems revolving around how best to meet precise end results. Norris et al. (1993) note that the approximate split of activities in the Customer Engineering Phase, from the projects studied, is as follows: 25% installation testing; 50% re-engineering for acceptable field performance; 15% adding essential user features not in original specification; 10% supplementary information for maintenance. Figure 5 provides a frame of reference that SD team members and managers can use to assess their own projects. While the study cited does not claim that these are ideal allocations of time, as evidence linking the original data and the corresponding success rates are not available, our intent is to suggest to SD teams to view their R&D Management 35, 4, 2005
379
Jason M. Pattit and David Wilemon Project Inputs/ Drivers
Requirements Capture Customer
Coding & Testing
Needs
Management Priorities
Customer Engineering
Competitive Pressures
Stable Product
Project Initiated
First Release
Figure 5. 3-Phase Process. Source: Norris et al. (1993).
projects as more than just technical challenges. Figure 5 is meant to help change the mindset of SD participants, encouraging them to tackle organizational issues in conjunction with their technical challenges. Enterprise SD makes use of these general process models, with the substitution of interfacing with internal customers. For example, in the Requirements Capture Phase, the development team will focus on problems the firm would like to solve by creating software for internal use. While this software may solve problems related to interfacing with the external market, including activities dealing with suppliers or customers, the real goal is to streamline some function within the firm through the use of advanced technology. Therefore, developers (and perhaps supporting SD vendors) will have to work closely with internal customers to design an adequate solution for the requirements generated by the internal users.
4. Major issues SD teams encounter It is critical for team members to identify project challenges and issues as early as possible in the development process. To this end, we offer several indicators team members can use to recognize the patterns that could potentially lead to failure 380
R&D Management 35, 4, 2005
along with methods for minimizing/eliminating the problem. It is important that team members have this type of tool, as the demands placed on a team may prohibit them from addressing issues in a timely manner unless they are identified and diagnosed as soon as possible. The process models presented (see Figures 1–4) deal mainly with the technical flow of the project. As noted, technical issues are not the only challenges SD teams encounter; people issues and problems arise when software is being developed. In fact, Norris et al. (1993) state that even though the commonly held belief is that improved technology tools and methods will make a project better, this is not always accurate. As Pressman (1996, p. 18) observes, ‘A process that stifles creativity will encounter resistance.’ However, as long as the basic needs of communication and automation are fulfilled, further technology support provides only a marginal effect (Norris et al., 1993). Nevertheless, satisfying a team’s communication needs can be a major challenge. Carmel and Bird (1997) define a team as an organizational work unit with a clearly defined task and a high degree of interdependence and intracommunication among its members. In order to achieve a successful project outcome, high performance is expected from team members. Team size can lead to concerns about communication; a prominent r Blackwell Publishing Ltd. 2005
High-performing software development teams ‘people issue.’ There is much support in the literature for the use of small project teams (e.g., Whitten, 1995; McConnell, 1996; Carmel and Bird, 1997; McConnell, 1998; Sawyer and Guinan, 1998; Humphrey, 2000; Jiang and Klein, 2000; Whitehead, 2001), but with the development of enterprise software, teams often reach sizes that are difficult to manage. It is not unusual for enterprise SD teams to involve members from various functional groups along with the firm’s information technology staff, greatly expanding the size beyond that of teams deployed for software implementation for a specific functional group. The number of communication links between team members is equal to [n (n 1)]/2, where n equals the number of team members (Carmel and Bird, 1997). Therefore, small teams have fewer links, which can lead to less communication quality deterioration. For example, a team with eight members has only 28 links while a team with 50 members has an astonishing 1,225 links. The shear number of links suggests that it is difficult for a team of this size to share vital project information and communicate effectively. This exorbitant number of links is clearly a hindrance to effective communication for a large enterprise SD team. What other factors lead to ‘people issues’ in SD teams? The age and complexity of a firm and the type of projects undertaken can also contribute to ‘people issues.’ Young firms usually exhibit the characteristics of an ‘organic organization,’ while more established firms are often characterized as ‘mechanistic organizations.’ Organic organizations are entrepreneurial in nature with open communication, while mechanistic organizations have more formal rules, policies, procedures, and formal communication channels (Miller, 1986). Gobeli et al. (1998) state that the development of large software systems is mainly a learning, communication, and negotiation process, and collaborative problem solving is more likely to occur in small, rather than in large teams. Organic organizations are better suited to collaborative problem solving, because they are typically composed of small teams, but as an organization becomes more successful it grows. Greiner (1972) recognizes that as organizations grow, they go through stages of evolution and revolution. A firm that was once characterized as organic may evolve into a mechanistic organization in order to accommodate growth. Problems such as coordination and communication magnify as new functions emerge, levels of management hierarchy increase, and tasks become more complex and interrelated (such as enterprise SD and deployment). r Blackwell Publishing Ltd. 2005
Another factor that can lead to ‘people issues’ is the overall lack of a ‘software development team culture.’ Curtis (1989) reports there is little attention paid to SD methods based on socialization patterns and the needs of developers. Sawyer and Guinan (1998) note that ‘people issues’ arise because of the low degree of shared norms that tie software developers together. They also note norms such as loyalty and supportiveness as part of the growing culture of software developers. However, many organizations fail to stress the factors leading to a lack of communication and intragroup coordination problems. In fact, the skills surrounding coordination, communication, conflict management, and supportiveness are not typically part of the formal education of software developers (Sawyer and Guinan, 1998). Team members are often required to develop these skills on the job, often during highly trying SD situations. Gobeli et al. (1998) report that an average project manager spends over 20% of his or her timehandling conflict. However, the literature on SD fails to address a number of the frequently encountered ‘people issues,’ especially how to recognize and counteract these problems, thereby reducing the time a project manager spends handling such issues. Table 1 offers a compilation of several major problems, the sources of these problems, and recommendations for minimizing/eliminating these problems. While Table 1 is not exhaustive, it does contain the typical problems encountered in most SD projects. This information is the result of an extensive review of the literature as well as our own experiences in dealing with SD teams.
5. ‘Best practices’ for SD projects ‘Best practices’ can be thought of as activities, strategies or approaches that are effective in solving numerous problems. The SD literature is replete with ‘best practices’ lists including DeMarco and Lister’s (1987) people ware practices, and McConnell’s (1996) rapid development ‘best practices.’ Unfortunately, these lists often tend to focus only on human resource practices or only on technical practices. The ‘best practices’ we note below have been identified through an extensive review of the literature on managing SD efforts, and the personal experiences of the authors working with and observing several SD teams. These ‘best practices’ differ from the nearterm solutions that are immediately practical to solving the problems presented in the previous section in that they are global and enduring R&D Management 35, 4, 2005
381
382
R&D Management 35, 4, 2005
Use of focused meetings, memos Encourage informal communication Formal methods can help guide developers regarding when and what to communicate
Proactive management policy to engage team Reward systems that encompass entire team Open-door policy-time to discuss issues in private and how to approach rest of team with concerns Visible, senior management
Provide opportunities for developers to attend group dynamics, conflict management and listening skills seminars Leaders and team members focus on project objectives during projects Use surveys and ‘workout’ sessions to assess and improve team performance Look for team opinion outliers Confront team members who are outliers Build and maintain management support Help management ‘brush up’ on technical issues Management interfaces with tech staff to keep abreast of project technical challenges
Infrequent or inappropriate use of meetings, memos, and automated communication tools Mixed messages Physical proximity (i.e. team members in remote locations) Specialization of tasks
‘Punishment’ for a failed task as opposed to using failure as a learning experience Perceived laissez-faire attitude toward team and its goals by management – ‘Why should I care if they don’t care that we are late/ over budget?’
Uneven interaction between the more technically experienced and newer developers Frequent member turnover Feelings of inferiority by younger/less experienced members Withdrawing from the team New members may possess superior technical skills, but inadequate teamwork skills
General dislike Group compromised of confronters suddenly interjected with someone who prefers to smooth over conflicts Conflicting agendas Egos
Perception that management is not behind project Perception that management does not understand technical aspects– ‘Why should I tell them something they won’t understand?’
Communication breakdowns
Lack or loss of management support
Ineffective teamwork
Personality conflicts
Inability to work with senior management
Attempt to build small teams w/complementary players Avoid ad hoc teams If possible, form semi-permanent teams of developers Try to balance experience levels Avoid adding manpower to make a project fall back in line – Brooks’ Law ‘Adding manpower to a late project makes it later’–w/out considering who you are adding
Minimizing/eliminating this problem
Sources of this problems
Major problems
Table 1. Major challenges software teams encounter.
Jason M. Pattit and David Wilemon
r Blackwell Publishing Ltd. 2005
Interpersonal and team training skills seminars Teach leaders to use confrontation and give-and-take approaches to conflict management Develop a learning culture and reinforce that project leaders are responsible for fostering learning within their teams Use semi-permanent teams Continually interface with customers to solidify objectives Remove ambiguity of goals and roles Involve customer in a and b testing Engage the customer at every step
Frequent turnover of team members Technological changes during project Inexact, fluid goals that continually change during project
Customer reticent to commit details Developers fail to show early progress to customers Multiple developers and users and attendant communication problems
Poor project leadership
Excessive changes
Ineffective developer/user working relationship
r Blackwell Publishing Ltd. 2005
Sources: van Genuchten (1991); Norris et al. (1993); Whitaker (1994); Whitten (1995); McConnell (1996); Carmel and Bird (1997); Gobeli et al. (1998); McConnell (1998); Sawyer and Guinan (1998); Humphrey (2000); Jiang and Klein (2000); Sheremata (2000); Whitehead (2001); Cantor (2002); Mann (2002).
project leader behavior dysfunctional fails to deal with conflict (withdraws or avoids) who ‘smoothes over’ conflicts versus confronting them
Develop hardware and software in parallel, when possible Utilize common modules to minimize ambiguity/complexity Provide training
Software designed before hardware completed Highly complex applications High degree of novelty/innovativeness
Technical conflicts
Inexperienced Project leader Project leader Project leader
Use team-based rewards Clear organization and formulation of project objectives, remove as much uncertainty about goals as possible Interface with customers frequently, express understanding of difficulties Stress value of integrative teamwork
Milestones poorly planned, reflecting only team’s objectives, not customer’s Customer reticent to commit real needs Individuals work on personal tasks and responsibilities w/out thinking about overall goals of project functionality and integration
Conflicts over personal goals/ team goals/ customer goals
High-performing software development teams
R&D Management 35, 4, 2005
383
Jason M. Pattit and David Wilemon practices that can be instituted throughout the organization. While these ‘best practices’ are valuable to understand, they may not be applicable to every SD project. We suggest that SD team leaders carefully review their team’s situation and compare where they might be encountering problems versus the suggestions offered here. While our list has practices in common with both DeMarco and Lister (1987) and McConnell (1996), we have attempted to make it easier for team’s to identify which practices are applicable by organizing our list into three types of problems. The three problem types we identify include those that are purely organizational or interpersonal in nature, those that are purely technical in nature, and those that exhibit a combination of organizational/interpersonal and technical elements. This categorization can be important in understanding the study of SD ‘best practices.’
5.1.2. Use small, effective teams. As noted, when a team grows by one member, the number of communication links increases by (n* 1), where n* represents the new number of team members. Managing the increased links can become difficult and lead to communication breakdowns and conflicts among team members. Keeping team size fewer than 10 is advisable in most SD projects (Carmel and Bird, 1997; Sawyer and Guinan, 1998; Jiang and Klein, 2000). When teams are held to 10 members or less, and the members are physically located in close proximity, it can facilitate team communication and coordination. This may not be practical for enterprise SD teams, but one way to overcome this limitation is to organize small sub-teams within the main SD team (McConnell, 1996). Each subteam can appoint a representative to report to the main team. This helps keep the number of representatives reporting to the main team manageable and helps facilitate open communication.
5.1. Best practices: organizational/ interpersonal nature
5.1.3. Proactive company policies toward conflict management. Firms are just beginning to emphasize a ‘software development team culture.’ Sawyer and Guinan’s (1998) study of a major software manufacturer revealed that exposure to group dynamics, conflict management, and listening skills seminars helps develop this culture among software developers. Another proactive policy is the use of a reward system that utilizes formal and informal acknowledgment of high team performance and also emphasizes that teamwork is critical to success (Sawyer and Guinan, 1998). This policy helps reinforce that conflict management is important, because rewards are based on how well a team can function and mitigate conflict versus how well an individual can perform a task. In addition, a practice that contributes to the mitigation of conflict is to use frequent ‘face-to-face’ meetings. These meetings are used to resolve interpersonal conflicts as well as technical issues. Team members will discover that as they interact and begin to put group dynamics, conflict management, and listening skills to use that they spend less time dealing with interpersonal issues at these meetings, and more time solving important technical problems.
5.1.1. Clearly define tasks and role assignments. Gaining frequent feedback from the customer helps promote synthesis of different points of view, but if the project goals are not well defined from the outset, individuals will tend to focus on their own goals (Jiang and Klein, 2000). During the team member selection process, specific tasks and their outcomes need to be clearly communicated, along with reporting requirements and responsibilities. One way to ensure that this information is well documented and clear is to create a project plan agreement. Some developers refer to this agreement as a ‘project contract book.’ Karolak (1998) offers the following outline for what should be contained in such an agreement: Tasks to be performed
What? By whom? When? Where?
Standards and methods to be followed Communication and status review methods Equipment and tools needed Interface issues
With other software packages With hardware With industry standards Managing business/technical conflicts 384
R&D Management 35, 4, 2005
5.1.4. Confronting and give-and-take conflict management style. Gobeli et al. (1998) report that project success can be explained by effectively managing conflict. Two particularly effective conflict management styles are confronting and give and take. Confronting is recognizing that a disr Blackwell Publishing Ltd. 2005
High-performing software development teams agreement exists, and then engaging in collaborative problem solving to reach a solution to which the conflicting parties are committed (Gobeli et al., 1998). Give and take recognizes that a disagreement exists, and then reaching a compromise solution. These methods are the most effective when they involve the entire team, without the project manager making a unilateral decision or the stronger members dominating the less assertive members. These methods also reinforce the lessons learned from group dynamic, conflict management, and listening skills seminars, and provide the team an opportunity to put these skills into practice in real SD project situations.
5.2. Best practices: technical nature 5.2.1. Utilize a development process. Selecting the appropriate SD process for a project is critical because the process guides almost all other activities. As noted, numerous models exist for SD, but most modern SD projects employ more advanced methodologies over the simple waterfall process. Given the sophistication of enterprise software systems, sequentially defining the entire problem, designing the entire solution, building the software, and then testing the product at the end is seldom practical. Rational, a firm specializing in software engineering processes, advocates that the iterative approach discussed earlier be employed. They maintain that an iterative process is necessary because it affords an increased understanding of the problem through successive alterations. This type of process allows projects to grow incrementally, and develops effective solutions through multiple iterations. Essentially the position that Rational takes is that processes help address and mitigate those activities containing the most risk in the SD lifecycle. A process helps reduce the risks by having definite milestones and checkpoints (Boehm, 1996, 1988; Knuchten, 1996). 5.2.2. Track and manage changes to project. The environment of SD is continually changing. SD that utilizes the iterative process model inevitably will result in changes to specifications, designs, and code. It is essential that all participants stay informed of changes to provide feedback regarding the results and implications of these changes and to be certain that each change is acceptable to all project stakeholders. Therefore, the process model needs to be designed to control, track, and monitor changes, and this can be accomplished by using some of the tools mentioned r Blackwell Publishing Ltd. 2005
earlier including change requests and deviation requests. Finally, the Rational group contends that change management is critical as it helps bring the development team together as a cohesive unit by describing how to make integration a routine activity. 5.2.3. Use component-based design. Component-based design can be thought of in a similar manner to how a contractor builds a house with standard two-by-fours and electrical fittings (Mann, 2002). Modular building blocks that have already been tested and proven can be reused in multiple projects. However, the use of interchangeable elements is only a useful engineering practice if components are connected by solid interconnectivity logic. 5.2.4. Frequent integration of software components (i.e. builds). Software that is compiled and tested on a more frequent basis during development is less prone to carrying defects deep into the development lifecycle as bugs are detected much earlier. If a bug is not detected until a late stage of development, it may be difficult to pinpoint, and once found, it may have a cascade effect on the entire software package. This means that even though the problem is isolated, modifying or removing the line of code may impact numerous other lines, changing the functionality of the entire program. Therefore, this catastrophe can be avoided by performing early and frequent integration of software components, which not only decreases defects but may also increase the speed of development (Sheremata, 2002).
5.3. Best practices: combined nature This section involves the interaction of organizational forces and technical practices. Whereas the organizational/interpersonal practices can be employed independent of the technical practices (and vice versa), the practices discussed in this section require that both components must be managed simultaneously to achieve SD success. Without execution of the organizational/interpersonal aspect of the practice, the technical aspect of the practice is not likely to succeed. 5.3.1. Peer reviews. In fostering a ‘software development team culture,’ peer reviews help foster healthy intragroup dynamics. By peer review, we mean that one developer on the team reviews another developer’s design work or code. While R&D Management 35, 4, 2005
385
Jason M. Pattit and David Wilemon this appears to be mainly a technical activity, peer reviews help promote interaction among team members. More experienced developers can be paired with less experienced developers in order to share knowledge with the newer team member. Reciprocally, the more experienced developer will be rejuvenated through interaction with an individual possessing new ideas. Both developers can benefit technically and personally from building on this relationship. The benefit is that problems are eliminated earlier in the development process. Periodic peer reviews have been shown to be as effective or even more effective than full testing after the code is completely integrated. As a consequence, development time is actually decreased, resulting in higher quality finished software products. 5.3.2. Feedback from customers. This practice contains elements that help with both technical and people issues. In enterprise SD, the customer is internal to the firm, but that does not make this practice less applicable. In fact, this practice is important, as organizations often perceive that lines of communication and goals are clearer between internal customers than with their external customers. From a technical standpoint, providing a and b versions of the software to internal customers can facilitate error correction, and speed the development process. Sheremata (2002) reports that continuous and rapid feedback from customers not only leads to earlier problem identification, but also improves software quality. From a ‘people issues’ standpoint, frequent feedback from customers reinforces open communication, especially among the various groups involved in enterprise SD. An increase in the direct contact between individuals helps promote the synthesis of different points of view (Sheremata, 2002). 5.3.3. Use multi-functional teams. Even though it is important to maintain small teams for the coding effort, the evolution of a software product from requirements to delivery crosses many different functions. This is especially true for enterprise SD. The resulting enterprise software product can be used by functions as diverse as accounting, sales and marketing, and manufacturing. Using multi-functional teams will help to develop and foster active interaction between these functions because they all have a stake in the functionality of the final software product. From a technical standpoint, the early and frequent involvement of various functions will help 386
R&D Management 35, 4, 2005
to reduce the complexity of the coding effort. This is because of the development of clearer requirements, leading to better solutions for the problems that need to be solved. 5.3.4. Use multiple best practices. According to Griffin (1997), organizations that succeed at new product development use multiple best practices. SD efforts can also benefit from effectively using best practices simultaneously. Frequent use of these best practices will help to develop and reinforce both cultural and technical aspects of the organization.
6. A diagnostic tool for software project leaders Project leaders are responsible for every aspect of the SD process and team. This is a challenging task, as the project leader must combine the talents of developers with diverse skill sets and personalities to deliver winning SD solutions. Therefore, successfully managing both the technical interfaces and group dynamics is critical to project achievement. Helping to make this task manageable, a diagnostic tool to assess the performance of the SD team and its process can be employed. The literature provides numerous examples of questionnaires that have been developed to assess new product development team success. Prominent examples of previous works with useful instruments include Briner et al. (1990) and Wheelwright and Clark (1992). For a diagnostic tool to be useful, it needs to be easily self-administered, relatively short, and flexible enough to be tailored to fit different projects and objectives. Essentially, the fundamental purpose of performance assessment is to encourage behavior that helps achieve the goals of the organization. From our own experience, we have found that a diagnostic used consistently as a periodic review tool at various steps in the development process provides valuable and immediate feedback that can be implemented quickly in the next step in the process or the next time a new project is being developed. Extending the use of a diagnostic tool to SD projects in order to achieve high performance can be helpful to SD teams and their leaders. We suggest that modifying the framework developed by Briner et al. (1990) regarding the assessment dimensions to be consistent with the terminology of SD can provide an excellent diagnostic tool. The management of stakeholders, the project lifecycle and the performance of inr Blackwell Publishing Ltd. 2005
High-performing software development teams Table 2. Diagnostic tool assessment categories. Assessment dimensions (Briner et al. 1990) – traditional project terms
Translation to software development terms
Management of stakeholders
Voice of customer assessment Senior management assessment
Management of the project life cycle
Software development process assessment Project success assessment
Management of the performance of individuals
Team leader assessment Project team assessment
dividuals are easily translated into terms that software developers are familiar with in Table 2. Within these categories, appropriate questions need to be developed in order to conduct a useful audit of the SD process. Our first step was to review the literature on assessing project team performance including Briner et al. (1990), Wheelwright and Clark (1992), Crawford and DiBenedetto (2003). We then conducted interviews with SD project team members regarding what they considered important to measure in terms of performance and interpersonal issues. The third step involved constructing the diagnostic instrument based on our personal experiences, the interviews with SD team members, and our literature review. We then tested the instrument with project teams. Their suggestions for improvement were then incorporated into the instrument. A final instrument was then developed. The questions can be scored using a five-point Likert-type scale, with one indicating that the respondent strongly disagrees with a statement and five indicating that the respondent strongly agrees with a statement. We suggest that SD project leaders use the following questions as a starting point for assessing their projects. As we note, however, the best diagnostic instrument is one, which a team develops for their own use. Our instrument can be used as a foundation for customizing a SD team’s own assessment instrument. 1. Voice of Customer Assessment We used prototyping to help validate customer needs? Voice-of-customer feedback is used during every prototyping step? We have a proactive, open concept generation process? 2. Senior Management Assessment Our senior managers are committed to effective and efficient SD projects? Our managers delegate sufficient authority to our SD project leaders? r Blackwell Publishing Ltd. 2005
Our company has a system that rewards successful project completion? 3. SD Process Assessment Our SD process helps us measure progress toward project completion? Major steps in the SD process are clearly understood and communicated? Our SD process works well? Key members of our SD team are involved throughout the SD process? 4. Project Success Assessment We used the lessons learned during previous SD efforts to guide our actions during new development projects? Our time working on this team has been time well spent? Our team documents and communicates our progress? 5. SD Team Leader Assessment It was clear who the project leader was for this project? Cross-functional involvement is strongly encouraged and supported by team leaders? Our team leader is capable of navigating our team through tough times as well as acknowledging our successes? Our leader communicates effectively with all team members? 6. Project Team Assessment The supporting functional areas carry out the tasks they are assigned in line with project specifications? The key departments (Management of Information Systems, finance, etc.) work together to achieve the same goals in this enterprise software project? Our project team is effective? Our project group knows the overall goals as well as the specific objectives of the project? R&D Management 35, 4, 2005
387
Jason M. Pattit and David Wilemon With the advent of corporate Intranets, administering this diagnostic tool is simplified. SD team members can take this questionnaire and input their scores anonymously. The scores can be collected in a database, and with the creation of a simple querying and data management program in Microsoft Excel, reports can be created outputting average scores, the ranges and any outliers for each question. Project leaders can then use these reports to conduct team review meetings to debrief the respondents and address questions where the team demonstrates a level of disagreement. As noted, the tool can be used periodically to immediately benefit from the feedback. Therefore, looking back at the general SD process examined earlier in our paper, this instrument can be administered after each of the three phases. Information gathered also can be applied to the subsequent phase or to the next project undertaken. (Note: The authors have developed a scoring table and instructions for interpreting the results. Please contact us for this SD project scoring system.)
7. Management’s role in facilitating effective SD programs The ‘best practices’ outlined here deal mainly with how project leaders can handle technical and people issues. However, senior and functional management can play a major role in creating healthy communications among developers. Senior management is also responsible for creating the culture of an organization. Jackson and Shuler (2000) define culture as the unique pattern of shared assumptions, values, and norms that shape the socialization activities, language, symbols, rites, and ceremonies of a group. While software-intensive firms need to develop a ‘software development team culture,’ they often do a poor job of creating one. What can assist is when senior management develops a culture fostering open communication, loyalty, personal commitment, and performance. Most firms are not culturally homogeneous organizations; they cannot be characterized by only one of the pure types of organizations defined by Hooijberg and Petrock (1993) and Quinn (1988). In fact, we contend that SD teams operate best where elements of both a clan culture and entrepreneurial culture are present. The clan culture contains elements of loyalty, personal commitment, and teamwork. The entrepreneurial culture is characterized by risktaking and a commitment to innovation. 388
R&D Management 35, 4, 2005
When an organization demonstrates elements of an entrepreneurial culture, it is not unusual for the organization to experience dynamic and turbulent projects. Keeping organizations ready for both significant change and difficult ventures is an ongoing effort, requiring conviction and a clearly communicated message of change from senior management (Whitten, 1995). In order to foresee what technical issues are likely and to communicate the challenges that lie ahead, senior management needs to have a rudimentary understanding of the technology being employed. By tapping into this knowledge, senior management can help guide a team and understand the technical roadblocks the team may face. This will lead to better understanding of how conflicts and communication breakdowns occur through the proliferation of technical problems that often manifest themselves as people issues. By understanding technology at a high level, senior management can focus on providing training and guidance to their SD project leaders on how to deal with various team issues. This helps senior management avoid getting too deeply involved into solving individual-level technology problems, and assists the team to achieve their project objectives. We have identified eight questions senior management can ask regarding how to build the type of culture, teams, and team leaders that are required for success in SD. Senior managers can measure their efforts against the suggestions offered here. Again, these suggestions are applicable to enterprise SD as well as for the design of commercialoff-the-shelf software. In fact, most of our suggestions apply to any organization that focuses heavily on new projects. The major difference is that implementation steps are specifically targeted toward software developers. How can management create a ‘software development team culture’? (Whitten, 1995; Hoch et al., 2000; Cantor, 2002) Foster teamwork, encourage participation; collect individual achievements, show how combined efforts lead to greatness; encourage risk-taking, team rewards; create a culture of learning – do not penalize failure; recruit the best programmers; encourage teams to engage in effective communication practices; be aware of team dynamics and organizational effectiveness; build flat, responsive organizations; maintain a clear vision. r Blackwell Publishing Ltd. 2005
High-performing software development teams How can management provide productive, effective guidance? (Hoch et al., 2000; Cantor, 2002) Bet on multiple options to prepare for uncertainty; avoid becoming the bottleneck – be a participant, not the center of the project (i.e. do not fall into the micromanagement trap). What can management do to ensure that an effective SD process is developed? (Whitten, 1995; Cantor, 2002) Create a rigorous SD process that has been defined and implemented to measure SD defects and problems carefully; steer the process, not the minute details. What can management do to grow capable SD project leaders? (Hoch et al., 2000) Provide team members with opportunities to demonstrate their leadership skills; identify people who work well together – teams are often led by ‘leadership teams,’ not single leaders. What training can management provide to SD team members? (Whitten, 1995) Assess training needs; sponsor seminars to encourage skill building. How can management empower SD team leaders? (Sheremata, 2002) Model effective teamwork; encourage developers to actively participate in cross-functional teams and demonstrate their teamwork and integrative capabilities; provide project managers with formal sources of influence; create active, effective cross-functional teams; increase access to ‘knowledge’ by delegating the authority to solve problems to project team members. How can management institute productive status review meetings? (Whitten, 1995; Cantor, 2002) Schedule regular review meetings; keep meetings flowing with useful, interesting information; keep meetings focused and productive; review old action items status, identify new action items for next meeting. How can management capture SD team learning? (McConnell, 1996; Cantor, 2002) Track project status; r Blackwell Publishing Ltd. 2005
use diagnostics for assessing health of team, SD process, progress, and status of technology; encourage active reviews of failures and successes; catalog information regarding project failures for use in future projects; recognize and reward effective team learning.
8. Learning from SD projects Learning is critical for effective SD processes. Throughout this paper we have presented examples of how development teams can track changes, use diagnostic tools to assess performance, and effectively utilize group meetings to gain and share valuable feedback on how the SD process is working. Teams that can capture, store, and retrieve knowledge created during a SD project can benefit the organization and gain from the experience. Moreover, future SD projects can use the learning from prior projects, which can accelerate the overall development process. Learning can be thought of at both an individual and an organizational level. Because development processes involve many individuals, it is critical to systematize the mechanism to capture the learning of individuals in order to benefit the entire organization. For example, in the SD process, individual developers will learn new coding skills or more efficient ways to do ‘builds-and-tests’ of modules. Wheelwright and Clark (1992) call this type of individual learning ‘learning by doing.’ This is not the type of learning that institutionalizes organizational processes that cut across the different functional groups involved in SD projects. So what is the type of learning that occurs within an organization? Looking beyond the purely technical sources of problems that arise, organizations need to understand how their development process can allow problems to propagate and remain unchecked until very late in development. For example, in SD, a firm may find that it repeatedly has problems integrating modules in the finished product at the component testing step even though the individual modules pass their previous function tests and perform their designated function perfectly. Thus, the problem has graduated to one that impacts all development functions, not just the individuals responsible for coding modules. In this example, a solution may be that the process does not contain an opportunity for developers to integrate modules at intermediate stages. The R&D Management 35, 4, 2005
389
Jason M. Pattit and David Wilemon learning gained by such a situation is that the individuals involved are performing to their best ability but that the problem exists because the process contains flaws. This demonstrates organizational learning, because not only is a better understanding of the process gained, but also the organization will have an opportunity to utilize what it has learned by determining how to implement the process change. In short, this learning and subsequent actions can impact the entire organization, not just the individual developers involved with a specific development team. Sheremata’s (2002) recent work demonstrates the most salient study on how learning can be captured from SD projects. This study examined 33 SD projects in order to verify theories about organizational learning that had been advanced by prior research. Sheremata (2002) indicates that most projects inherently accumulate the knowledge needed to solve new problems and develop new software products. However, determining what information to store and subsequently retrieve for use with a current or new project is difficult. Sorting through the information to find relevant and accurate knowledge is critical to avoid making the same mistakes and potentially accelerate the SD process. Prior research consistently shows that decentralizing decision making, and providing developers and programmers with authority to solve problems helps unlock the knowledge that can be gained from a project (Burns and Stalker, 1961; Smart and Vertinsky, 1977; Nord and Tucker, 1987). One practice that project leaders can use to encourage learning is to delegate authority to team members to solve problems. Sheremata (2002) suggests that delegating will not only en-
courage individual learning, but also can remove obstacles that block the flow of information within an organization. This type of learning and knowledge transfer is similar to Wheelwright and Clark’s (1992) approach in that it institutionalizes organizational learning processes. How should organizations collect and then disseminate useful knowledge? Sheremata’s (2002) findings also indicate that projects can mix and match process steps, in order to take advantage of the unique opportunities and constraints encountered during each new project. The quality and quantity of learning can be improved and increased through a number of actions that help remove obstacles to learning. These actions include encouraging team communication, using milestones to assess progress, creating an awareness of the benefits of project learning, and reducing the physical distances between individuals (Hage et al., 1971; Allen, 1977; Sheremata, 2000). Learning also can be achieved through reviews of the entire project with major project stakeholders (e.g. senior management, internal customers/users, functional support groups, etc.). Reviewing aspects of the project with final users, steering committees, and support departments adds to the amount of knowledge that can be captured, increasing the chances that significant learning will take place. An interesting perspective on learning presented by Purser et al. (1992) is that projects in general are knowledge intensive. Thus, the very projects that develop core competencies propagate the knowledge base. SD projects often build upon the competencies that an organization has already established, combining capabilities to
Match Successful Program
Governing Values
Actions
Mismatch & Errors
Software Design & Development Process
Software
Maintenance & Debugging Process
Single Loop Learning Fixes to Coding Errors Double Loop Learning Figure 6. Learning Cycle. Note: Top cell of the boxes from Argyris (1990). Bottom cell of the boxes adapted from Banker et al. (1998).
390
R&D Management 35, 4, 2005
r Blackwell Publishing Ltd. 2005
High-performing software development teams exploit organizational learning (Bourgeon, 2002). Therefore, putting learning into action during SD projects is an ideal setting for experimentation. This is especially true for organizations that use cross-functional SD teams. As Leonard-Barton et al. (1994) state, projects provide a real test for the firm to reinforce relations between functions. Transitioning to a learning organization involves time, encountering resistance, and the need for flexible, adaptive approaches. It is crucial to encourage people to take initiative, demonstrate creativity, and experiment. It is useful to consider SD projects from the perspective of the work on organizational learning by Chris Argyris. As demonstrated earlier, SD projects are the result of carrying out a systematic development process. This process is the sum of numerous actions that either produces successful results or failures over a finite lifecycle. It is important that these outcomes are reviewed, and that the appropriate changes are made to the actions that lead to failures. Argyris (1990) calls this single-loop learning, where only the actions are modified, but no thought is given to the reason why the action is allowed to persist. This type of learning simply identifies the routine, easy problems, and does not seek long-term solutions. Therefore, the governing values that helped to determine the shape of the development process need to be examined in order to bring to light the policies that led to the shortcomings in the first place. Argyris (1990) labels this as double-loop learning, characterized by a second feedback loop that ties the mismatch between action and result to the fundamental principles of the organization. However, the organization needs to be aware that a mismatch exists, facilitating the need to engage in learning. Individuals in such organizations are practicing deutero-learning, which Argyris and Scho¨n (1978) characterize as ‘learning about learning.’ This implies that team members are aware that mismatches are present, and that they have learned to use both single- and double-loop learning. If we look back at the example of the firm having difficulties integrating modules, the action to solve this problem is to create an intermediate process step that forces developers to integrate. However, this would be a simple, single-loop learning action with only short-term consequences. Banker et al. (1998) recognize the unidirectional flow of information between SD development and maintenance processes as especially troublesome. The traditional models of SD are often plagued by a lack of communication r Blackwell Publishing Ltd. 2005
between maintenance and developers. The SD and maintenance process proposed by Banker et al. (1998) looks strikingly similar to a doubleloop learning process. Figure 6 details the parallels between these two models, presenting what we believe to be the first explicit synthesis of the organizational learning cycle and the SD process. Delving deeper into the module integration example, the organization needs to review the factors that created this process problem initially. The organization may discover that it does not encourage interaction among developers who are not working on the same part of a coding effort. This can have a profound impact on the entire organization and can lead to systemic problems beyond the firm’s SD projects. It can also lead to communication breakdowns that prevent developers from interacting with colleagues, asking for assistance when another developer may have superior skills, or collaborating with other developers when creativity is called upon. This doubleloop learning can help reshape the overall values of the organization, potentially eliminating other actions before they are ever implemented that might become problems in the future. Once an SD team becomes proficient using both singleand double-loop learning, it is practicing deuterolearning. In fact, this example demonstrates that deutero-learning for SD projects not only helps the organization to improve technically, but may also help the organization gain insight into how to build a SD team culture.
9. Summary and conclusion SD projects can be a complex combination of technical and people issues. Four generic models of the SD process have been presented. Managing successful development projects can be enhanced by understanding the drivers of projects, the general steps that all SD processes share, and the major phases that a project progresses through. During a project, teams invariably encounter both technical and people issues. A number of challenges have been identified and we have presented several of the most common ones. Development team leaders can quickly identify these issues and implement actions to eliminate or minimize their interference with the success of a project. We also presented several best practices currently used by effective SD teams. These best practices are global and enduring in nature, and often can be implemented throughout the organization. R&D Management 35, 4, 2005
391
Jason M. Pattit and David Wilemon We have stressed that SD project managers can use diagnostic tools to assess the performance of their teams. The assessment recommended evaluates six aspects of a project, the team and its leadership and looks for discrepancies among team members, especially where the team perceives their project might be failing or improving. The feedback from this tool can be used to help shape an organization’s entire SD efforts. In fact, senior management can judge how effectively it is accomplishing goals such as developing team leaders, supporting SD efforts, and promoting learning throughout the organization. Developing a learning organization needs to be a primary senior management focus in order to create highperforming SD projects. SD projects present an opportunity to not only improve technical capability but also to develop a SD team culture. We suggest that further research be conducted to study the emerging models of SD processes. These advanced models offer opportunities to examine how the time associated with SD projects can be reduced, but also how knowledge can be captured and disseminated within complex organizations. How best to create a ‘software development team culture’ provides another promising area for further research. The aspects of culture that promote healthy relationships between developers and which promotes successful results are especially needed. Lastly, a study of senior management in firms developing software is another area for further research. A correlation between the activities that senior managers conduct to develop leaders and promote learning in their organizations with project success rates would be of particular interest.
Acknowledgements We would like to acknowledge the helpful comments of Jeff Butler, and the two anonymous reviewers on an earlier version of this article.
References Allen, T.J. (1977) Managing the Flow of Technology: Technology Transfer and the Dissemination of Technological Information within the R&D Organizations. Cambridge, MA: MIT Press. Argyris, C. and Scho¨n, D.A. (1978) Organizational Learning: A Theory of Action Perspective. Reading, MA: Addison-Wesley.
392
R&D Management 35, 4, 2005
Argyris, C. (1990) Overcoming Organizational Defenses: Facilitating Organizational Learning. Upper Saddle River, NJ: Prentice Hall. Banker, R.D., Davis, G.B. and Slaughter, S.A. (1998) Software development practices, software complexity, and software maintenance performance: a field study. Management Science, 44, 4, 433–450. Boehm, B.W. (1988) A spiral model of software development and enhancement. Computer, 21, 5, 61–72. Boehm, B.W. (1996) Anchoring the software process. IEEE Software, 13, 4, 73–82. Boudette, N.E. (1999) Europe’s SAP scrambles to stem big glitches. Wall Street Journal, November 4, A25. Bourgeon, L. (2002) Temporal context of organizational learning in new product development projects. Creativity and Innovation Management, 11, 3, 175–183. Briner, W., Geddes, M. and Hastings, C. (1990) Project Leadership. New York: Van Nostrand Reinhold. Brooks, F.B. (1975) The Mythical Man-Month: Essays on Software Engineering. London: Addison-Wesley. Burns, T. and Stalker, G.M. (1961) The Management of Innovation. London: Tavistock. Caldwell, B. (1998) Andersen consulting sued over ‘flawed’ SAP R/3 job. InformationWeek, July 3. Cantor, M. (2002) Software Leadership: A Guide to Successful Software Development. Boston: AddisonWesley. Carmel, E. and Bird, B.J. (1997) Small is beautiful: a study of packaged software development teams. The Journal of High Technology Management Research, 8, 1, 129–148. Crawford, M. and DiBenedetto, A. (2003) New Products Management. Boston: McGraw-Hill Irwin. Curtis, W. (1989) Three problems overcome with behavioral models of the software development process. Paper presented at the 11th International Conference on Software Engineering. Pittsburgh, PA. DeMarco, T. and Lister, T. (1987) Peopleware: Productive Projects and Teams. New York: Dorset House. Diederich, T. (1999) Bankrupt firm blames SAP for failure. ComputerWorld, August 28. Gobeli, D.H., Koenig, H.F. and Bechinger, I. (1998) Managing conflict in software development teams: a multilevel analysis. Journal of Product Innovation Management, 15, 5, 423–435. Greiner, L.E. (1972) Evolution and revolution as organizations grow. Harvard Business Review, 50, 4, 37–46. Griffin, A. (1997) PDMA research on new product development practices: updating trends and benchmarking best practices. Journal of Product Innovation Management, 14, 6, 429–458. Hage, J., Aiken, M. and Marrett, C.B. (1971) Organization structure and communications. American Sociological Review, 36, 5, 860–871. Hoch, D.J., Roeding, C.R., Purkert, G. and Lindner, S.K. (2000) Secrets of Software Success: Manager Blackwell Publishing Ltd. 2005
High-performing software development teams ment Insights from 100 Software Firms around the World. Boston: Harvard Business School Press. Hooijberg, R. and Petrock, F. (1993) On cultural change: using the competing values framework to help leaders execute a transformational strategy. Human Resource Management, 32, 29–50. Humphrey, W.S. (2000) Introduction to the Team Software Process. Reading, MA: Addison-Wesley. Jackson, S.E. and Schuler, R.S. (2000) Managing Human Resources: A Partnership Perspective. Cincinnati, OH: South-Western College Publishing. Jiang, J. and Klein, G. (2000) Software development risks to project effectiveness. Journal of Systems and Software, 52, 1, 3–10. Karolak, D.W. (1998) Global Software Development. Los Alamitos, CA: IEEE Computer Society. Knuchten, P. (1996) A rational development process. CrossTalk, 9, 11–16. Leonard-Barton, D., Bower, K., Clark, K., Holloway, C. and Wheelwright, S. (1994) How to integrate work and deepen expertise. Harvard Business Review, 72, 5, 121–130. MacDonald, E. (1999) Maker of Gore-Tex sues PeopleSoft and Deloitte. Wall Street Journal, November 2, B14. Mann, C.C. (2002) Why software is so bad. Technology Review, 105, 6, 33–38. McConnell, S. (1996) Rapid Development: Taming Wild Software Schedules. Redmond, WA: Microsoft Press. McConnell, S. (1998) Software Project Survival Guide. Redmond, WA: Microsoft Press. Miller, D. (1986) Configurations of strategy and structure: towards a synthesis. Strategic Management Journal, 7, 3, 233–250. Montoya, S. (1998) FoxMeyer files suit against SAP software company. AP Wire, August 27. Nord, W.R. and Tucker, S. (1987) Implementing Routine and Radical Innovations. Lexington, MA: Lexington Books. Norris, M., Rigby, P. and Payne, M. (1993) The Healthy Software Project: A Guide to Successful Development and Management. West Sussex, UK: John Wiley & Sons Ltd.
r Blackwell Publishing Ltd. 2005
Pressman, R. (1996) Software process perceptions. IEEE Software, 13, 6, 16–19. Purser, R.E., Pasmore, W.A. and Tenkasi, R.V. (1992) The influence of deliberations on learning in new product development teams. Journal of Engineering and Technology Management, 9, 1–28. Quinn, R.E. (1988) Beyond Rational Management: Mastering the Paradoxes and Competing Demands of High Performance. San Francisco: Jossey-Bass. Sawyer, S. and Guinan, P.J. (1998) Software development: processes and performance. IBM Systems Journal, 37, 4, 552–569. Sheremata, W.A. (2000) Centrifugal and centripedal forces in radical new product development under time pressure. Academy of Management Review, 25, 2, 389–408. Sheremata, W.A. (2002) Finding and solving problems in software new product development. Journal of Product Innovation Management, 19, 144–158. Smart, C. and Vertinsky, I. (1977) Designs for crisis decision units. Administrative Science Quarterly, 22, 4, 640–657. Thamhain, H.J. and Wilemon, D.L. (1986) Criteria for controlling projects according to plan. Project Management Journal, 17, 2, 75–81. van Genuchten, M. (1991) Why is software late? An empirical study of reasons for delay in software development. IEEE Transactions on Software Engineering, 16, 6, 582–590. Wheelwright, S.C. and Clark, K.B. (1992) Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency, and Quantity. New York: The Free Press. Whitaker, K. (1994) Managing Software Maniacs: Finding, Managing and Rewarding Winning Development Teams. New York: Wiley. Whitehead, R. (2001) Leading a Software Development Team: A Developer’s Guide to Successfully Leading People & Projects. Harlow, UK: Addison-Wesley. Whitten, N. (1995) Managing Software Development Projects. New York: John Wiley & Sons, Inc.
R&D Management 35, 4, 2005
393
