Patricia J. Guinan

Enabling Software Development Team Performance During Requirements Definition: a Behavioral Versus Technical Approach

As software development projects continue to be over budget and behind schedule, researchers continue to look for ways to improve the likelihood of project success. In this research we juxtapose two different views of what influences software development team performance during the requirements development phase. In an examination of 66 teams from 15 companies we found that team skill, managerial involvement, and little variance in team experience enable more effective team processes than do software development tools and methods. Further, we found that development teams exhibit both positive and negative boundary-spanning behaviors. Team members promote and champion their projects to the outside environment, which is considered valuable by project stakeholders. They also, however, guard themselves from their environments; keeping important information a secret from stakeholders negatively predicts performance.

Software development: processes and performance

This paper presents data that describe the effects on software development performance due to both the production methods of software development and the social processes of how software developers work together. Data from 40 software development teams at one site that produces commercial software are used to assess the effects of production methods and social processes on both software product quality and team performance. Findings indicate that production methods, such as the use of software methodologies and automated development tools, provide no explanation for the variance in either software product quality or team performance. Social processes, such as the level of informal coordination and communication, the ability to resolve intragroup conflicts, and the degree of supportiveness among the team members, can account for 25 percent of the variations in software product quality. These findings suggest two paradoxes for practice: (1) that teams of software developers are brought together to create variability and production methods are used to reduce variability, and (2) that team-level social processes may be a better predictor of software development team performance than are production methods. These findings also suggest that factors such as other social actions or individual-level differences must account for the large and unexplained variations in team performance.

Social interactions of information systems development teams: a performance perspective

We report results from a longitudinal study of information systems development (ISD) teams. We use data drawn from 60 ISD teams at 22 sites of 15 Fortune 500 organizations to explore variations in performance relative to these teams’ social interactions. To do this, we characterize ISD as a form of new product development and focus on team‐level social interactions with external stakeholders. Drawing on cluster analysis, we identify five patterns of team‐level social interactions and the relationships of these patterns to a suite of objective and subjective measures of ISD performance. Analysis leads us to report three findings. First, data indicate that no one of the five identified patterns maximizes all performance measures. Second, data make clear that the most common approach to ISD is the least effective relative to our suite of performance measures. Third, data from this study show that early indications of ISD project success do not predict actual outcomes. These findings suggest two issues for research and practice. First, these findings indicate that varying patterns of social interactions lead to differences in ISD team performance. Second, the findings illustrate that singular measures of ISD performance are an oversimplification and that multiple measures of ISD performance are unlikely to agree.

What's your social media strategy?

This publication contains reprint articles for which IEEE does not hold copyright. Full text is not available on IEEE Xplore for these articles.

The effective use of automated application development tools

In this paper we report on the results of a four-year study of how automated tools are used in application development (AD). Drawing on data collected from over 100 projects at 22 sites in 15 Fortune 500 companies, we focus on understanding the relationship between using such automated AD tools and various measures of AD performance—including user satisfaction, labor cost per function point, schedule slippage, and stakeholder-rated effectiveness. Using extensive data from numerous surveys, on-site observations, and field interviews, we found that the direct effects of automated tool use on AD performance were mixed, and that the use of such tools by themselves makes little difference in the results. Further analysis of key intervening factors finds that training, structured methods use, project size, design quality, and focusing on the combined use of AD tools adds a great deal of insight into what contributes to the successful use of automated tools in AD. Despite the many grand predictions of the trade press over the past decade, computer-assisted software engineering (CASE) tools failed to emerge as the promised “silver bullet.” The mixed effects of CASE tools use on AD performance that we found, coupled with the complex impact of other key factors such as training, methods, and group interaction, suggest that a cautious approach is appropriate for predicting the impact of similar AD tools (e.g., object-oriented, visual environments, etc.) in the future, and highlight the importance of carefully managing the introduction and use of such tools if they are to be used successfully in the modern enterprise.

Antidotes for high complexity and ambiguity in software development

In a longitudinal study of 47 software development teams, we investigate interactions between team and technology factors and the degree of complexity and ambiguity of the projects themselves. From the literature, we propose a theoretical model that identifies a characteristic of the technology (modularity) and a characteristic of the team process (conflict resolution) used during system development, as effective for minimizing the adverse effects of high task-based complexity and ambiguity (those tasks for which multiple acceptable solutions exist). We hypothesize that modularity and conflict-resolution techniques will account for a significant amount of the variance in user satisfaction for highly complex and ambiguous projects, but that this will not be the case for simple and unambiguous projects. Our findings confirm this hypothesis, indicating that effective conflict resolution and modularity are associated with significantly higher client satisfaction six months after implementation for all projects. An explanation for these findings is offered, followed by implications for theorists and practitioners.

Booz Allen Hamilton: Social and Beyond

Abstract By 2008, consulting company Booz Allen Hamilton needed a more effective way to connect employees to each other and to valuable content. The majority of its consultants worked at client sites and there was a growing feeling of isolation at the firm. In addition, employee affinity to Booz Allen was starting to slip. Previous efforts at knowledge management, such as technology email lists and content management systems, had not been as effective as hoped: information silos remained. In 2008, Walton Smith and his team rolled out Hello, an enterprise collaboration platform containing tools such as social profiles, blogs, wikis, tags, and digital communities. By 2011, the platform was highly adopted by Booz Allen with ample business benefits for different stakeholders. Smith, however, faced difficult decisions going forward. Should the firm continue with internal software development/open source or should it move the Hello platform to a large, integrated vendor solution? Also, how could Booz Allen leverage its success with Hello to sell enterprise collaborative software solutions to its clients, who faced similar challenges?

Fletcher Allen Health Care’s Telemedicine Initiative

AbstractAs hospitals and caregivers struggle with the new economics of health care, some are investigating telemedicine technologies, which circumvent the traditional constraints of time and place. This case describes the early stages in a teaching hospital’s use of telemedicine applications. Vermont’s only tertiary-care teaching hospital, Fletcher Allen Health Care (FAHC) is promoting video-conferencing and other telemedicine technologies in its catchment area, consisting of Vermont and six New York counties. An ambitious

Software development under conditions of high task complexity and ambiguity

30 million technology initiative was funded, with

Booz Allen Hamilton: Social and Beyond Research Note

17 million allocated to enhancing Fletcher Allen’s IT infrastructure and decision support capabilities, and