FAYETTEVILLE, Ark. — When managers need to understand employee issues like morale or productivity, they can turn to a variety of tools to explain and predict employee behaviors. While these tools are commonly used in many companies, they are seldom applied when the questions involve engineering and technology workers, according to University of Arkansas researcher Bill Hardgrave, executive director of the Information Technology Research Center.

"In fact, most research examining software development innovations focus on the technology and ignores the people. Yet, people are the single most important variable in the software development equation," said Hardgrave, who holds the Bradberry chair in information systems.

Hardgrave and researchers Cynthia Riemenschneider, assistant professor of information systems, and Fred Davis, professor and department chair of information systems, wanted to if these models could be used to explain the developers’ intention to adopt the new methodologies. The results of their research will appear in an upcoming issue of IEEE Transactions on Software Engineering.

"We were studying failure of software programmers to adopt methodologies, which is a critical problem in the industry," explained Hardgrave. "Although there are a number of psychological models that could be used to address this problem, we found that very little research had been done using these models."

The researches compared five common behavioral models to determine their relative usefulness in a technical setting: The Technology Acceptance Model (TAM), TAM2, Perceived Characteristics of Innovating (PCI), Theory of Planned Behavior (TpB) and the Model of Personal Computer Utilization (MPCU).

Although these are general theories, each looks at somewhat different parameters. To determine which parameters were most applicable in a technical environment, the researchers compared the models in an experiment conducted in the information systems department of a Fortune 1000 company. The Fortune 1000 company was in the process of implementing a new development methodology.

"The new methodology represented a radical change for the developers," explained Hardgrave. "They moved from an environment with no prescribed processes in place to an environment guided by an organization-wide methodology."

Methodologies are comprehensive systems that standardize the steps in the development process. Although they can provide increased productivity and profitability, development methodologies are only used in about half of all companies that develop software because of the difficulties in deploying the systems.

"Many organizations are trying to improve their software development by implementing formal methodologies," explained Davis, who holds the David D. Glass chair in information systems. "But this usually represents a substantial change from their previous practices. Developer resistance can prevent the company from fully deploying or realizing the benefits of the methodology."

Overcoming this resistance requires knowledge of the factors make an employee intend to use the methodology. To determine these factors, the researchers conducted a study with 128 developers in a company implementing a new methodology that had been custom-created for the company’s internal use.

The developers were introduced to the methodology in a presentation, trained with it for six weeks and weregiven written and online instructions. At the end of six weeks, developers were instructed in writing to begin using the new policy. After six more weeks they were given a questionnaire to assess their intention to use the new methodology.

The researchers compared each model with the results of the experiment to determine how well its parameters fit the actual situation. Although some factors from each model were significant, no one model contained all four of the most significant determinants of developer behavior — usefulness, compatibility with existing practices, social pressure, complexity of the new methodology and organizational mandate.

This research can provide managers with important information for designing an implementation of a technology. For example, since usefulness was regarded as the key element in the developers’ intention to adopt the methodology, managers should ensure that their developers understand the importance of the methodology to both the individual and the organization and that their performance measurement and reward structure is consistent with the methodology.

"A methodology may improve overall firm performance and productivity in the long term, but not enable individual developers to be more productive in the short term," explained Hardgrave. "But if compensation structures are based individual performance measures, it is not in the best interest of the developer to adopt the methodology. Positive consequences for the organization cannot offset negative consequences for the individual."

This study was the first to empirically test psychological models in methodology adoption. By demonstrating that each of the five models could provide significant information, the study showed that they could be successfully applied in a technology setting.

"From a practical perspective, insights provided by the study suggest better strategies for introducing methodologies and avoiding situations where time and money are spent on methodologies that are not used," said Hardgrave. "But this study can also serve as a foundation for studies of methodology acceptance in a variety of engineering areas beyond software engineering."