Systems Analysis and Design: People, Processes, and Projects

Keng Siau, Roger Chiang, Bill C. Hardgrave

• Publisher: Routledge
• Year: 2015
• Print ISBN: 9780765623539
• eBook ISBN: 9781317459101
• Edition: 1
• Topic: Computer Science
• Subtopic: Software Development
• Index: Computer Science

For the last two decades, IS researchers have conducted empirical studies leading to a better understanding of the impact of Systems Analysis and Design methods in business, managerial, and cultural contexts. SA&D research has established a balanced focus not only on technical issues, but also on organizational and social issues in the information society..This volume presents the very latest, state-of-the-art research by well-known figures in the field. The chapters are grouped into three categories: techniques, methodologies, and approaches.

CHAPTER 1

____________________________

SOCIAL AND TECHNICAL ASPECTS OF SYSTEMS ANALYSIS AND DESIGN

JOHN ERICKSON AND KENG SIAU

Sociotechnical theory has served as an explanatory vehicle for information systems development and deployment for more than thirty years. In the competitive environment that most industries operate in, information systems are essential for solving problems, and gaining and maintaining competitive advantages. Understanding both the technical and behavioral aspects of systems is also a critical component of the systems development process. Information systems can often determine the success or failure of a business. Unfortunately, the overall success rates of systems development projects historically have been very low. The statistics cross industries, organization size, and national boundaries. Much research has been devoted to examining why systems fail so often and how they can be improved (Avison and Fitzgerald, 2003; Hardgrave et al., 2003; Schmidt et al., 2001; Smith et al., 2001; Siau et al., 1997).

A wide variety of approaches to systems development have been proposed and tried over at least the past twenty years. For example, between 1989 and 1994, the number of object-oriented development approaches grew from around ten to more than fifty (Booch et al., 2005). Recent years, between 1994 and 2008, have not seen a drop in the number of proposals regarding how best to build systems. Entirely new approaches have been designed and tried in practice. Pair programming (Williams and Kessler, 2002), extreme programming (Beck, 1999), and agile development (Erickson et al., 2005; Fowler and Highsmith, 2001) were proposed and used in the late 1990s and the early years of the next decade, while Web services, service-oriented architecture (Erickson and Siau, 2008), cloud computing, Web 2.0, and open source systems (Long and Siau, 2007) continue the trend of proliferation of system-building approaches in more recent times.

In particular, open source development can be connected to sociotechnical systems because at least one of its basic tenets—that users can meaningfully contribute to technical systems development, particularly application development—proposes that users should be more closely connected to systems building. Traditionally, applications are built so that the developing company owns the source code, and keeps it closed, for the most part, to outside programmers or users. Open source development, however, allows users from outside the developing organization to contribute to code writing, and also to programming improvement initiatives. Peer-based collaboration efforts, including open source and pair programming, that are aimed at improving applications and systems represent a fundamental divergence in thought regarding how systems should be built.

As the volume title indicates, the organizational theme is people, processes, and projects. This implies a synergy for the organization when both the human component and the technological component can be put together in attempts to gain competitive advantage. Technical approaches and practice combined with those of social and behavioral sciences have become important to ensuring business success. In addition, the sociotechnical approach can provide insight into better organizational and process design and practice and has become a critical element that organizations must deal with effectively. The sociotechnical approach has been used as an explanatory vehicle for many years (e.g., see Ryan and Harrison, 2000; Ryan et al. 2002; Stein and Vandenbosch, 1996), with one of the early and noteworthy formulations of the theory emerging from Cherns’s 1976 observations. He followed up in 1987 with a review and modifications to the 1976 work. Sociotechnical theory assumes that an organization or subcomponent can be viewed as a sociotechnical system. A sociotechnical system is composed of two interindependent, closely related and interacting systems, social and technical (Bostrom and Heinen, 1977a).

Table 1.1

Cherns’ Principles for Social-Technical Design

Principle 1.	Compatibility
Principle 2.	Minimal Critical Specification
Principle 3.	Variance Control
Principle 4.	Boundary Location
Principle 5.	Information Flow
Principle 6.	Power and Authority
Principle 7.	Multifunctional
Principle 8.	Support Congruence
Principle 9.	Transitional Organization
Principle 10.	Forth Bridge

CHERNS’S PRINICIPLES ON SOCIAL-TECHNICAL DESIGN

Cherns (1976, 1987) insisted that if systems builders failed to account for the social requirements or needs of the system being constructed, those needs would be met in “some other way,” and such other ways would likely impede the organization as much as help it. Cherns (1976) went on to delineate nine principles that he insisted should provide a basis for the sociotechnical design of business or organizational systems. In his 1987 revisitation of the theory, he modified some of the existing principles and added a tenth principle. Table 1.1 summarizes Cherns’s ten principles.

The first principle is compatibility. By compatibility, Cherns means that design execution should be in alignment with the design goal for the system itself. An important part of this principle is the idea that even experts (systems analysts, domain experts, etc.)—or perhaps, especially experts— must be willing to put their assumptions on the table.

Cherns’s second principle, minimal critical specification, means that essential characteristics of the systems must be identified. Conversely, this principle also means that the builders should specify the minimum design necessary to meet the objectives. In other words, adherence to this principle is a way to deal with project scope creep.

Variance control represents Cherns’s third principle. Underlying variance control is the basic assumption that variances should not be moved across organizational boundaries. As such, this principle is interdependent with boundary location (the fourth principle) and information flow (the fifth principle). Boundaries are often set by functional area designations and sometimes by process designations. The fourth principle states that boundaries should not be drawn in ways that impede information flow. However, given that at least some processes are transfunctional, meaning they cross functional boundaries by definition and necessity, internal boundaries can block the flow of information. This is not to say that boundaries should be eliminated, but rather that they should be carefully drawn and managed as organizational needs and boundaries change through business pressure.

The sixth principle, power and authority, states that those who need resources or inputs should have access to acquire and use them. However, this also means that with the authority comes responsibility for appropriate use. This principle can be closely associated with information flow and boundary issues (the fourth and fifth principles).

The multifunctional principle, Cherns’s seventh, simply proposes that organizations must adapt to their environments. However, in the context of the fourth, fifth, and sixth principles, developers and organizations must also realize that many of the boundaries are internal and that as a result, so are some of the “environments” that they must adapt to. This is most evident when implementing an enterprise system (Doherty and King, 2005).

Support congruence represents Chems’s eighth principle. It proposes that support for human-based processes, such as human resources, marketing, and planning, should be conceived and delivered similarly to support for concrete processes typically found in a manufacturing company. Adherence to this principle can mean a significant change to policies, some of which may have been in place for a long time. Thus, resistance to change is possible or even likely.

The ninth principle is known as the transitional organization principle and presumes that transitions from legacy systems to new systems must be designed and planned. This includes training and other means of obtaining buy-in from end users and other constituents. Cherns named the final principle the Forth Bridge principle, or incompletion principle. This name refers to a famous railroad bridge in Scotland that can never be freshly painted in its entirety at one time. By the time painting is completed on both sides, the paint on the first side of the bridge has deteriorated so much that it is time to repaint it again (one could use painting and maintenance on the Golden Gate Bridge as an equally apt analogy). This principle states that systems are never really static, but rather are continually changing and dynamic, and require more or less continuous maintenance and repair. Maintenance and support continue over the life of a system, and change is continuous and/or incremental rather than all at once or not at all.

Cherns’s works did not include a specific framework for examining or classifying sociotechnical systems. They were more general principles and values that others used to build upon.

OTHER SOCIAL-TECHNICAL FRAMEWORKS AND THEORIES

Once researchers had a chance to examine Cherns’s ideas in detail and organizations begin to act on them, other ideas were proposed and developed to extend understanding of sociotechnical systems and their related development. Among the researchers investigating sociotechnical systems were Markus (1983), Lamb and Kling (2003), and Bostrom and Heinen (1977a, 1977b). The basic ideas driving the research are explored in the following section.

Markus examined resistance to management information systems (MIS) projects from several existing theoretical perspectives. The first theory was based on the idea that resistance to change (identified as a primary reason that systems development efforts fail) could emerge from the human or behavioral perspective. In other words, resistance to change is an internal phenomenon originating in individuals or in their groups.

The second theory presumed that resistance to change, or user nonacceptance of the system, is driven primarily by the quality and design of the system itself (Markus, 1983). Accordingly, even if a system was well constructed from a technical perspective and accomplished everything the developers wanted, but included a very poorly designed interface, then the system was still likely to fail.

The third theoretical approach was to include the human and technology-based elements as actors or components of the system. The idea was then to examine the effects of interactions between the various human and technological components of the system. Markus used a single case study to illustrate how the various elements of each of the theories could be applied as an explanatory vehicle.

Markus arrived at a number of conclusions from the case study. One conclusion was that technical systems by themselves cannot induce large changes to the organizations. The people tasked to use the systems will tend not to accept the system if it is simply imposed upon them. On the other hand, technical systems cannot operate themselves, and people must be i...

Table of contents

• Cover Page
• Half Title Page
• Title Page
• Copyright Page
• Contents
• Series Editor's Introduction
• 1 Social and Technical Aspects of Systems Analysis and Design
• PART I Social Systems Focus: People
• PART II Sociotechnical Systems Focus: Processes
• PART III Technical Systems Focus: Projects
• Editors and Contributors
• Series Editor
• Index