Pergamon Accting., Mgmt. & Info. Tech., Vol. 4, No. 2, pp. 61-86, 1994

Copyright 0 1994 Elsevier Science Ltd Printed in the USA. All rights reserved

0959-8022&l $6.00 + 03




Claudio U. Ciborra University of Bologna and Theseus Institute

Giovan Francesco Lanzara University of Bologna

Abstract - Most accounts of computer-based innovation in organizational settings assume a naive pic-

ture of organizational change, overlooking events, features, and behaviors that, though unexpected and

puzzling, may be the sources of inventions, new knowledge, new organizational routines and arrange-

ments. The ambivalent, untidy, and often unpredictable character of IT-based innovation and change

is hardly captured, even by more recent theoretical approaches that have nevertheless provided a deeper

understanding of the complex interaction between technology and organizations. Based on field obser-

vations of the failures and successes during a major systems development effort in a large European

computer manufacturer, we tell a different story: We submit that failures at innovation, surprises, and

a whole range of related phenomena can be accounted for by introducing the notion of formative con- text, that is, the set of institutional arrangements and cognitive imageries that inform the actors’ prac- tical and reasoning routines in organizations. Limited capability to inquire into formative contexts is

responsible for the actors’ limited learning, irrespective of their strategies, interests, espoused theories,

and methods. Still, we suggest, plenty of opportunities for innovation lie in the open, pasted-up nature of formative contexts and a new vision of design based on “context-making” interventions can bring

them to light.

Keywords: Information technology, Innovation, Formative contexts, Systems design.


In the last three decades a whole variety of computer-based information systems have invaded our workplaces in organizations and institutions, in some cases radically chang- ing their familiar landscape. These multiple waves of innovation in information technol- ogy have yielded remarkable transformations in organizations and aroused new research interest in the dynamics and the complexities of organizational change. Countless studies have looked at the impacts of automated systems on issues such as task allocation and execution, information flows, decision-making, upgrading/downgrading of skills and employment. In such studies the new systems have been regarded either as technical tools supporting a more efficient execution of work routines or as organizational technologies automating control operations and coordination processes and bringing about a new orga- nization of work.



Successes, failures, conflicts and power games around the design and use of new tech- nology are also reported in the literature (Boland & Hirschheim, 1987; Lyytinen & Hirsch- heim, 1987), together with instructions regarding which actions and remedies should be taken to obtain specific organizational outcomes; for example, the application of structured design methods (De Marco, 1979; Jackson, 1983; Yourdon, 1982); or users’ participation in systems development (Briefs, Ciborra, & Schneider, 1983; Mumford 8z Henshall, 1979); or, finally, the political skills and strategies required for the effective management of change (Keen, 1981; Markus, 1983).

Despite their different perspectives these stories of technological and organizational inno- vation share a sort of deterministic explanation, which assumes a linear, straightforward consequentiality among the actors’ choices, actions, and outcomes of the innovation pro- cess, and attributes to systems a “closed,” purely instrumental character: systems are “designed” ex ante, embed preestablished and nonambiguous purposes, and provoke “impacts” accordingly. In other words, it is assumed that designers and implementors have a clear view and stance with respect to what a system should or should not do, and that the system itself will behave to the rule. According to such stories it seems that despite their intrinsic complexity systems never exhibit unexpected features or behaviours, and hardly influence the premises, the goals, and frames adopted (often unawarely) by the actors engaged in the innovation process.

We regard this genre of storytelling as too coarse. By assuming a simplistic picture of the dynamics of organizational change, these stories miss the deeper, multiple realities and meanings of systems’ design and computer-based innovation in organizational settings. Fur- ther, they overlook the increasing number of novel and puzzling behaviours exhibited by systems when they are in use, and therefore fail to account for events and features that, because they fall outside the scope of the original plans, sometimes happen to be the sources of inventions, new knowledge, new organizational routines and arrangements. In many an instance some of the novelties- be they positive or negative-are not even perceived by organizational members and analysts. As a consequence, the understanding of the complex- ities of systems’ design and change may be inadequate and the implementation process may suffer severe limitations.

In the attempt to better understand the implications of information technology and to overcome the deterministic flavour of many previous stories and explanations, a number of different researchers in recent years have carried out more refined empirical studies and developed more theoretically articulate frameworks to account for the complexities of tech- nological and organizational innovation. To name only a few, Miller and Friesen (1980) first, then Greenwood and Hinings (1988) introduce the notions of “archetype” and “change track” to provide a descriptive account of the dynamics of organizational transitions; Bar- ley (1986), Orlikowsky and Robey (1991), Poole and DeSanctis (1990) use Anthony Gid- dens’ theory of structuration (Giddens, 1979, 1984) to capture the “structuring” role of technology and reconceptualize its complex, “dual” character (Orlikowsky, 1992); Zuboff on her part, in a broader, neo-Weberian mode, delves deeply into the subtle interactions between knowledge, work, and power brought about by the advent of the “smart machine” (Zuboff, 1988). These approaches all strive toward the search for new concepts and frame- works better suited to allow for a more satisfactory treatment of the complex interactions between organizations and information technology and have, indeed, produced valuable results. But, perhaps with the notable exception of Zuboff, they overlook some important points that we regard as crucial. First of all, they tend to be too general, and the concepts developed retain a much too abstract character. For instance, as Orlikowsky’s recent work


shows, what Giddens’ structurational approach can offer to our field of interest is a sort of metatheory to systematize a wide range of phenomena in a coherent manner, with an altogether heavy reproductive and ordering bias. The same underlying interest in pattern reproduction and continuity is revealed by Greenwood and Hinings’ design archetypes and tracks. As we shall see in the following, concepts like “structuring” or “archetypes and tracks” do not seem to us apt enough to capture and convey the fragmented, ambivalent, untidy, and often unpredictable character of change and innovation in organizational set- tings. More specifically, they seem to be at loss in accounting for actions and behaviors that may not be necessarily consistent with the reproduction of existing patterns, or even with the structuring of whatever new pattern, but simply “branch out” of the currently practiced repertoire of routines. Second, in these approaches the issue of design practice is much talked about but never tackled seriously: Design is thought about as a method rather than as a practice or intervention. How then do such abstract frameworks come to bear when we come to the question of how a specific structure is actually produced (not simply described) or how a new system or organization is designed in practice? To what extent do they generate and convey usable, practical knowledge, that can be of help to systems design- ers when they are involved in designing within their unique organizational settings? We feel that the field of information systems needs more practical, action-oriented, close-to- experience concepts to deal with the ambiguities, and with the opportunities, of real change and design situations.

Based on evidence from a case of software production in a large computer manufactur- ing company, this paper explores a different path. We propose an interpretive vocabulary for helping systems’ designers and organizational actors better deal with the ambiguous and interactive settings they find themselves in, and we sketch a tentative framework for sys- tems’ development based on local, practical experiments, that we call “designing-in-action.” Our argument is built on distinct, but interconnected parts. First of all, we submit that computer-based information systems are not just technical tools or organizational technol- ogies, but also, as the case will show, embodiments or “vehicles” of emerging modes of work organization, of new cognitive imageries and institutional arrangements. Not only do they bring about new routines for work or incrementally adapt old ones, but they also enact whole new patterns of behaviour and modes of thought.

Second, and more specifically, we argue that computers-or, for that matter, any other innovative artifact -do interact with both the structural and institutional arrangements associated to a given division of labour and the assumptions, frames, and mental images that people hold while routinely enacting and practicing that specific division of labour. The repertoire of current skills and practical knowledge of people at work and the cogni- tive ground itself upon which they are built are also deeply affected. Systems are relatively open and plastic, no matter what their initial purposes and designs may be. But once designed and introduced into the organization, they tend to evolve along paths that are often unexpected and irreversible, subtly changing the ways people design and carry out their work practices, experiment with alternative arrangements and routines, or implement alternative visions and designs.

Third, most of these change processes, because of their cognitive and social embedded- ness, are largely unnoticed in organizational and design settings. But being unaware of them may cause failure of any effort aimed at steering or redirecting the course of innovation. Indeed, a major obstacle to effective experimentation and adoption, and more generally to flexibility and innovation, is limited learning, that is, the limited capability to reflect upon and reframe the institutional and cognitive grounds that support the habitual “ways


of doing things,” individual and organizational. Consequently, the capability of implement- ing new patterns of action is also limited (Argyris, Putnam & McLain Smith, 1985; Argyris & Schon, 1974, 1978). Yet, the effective adoption of new systems can only occur through processes of learning where organizations become competent in smoothly turning anom- alies and novelties into innovative patterns of behaviour. Failure to do so will predictably yield situations where people and organizations-to recall a verse of T.S. Eliot - “had the experience but missed the meaning.”

In order to interpret the puzzling evidence shown by the case and to investigate the nested mix of practical, cognitive, and institutional elements influencing routines’ execu- tion and change, we must take a theoretical step that we regard as crucial: We must draw a distinction between the work routines as they are carried out daily in organizations and the “formative context” within which those routines are “formed” and receive their mean- ing and scope in an actual situation of action. Originally the distinction comes from phe- nomenology and ethnomethodology (Garfinkel, 1967; Schutz, 1960) and was later used in anthropology (Bateson, 1972) and social and political theory (Unger, 1987). As Blackler (1992) has recently pointed out, the awareness of such distinction is paramount in refram- ing many of the technical and management issues emerging around the design and the adop- tion of new technology in organizations. In this paper we explore the idea and the salient characteristics of formative contexts in detail, stressing their subtle and pervasive influence in the design and operation of new routines and systems. The open, pasted-up nature of systems and routines and the embedded quality of practical knowledge informing human skills are shown to be positive assets to be purposefully exploited rather than handicaps to be removed. The main implications for a new vision of design based on “context-making” intervention and online practical experiments are finally sketched. The outcome of such “designing-in-action” should be systems and routines that help organizational actors per- form a perpetual activity of reflection and self-questioning.

Our argument is based on data gathered during a 6-month field study of a major effort at technology-based innovation involving about 400 persons. We have conducted on-site participant observation of the work process and semistructured interviews with the major actors-designers, personnel officers, and programmers-at different stages of the system’s development project. Also, in the course of our analysis we have given our partners some feedback about the phenomena that we observed, as we made sense of them. Such inter- action allowed us to collect further data for testing and refining our understanding and helped the actors to become more aware of their own behaviours and discover features about their work that they hadn’t previously perceived or thought about.


The R&D department of a large European computer manufacturer was assigned by top management the task of developing the operating system of a new minicomputer line. The challenge of coordinating and controlling hundreds of programmers working simultaneously at the same piece of software caused concern for the already precarious internal organiza- tion of the department. Market analyses signalled that the industry needed a competitive solution within 2 years time, maximum: Beyond that horizon the technology and market trends for operating systems were impossible to forecast. Hence, the imperative of a quick time to market for the new system in the making.


In an initial move to face the complex task under such time pressure, the chief software designers chose to shape the overall department’s structure according to the functional orga- nization of the new system. A team of programmers was set up for each function the SYS- tern was designed to perform. A hierarchical structure was set up to connect the various teams. This overall design choice was based on an analogy, widely supported in the data processing profession, between the work organization’s and the software structure: the cur- rent belief for successful software development prescribed designers to use the same orga- nizing rules for both the artifact to be built and the people who should perform the job (Daly, 1979). The organizing rules suggested were:

l Keep each software segment small so that it can be easily understood; correspondingly each software team should be small so that it can be effectively controlled;

l Each software segment should be loosely coupled to other segments; each software team should be assigned a unit of work, which allows for minimal coupling among

software teams; l The scope of effect of a software segment should be a subset of scope of control; soft-

ware teams should report to a manager so that the decisions made within the manager group have minimal effect on the work of other managerial groups;

l As software is decomposed into a hierarchy of segments, higher-level segments per- form decision-making and lower-level segments do the actual work; correspondingly, the managerial hierarchy performs decision-making and the lower organization lev- els perform the actual work;

l Pathological connections, i.e., those communication links not respecting the hierar- chical software structure should be avoided; in the same spirit, sideways connections among programmers in the organizational structure should also be avoided.

As a way of controlling costs in systems building activities, the organization mandated that the system development process be divided into phases and that specific documenta- tion be produced at the end of each phase so that work progress could be monitored and corrections made when necessary. In parallel, the personnel department started out to define tasks, roles, rewards, and career paths for each unit in the functional organization. The hierarchy looked as follows: a chief programmer, responsible for developing one or more subprograms, controlled the interfaces between modules within a subprogram. Inter- faces between subprograms within a class were controlled by the first line manager, who was responsible for the development of a software class, and so on.

Unfortunately, cooperation between the software designers and the personnel depart- ment proved to be lukewarm. The former thought that there were more urgent deadlines to be met in actually constructing the system; the latter tended to avoid the analysis of the technical details of each task, given their ignorance of software production. When the actual project started, it was apparent that communication from one activity to the succeed- ing ones was carried out in various, unexpected forms: for example, by having one person carry out a whole sequence of activities, thus centralizing information; by oral communi- cation among members of a subproject; or by notes often discarded after their initial use. As a result, the project proceeded without any effective management review and control, and the everyday work organization of the programmers remained terra incognita for both groups.

After some time, the project was plagued by problems that computer manufacturers often face in this type of endeavor: delays, sky-rocketing costs, poor documentation, back-


logs. It was evident that the project could not be managed by manual methods, fragmented documentation and loose planning. Continuing time pressures urged the department heads to move swiftly to a more modern software organization, by establishing stricter controls over the development process, and improving software productivity significantly. Specif- ically, more advanced tools were needed to provide support for the system designers in the collection, control and processing of design specifications and programs, such as:

l Improved organization hierarchy through chief programmers and a thoroughly doc- umented and enforced design methodology:

l Standard techniques to decompose software in functional entities; l Strict software documentation, usually computer generated, that is, a direct output

of the design process. Such documentation is structured and accompanied by a hier- archical chart;

l Design walkthroughs according to preestablished review formats employed at each level of software decomposition;

l Strong management planning and control systems to help plan and control software quality, time, and cost.

More in general, all major software interfaces and data structures had to be better defined before the detailed design. They would form a “contract” to be monitored and controlled throughout design and testing. Standards would represent the way through which interfaces and personnel communicate with each other.

When a major restructuring was decided by top management, two innovations were introduced to increase productivity and improve the organization of work. The first one consisted of a structured methodology for rationalizing software development, that is, a set of guidelines, very much inspired by the principles above, to organize work, divide it into stages, define precise goals and activities for each stage, such as analysis, program- ming, documentation etc. (DeMarco, 1979). At the espoused level the idea of a structured methodology appealed to everybody in the R&D department, because it supported key- values of the software culture: rationality, order, transparency, and consistency. In fact, the software engineering methodology was supposed to change the activities of systems analysts and programmers from an art to an engineering task. As for any engineering activ- ity the aim of the methodology was to provide a framework and tools to allow program- mers to complete their job in a prespecified time period at a minimal cost. Three concepts shaped the methodology: modularity, top-down development, and a structured approach. Modularity isolated the logical parts of the system that belonged together. Each module performed some logical subset of the total system processing. The communication between modules was carefully controlled, and as a result the internal programs needed not be known by the other modules. The basic structure of the modules was designed to facilitate a better organization. Since the workload could be parceled out among programmers according to skill levels, the limited scope of each module made local development an eas- ier task to execute and monitor. Last but not least, the standards developed for interfac- ing modules formed a basis for the programmer’s communication. Each module could be more easily optimized. Explicit schedules for testing could be generated. Changes could be isolated to closed modules: they could be made without widespread changes in the over-

all system. This was the theory (Konsynski, 1984). Surprisingly enough, the practicalities in the use

of the structured methodology lead to a very different outcome: To everybody’s astonish- ment the usual messy organization crept rather quickly into the rational grid of the meth-


odology, devoiding it of any real and lasting impact. At the espoused level, structure was in, and sloppy development practices were out; at the actual behavior level, structure was out, and a sort of “garbage can” (March & Olsen, 1976) organization was in.

On the other hand, the second innovation-the so-called “software factory”- turned out to be an undisputed success. This concept included a set of development tools that allowed software managers and programmers to perform the innovative aspects of software devel- opment and automate most of the structured tasks. Typical functions performed by the software factory are:

l Programs accept rough software documentation and check all data variables, insert a definition of each data element; format documentation according to predefined stan- dards; generate data base maps and flow charts;

l A requirement language processor and a language processor allow for cross correla- tion between system specification and the design documentation, and check for completeness;

l A software library allows for effective storage and subsequent retrieval of functional software modules, facilitating extensive sharing and reuse of modules both within a given development as well for exchange among different developments:

l High-level programming languages are dedicated to automatic code generation.

The software factory selected for the department consisted of a computer network connecting hundreds of workstations, on which the set of software tools ran to support the programmer’s job. The network allowed resource-to-resource communication both by mon- itoring dependencies between software modules and by distributing the builds over the net- work; many modules were compiled on multiple computers simultaneously, or on one centralized mainframe, rather than one at a time on a single batch machine, as it occurred previously. The factory provided a capability for system-to-user communication via auto- matic triggers that notified people about changes to specific files. And it supported person- to-person communication through its task manager. Thus, for example, there were commands for revision control and for creating file dependencies (Cardwell & Miner, 1991).

The software factory linked each programmer to his/her fellow worker through elec- tronic mail facilities, forming a new programming environment for interactive and simul- taneous software development. In the new environment, individuals gained the power to make decisions that would otherwise require discussion, transactions, or hierarchical approval: The software developers discovered that the tools would automatically notify appropriate team members of ongoing changes, and previous versions of the software could be retrieved if necessary. The software factory represented the running memory of the project resulting from individual actions and team interactions. Indeed, it became the basic infrastructure for the daily work of the programmer: Everybody took the “factory” for granted as the environment for “programming-in-the-large.”

However, the success did not help the diffusion of structured methodology. The lesson stemming from its failure was hardly learned: With costly investments, new attempts at developing and enforcing “more structured” methodologies were again carried out, with no better results. Various explanations were aired for the cyclic failures and the apparent impossibility to put order in the work flow. Some programmers suggested that a messy organization was in the interest of the chief designers: It gave them ample room for maneu- vering and politicking. Others claimed that a more formal structure and further automa- tion were necessary. A group of dissatisfied programmers, backed by the union, went so far as to try out a “democratic” work group. But the majority of programmers were wary


of such a grass-root experiment, because they considered it inapplicable to complex pro- gramming tasks. Its advocates, too, conceded that the alternative organization would require extra effort and commitment that just were not there.

At a closer look, however, the actual work organization showed some striking features, indicating that programmers operated through the software factory in a way that sharply differed from the various images and theories that they and their managers espoused. Though not officially acknowledged, group work was widely practiced “below the surface.” Namely, much of the coordination that supported it took place via the electronic mail and software tools. The messaging system provided an informal channel for direct communi- cation between programmers; the tools allowed for the integration of different pieces of code and would keep automatic updating of the parameters of a program, when other inter- linked programs were changed. The software factory was then not just a production tool but also an “organizational technology,” able to “informate” the whole Department (Zuboff, 1988). The network could support enlarged work groups comprising several pro- grammers at a time, crossing both the physical barriers defined by the department’s geo- graphical layout and, more importantly, the organizational boundaries between the units of the hierarchy. As a result, the real tasks, roles, and communication patterns were gov- erned neither by the formal structure defined by personnel nor by the vague functional scheme set up originally by system designers. They were, instead, the product of informal cooperation and bargaining taking place through the computer network.

Note how the software factory and its tools changed the nature of communication and teamwork. In the previous arrangement, horizontal communication between peer groups was considered pathological. It was then hoped that through the structured methodology standard would enforce a structure of communication. Thanks to the network, instead, a new underlying factor was allowed to emerge as an effective support for better communi- cation: trust. Team members learned to trust each other instead of making decisions on their own or reporting through the organizational hierarchy. Each developer was respon- sible for fully testing his/her own software modules prior to putting them in the pool of modules that was used by other developers. The trust in each other, coupled with confi- dence in the tools’ ability to reconstruct an earlier development state, increased productiv- ity by maximizing autonomy.

At a closer reflection a number of puzzling questions emerge from the case. Why did carefully planned changes, such as the structured methodology, fail, while other changes of equal scope and applied according to the same logic, turn out to be unquestioned suc- cesses? How come there was no learning from mistakes when failures occurred? Why did the various groups involved in the project-personnel, top management, designers, and programmers - keep oscillating between complaining about the status quo and taking ini- tiatives with very little impact? And finally, why did everybody fail to perceive that the pro- grammers were working in a radically different way thanks to the software factory?


Approaches in good currency: Task complexity, power games, cultural factors

When we tried to clear out what to us was a puzzle, we first turned to the main avail- able perspectives in the literature to account for technical change in organizations, namely: the complexity/uncertainty of the technology and the task (Galbraith, 1977; Herbs& 1974);


the power relationships between various interests groups (Crozier 8z Friedberg, 1977; Keen, 1981; Marcus, 1983); or the analysis of organizational culture (Schein, 1984, 1992; Smir- cich, 1983; Van Maanen & Barley, 1984).

To be sure, in the case described, the complexity of programming-in-the-large coupled with the actors’ bounded rationality may explain why the structured methodology failed. While software engineering manuals suggest that proper planning, management and con- trol, structure, formal rules and regulations, and task discipline are necessary in order to achieve a more reliable and well-understood product, empirical studies, backed by orga-

nization theory (Galbraith, 1977), consistently show that the development of complex soft- ware programs is an “organic” task, where 50% of the typical programmer’s time is spent interacting informally with other team members, and that such a task resembles a R&D activity more than manufacturing (Brooks, 1982; Dijkstra, 1976; Hauptman, 1986). Note, on the other hand, how the software factory was better suited for the new and complex task of the R&D department. It both improved individual productivity and allowed for flexi- ble coordination and bargaining between the work places linked to the network.

If actors, when trying out the structured methodology, may have ignored the limitations of the managerial philosophy dominating the software engineering field, it still remains to be explained why they were not ready to learn from the failures and ignored the work orga- nization that was emerging in the software factory. Unfortunately, even the approach based on political analysis is of little help here. All the actors, regardless of their position in the hierarchy, their particular interests, and their influence on the process, seem to be blind to mistakes and novelties. For example, those in favour of a more structured methodology were to be found not only among the systems designers but also in the programmers’ group. And the opposition to the union-supported reorganization did not come from management only. Instead, all the actors equally ignored the emergent work organization, which, by the way, would have provided ample opportunity for creating a power basis to influence the technology and the work flow. In sum, each group knew how to master its own routines, but did not grasp what went on in the department and was not able to intervene in an effec- tive way, no matter what its goals were.

Why did the actors show, then, such limited capability to learn from the failure and suc- cess of the two innovations? Being dissatisfied with the previous approaches, we tried with cultural analysis. Indeed, the actors’ blindness could originate from the dominant software and organizational culture pervading the R&D department. Deeply-engrained, shared images of hierarchical control, specialization of work, decomposition and modularity of task constitute a self-contained, coherent universe from which there is no escape for the actors. That is partly the case. But, then, how come at one stage they begin working in a new way? Where do the new routines come from? If the culture factor can help us, at a general level, to account for the actors’ unawareness of their own behavior, it fails to account for the “deviant,” emergent practices in the software production work. When the programmers begin to use the software tools, what kind of practical knowledge do they bring to the situation? And in which ways is such knowledge embedded in the context of action, that is, embodied in the tools and in the specific structure of the task, or draped in the organizational structure and in the process of collectively executing the task? Fur- thermore, how can we explore the implications and the consequences for learning and action of the actors’ unawareness of their current practices? Because of their stability and continuity bias cultural analysts have often disregarded issues of technological discontinu- ity, design and innovation.


The influence of the formative context

If we want to dig more deeply into the case and bring its richness to the surface, we need to bring the culturalist interpretive schema to bear more explicitly on the specific action and design situation. A more operational, action-oriented concept must be introduced: The actors, when skillfully executing the routines, when implementing innovations and imag- ining alternatives to improve their effectiveness, are under the influence of a pervasive and deep-seated texture of relations, or formative context, which accounts for their skill, the inertia of their learning, and the unawareness of their actual practices.

The formative context is the set of the preexisting institutional arrangements, cognitive frames and imageries that actors bring and routinely enact in a situation of action (Unger, 1987). A formative context comprises both an organizational and a cognitive dimension and has far-reaching, subtle influences: It constitutes a background condition for action, enforc- ing constraints, giving direction and meaning, and setting the range of opportunities for undertaking action. Though a formative context provides the ground for routine execution and influences the creation of new routines, actors are usually not aware of the formative contexts that inform their practical and argumentative routines. They tend to take them for granted, except in the case of major breakdowns (Bateson, 1972; Garfinkel, 1967; Schutz, 1960).

The outcome of a formative context in a work setting is a texture of routines, roles, and tasks that come to possess an “aura of naturalness” for those who daily execute the rou- tines in that context. The type of context that influences the members of the R&D depart- ment can be characterized as hierarchical. The hierarchy, the functional decomposition as a strategy for problem-solving, the drive toward structured formalization, the conflict between technical and bureaucratic roles, the informal organization of work seen as opaque and dysfunctional, etc., are some of the institutional arrangements and preconceptions that can be associated to it. The hierarchical formative context is retrieved and enacted by the actors in situations through specific moves and decisions (Pentland, 1992), when they need to make sense of their everyday routines and invent changes to achieve higher effectiveness.

Thus, when we interviewed the programmers and asked them to provide a description of their jobs, they would describe them according to the hierarchical system of roles and tasks, but they would not mention the role of the software factory, first because it is taken for granted, like the telephone, and second because it is not a part of the current, accepted descriptions of tasks and roles in the organization. The software tools and the work rou- tines by which they were actually doing the job did not surface explicitly in their verbal accounts, but stood-so to speak-in the background of their focus of attention and aware- ness. For instance, the programmers currently used the electronic mail facilities-it came “natural” to them- but never mentioned that such facilities supported direct all-to-all com- munication and coordination of work. They “talked” to each other all day long via the mes- saging system but apparently did not realize that by such “moves” (Pentland, 1992) they were indeed enacting a new “organized” way of building up the software code and pro- grams, which implied working and thinking in a network. Furthermore, when we asked them why they kept rehearsing the application of the structured methodology in the face of its evident failures, they answered that the failures were due to sloppy applications and to capricious human behavior, that the methodology was basically sound and was the “obvious” thing to do for such a complex programming task.

When later on in our analysis we made them notice that they were actually achieving group coordination by accomplishing the programming job in ways that strongly differed


from what they espoused, initially they seemed puzzled and claimed that electronic mail was only a technical tool, but later on, taking a second thought, they slowly began to realize that in their practical dealings and relations they were in fact following two different log- its at the same time: One was draped in (and in a way given by) the software factory and allowed for online, interactive and simultaneous, network-based, informal coordination and mutual adjustment; the other was formally stated in the official organizational design pro- vided by the system designers, and was based on formal procedures, hierarchical control, authority, and formal reporting to the higher level managers.

The hierarchical formative context blocks the learning of the department’s members; it makes them blind to the mismatch between structured methodologies and the uncertain- ties of the development process: To recognize the mismatch and reflect upon it would mean threatening large regions of the context itself. Also, the conflicts generated to support the present organization or to change it in a radical way (like the democratic work groups) hin- der the creation of a set of concepts and a language to describe those changes that have occurred but do not lead to higher formalization and standardization. Attention is focused, instead, upon the existing hierarchical arrangement, whether the purpose is to negate or to strengthen it.

In fact, the case shows that the interaction between daily work routines and the under- lying formative contexts to which they are linked is a complex one, especially in periods of transformation, when new events bring about sweeping changes. To wit, the introduction of the software factory, though implemented within the hierarchical framework, leads to unexpected outcomes, such as the establishment of the extension of new horizontal links between workplaces, the emergence of routines and behaviors, like working and bargain- ing in a network, that may point to a formative context of a different kind. Such con- text, that can be described as networking, is difficult to access because contexts tend to be undiscussable and because of the strong influence still produced by the hierarchical one (Figure 1). This leads to a general conclusion: Formative contexts show a pasted-up nature, and a makeshift one, where old and new routines are tested, discarded, retrieved, collated, and combined along a main stream of sense.

Finally, note how the case, and the notion of formative context we have introduced to interpret it, not only show an instance of limited learning during technological and orga- nizational change, but also open up a new field of inquiry and design. Namely, when devel- oping a system like the software factory, the object of design and construction- be it deliberate or unintended-does not only consist of new organizational routines, programs, procedures, databases and flows but, more importantly, of a new formative context. This can shape both the organization of work and the set of social scripts that govern the inven- tion of alternative forms of work, the future ways of problem-solving and conflict reso- lution, the revision of the existing institutional arrangements and the plans for their further transformation.

Kin concepts: Affinities and differences

As we have used it here and elsewhere (Ciborra & Lanzara, 1989, 1990), the notion of a formative context shares some similarities with a number of kin concepts that recently have come in good currency in the field of organizational studies, such as frames of ref- erence (Shrivastava & Schneider, 1985), organizational culture (Gagliardi, 1986; Schein, 1984, 1992; Smircich, 1983; Van Maanen & Barley, 1984), structuration (Giddens, 1979, 1984; Orlikowsky, 1992), or theory-in-use (Argyris, Putnam, & Smith, 1985; Argyris &



Preexisting formative context Emergent formative context +

(the Hierarchy) (the Network) division & mental schemes new division & new mental of work



Structured methodology Software factory

Conflicts & frictions Online adoption & use in implementation (‘bricolage’, branching out,

I deviations, reinvention)

I Traditional work routines New work routines

(hierarchy conceived (informally and as “natural” and unreflectively unescapable) performed)

Fig. 1. The process of innovation: The influence of the preexisting and the emergent formative contexts.

Schon, 1974, 1978). Such similarities might lead one to question the need for introducing a new concept. What does the formative context do that the other concepts don’t?

To begin with, a formative context designates what binds, in a loosely connected texture, an individual or a collective (group, organization) to an established world of objects and relations, and to the associated cognitive imageries, presuppositions and meanings of which that world is the embodied vehicle. It comprises what actors take for granted in their daily practical routines and transactions, what somehow they perceive as having an “institutional” valency for them. The context is “formative” in that it shapes the ways people perceive, understand, make sense, perform, and get organized in a situation bounded in space and time. It is “formative” because it may help people see and do things in new ways, or, on the contrary, make them stick stubbornly to old ways. Following Bateson (1972), context is used here in its interactional or transactional meaning, rather than psychological. Thus it is directly related to the manner in which individual or collective experience is organized, and to choices and actions that can variously punctuate and modify the flow of experience.

When enacted in a situation of action, formative contexts are expressions of a social cog- nition that transcends the individual. Such cognition may well be embodied in material or symbolic artifacts, organizational structures and procedures, institutional settings, and, most crucially, in the relationships or “couplings” binding actors and their work tools in a sort of microecology of stable uses and shared meanings. Thus, by introducing the notion of formative context in organizational analysis, we want to capture both the institutionally- embedded quality of social cognition and the cognitive dimension of institutional and orga-


nizational arrangements. Also Greenwood and Hinings (1988) with their notion of design archetype point to the need for concepts that capture the dual dimension of organizations - cognitive and institutional-and at the same time allow for a more synthetic treatment of the phenomena of organizational change, momentum, and inertia. In this perspective, on the one hand institutions and organizations embody and “act out” established assumptions and cognitions, and pose different cognitive demands to their members, depending on how roles, ranks, and tasks are defined and assigned; on the other, shared cognitive and learn- ing processes, and the outcomes of them, feed and crystallize into established artifacts and repertoires or cognitions that work as “cognitive institutions” in their own right, and can be modified or updated only through complex social and institutional mechanisms. As Mary Douglas (1986) has nicely pointed out, institutions - social and political-are estab- lished systems of premises or programs for action that help people think and act, or pre- vent them from doing so when they want to do it differently. To borrow Seymour Papert’s felicitous expression, they are-like the telephone or the computer- tools people use to think and act with (Papert, 1980).

Even this short account might shed some light on the differences between the idea of a formative context and purely cognitive concepts like frame, script, or schema as they have been developed in the cognitive sciences (Abelson, 1976; Minsky, 1985, 1987; Shank & Abelson, 1977) or in the psychology of choice (Tversky & Kahnemann, 1981). Being based on the pervasive idea of representation as an explicit symbol system, when applied to the analysis of organizational phenomena (Shrivastava & Schneider, 1985; Sims & Gioia, 1986), they lead to an excessive mentalization of organizations reality. Using purely cognitive con- structs, like frames or schemata, misses the fact that many important human skills and organizational abilities need not be associated with a capacity for external symbolic expres- sion. In other words, it may happen that individuals and organizations know how to do things that they cannot yet say or explicitly represent. Furthermore, these notions apply more easily to individuals rather than to collectives. Being conceived as structures or sche- mata that sit in the individual’s mind, they are too individualistic. When transposed to the analysis of organizational phenomena, they lead to theorize, by analogy, a sort of orga- nizational mind where all the representations are stored, waiting to be “acted out” in some behavior or performance. What gets lost is the social dimension of organizational cogni- tion, that is, the fact that all organizational cognition is directly expressed by a situated col- lective performance and produced within a social interaction (Pentland, 1992).

Secondly, and most importantly, a formative context is to be understood in the perspec- tive of action science (Argyris, Putnam, & Smith, 1985; Argyris & Schon, 1978; Schon, 1983). The idea that a formative context is an action-oriented concept is not easy to grasp. When actors undertake action, they enact a context in a situation bounded in space and time, and respond to it. In order to have a formative context there should be an action going on. For example, cultural features, organizational arrangements, design archetypes, and even material artifacts can become “items” of a formative context, when people use them as unquestioned grounds or “vehicles” for executing or designing routines in a situ- ation of action.

It is precisely the need to focus on action that makes it difficult to use Greenwood and Hinings’s concept of a design archetype for our purposes, notwithstanding the similarities. Archetypes assume a basic coherence between various org~ization~ elements and are used mainly for classificatory purposes, but fail to see that in practice, as Burns has remarked, “working organizations seem to be makeshift assemblies of relationships and activities which operate in accordance with several quite different sets of principles and assumptions”


(Burns, 1981). Also, they overlook the possibility that in a situation of action actors may be unaware of the archetypes guiding their routines and behaviours, and that such unaware- ness may influence both their choices and designs and the meanings they give to them. Finally, the concept of a design archetype may be useful to the analyst to gain knowledge about types of change or inertia, but is of little help to the agent if the question is how to produce a specific change or design in the situation in which he or she is engaged.

Similarly, though the notion of formative context is naturally inscribed in the culture- oriented approach to organizational analysis, the concept of culture has been used in the literature mainly in a descriptive fashion and has dealt with the domain of action only in a restricted way. Thus, for example, organizational culturalists such as Schein (1984), Van Maanen (1984), or Smircich (1983), who provide very perceptive and valuable insights on a variety of organizational phenomena, do not have an explicit agenda for design and inter- vention. And even those who have applied cultural analysis to the issue of change in institu- tional settings (Gagliardi, 1986; Pfeffer, 1981) seem to focus their attention on the conscious mental level, working on explicit representations and symbols, disregarding the taken-for- granted routines, institutional arrangements, and artifacts that populate our organizations and deeply affect our behaviours, imageries, and perceptions. But we claim that there might often be an important gap between observable behaviours and routines and background culture. The culture of a person or organization may become an item of the formative con- text if it is somehow relevant to the design or completion of an action, but it does not nec- essarily coincide with the context. That happens because people tend to design routines in response to a situationally-determined context that has mediating and “filtering” (forma- tive) properties with respect to their culture, and of which they may not be aware. Conse- quently, it may happen that people, who hold the same “cultural” assumptions at a general level, design remarkably different routines and behaviours pointing to different contexts.

One of the key issues of this paper, namely the complex, recursive relation between action and its institutional, or structural, background is being currently explored by authors that use Giddens’ structuration theory (Giddens, 1979, 1984) as a general framework for reconceptualizing the role and impact of information technology in organizations (Or- likowsky, 1991, 1992; Poole & De Sanctis, 1990). Though a full appraisal of the differences and similarities to our approach is beyond the scope of this paper, we shall briefly provide some reasons why we would resist interpreting the data of our case in a structurational per- spective. Stemming from a theoretical interest in the more general problem of social repro- duction (Giddens, 1976), the notion of structuration has an inherited bias for stability and reproductiveness that makes it awkward to deal with change (Sewell, 1992). Interestingly enough, structuration, as it has been applied to the IT field, has proved effective in eluci- dating the control mechanisms built in the technology or the self-reinforcing processes of preexisting institutional patterns and frameworks in organizational settings, highlighting the continuities and the regularities in those processes (Orlikowsky, 1991). But in our field study, on the contrary, we were exposed all the time to empirical evidence of fractures, inconsistencies, deviations from current routines, emergent properties in the process of change, which called for interpretation: Few things seemed to fall in place. Rather than a rule-based structural “syntax” of social change and transformation we needed a more prag- matic conceptual vocabulary that would help us better capture the actors’ perspectives and situated meanings when they are involved in action, account for their limited learning, and at the same time render the messy, makeshift, pasted-up character of the activities going on in a process of design and change. When performing their work routines or inventing new ones, actors do not directly respond to structures, rather they tacitly enact a context,


which is often embedded and implicit and has formative rather than structuring properties. Indeed, modalities of structuration may come to bear in a situation of action only within (and by means of) an enacted context, as it is perceived by the actors. Thus, while struc- turational approaches bend toward the search for general patterns across a wide range of situations, behind the formative context idea is a curiosity for the uniqueness and the gusto of specific design and action settings.

The distinction (and the connection) between organizational routines and their back- ground formative context is of paramount importance when we come to the question of how to design and implement innovation, for, when designing a new system, the object of design and construction-be it deliberate or unintended-does not only consist of new rou- tines, programs, and procedures but, more importantly, of a new formative context. Hence, strategies for change and design must be able to unfreeze and restructure cognitions and meanings that are hidden in the practical relations of people to their formative contexts. This is not easy to do, because smooth functioning of organizational routines tends to dis- connect individuals and organizations from their underlying contexts. In such conditions, effective change becomes problematic. Argyris and Schon (1978) rightly point to this prob- lem in their analysis of limited learning cycles, based on the distinction between an espoused theory and a theory-in-use. To be sure, what Argyris and Schon call theories-in-use share with formative contexts the same tacit, embedded quality that makes them hard to access and change. But, unlike a theory-in-use, a formative context needs not have a causal struc- ture. Rather, it has a fabric, textured with associative relations linking a wide variety of materials. While theories-in-use inform individual or organizational capacity to produce behavior in specific circumstances and tend to stay constant across situations, formative contexts express the engrained, sedimented cognitions, and the enduring, “institutional” artifacts that those theories-in-use have yielded and stabilized in organizational history.


The implications of the formative context idea for understanding the dynamics of inno- vation in organizations must now be further spelled out. More specifically, the following issues emerging from the case need to be explored: (a) Why do systems and routines designed according to a given logic get implemented and used according to a different logic? (b) What makes formative contexts change or, in any event, drift in spite of their high resil- ience and pervasiveness? (c) What are the interactions between contexts and actors, both at the cognitive and the organizational level?

The pasted-up nature of information systems

If we now go back to the case, we may take it as an instance of what everyone can expe- rience in the everyday life of an organization: Systems and routines are subject to “shift and drift” phenomena. The ways they are implemented and used never fully correspond to the original plans and visions, and design processes more often than not take paths unthought of at the start, almost beyond the actors’ will.

Systems, and the processes that lead to their construction, possess an open nature and are subject to continuous reinvention, that is, to an innovative adoption process carried out by the users themselves (Rice & Rogers, 1980). In part, they are characterized by formal- ized components, such as hardware, software, rules, functions, etc., but these do not com-


pletely dispose of how systems and processes behave in everyday life. Surrounding these stylized components, usually laid down as a result of ex ante design, there are routines and interventions carried out by users who may take unplanned courses of action or by design- ers who happen to be temporarily with the project, introduce quirky or irreversible design choices, and then leave. All these routines and interventions are continuously developed, tried out, retained or discarded, retrieved and combined, on a local, often tacit basis, out- side or at the margins of the master plans and designs, in an endless process of bricolage. Yet, though they constitute a “noncanonical” form of practice (Brown & Duguid, 1991), they are not without implications for implementation. There is no way to avoid their influ- ence on how a system or process will actually be and behave in its real-life operation. They are the outcome of an on-line design activity that we call designing-in-action.

But our perspective would be limited if we consider only the formal and informal adjust- ment routines that punctuate the development of any system (Nelson & Winter, 1982). The routines point to, and are an expression of, a formative context that comes to govern the choices and actions of users and designers (note how the latter distinction tends to blur: Both users and designers fully share the responsibility for developing routines and affect- ing formative contexts). The context itself, however, has not and cannot have a coherent and orderly structure: It results from a pasted-up combination of everyday practices and tinkering, a sedimentation of local and global arrangements. Thus formative contexts “shift and drift.” For example, the formative context underlying the routines of a given informa- tion system as it is concretely used may not coincide with the one that has governed the design and the development of the same system. It may reflect instead the actual, idiosyn- cratic division of work that emerges from the actors’ daily interactions with the system. Thus, the software factory had impacts that were not planned within the context that formed the background of its implementation. In this loosely connected set of practices, routines, and frameworks, single components are always up for grabs, while the set shows strong resilience as a whole.

In sum, formative contexts posses a double nature. On the one hand, they appear to be highly stable and inescapable, given their wishy-washy, sticky pervasiveness; on the other hand they can be regarded as the culture bed, at the routine level, for experiments in orga- nizational restructuring and innovation, within certain economic and technical constraints, themselves subject to local revision and manipulation. A regimen of permanent, inelimina- ble fluctuations characterizes such culture bed (Ciborra, Migliarese & Romano, 1984).

Each fluctuation, as the case of the software factory shows, can “escalate,” be ampli- fied and become the new way of running and conceiving things, thus contributing to shape the emerging formative context. Whether local fluctuations in practices and routines can escape the preexisting formative context, be intentionally tried out and developed by actors in everyday situations, depends heavily upon the degree of cognitive openness and vulner- ability the actors, the systems and the formative contexts allow for, or, in the words of the poet Keats, on the degree of Negative Capability they are equipped with, that is the capa- bility “of being in uncertainties, Mysteries, doubts, without any irritable reaching after fact and reason.”

Practical knowledge and the problem of routines’ change

Negative Capability is indeed a quality that the actors in the case seem to lack. As soon as mistakes, failures, or novelties destabilize their deeply-engrained way of doing things, the actors, instead of using them to question the status quo and design new courses of action, stick to their old way, showing distinctive limited learning skills (Agryris, 1977).


In general, a preexisting formative context is responsible for molding practical knowl- edge of people at work, perfecting the learning skills and biasing the imageries of those who engage in design and change. Individual skills and organizational routines supporting every- day practices are grounded on a knowledge-base that is taken for granted when engaging in action. Established repertoires of experiences and frames that have proved successful in similar occasions enable the actors to smoothly and unreflectively perform their routines (Polanyi, 1966). The formative context embeds such a knowledge-base, which represents the hidden, background component of skilled performance, straightforward organizational routines, and quiet functioning of institutional arrangements.

Due to the embedded quality of practical knowledge that informs human skills, one tends to pay attention to the locus of performance, while at the same time becoming una- ware of the formative contexts. Consequently, people exhibit poor capability at surfacing, questioning, eventually smashing them when they need to do so. A source of limited learn- ing is to be found precisely in how knowledge for action is split in the two levels of ready- at-hand routines and underlying formative contexts: If the focus of attention is on the former and the performance is successful, the latter tend to fade in the shadows of unawareness, becoming prewritten and unquestioned social scripts. Failures and novelties threatening their stability will seldom trigger a learning process leading to their restructur- ing: formative contexts gain thus a semblance of “natural necessity” (Bateson, 1972; Garfinkel, 1967).

Knowledge and experience sealed in formative contexts are expressions of what may be called the rationality of the obvious: they are, in a way, ready-at-hand cognitive resources that need not be questioned or tested every time one uses them. But the incapability of ques- tioning the obviousness of contexts generates cognitive inertia in organizations, precisely when a high capability for change and innovation is required, for example when applying a new technology. At the extreme, as in the software factory case, people start out prac- ticing new routines without being fully aware that they are dealing with a new formative context. So, actors are not able to see the new routines and do not talk about them while actually performing them, because the underlying formative context falls out of their cog- nitive reach.

This also means that whenever a knowledge-based system, or even a bread-and-butter computer application such as a payroll procedure are designed and implemented in an orga- nization, the basis for competence and the relevant formative context are affected in at least three ways. First, the boundary is shifted between what is tacitly held as background knowl- edge and what we are aware of as foreground “situational” knowledge (where in a specific work situation the focus of attention is explicitly directed to). Second, the basis for the invention, testing, and adoption of new forms of practical knowledge surrounding the use of the system in the work setting is altered. New practices, informal rules and ways of cir- cumventing routines are tried out and set in place within the constraints defined by the new infrastructure and its intrinsic requirements. Third, any invention of alternative practices, any radical departure from existing routines is deeply conditioned by the new mix of back- ground and situational knowledge, the new set of formal and specialized tools required by the system and the local practices, and informal know-how developed by using the new system.

Reframing information systems: Cognitive and institutional implications

Our argument will now be pursued further by taking as an instance the field of infor- mation systems, where the question of being able to restructure and invent organizational


routines is of crucial importance. According to a view in good currency, information sys- tems consist of routines, procedures, and technologies to process data electronically. Designing an information system means designing and implementing functional require- ments and specifications leading to formal and rigorous encodings, software routines, data- bases, and so on (DeMarco, 1979; Hice et al., 1978; Jackson, 1983). Recently this view has been challenged and more attention has been paid to the work, control, and decision pro- cesses served by the information system: The relevant object of system development is the organization and the control of work, not data flows or information as such. Finally, another perspective is based on the notion of transaction costs: An information system con- sists of the flows of data designed to efficiently support the network of economic transac- tions taking place within the organization (Ciborra, 1993; Williamson, 1981).

All the three approaches-as others do-rely on the implicit assumption that informa- tion systems can be realistically and rigourously described and designed in terms of data flows, work routines, or economic transactions. In this perspective, knowledge necessary for the design and the implementation of the new system can be acquired by interviewing users about their current routines and activities within a given user/analyst interaction. Such interaction may indeed involve conflicting interests and visions vis-a-vis the technology or the organization, but is supposed to be transparent with respect to the meaning given to the notions of data flows, databases, decisions, tasks, functions, etc. In other words, the three approaches limit their inquiries and methods to the explicitly visible patterns of activ- ities, though segmented and grouped in different ways. They construct pictures of infor- mation systems based-each in its own way-on a distinctive kind of obviousness.

Taking a different perspective, we submit that the components of an information system-data flows, work procedures or transactions - retain a more complex quality than what is currently assumed in these naively realistic pictures. These components are second- order constructs both from a cognitive and an institutional point of view. They are visible embodiments of ways of organizing reality, cognitively and institutionally, which are deeply entrenched in the formative contexts we bring to projects and organizational situations (Boland, 1979; Suchmann, 1987; Weick, 1985). What is considered the “natural necessity” of a data flow, a work routine, or a pattern of transactions is contingent upon a forma- tive context that may change as institutional arrangements and cognitive images evolve, shift, and break down. When that happens, what is taken to be data, routine, task, or orga- nizational function may lose its habitual meaning, and is seen and “acted out” in a differ-

ent way. We can now formulate a thesis that, as we shall try to show in the last section of the

paper, is full of consequences for the design and the use of new technology. That the soft- ware factory is an innovation containing, as it is concretely used, the seeds of a new for- mative context is not, in itself, an exceptional event. Any information system and, more generally, any artifact or tool affecting the division of work and the practical knowledge of people at work, shows the features of a formative context.

Indeed formative contexts mold information systems. They do it cognitively: The use of information systems embodies forms of practical knowledge concerning the gathering, processing, and distribution of information. By introducing new modes and procedures through which individuals and organizations deal with knowledge, an information system may cause a shift and a restructuring of the cognitive frames and assumptions underlying human performances and governing human actions. In other words, the hardware and the software may convey a varied cognitive imagery through which people grasp their world, undertake action, and communicate in a specific situation. They do it institutionally: An


information system can be regarded as supporting a set of contractual and institutional arrangements between individuals and organizations. By bringing about specific ways of organizing social relations and performing economic transactions, an information system embeds a set of rules, norms, and constraints that partially come to govern the processing, the communication and the use of information. Designing a system means, to a large extent, changing and restructuring the institutional bonds and background conditions upon which, even at the microlevel, people establish and enact their practical dealings and relations.

Information systems, then, should always be treated and designed at two distinct lev- els: the one of the formed routines and the one of the formative contexts. It is unlikely that a routine, even a payroll application, can be designed without at the same time affecting its formative context, and it is difficult to restructure organizational practices if the under- lying context is not restructured, too. System design cannot escape the issue of how to inquire and design formative contexts.


Are we equipped theoretically and practically to conceive and design systems as forma- tive contexts? If real-life systems are, to a large extent, the outcome of “pasting-up” and bricolage activities, what criteria should govern their construction? How can we tap rele- vant knowledge embedded in formative contexts and connect it to effective system design and implementation? These questions lead us to propose a style of design, based on prac- tical on-line experiments, exploiting rather than denying the qualities of systems and prac- tical knowledge described above (Moran & Anderson, 1990).

The challenge: Toward a new agenda for design

Current systems design practices, being mainly oriented to designing databases and pro- cedures in a cost-effective way or according to some principle of economic or political equity, tend to overlook the institutional and cognitive frameworks within which routines are formed, and given legitimacy and meaning. To wit, no matter how formally rigourous or participation-oriented they are, these practices seem unable to question and affect the quality of the actors’ relations to the institutional and cognitive frameworks that they estab- lish and inhabit in organizations. On the contrary, by not distinguishing clearly between routines and formative contexts, they tend to obscure the knowledge necessary to relate rou- tines’ change or persistence to the restructuring of formative contexts, to track the com- plex feedback loops binding contexts and routines, and to analyze the quality and the fabric of the contexts.

While current design methods capture and emphasize the functional or problem-solving role of a routine, they fall short of understanding how the same routine may reproduce or break powerful imageries and institutional bonds at a deeper level. Conventional methods are based on the assumption that people will “automatically” start out adopting novel pat- terns of behavior and new ways of looking at things just because a new machinery has been cast into the organization; or else they claim not to disrupt the present organization, when in fact they do it, again leaving the actors incapable of effectively handling technical change and unaware of the emergence of a new formative context, as in the case of the software factory. Thus system designers keep reproducing the conditions for the recurrent discrep- ancy between theory and actual system performance.


But can the design of formative contexts be within the actors’ institutional and cogni- tive reach? To begin with, consider those highly successful systems, that have established new standards in business: in general, they do not seem to be the outcome of a carefully planned design and project management. To the contrary, they reveal once again their quasi-accidental quality, the uniqueness of their discovery, their pasted-up, experimental nature. For example, strategic information systems (Wiseman, 1983, such as the renowned one developed in the late seventies by McKesson Chemical and American Hospital Supply (Guild, 1988), seem to derive their quality from the inventive exploitation of the potential of computer systems already in place for other “more serious,” but hardly imaginative pur- poses such as accounting.

What seems to matter here, more than a formalized methodology that freezes action and thought, is the serendipity of the process, the actors’ willingness to explore routines, activ- ities, and events that “branch out” of a main design, system, practice, or sense, and their capability to take the chances offered by the pasted-up nature of systems and practices, instead of trying to harness them to further standardization (Hedberg & Jonsson, 1978; Weick, 1985).

If we are to face the challenge that the complexity of real-life systems in organizations is calling for, current design practices need to be redirected. We argue that these should amount to more than property determination and requirements specification, to more than exercises in routine problem-solving or interest-accommodation, for they should deal with the structures and frameworks within which such exercises take place, i.e. with shaping and restructuring formative contexts. What is badly needed is competence in context-making rather than new techniques of problem-solving, game-playing or participation. Most impor- tantly, actors need to learn practices that help them question and restructure the formative contexts that influence their cognitions and actions.

The intervention: Designing on-line practical experiments

How can people deal with the design of formative contexts? The answer is to be searched for in the very nature of formative contexts. Recall the following:

l Formative contexts are seldom replaceable all at once; rather they change in a piece- meal fashion. The actor’s imagery tends not to follow the machinery right away, at least not so rapidly and smoothly or in the direction expected;

l Formative contexts and the processes through which they are formed possess a trumped-up quality: Single components are continuously replaced or combined with new ones in a process of tinkering and practical experimentation that need not be methodical or systematic;

l Consequently, context change and context-making are not governed by law-like con- straints or stable developmental tendencies; on the contrary, they proceed by “branch- ing out” and fluctuation. Full control and centralized standardization of the process are usually impossible;

l Formative contexts are surfaced in situations, actions, behaviors. It depends upon our awareness and learning skills to be able to reflect and intervene upon them.

Thus, one can change formative contexts only by intervening in situations. Intervention, as we propose it, is a strategy of action to come to grabs with the pasted-up nature of con- texts, both cognitively and institutionally. Practical intervention in a specific organizational setting challenges the institutional arrangements and the cognitive imageries on which estab-


lished routines are based. It aims at creating conditions that help people question and gain insight into formative contexts, while actually designing or executing routines in situations. The logic of intervention is in many respects different from the logic of analysis. Its epis- temology draws-on a theory of action (Argyris, Putnam, & Smith, 1985; Argyris & Schon, 1978). It is concerned with acting and learning in situations by making practical experiments to test formative contexts, to surface conflicts and inconsistencies, to explore deviations from routines and envisage the alternative contexts that they may lead to. From such on- line experimental activity analysis is not all excluded, but it cannot be done independently of the situation at hand: It is a sort of analysis-in-action. Being often difficult or impos- sible for people to conduct an inquiry of this kind while they are engaged in designing, the presence and activity of a “watcher” or “reflector” become crucial for intervention and designing-in-action. The reflector-who is a designer in his own right-helps designers and users to carry out evaluative and reflective functions on their own ways of thinking and act- ing in the design process. As it was conducted in a number of projects (Lanzara, 1991; Lan- zara & Mathiassen, 1988), a context-making experiment would involve the following activities:

l Living with the process and closely watching the designers’ activities and interactions as they progress in their work;

l Keeping track of the design process and mapping it as it unfolds, recording and mem- orizing events that designers perceive as relevant;

l Eliciting information from the designers through recurrent questioning, in order to make them explicitly describe and account for what they are doing, why, and how: objects, activities and reasons for action that they often take for granted;

l Helping designers reflect upon design assumptions, institutional constraints, strategies for action, aims and objectives, problems encountered, options for solutions, anom- alies and deviations from normal routines;

l Engaging in joint evaluations and self-evaluations, trying to assess the meaning of events and situations that designers perceive as relevant for the process and the out- come of design;

l Designing on-the-spot experiments in self-observation and self-evaluation by which designers can see themselves and their formative contexts mirrored in the others’ pic- tures of shared objects, events and situations;

l Helping the designers to proceed from self-observation to construction and testing of alternative pictures, frameworks and institutional arrangements, working out all the thinkable (although not necessarily feasible) consequences of imagined contexts in terms of routines and activities.

In other words, the reflector’s role is that of a mirror where people can look at themselves as they are seen and described by another mind. Actually, a better analogy would be a vid- eotape where one can look at oneself “in action.” This is what trainers and coaches usu- ally do in sports like skiing or soccer, or what choreographers do with dancers, in order to pinpoint and correct mistakes, and develop new ways of performing. Because of the reflector’s presence and inquiry, a domain of discourse is created that gives a kind of objec- tive existence to people, events, actions, and processes. Thus an additional abstract dimen- sion is introduced in the design process by making it “double back on itself” (Olafson, 1979). This “doubling back” is what allows people to have access to and intervene in the formative context with the purpose of challenging and changing it. The reflector is an active medium that may facilitate this process by helping designers go beyond their current ways


of doing things, by making visible and discussable what is generally held invisible and undiscussable.

Although the primary purpose of the reflector’s intervention is to break up consolidated knowledge and institutions, it should not be viewed as a merely destructuring activity: It involves projects, programs, and skills to transform deeply-engrained scripts, to depart from current practices, to respond to surprises in real-time, and to act with the “materi- als” of ambiguous and ever-shifting situations. Unfreezing and disrupting previous contexts require the invention of alternative practices, systems and organizational arrangements that possess a certain quality, namely the capability for self-questioning, for being viable means to further rounds of transformation (Weick, 1977).

The role of the designers themselves shifts from problem-solvers to context-makers. Their task should be to create a milieu where all participants are given the opportunity to project their own formative context upon one another, and thus, precisely because of this mirroring effect, become able to see it and reflect upon it (Lanzara, 1991). What is involved here is more than instrumental problem-solving or interest accommodation within a given context. Rather, it is the modification of the institutional and cognitive conditions that may constrain or liberate a whole set of problem-solving activities, of norms for conflict reso- lution, which ultimately determine what a system does in an organization.

The outcome: Systems and routines for self-questioning

We believe that our new understanding of the emerging properties of systems, and our new approach to systems development as context-making and designing-in-action have important implications for the functions computer-based systems are designed to perform.

In other words, we submit that the making of formative contexts as one of the basic activities in systems design should influence the very object of design. As a final exercise we indicate, then, the qualities that systems and routines may come to possess in this new perspective:

l Systems should facilitate rather than hinder the process of reinvention that any com- plex technological artifact undergoes when put to use;

l Application software should be designed in such a way that they do not conceal their relations to formative contexts, but make those relations explicit and questionable;

l Systems should be designed as media for enhancing coordination and communication: problems and solutions shift all the time, and systems, because of their open, pasted- up nature, benefit from loosely coupled forms of organizing;

l Systems and applications should provide on-line feedback to users on the organiza- tion of work, and on coordination and communication patterns which emerge from their use;

l Systems should be “expert,” though in a quite different way from current conceptions: In addition to supporting or replacing knowledge-based established routines of pro- fessionals and managers in specific domains of expertise, they should support their capabilities for reflection and inquiry within the contexts in which they are embedded, helping them to build up, question, and modify practical knowledge according to the emergence and the shift of problematic situations and contexts;

l Finally, systems should be designed as proactive, dynamic mirrors of human action, supporting and enhancing perpetual individual and institutional self-questioning: in short, they should play the role of “reflectors,” helping the users connect their prac-


tical and argumentative routines to the established or emerging formative contexts, rather than concealing that connection, as they often do.

We claim that such qualities and uses of technologies and systems would give the users a further cognitive and behavioral empowerment and would support a more flexible orga- nization, escaping the rigidity of many conventional applications. Furthermore, we suggest that in systems development higher capabilities for dealing with process phenomena on-line should replace or at least complement the current product-and-performance-oriented attitudes.


What we have been claiming so far is that current ways of looking at systems develop- ment fall short of understanding it as a phenomenon in the domain of action and change. In our view, they all share a fundamental flaw: They assume a direct consequentiality between conditions, choices, and actions leading to change and innovation.

Participation, consensus and users’ know-how are by all means necessary but not suf- ficient conditions for effective design and implementation: There are other sources of dif- ficulty stemming from cognitive, behavioral, and institutional bonds. Preexisting formative contexts plainly impede actors, regardless of their goals, interests, and espoused theories, to connect imagined alternatives to actions, to detect mistakes and appreciate novelties. On the one hand, the open, pasted-up nature of systems and development processes defies many formalized and participative attempts at mastering and steering a process toward spe- cifically programmed objectives; on the other hand, such nature can be purposefully exploited to design-in-action, to make things change by intervening in situations and exper- imenting with makeshift artifacts, or to keep going when the situation seems to be hope- lessly “blocked.” This is what makes systems, organizations, and people working with them capable of overcoming inertia and vicious circles when environmental turbulence requires high levels of flexibility (Emery & Trist, 1965; Lanzara, 1983).

The reframing we have proposed leads to a further outcome, which can shed a new light on the role of systems per se. Namely, systems share many of the qualities of formative con- texts, and designing a system interferes, if not coincides, with enacting a formative context, that is, a cognitive, institutional, and behavioral artifact, and a makeshift one. This arti- fact influences not only the routines that form the everyday world of people at work, but also, and most importantly, the ways people make sense of their routines and imagine future changes to their lifeworlds (Boland, 1979; Boland & Day, 1982; Weick, 1985). Our approach takes such everyday practice seriously (Moran 8z Anderson, 1990), instead of exorcizing it in the name of imperatives dictated by a misplaced notion of technical ratio- nality and by an artificial split between knowledge and practice.

Acknowledgements-The core ideas and arguments of this paper were preliminarily presented in May 1987 at the IFIP Conference on Information Systems Devetopment for Human Progress in Organizations held in Atlanta, GA, USA. Since then, revised versions have widely circulated among many colleagues who, with their suggestions

and critical comments, have helped us to improve it. We thank Chris Argyris, Richard Boland, Shahaf Gal, David

Hickson, Lars Mathiassen, Donald Schon, John Van Maanen, Karl Weick, Shoshana Zuboff, and anonymous reviewers.




Abelson, R.P. (1976). Script processing in attitude formation and decisionmaking. In R. Carroll & W. Payne (Eds.).

Cognition and social behavior. Hillsdale, NJ: Erlbaum & Associates.

Argyris, C. (1977). Organizational learning and management information systems. Accounfing, Organizations and Societv, 2(2), 113-123.

Argyris, C., & Schon, D.A. (1974). Theory in practice: Increasing professional effectiveness. San Francisco: Jossey Bass.

Argyris, C., & Schon, D.A. (1978). Organizational learning: .4 theory of action perspective. Reading, MA:


Argyris, C.. Putnam, R., & McLain Smith, D. (1985). Action science. San Francisco: Jossey Bass. Barley, S.R. (1986). Technology as an occasion for structuring: evidence from observation from CT scanners and

the social order of radiology departments. Administrative Science Quarter&, 31(l), 78-108.

Bateson, G. (1972). Steps to an ecology of mind. New York: Chandler Publishing. Blackler, F. (1990). Formative contexts and activity systems: Postmodern approaches to the management of change.

In M. Reed & M. Hugues (Eds.), Refhinking organization (pp. 273-294). London: Sage.

Boland, R. (1979). Control, causality and information systems requirements. Accounting, Organizations and Soci-

et.v, 4(4), 259-272.

Boland, R., & Day, W. (1982, December). The process of system design: A phenomenological approach. Proceed- ings of the Third International Conference on Information S_vstems. Ann Arbor, MI.

Boland, R.. & Hirschheim, R. (Eds.). (1987). Critical issues in information systems research. New York: John

Wiley & Sons.

Briefs, U., Ciborra, C., & Schneider, L. (Eds.). (1983). System design for, with, and b_v the users. Amsterdam: North Holland.

Brooks, F.P. (1982). The myfhicul man-month. Reading, MA: Addison-Wesley.

Brown, J.S., & Duguid, P. (1991). Organizational learning and communities-of-practice: Towards a unified view

of working, learning and innovation. Organization Science, 2, 40-57.

Burns, T. (1981). Rediscovering organization: Aspects of collaboration and manugerialism in Hospital Orguni-

xztion. University of Edinburgh, UK.

Cardwell, S., & Miner, K. (1991). Distributed computing and organizational change enable concurrent engineer-

ing. Hewlett Packard, Palo Alto. Ciborra, C.U. (1993). Teams, markets and systems- Business innovation and information technology. Cambridge,

UK: Cambridge University Press.

Ciborra, C.U., & Lanzara, G.F. (1989). Change and formative contexts in information system development. In

H.K. Klein & K. Kumar (Eds.), System development for human progress (pp. 21-40). Amsterdam: North

Holland. Ciborra, C.U., & Lanzara, G.F. (1990). Designing dynamic artifacts: Computers systems as formative contexts.

In P. Gagliardi (Ed.), Svmbols and artifucts: Views of the corporate landscape (pp. 147-165). Berlin: Walter

de Gruyter. Ciborra, C.U., Migliarese, P., & Romano, P. (1984). A methodological inquiry into organizational noise in socio-

technical systems. Human Rekutions, 37(S), 565-588. Crozier, M., & Friedberg, E. (1977). L’ucteur et le systeme. Paris: Editions du Seuil.

Daly, E.B. (1979). Organizing for successful software development. Datamution, December, 107-l 19.

DeMarco, T. (1979). Structured analysis and system specification. New York: Yourdon Press.

Dijkstra, E.F. (1976). A discipline of programming. Englewood Cliffs, NJ: Prentice Hall.

Douglas, M. (1986). How institutions think. Syracuse, NY: Syracuse University Press.

Emery, F.E., Trist, E.L. (1965). Socio-technical systems. In C.W. Churchman, & M. Verhulst (Eds.), Munuge-

ment sciences: Models and techniques. Oxford, UK: Pergamon Press. Gagliardi, P. (1986). The creation and change of organizational cultures: A conceptual framework. Organization

Studies, 7(2), 107-134. Galbraith, J.R. (1977). Designing Organizations. Reading, MA: Addison-Wesley.

Garfinkel, H. (1967). Studies in ethnomethodo/og_v. Englewood Cliffs, NJ: Prentice Hall.

Giddens, A. (1976). New rules of sociological method. New York: Basic Books. Giddens, A. (1979). Centralproblems in social theory: Acfion, strucfure and contradiction in social analysis. Berke-

ley, CA: University of California Press.

Giddens, A. (1984). The constitution of sociep: Outline of a theorv of structuration. Berkeley, CA: University

of California Press.


Greenwood, R., & Hinings, C.R. (1988). Organizational design types, tracks and the dynamics of strategic change.

Organization Studies, P(3), 293-316. Guild, D.W. (1988, June). Two examples of strategic information systems. Proceedings of the Workshop on Znfor-

mation Systems Strategic Planning. World Trade Center, New York, NY. Hauptman, 0. (1986, April). Influence of task type on the relation between communication and performance:

The case of software development. R&D Management. Hedberg, B., & Jonsson, S. (1978). Designing semi-confusing information systems for organizations in chang-

ing environments. Accounting, Organizations und Society, 3(l), 47-64. Herbst, P.G. (1974). Socio-technical design: Strategies in multidisciplinary research. London: Tavistock Publishing. Jackson, M. (1983). System development. Englewood Cliffs, NJ: Prentice-Hall. Kanter, R.M. (1983). The change masters. New York: Simon and Schuster. Keats, J. (1817, December, 21,27?) Letters to George and Tom Keats. In C. Baker (Ed.), Poems ond selected let-

ters of John Keats. New York: Bantam Books. Keen, P.G.W. (1981). Information systems and organizational change. Communications of the ACM, 24(l), 24-33.

Konsynski, B.R. (1985). Advances in information system design. Journal of Management Information Systems, Z(3), 5-32.

Lanzara, G.F. (1983). Ephemeral organizations in extreme environments: Emergence, strategy, extinction. Jour- nal of Management Studies, 20(l), 73-95.

Lanzara, G.F. (1991). Shifting stories: Learning from a reflective experiment in a design process. In D.A. Schon

(Ed.), The reflective turn: Casestudies in ond on educationalpractice (pp. 285-320). New York: Teachers Col- lege Press.

Lanzara, G.F., & Mathiassen, L. (1988). Intervening into system development area projects. In G.C. van der Veer,

T.R.G. Green, J.M. Hoc, & D.M. Murray (Eds.), Working with computers: Theory versus outcome (pp. 177- 214). London: Academic Press.

Lyytinen, K., & Hirschheim, R. (1987). Information systems failures: A survey and classification of the empiri-

cal literature. Oxford Surveys in Information Technology, 4, 257-309. March, J.G., & Olsen, J. (1979). Ambiguity and choice in organizations. Bergen: Universitetsforlaget. Markus, M.L. (1983). Power, politics and MIS implementation. Communications of the ACM, 26, 430-444. Miller, D., & Friesen, P. (1980). Archetypes of organizational transitions. Administrative Science Quarterly, 25,


Minsky, M. (1975). A framework for representing knowledge. In P.H. Winston (Ed.). Thepsychology of com- puter vision. New York: McGraw-Hill.

Minsky, M. (1977). Frame-system theory. In P.N. Johnson-Laird & P.C. Wason (Eds.). Thinking: Readings in cognitive science. Cambridge, UK: Cambridge University Press.

Moran, T.P., & Anderson, R.J. (1990). The workaday world as a paradigm for CSCW design. In Proc. CSCW PO. Los Angeles: ACM.

Mumford, E., & Henshall, D. (1979). A participative approach to computer systems design. London: Associated Business Press.

Nelson, R., & Winter, S. (1982). An evolutionary theory of economic change. Cambridge, MA: Harvard Uni- versity Press.

Olafson, F. (1979). The dialectics of action. Chicago: The University of Chicago Press. Orlikowsky, W.J. (1991). Integrated information environment or matrix of control? The contradictory implica-

tions of information technology. Accounting, Management and Information Systems, l(l), 9-42. Orlikowsky, W.J. (1992). The duality of technology: Rethinking the concept of technology in organizations. Orga-

nization Science, 3(3), 398-427.

Orlikowsky, W.J., & Robey, D. (1991). Information technology and the structuring of organizations. Znforma- tion Systems Research, 2(2), 143-169.

Papert, S. (1980). Mindstorms. New York: Basic Books.

Pentland, B.T. (1992). Organizing moves in software support hot lines. Administrative Science Quarterly, 37, 527-548.

Pfeffer, J. (1981). Management as symbolic action: The creation and maintenance of organizational paradigms.

In B.M. Staw and L.L. Cummings (Eds.), Research in organizational behavior (pp. l-52). Greenwich, CT: Jai Press.

Polanyi, M. (1966). The tacit dimension. Garden City, NY: Doubleday.

Poole, M.S., & De Sanctis, G. (1990). Understanding the use of group division support systems: The theory of adaptive structuration. In J. Fulk & C. Steinfield (Eds.), Organizations and communication technology (pp. 173-193). Newbury Park, CA: Sage Publications.

Rice, R.E., & Rogers, E.M. (1980). Reinvention in the innovation process. Knowledge, Z(4), 488-514.


Schein, E.H. (1984). Coming to a new awareness of organizational culture. Sloan Management Review, Winter, 3-16.

Schein, E.H. (1988). Process consultation. Volume I: Its role in organizational development. Reading, MA: Addison-Wesley.

Schein, E.H. (1992). Organizational culture and leadership (2nd ed.). San Francisco: Jossey-Bass. Schon, D.A. (1983). The reflective practitioner: How professionals think in action. New York: Basic Books. Schutz, A. (1960). Collected Papers, Vol. 1: The Problem of social reality. The Hague: Martinus Nijhoff. Sewell, W.H. (1992). A theory of structure: Duality, agency, and transformation. American Journal of Sociol-

ogy, 98(l), l-29.

Shank, R., Abelson, R.P. (1977). Scripts, goals, plans, and understanding: An inquiry into human knowledge struc- tures. Hillsdale, NJ: Erlbaum Associates.

Shrivastava, P., & Schneider, S. (1985). Organizational frames of reference. Human Relations, 37(10), 795-809. Sims. H.P., & Gioia, D.A. (Eds.) (1986). The thinking organization: Dynamics of organizational social cognition.

San Francisco: Jossey-Bass.

Smircich, L. (1983). Concepts of culture and organizational analysis. Administrative Science Quarterly, 28(3), 339-358.

Suchmann, L. (1987). Plans and situated acrions. Cambridge, UK: Cambridge University Press. Tversky, A., & Kahnemann, D. (1981). The framing of decisions and the psychology of choice. Science, 211,

453-458. Unger, R.M. (1987). Fa/se Necessity. Cambridge, UK: Cambridge University Press. Van Maanen, J. (1984). Doing new things in old ways: The chains of socialization. In J.L. Bess (Ed.), College

and university organization. New York: New York University Press. Yourdon, E. (1982). Managing the system life cycle. New York: Yourdon Press. Weick, K. (1977). Organization design: Organizations as self-designing systems. Organizational Dynamics, 6(2),

30-46. Weick, K. (1985). Cosmos versus chaos: Sense and nonsense in electronic contexts. Organizational Dynamics, 14(2),

50-64. Williamson, 0. (1981). The economics of organization: The transaction costs approach. American Journal of Soci-

ology, 87(3), 548-577. Wiseman, C. (1985). Strateg.v and computers. Homewood, IL: Dow Jones-Irwin. Zuboff, S. (1988). In the age of /he smart machine. New York: Basic Books.