In lieu of an abstract, here is a brief excerpt of the content:

Calvin Pava Nonroutine Office Work1 Predominantly nonroutine office work often defies traditional socio-technical analysis. Multiple, concurrent, nonlinear conversion processes and profes­ sional separation render this approach inapplicable. This paper explores a socio-technical intervention based on the modified procedure. The setting is a software engineering group in a moderate-sized computer systems firm. At the time of the design, the department employed 52 professionals and 12 support staff. The steps taken were as follows: Step o: Mapping the Target System Step 1: Entry, Sanction, Start-up Step 2: Initial Scan Identify the Environment Summarize Major Historical, Social and Physical Features Formulate the Mission Formulate the Philosophy Step 3: Technical Analysis List and Assign Priorities to Deliberations Identify Different Forums Identify Parties to Each Deliberation List Obvious Information Gaps in Each Deliberation Analyze Component Office Work Activities for Each Deliberation Step 4: Social Analysis Depict the Role Network Summarize Characteristic Values Identify Reciprocal Values Outline Discretionary Coalitions Step 5: Work System Design Charter Major Deliberations and Discretionary Coalitions Chart Responsibility for Major Deliberations Design Human Resource Policies that Support Effective Coalitions Step 6: Approval and Enactment ‘A revision of Chapter 5 in C.H. Pava, Managing New Office Technology: An Organizational Strategy. New York/London: Free Press/Collier Macmillan, 1983. Nonroutine Office Work 645 Step o: Mapping the Target System The initial request for organization redesign came from a program team leader in a unit assigned to a large, innovative software development project for a highly advanced system the company was working on. He was concerned that the existing social and technical infrastructure, adequate for smaller projects, would prove insufficient to manage such a large undertaking, and he explored this situation with a consultant. From the start it was apparent that changing only the organization of a few program team leaders reporting to this single development program leader would not generate much improvement. Instead, a broader change initiative was necessary. At a minimum, the reconfiguration of work would have to embrace the entire software group involved in the computer system develop­ ment project, perhaps spilling over into hardware engineering. Ultimately, organizing deliberations2 that spanned all units working on the new computer would result in the tradeoffs necessary for its success. Step 1: Entry, Sanction, Start-up The program team leader worked with the consultant to create interest in the proposed design effort. Discussions and instructional materials (cases of re­ design in other organizations) eventually persuaded all development program leaders and senior programmers to sanction redesign of the entire software group. Representatives from different levels and specialties in the software group formed the design team. The team’s mandate was to analyze the software group and to propose a more effective social and technical configuration. The team members were also asked briefly to analyze other groups involved in the computer system project and to suggest changes that might be made in their work system. The development programmer convinced initially skeptical, reluctant top managers to champion the design effort. To do this, the heads of other units involved in the development of the computer system were invited to join a steering committee. This committee would periodically review the design team’s work, providing a sounding board and perhaps smoothing the way for redesign of other units participating in the computer development project. Because of severe time pressure on all team members, it was agreed in advance that the consultant would perform certain tasks on behalf of the design 2Pava’s “deliberations” and “discretionary coalitions” are detailed by Trist in this volume, pp. 662-73. 646 Collaborative Action Research team; precisely what was initially left open. It was also agreed that the team was to meet once each week for a maximum of five hours and that the steering committee would meet with the design team on a monthly basis, with short updates written weekly by a design team member and the consultant. Step 2: Initial Scan The initial scan gets the design team to paint the “ big picture” — how the system’s software engineering organization has developed and how it currently functions. Id e n t i f y t h e E n v i r o n m e n t The mission of a work system must be executed in relation to a dynamic envi­ ronment. Socio-technical theory distinguishes two levels of the environment: the transactional and the contextual. The design team outlined the software group’s transactional environment to include hardware engineering, market­ ing, customer service and...


Additional Information

Related ISBN
MARC Record
Launched on MUSE
Open Access
Back To Top

This website uses cookies to ensure you get the best experience on our website. Without cookies your experience may not be seamless.