Reference no: EM131816932

In 1974, when I was teaching at Colorado State University, we conducted a study of the causes of information systems failures. We interviewed personnel on several dozen projects and collected survey data on another 50 projects.

Our analysis of the data revealed that the single most important factor in IS failure was a lack of user involvement. The second major factor was unclear, incomplete, and inconsistent requirements.

At the time, I was a devoted computer programmer and IT techie, and, frankly, I was surprised. I thought that the significant problems would have been technical issues. I recall one interview in particular. A large sugar producer had attempted to implement a new system for

paying sugar-beet farmers. The new system was to be implemented at some 20 different sugar-beet collection sites, which were located in small farming communities, adjacent to rail yards. One of the benefits of the new system was significant cost savings, and a major share of those savings occurred because the new system eliminated the need for local comptrollers. The new system was expected to eliminate the jobs of 20 or so senior people.

The comptrollers, however, had been paying local farmers for decades; they were popular leaders not just within the company, but in their communities as well. They were well liked, highly respected, important people. A system that caused the elimination of their jobs was, using a term from this chapter, organizationally infeasible, to say the least.

Nonetheless, the system was constructed, but an IS professional who was involved told me, "Somehow, that new system just never seemed to work. The data were not entered on a timely basis, or they were in error, or incomplete; sometimes the data were not entered at all. Our operations were falling apart during the key harvesting season, and we finally backed off and returned to the old system." Active involvement of system users would have identified this organizational infeasibility long before the system was implemented. That's ancient history, you say. Maybe, but in 1994 the Standish Group published a now famous study on IS failures.

Entitled "The CHAOS Report," the study indicated the leading causes of IS failure are, in descending order: (1) lack of user input, (2) incomplete requirements and specifications, and (3) changing requirements and specifications. That study was completed some 20 years after our study. In 2004, Professor Joseph Kasser and his students at the University of Maryland analyzed 19 system failures to determine their cause. They then correlated their analysis of the cause with the opinions of the professionals involved in the failures.

The correlated results indicated that the first-priority cause of system failure was "Poor requirements"; the second-priority cause was "Failure to communicate with the customer." (Google or Bing "Joseph Kasser" to learn more about this work.)

In 2003, the IRS Oversight Board concluded that the first cause of a massive, expensive failure in the development of a new information system for the IRS was "inadequate business unit ownership and sponsorship of projects.

This resulted in unrealistic business cases and continuous project scope ‘creep.'" For over 30 years, studies have consistently shown that leading causes of system failures are a lack of user involvement and incomplete and changing requirements. Yet failures from these very failures continue to mount.

Questions

1. Using the knowledge you have gained from this chapter, summarize the roles that you think users should take during an information systems development project. What responsibilities do users have? How closely should they work with the IS team? Who is responsible for stating requirements and constraints? Who is responsible for managing requirements?

2. If you ask users why they did not participate in requirements specification, some of the common responses are the following: a. "I wasn't asked."

b. "I didn't have time."

c. "They were talking about a system that would be here in 18 months, and I'm just worried about getting the order out the door today."

d. "I didn't know what they wanted."

e. "I didn't know what they were talking about."

f. "I didn't work here when they started the project."

g. "The whole situation has changed since they were here; that was 18 months ago!" Comment on each of these statements. What strategies do they suggest to you as a future user and as a future manager of users?

3. If you ask IS professionals why they did not obtain a complete and accurate list of requirements, common responses are:

a. "It was nearly impossible to get on the users' calendars. They were always too busy."

b. "The users wouldn't regularly attend our meetings. As a result, one meeting would be dominated by the needs of one group, and another meeting would be dominated by the needs of another group."

c. "Users didn't take the requirement process seriously. They wouldn't thoroughly review the requirements statements before review meetings."

d. "Users kept changing. We'd meet with one person one time and another person a second time, and they'd want different things."

e. "We didn't have enough time."

f. "The requirements kept changing." Comment on each of these statements. What strategies do they suggest to you as a future user and a future manager of users?

4. If it is widely understood that one of the principal causes of IS failures is a lack of user involvement, and if this factor continues to be a problem after 30+ years of experience, does this mean that the problem cannot be solved?

For example, everyone knows that you can maximize your gains by buying stocks at their annual low price and selling them at their annual high price, but doing so is very difficult.

Is it equally true that although everyone knows that users should be involved in requirements specification, and that requirements should be complete, it just cannot be done? Why or why not?