David Jennings

This paper focuses on organisational change and CSCW, and it reviews approaches to CSCW development that start from analysis of requirements. As an alternative, the paper presents an approach which sees development as a continuous process, with organisational change as a central factor rather than a problem to be overcome. This CSCW development process should be "owned" by the user organisation, and therefore the CSCW practitioner's support should take the form of consulting with the organisation as a facilitator of organisational and technological change. A number of precepts of this consultancy support are outlined, and their implications are considered.

1. INTRODUCTION
2. ORGANISATIONAL CHANGE: IMPLICATIONS FOR CSCW DEVELOPMENT PRACTICE
3. THE ROLE OF ANALYSIS IN CSCW DEVELOPMENT
4. REFOCUSING CSCW DEVELOPMENT
5. AN OUTLINE FOR CSCW PROCESS CONSULTANCY
6. DISCUSSION AND CONCLUSION
7. REFERENCES

KEYWORDS:

Organisational change, Requirements analysis, Consultancy, Design cycle.

Organisations throughout the world are going through rapid and major change. Such change often affects the patterns of interaction and co-operation within and between organisations, and this in turn is bound to affect requirements for computer support. Writers on CSCW often stress the importance of seeing the nature and requirements of Cooperative work as conceptually prior to the designing of computer technologies to support such work (e.g. [28, 33]). This argument makes intuitive sense, but by focusing on organisational change I will attempt to highlight the assumptions about the nature, determinants and stability of Cooperative work requirements that underpin requirements analysis for CSCW.

How might organisational change affect the nature of Cooperative work? Conversely, how might organisational change might be effected by the computer technologies which constitute either the backdrop of Cooperative work or its mediation? There is a dialectical relationship between technological artefacts and the interactions which they support or mediate. So new technologies will have an impact on the social settings whose requirements they were designed to meet. The size of this impact may vary, so that in some cases it is easily manageable while in others it represents a significant problem. The impact is likely to be larger for CSCW cases than for single-user applications because the former are more sensitive to social context and to other subtle cues (e.g. see [17]). One tactic for reducing any problems caused by this impact is to reduce the cycle size and periodicity of delivering and enhancing new technologies, so that the feedback loop is smaller and quicker, and the organisational and technological factors can be better entrained (cf. [39]).

I am interested here in how CSCW design and implementation might accommodate, harness and drive organisational change. Following on from this, I am also interested in the division of labour in CSCW development itself, including the sort of organisational analysis and consultancy work needed to support development.

The paper begins with a consideration of different forms of organisational change and the challenges that such changes bring for CSCW. In the light of this, the third section reviews the case for trying to tie down CSCW requirements through analysis. The next section presents the threads of an alternative model of CSCW development, focused principally on organisational change rather than requirements, and the implications of this model for the design cycle. The paper then outlines the precepts of a process consultancy approach that is intended to support the alternative model, and the final section considers the practicality and desirability of implementing this approach.

The introduction of new IT systems always represents a change of some degree to the status quo of an organisation. Indeed, some consultants specialise in helping manage the change of IT introduction. Organisational change is ubiquitous and takes many dimensions at many different levels. Meanwhile, decisions about IT and technologies for CSCW are rarely the primary motors of change at any point in an organisation. There are usually other types of change running behind or alongside the technological change, and these may be loosely or tightly coupled to technological issues. This section aims to map out first some types of change that may be only indirectly linked to technological issues, and then some current trends in technology-related change.

(1) There are some changes which are extrinsic to the main function and constitution of an organisation, such as geographical relocation, and any staff turnover that might be associated with this. This sort of change can cause problems if it occurs concurrently with system development work, as its effects on organisational culture and patterns of communication may be variable and unpredictable.

(2) Many organisations undergo periodic reviews of their size and structure. Linked to this there must usually be a redistribution of decision making and a redrawing of organisational boundaries.

(3) An increasing number of organisations are literally reconstituting themselves. This can mean many things. Organisations are moving from the public to the private sector by a variety of means. Large monoliths are breaking up into loose federations of more or less independent local units. And on a more subtle, strategic level, many businesses are redefining the terms of the entire range of their operations on the basis of management initiatives like Total Quality Management and Business Process Re-engineering (BPR).

Clearly all these changes are likely to be interdependent. The major concern here, to which I shall return, is how each of these types of change might affect the design of work, the terms of Cupertino and the interactional practices in the organisations concerned.

CSCW is not the only discipline that is addressing the increasingly tight coupling of work design and technology throughout organisations. Much management and business school research is also recognising the ubiquity of IT in today's organisations and the potential strategic implications of this (e.g. [9, 16, 24, 35]). Some of the key messages arising from this work can be sketched as follows.

(4) IT is no longer a tool for automating localised and specialist functions, but is becoming an integral part of organisational infrastructure, in the same way that, say, the people in the organisation or the geographical distribution of the organisation's buildings are. (And in this way IT is intimately intertwined with these other infrastructural elements).

(5) IT infrastructure is a management resource which needs to be linked closely to the organisation's business strategy. There are at least three levels at which this can be done. Firstly the organisation's business processes can be redesigned in the light of business goals and organisational reconstitution (see 3 above), and the IT strategy designed to support this change. Secondly, the business process redesign may be informed by changes which new IT infrastructure makes possible. This reflects a key change in management thinking from seeing IT as a means of cost control/reduction to seeing it as an "enabler" of desirable strategic shifts. Finally, this last shift may be extrapolated to the point where IT specifically enables or encourages organisational reconstitution, for example by allowing the organisation to move into new markets. (See [35] for a fuller consideration of the different degrees of strategic change.)

(6) Both the above points encourage managers to delegate fewer IT strategy issues to technical professionals. They should ensure that they themselves have a grasp and a vision of the development of IT infrastructure and how it is linked to their other goals. The implication is that those organisations which are savvy to the strategic possibilities of technology will be better placed to control their own organisational development holistically. Thus Hales [13] suggests that, "The locus of design in the most fundamental sense is general management on the use side, rather than some specialist technical function... on the supply side." Technological development is a managerial issue "in the sense of determining and being embedded in an organisation's practice," and Hales refers to this managerial work operating at the level of "design of design."

This list of issues is intended to be suggestive, rather than comprehensive. Against this backdrop of organisational changes, we need to ask how the traditional sequential model of requirements analysis-design-build-implement-review will hold up when applied to Cooperative work.

Researchers have already given considerable attention to requirements analysis for CSCW. This attention is necessary because the social context of Cooperative tasks and interactions makes them more subtle and fragile than the procedural or productionline tasks that have traditionally been supported by information systems. In order to deal with the subtleties of social context, researchers have used different methods - drawn from sociological and anthropological traditions, particularly ethnography - to do their analysis for CSCW (e.g. [17, 20, 21]).

The attention given to analysis in CSCW has, however, raised further questions. What is the status of the outcome and findings of any analysis? What could or should they be used for? Who could or should do the analysis, and who should use its outcome? When should the analysis be done and when should it be used?

Social science researchers have urged caution about "applying" ethnographic analyses to systems design (e.g. [21]). And Bentley et al [4] suggest that, "the information provided by ethnography is essentially background information [which] did not result in specific, detailed systems requirements; rather it provided pointers to appropriate design solutions."

Systems design and software engineering are primarily disciplines of synthesis more than analysis. Therefore can we expect technical CSCW developers to take on the perspectives and modes of understanding of social scientists as a prerequisite for doing design? Alternatively, if social scientists or other third parties do the analysis, should they make recommendations about design (bearing in mind that design is at some level bound to bring about changes in the setting that has been analysed)? What role should users have in analysis and design? Finally, what analysis work needs to be done at the requirements stage, and what can be left to the evaluation or review stages?

All these questions point to the need for a review of the division of labour in CSCW development. It may not be enough simply to transplant the traditional implementations of the software design cycle to Cooperative settings, and then focus a bit more on doing sophisticated requirements analysis to tidy up the complexities and loose ends. To illustrate and elaborate this argument, I shall take the model of CSCW requirements analysis, as carried out by an ethnographer, as my point of departure.

The idea of requirements analysis for CSCW depends on the idea that Cooperative work has some structure to it which is invariant over certain conditions and that these conditions will not be affected by the introduction of new technology. In other words there is an assumption that, at some level, Cupertino itself is implementation-independent. The question then becomes one of defining what those "certain conditions" are under which Cupertino is invariant, and at precisely what "level" it is implementation-independent.

When is Email a suitable replacement for a telephone or face-to-face conversation? When is an online conference a suitable replacement for a meeting? Under what conditions can paper-based information be replaced by shared on-screen information? Many of the recent ethnographic studies of Cooperative work have answered these questions very successfully for the work contexts which they have studied (e.g. [17, 20, 26]). Inevitably some researchers are asking the further question of whether these answers show any generic pattern. If this were the case, the results could be generalised to other settings without the need for the same intensive research.

The findings of Conversation Analysis suggest that there is a fixed repertoire of moves for turn-taking in conversations. By analogy, we could speculate that there may be a repertoire of interactional practices which constitute the micro-level building blocks for Cupertino. However, given the multiple modalities which constitute interaction and the multiple media which support them, this seems unlikely. New technological environments are linked to changes in the social and psychological ecology of interaction that are likely to manifest themselves in even the most basic Cooperative practices. Even if basic building blocks of Cupertino could be identified at the micro-level in principle, this would take an enormous amount of research work in practice. And it would still leave more work to be done in applying the building block analysis in each new setting of Cooperative work. There remains a large gap between the in-depth analysis of specific interactions and the sort of large-scale changes to organisational boundaries which affect many "Cooperative" relationships - and CSCW must function at both levels.

Under these conditions, what prospect might there be for requirements analysis to guide CSCW design effectively, and are there any alternatives to this approach? I suggest that in a large proportion of cases, the option of carrying out full social scientific analysis and incorporating this in a lengthy up-front requirements stage will be ruled out, partly by its cost, but more importantly by the time it takes. Take, for example, the reported cases of the organisations who have implemented GroupWare systems more or less "on faith," without requirements analysis or even full business cases. They do this on the grounds that the impact and savings of Cooperative work are simply too intangible to specify precisely. Also, the organic and fluid nature of Cooperative work may mean that requirements change so fast that the analysis and subsequent design are constantly lagging behind the latest organisational developments.

The alternative model for CSCW development that I propose here retains all the basic elements of the traditional design cycle. However, it liberalises the relationships between the stages in the cycle. It also redistributes the division of labour between users, designers or engineers and third party researchers or consultants. The alternative model puts the transformation of Cooperative work and interactional practices at its centre.

The emphasis on transformation means that "capture" of requirements is an elusive goal and an unrewarding task. I suggest that we extend the idea of using IT as an "enabler" to the CSCW field. We should concentrate on new media and new environments that allow people to interact in ways which they have not previously considered, so that they potentially can reshape the domain and the purposes of what counts as Cooperative work (cf. Sproull and Kiesler [36] for an account of how Email use can develop in this way; also Hollan and Stornetta's [19] manifesto for Cooperative environments that provide possibilities "Beyond Being There").

The sort of shift of focus which I am envisaging would entail significant changes in the modus operandi of all the parties involved in CSCW. The growth of interest in CSCW is likely to hasten some significant changes in the process of development of IT systems for fluid and complex organisational environments, such as those in the service and administration sectors (note 1). These changes can already be discerned in various stages of maturity in some work on systems development methodologies and Human-Computer Interaction (HCI). The following five tendencies can be seen as different views of one overall shift.

CSCW will encourage the deconstruction of the boundaries between stages in the development process (requirements analysis-design-build-implement-review) so that it becomes much less differentiated. The different activities will still all take place, but they may proceed in parallel, interweaving much more closely together. It will be possible to start this design cycle with almost any one of the component activities, depending on the situation of the user organisation. The collapse of the discontinuity between designing systems and designing work (i.e. designing use of systems) is critical. It is often recognised that much system design work actually goes on after implementation, in the "maintenance" stage; so we could propose a new adage, "Plan to design in use - you will anyway". These changes are an extension of current developments in iterative prototyping, evolutionary development, simulation and usability evaluation.

The focus of many of the activities of the development process may be relocated so that users take charge of more of them. Consequently users become better able to link development activities to changes in requirements and to strategic shifts in their organisation of the kinds described above. Professionals and specialists from outside the user organisation may thus have a reduced rile in particular development activities and in project management. This does not imply a reduction in the amount of technical work to be done, but rather a change in the distribution of technical work and technical skills. Instead of working mainly for large system suppliers - relatively isolated from the people who use their products and services - more people with technical skills will work directly for user organisations. Staff within these organisations will have different mixes of technical and other business know-how, but relatively few will function solely as technicians. This distributed and gradational pattern of expertise already exists for some software (e.g. [27]). It is being further promoted by initiatives to train "hybrid" managers who combine IT knowledge with other managerial skills (for example, the British Computer Society has a Task Group to encourage hybrid training and development programmes).

There will be a shift in emphasis from thinking of IT as a tool to achieve certain pre-defined ends (i.e. satisfying the user requirements) to seeing it as an environment to be actively explored by users, initially to support and then to transform their existing interactional practices. Rather than asking, "Will this technology help us do what we do?", users will be encouraged to ask, "What sorts of things could we do with this technology, and how should we decide if we want to do them?" On the technical side, the priority of building infrastructure environments is already recognised. And one of the most successful GroupWare products so far, Lotus Notes', is marketed as an application development environment : it would be hard to see it as a tool in the singular, but users can make tools with it. On the user side, increasing exploration is a by-product of increased maturity and sophistication as group users of new technologies. There is a parallel here with the way individuals progress from being tentative, "naïve" users to being "expert" or "power" users who are much more likely to tailor and explore their technological environments.

After organisations have reached the level of maturity where their technological environment comprehensively supports most of their existing interactional practices, they could enter a phase where they cyclically and incrementally shift these practices, reconstitute themselves, and enhance or adapt their technological environment. Whether the increments were small and evolutionary or more radical, quantum jumps might be contingent on other factors (and their link to the technological environment). The term bootstrapping , used to denote this incremental to-and-fro-ing between organisation and technology, is borrowed from Engelbart. Critically, this term recognises that while organisational needs may sometimes lead technological development, so, conversely, technological enhancements can sometimes lead organisational changes. This is not to say that change will be driven by technology, but that technology could implicitly suggest options for change by opening up new design spaces (note 2). You can start with any activity in the design cycle: for example, by building or implementing a Notes application, evaluating its use and reflecting on future possibilities and requirements in the light of this. Of course, starting from any point in the design cycle is a luxury only afforded if you are confident that full cycles will indeed take place, but if you have this assurance (see below) you may as well take advantage of it.

Following from the above points, a by-product would be that organisations would see development less in terms of delivering technological products, and more as part of a wider process of organisational development. This sort of framework is already beginning to be developed within HCI (e.g. [3, 10, 13]). Hales [13] points out that when the design process is located within the user organisation, it is more likely to achieve full design cycles, in a way that usually does not happen with product-based, supplier-led approaches. The extent to which this process is contained within the organisation concerned would depend on its technological/strategic maturity: with increasing maturity comes self-sufficiency. However, it is unlikely that this maturity would develop spontaneously and quickly in many organisations. The parallel drawn above with naïve and power users suggests a potential set of barriers to overcome, in that many users stop progressing long before they reach the more advanced stages. This problem is, if anything, likely to be greater at the group level.

Thus, although I have suggested that the above changes in the modus operandi of development are beginning to appear as tendencies of their own accord, they may need some kick-starting. This will also be needed because the changes could represent a major break with the status quo of development practice - principally because they put much more responsibility for design and development work onto user organisations who have got used to depending on the "professionals" to manage this for them.

The attainment of organisational self-sufficiency is particularly important because, once an organisation has enclosed the process of design and development more fully within itself, a number of spin-off benefits may ensue. One benefit is the knowledge produced through the design process itself. This mainly comprises
a) a new perspective on - and self-awareness of - the organisation's functions, and
b) a more detailed understanding of how specific technologies can support and enable those functions.

The latter element usually gets carried off by outside specialists to enhance their learning and marketability. Moreover, the organisation's ability to make use of both types of knowledge together, and to synthesise them, may induce a particularly rich, secondary level of learning. This is a valuable resource to help the organisation bootstrap its way towards increasing technological/strategic maturity. Thus Hales [13] makes the link between this kind of approach and the concept of a "learning organisation", or the term he coins: a designing organisation.

As suggested above, all this depends on a slightly more free-form and experimental type of design than the traditional conception. (I find the idea of "design by experiment" an attractive oxymoron.) Experimentation fosters learning, and learning fosters self-sufficiency. As Pedler et al suggest in The Learning Company [29], the emphasis should be on "managerial action as experiment rather than the 'right answer'". I suggest that the best way to kick-start the move towards increased managerial and organisational self-sufficiency is through consulting with user organisations. In the next section I outline some of the methodological features of the consultancy process which I propose as an approach to promoting effective CSCW development.

There are many different types, models and practices of consultancy. As I have indicated, I am concerned with consultancy that promotes organisational development through the processes of CSCW development and use. Since it is organisational change that I am aiming to make the central factor of my approach, I concentrate in this section on the social and organisational aspects of consultancy support (though this is not intended to devalue the technical dimension of the work). What follows is thus closest to the "process consultancy" tradition (e.g. [31, 32]).

In a paper on sociology for system design, Hughes and King [21] provide nine precepts for carrying out social scientific analysis of work settings, based on an ethnomethodological version of ethnography. I adopt a similar approach here in proposing consultancy precepts. However, while I share with Hughes and King a focus on the social dimension, I am concerned primarily with engaging with this dimension rather than analysing it. This distinction is an important one, which I will show has considerable impact on how we might go about supporting CSCW development.

This precept is linked to the organisational learning idea. Learning often benefits from a catalyst or seed-crystal, and to this end, many consultants reframe their customers' problems in terms of a particular conceptual framework and reflect this reframing back to them. Straight away this appears to conflict with one of Hughes and King's precepts for ethnography, which stresses the "vital importance of resisting bringing in categories to describe activities and their social organisation from 'without' the setting" [21]. However, there is an important difference in that the consultant's framework should not be imported for any imposed, definitional purpose, but it should be a catalyst for the organisation's own self-analysis. Thus the framework should ultimately be digested and reworked "from within" the members' own understandings. This is admittedly different to the approach taken by some consultants - particularly technical ones - who often do impose their own "outside" definition. This latter approach may work when design principles and intuitions that are developed in one context can readily be generalised to another context. However, GroupWare design is less generalisable across contexts than single-user software, and Grudin [12] has pointed out that intuition is a poor basis for designing group applications. I am talking about a different form of consultancy, based on the process of getting organisations to articulate better their own understandings and design ideas in terms of how they could change their organisation.

Consultants often talk about means of "leveraging" change in organisations. The leveraging metaphor brings with it connotations of action-at-a-distance, which again seems inconsistent with the orientation of ethnography and analysis (cf. [25]). Indeed, many consultants appear to present and organise their work in terms of fairly straightforward causal models. These are far enough removed from the quiddity (to use the ethnomethodological term) of organisational life to give them the leverage they want. (I shall return to consider how accurate this appearance is below.) Research and analysis-based approaches often seem to back off from the idea of bringing about organisational change, but consultants have a different function. Two examples will illustrate critical differences between analysis and consultancy approaches. Firstly, Grudin [11, 12] may be right that the low cost of CSCW applications often blinds managers to potential organisational implications, so that they are not initially inclined to invest in exploring these implications. But consultants cannot just accept this observations and leave it there, for it is part of their rile to encourage organisations and their members to review their thinking and their actions. The same principle applies with Grudin's finding that individuals are not inclined to work with an application when someone else appears to gain most of the benefits. The point that applications should ideally be designed to avoid this is valid, but nevertheless, experience of Cooperative teamwork shows that people do undertake tasks for others' benefit - without needing management instruction - if and when a strong commitment to the team and to collective responsibility has been engendered. In such cases, it could be part of the consultant's job to facilitate organisational development towards this goal. The general point is that the consultant encourages exploration of new organisational and technological possibilities for Cooperative interaction.

Good consultants have been practising "user involvement" longer than system designers. Schein [31], for example, refers to the "perpetual renegotiation of the psychological contract". To be fair, this is easier for consultants as there are usually fewer elements to consulting which lend themselves to "black-boxing" (i.e. showing the customer only the inputs and outputs of the process, and none of the work between). However, I think it is helpful to consider how some features of consultancy have evolved to support the process of continuous negotiation while at the same time retaining the appearance of a formal, one-shot, contractual agreement. I suggest that this is done by consultants working at two or three of the following levels.

a) First is the more formal level at which the consultant presents his or her conceptual framework for reviewing the organisation's position. This could be seen as an instance of "configuring the user" [40], in that the imported framework may attempt to define and delimit the users' possible actions. But the negotiated nature of consultancy means that this is less of a one-way process than it might otherwise be. Indeed the value of a straightforward framework is that it aims to give customers some understanding of the consultancy work, some opportunity to question it, and also the basic ability to act on the basis of it. Argyris [1] suggests that,

One of the most powerful ways to make knowledge actionable is to make it user friendly. In order for knowledge to be user friendly it must use concepts of causality, concepts of implementation, and concepts of assessment that are... useable by practitioners in their contexts. When this requirement is not met, the gap between knowledge and action... is large.

b) This still allows for the possibility that there is a second level where the consultant works as an expert , using knowledge that is not so user friendly. This work is framed by the negotiation and monitoring of the overall framework, but may involve some more complex concepts and techniques which are not made fully transparent to the customers, and are thus not fully open to negotiation.

c) Finally there is a level which is rarely formally acknowledged, but which I suggest plays a key part in informing and keeping on track much organisational consulting. This could be called an informal "gossip" level, but it is often much more important than this term implies. It involves picking up on between-the-lines hints, sounding out half-formed ideas and speculations informally, and discussing issues with the grassroots operative-level staff as well as with the managers who would be involved in the negotiations at the more formal level. In most consultancy projects this level of informal negotiations is critical to the project's success.

Negotiation on these multiple levels is critical to engendering the organisational "ownership" that CSCW consultancy needs if it is to succeed. As Bannon and Bødker [3] point out, many researchers who in principle support this sort of process-orientated position still "maintain an ideal of being able to do design based principally on analysis rather than interaction with real people conducting work." In other words, they are still working within a one-way process from analysand to analyst, rather than a two-way negotiation between the two.

This precept is in a way the darker underside of the previous ones. The terminology of "facilitation", "catalysts" and "negotiation" reflects the language of open participatory democracy. It makes it seem that the consultant is simply oiling the wheels and uncovering latent solutions. But facilitation is hard work; and intensely political work. It is work that can only be accomplished by working through other actors, identifying their interests, and working these through to some kind of (provisional) resolution. It requires some of the same disciplines as are deployed by the theatre director or film-maker. The manufacturing of consensus/ consent is necessary to reach a place where the actors can say, "we can go forward from here."

This is part of the common thread which runs through the move away from lengthy requirements analysis, and towards the bootstrapping and learning organisation ideas. For example, Swieringa and Wierdsma [38] contrast the learning organisation to a prescriptive organisation. A prescriptive organisation first analyses and designs its organisational "blueprint" and then tries to implement this in behavioural changes, rather than taking these two steps in parallel. By comparison, "In a learning organisation changes come about according to the trekker model : even though we do not know precisely where we are heading and certainly not where we will finish up, we choose a direction and off we go" [38]. (Note the echoes here of Suchman's thesis in Plans and Situated Actions [37].) In emphasising process over product, the consultancy approach favours this trekker model. It should also promote experimentation in exploring the possibilities of the technological environment.

This precept again provides a counterpart to one of Hughes and King's, which instead of "...in enough detail...", specifies "...in all their detail" [21]. The advantage of the process-based approach is its rapid feedback cycles, which should enable it to avoid the requirements of infinite detail. In the language of ethnomethodology, consulting is itself a situated accomplishment. That is, the criteria for saying whether it has accomplished its goals adequately are specific and indexical to the setting - and linked to the achievement of social consensus mentioned in the previous paragraph.

At the same time, this precept does borrow from the approach of ethnography. It borrows a means of "making strange" the tacit underpinnings of people's interactional practices - the elements and behaviours which they themselves cannot introspect. If consultants reflect this contribution back to the members of the organisation, it can feed into evaluation and analysis activities, and also into clarifying the available design space (both for design of technological systems/environments and design of their use). This suggests that consultants adopt a sort of problem-oriented and bastardised version of the ethnographic approach, perhaps more akin to what is normally called "action research".

We have seen that consultancy must complement analysis and explanation with synthesis and recommendation. In addition to this, it may also draw to varying degrees on both the "engineering" and "gardening" metaphors for CSCW development [14], and it may mix evolutionary approaches to change with more discontinuous orientations. Consider, at one end of the spectrum, the example of Business Process Re-engineering where Hammer [15] presents a programmatic vision of what BPR consulting should aim to do, stressing that, "At the heart of reengineering is the notion of discontinuous thinking - of recognising and breaking away from outdated rules and fundamental assumptions that underlie operations." In practice, however, much BPR consulting takes an evolutionary approach to improving business processes, at least in part, and combines bottom-up and top-down elements. This is often necessary to ensure the success of a consultancy project and it requires that the consultant takes the members' perspective into account. In adopting this perspective, consultancy could be seen in one sense to incorporate the ethnomethodological approach, but it has to manage its own shifting between this and other (potentially inconsistent) perspectives.

Consultants often have to make judgements based on information that is "inadequate" to decide the matter at hand with the same degree of confidence as would be expected in the social sciences (cf. Bentley et al [4] who point out that the same is true of engineers). This involves more than just projecting from analytical data. It involves synthesising information from a number of sources and projecting from any notional findings to turn them into recommendations. In this process the consultant is in a very similar position to the software engineer, and consulting, like design, can be said to be a matter of satisficing for the purposes at hand. As such, it rests on a sort of confidence trick: consultants trade heavily on their previous experience, since implicit and "scientifically" unwarranted generalisations from previous experience are a key part of their work. While questions about the degree to which social analysis can really be applied to design, and about the epistemological rights and wrongs of trying to synthesise different techniques, may concern some social science writers (e.g. [6, 21]), these questions are academic from the consultant's point of view.

On the basis of the above precepts, I summarise in Table 1 some of the key dimensions on which we can map the relation between analysis (including requirements analysis) and consultancy orientations. These are shown as tendencies : I hope it is clear from what has been said above that these are not hard-and-fast distinctions.

Table 1 - Comparison of Orientations in Social Science Analysis and Consultancy

While the folklore of the trade has it that the spreadsheet was the breakthrough product which got the personal computing revolution under way, the CSCW community generally agrees that there will be no equivalent GroupWare product that launches group computing with such a big and sudden surge. This is largely because the applicability of any GroupWare product is so critically dependent on organisational context; and, even where the context is favourable, the collective learning curve is so much longer than the individual one. Thus for CSCW to be taken up more widely, we need a product which takes cognisance of existing technical platforms, and a range of organisational factors, and thirdly - and this is the critical part - of how the technological and organisational factors could be tailored and configured so that they are successfully bound together. It seems unlikely that this third dimension could ever be codified to the point where it could be embedded in software, on account of the large and unpredictable number of factors involved in each situation. Even if it could, the resulting product would not be guaranteed success. In order to carry the organisation through any change without disaffection but with organisational learning, the members of the organisation have to be involved in a process of negotiating the change . There is no easy short-cut for the process of co-operatively designing their Cooperative work. The rile of consultancy in CSCW is to foster, support and guide this process.

I have emphasised to the "bootstrapping" nature of the CSCW development process which recognises the two-way flow of inspiration between organisational and technological development. Specific requirements may sometimes drive the development of the technological environment, but "requirements" (i.e. opportunities) may also sometimes be inspired by the options which that environment enables. It is this second option which goes beyond the purely requirements-driven approach recommended by Norman [28], Schmidt and Bannon [33] and others. Schmidt and Bannon approve in principle of the approach of building experimental GroupWare and trying it out in Cooperative work settings, but they do not consider the possibilities of how this might enable new forms of interaction and Cupertino. Consequently this seems only a peripheral part of their recommended work programme for CSCW. I hope that my proposed process consultancy approach might foster more of an "anything goes" approach to development and innovation in CSCW.

An important facet of the approach that I am recommending for CSCW is that the development process is Cooperative in the same way as its output: the means and the ends are cut from the same cloth. This arises from the emphasis on an ongoing process where outputs become inputs for the next cycle. There is a good case for applying the same criteria to the process of CSCW development as we do to CSCW technologies. For example, let us apply Robinson's [30] four criteria for successful CSCW applications to the process consultancy I have outlined.

1 Double-level language

I suggested in my third precept for consultancy that there should be a formal level of communication - which comprises a relatively simple framework for leveraging the development process - and an informal or cultural level which enables continuous monitoring of and feedback to the process. This complementing of formal and informal processes is what Robinson means by double-level language.

2 Mutual influence

Mutual influence should also be implicit in the negotiation processes, both between consultant and customer, and between different parties within the customer organisation. The emphasis on process means that it should be possible to review development continuously and to adjust its course accordingly, as in the trekker model (see the fifth precept).

3 Equality

Arguably, equality in organisations is more a process than a state. My fourth precept alludes to the differences of interest which exist in every organisation. I suggested there that some form of resolution of competing interests is necessary to clear the way for moving beyond the status quo . But this equality is highly provisional, and needs to be reinvented and re-negotiated at every step of the process. This area needs to be explored more fully, particularly in terms of tradeoffs between involving all parties as much as possible in the process, and keeping each part to a manageable size so that it does not get bogged down.

4 New competence
The process consultancy approach encourages the user organisation to take a greater rile in the development process than might otherwise be the case. This is partly motivated by the need to bind technological and organisational factors together and to link them to business strategy. But it also encourages the organisation to think about its interactional practices, their requirements and possibilities, in ways that they might not previously have done. The maturity model implicit in my approach reflects organisations' growing competence in these areas.

It may be useful to anticipate some possible reservations and objections to the process consultancy approach I have outlined. One might be that it is not practical to implement the approach because it is predicated on a broad shift in the modus operandi of system development for organisations which has not yet taken place. Certainly it is clear that this shift will not happen quickly or all at once, and some sectors of the market will lag behind others. But this need not stop us from building on the shift before it is complete. There are already many examples where this is happening. One is the network of Lotus-accredited consultants who provide user organisations with a range of consultancy services to support implementation of Notes applications. Examples of a different kind are provided in the BPR literature (e.g. [15, 16]), and the Participatory Design literature (e.g. [34]) provides a further thread. Many of these seeds have been germinating for some time, and further work in CSCW could bring out more of their latent potential by cross-fertilising them.

A second reservation might be that my approach is similar in its technical implications to the evolutionary prototyping, which is much less popular in practice than "throwaway" prototyping. Clearly there are similarities, and for a defence of the evolutionary approach, including a rebuttal of many of the common arguments against it, I refer readers to Gilb [8]. Gilb highlights the importance of an open-ended architecture to support evolutionary developments, and again this is provided by technical environments with high-level application-building tools. I accept that, when adopting this approach, it may be necessary or useful occasionally to do some reverse engineering to improve the elegance or performance of application design.

Thirdly, there may be a question mark over how well my approach would scale up from relatively small, loose and manageable Cooperative work areas to larger and more tightly-coupled areas. This remains an open question. As I have suggested above, I believe that the parameters of interaction, Cupertino and interdependency in work may be in the midst of a long term sea-change. Thus while the consulting process clearly must remain manageable, the limits on what counts as manageable may be changing, and probably the only way to locate the boundaries of the approach is to test them.

Finally, there may be reservations about the increased reliance on user organisations to manage CSCW development themselves. It is often argued - usually by anecdote - that user-developed or user-tailored systems tend to be very poorly designed. Leaving aside the question of the criteria by which these judgements are made, I believe it is possible to admit this point and still recommend an increasing emphasis on encouraging users to develop and configure their own technology. That they may not have the competence to do this now, does not mean that they should not develop this competence in the long term. Perhaps, as Henderson [18] suggests, we need a proper framework to inform "folk development". This brings us back to the question of the division of labour in the CSCW enterprise. The approach outlined in this paper ultimately supports the maximising of a Cooperative self-sufficiency. It promotes the "de-professionalisation" of CSCW development in the sense intended by Illich [22], putting more power - along with more direct control of the work - in the hands of the user rather than the supplier (see [23] for more detail on these points).

Earlier versions of this paper were presented to seminars at the Universities of Surrey, Lancaster and Manchester during 1993. I would like to thank those attending for contributing insightful questions and points. I would also like to thank Duncan Sanderson, Mike Hales, Ross Anderson and Ian Franklin for their comments on earlier drafts.

NOTES

1 It is important to stress that my argument applies principally to instances which are both complex and fluid. The organisational environment of safety-critical systems, for example, may be complex, but is not as fluid as much organisational life - for the simple reason that it cannot afford to be.

2 The most suggestive example of this modus operandi that I can offer is Brian Eno's exploration of the affordances of technologies for audio and video recording. Bofop [5] writes that, "there has been an underlying consistency at the foundation of all Brian Eno's work. This consistency is the product of his curiosity about the nature of the medium in which he is working - a curiosity that has often succeeded in generating results just beyond current assumptions of what was possible. This experimental attitude asks several questions: what can be done now that could not be done before? What kinds of music does that suggest? And what kinds of listening behaviour? These questions, in turn, point up a central assumption of Eno's work: not only is music always evolving new forms of structures, it is also continually changing its social function, occupying new niches in the cultural landscape... Technological change is, of course, a major factor in this evolution... specific recording techniques have suggested entirely new ways of composing music." Closer to home, a similar approach to technologies for CSCW can be discerned in work at Xerox EuroPARC on media spaces [7]. However, my concern here is to extend this experimental attitude beyond research and development departments to everyday working life.

REFERENCES

1 Argyris C (1993) On the Nature of Actionable Knowledge. The Psychologist, Vol. 6 , No. 1. 29 - 32.

2 Bannon L J (1992) Perspectives on CSCW: From HCI and CMC to CSCW. Proceedings of the International Workshop on Human-Computer Interaction , St Petersburg, Russia, August.

3 Bannon L J and Bødker S (1991) Beyond the Interface: Encountering Artifacts in Use. In J M Carroll (ed.) Designing Interaction: Psychology at the Human-Computer Interface. Cambridge: Cambridge University Press. 227 - 253.

4 Bentley R, Hughes J A, Randall D, Rodden T, Sawyer P, Shapiro D and Sommerville I (1992) Ethnographically-informed Systems Design for Air Traffic Control. In CSCW '92: Sharing Perspectives: Proceedings of the Fourth International Conference on Computer Supported Cooperative Work, Toronto, 31 October - 4 November. New York: ACM Press.

5 Bofop C S J (1985) Untitled notes reprinted on insert of Thursday Afternoon CD by Brian Eno. Opal/Polydor.

6 Button G (1990) Going up a Blind Alley: Conflating Conversation Analysis and Computational Modelling. In P Luff, G N Gilbert and D Frohlich (eds.) Computers and Conversation. London: Academic Press.

7 Gaver W W (1992) The Affordances of Media Spaces for Collaboration. In CSCW '92: Sharing Perspectives: Proceedings of the Fourth International Conference on Computer Supported Cooperative Work, Toronto, 31 October - 4 November. New York: ACM Press.

8 Gilb T (1988) Principles of Software Engineering Management. Wokingham: Addison-Wesley.

9 Grindley K (1992) Managing IT at Board Level: The Hidden Agenda Exposed. London: Pitman.

10 Grønbæk K, Grudin J, Bødker S and Bannon L (1993) Achieving Cooperative System Design: Shifting from a Product to a Process Focus. In D Schuler and A Namioka (eds.) Participatory Design: Perspectives on Systems Design. Hillsdale, NJ: Lawrence Erlbaum.

11 Grudin J (1988) Why CSCW Applications Fail: Problems in the Design and Evaluation of Organizational Practices. In CSCW '88: Proceedings of the Second International Conference on Computer Supported Cooperative Work . New York: ACM Press. 85 - 93

12 Grudin J (1990) Groupware and Cooperative Work: Problems and Prospects. In B Laurel (ed.) The Art of Human-Computer Interface Design. Reading, Ma.: Addison-Wesley.

13 Hales M (1993) User Participation in Design: What it Can Deliver, What it Can't and What This Means for Management. In P Quintas (ed.) The Social Dimensions of Systems Engineering: People, Processes, Policies and Software Development. Chichester: Ellis Horwood. 215-235.

14 Hales M (1994, in press) Where are Designers? Styles of Design Practice, Objects of Design and Views of Users in Computer Supported Cooperative Work. In D Rosenberg and C Hutchison (eds.) Design Issues in CSCW. London: Springer-Verlag.

15 Hammer M (1990) Reengineering Work: Don't Automate, Obliterate. Harvard Business Review, July-August, 104-112.

16 Hammer M and Champy J (1993) Re-engineering the Corporation: A Manifesto for Business Revolution. London: Nicholas Brealey.

17 Heath C and Luff P (1992) Collaboration and Control: Crisis Management and Multimedia Technology in London Underground Line Control Rooms. Computer Supported Cooperative Work, Vol. 1 . 69-95.

18 Henderson A (1991) A Development Perspective on Interface, Design, and Theory. In J M Carroll (ed.) Designing Interaction: Psychology at the Human-Computer Interface. Cambridge: Cambridge University Press. 254 - 268.

19 Hollan J and Stornetta S (1992) Beyond Being There. In CHI '92: Striking a Balance: Proceedings of Conference on Human Factors in Computing Systems, Monterey, 3 - 7 May. New York: ACM Press.

20 Hughes J A, Randall D and Shapiro D (1992) Faltering from Ethnography to Design. In CSCW '92: Sharing Perspectives: Proceedings of the Fourth International Conference on Computer Supported Cooperative Work, Toronto, 31 October - 4 November. New York: ACM Press.

21 Hughes J A and King V (1992) Sociology for Large Scale System Design. Paper presented to CRICT conference on Software and Systems Practice: Social Science Perspectives, Ramada Hotel, Reading, 30 November - 1 December.

22 Illich I, Zola I K, McNight J, Caplan J and Shaiken H (1977) Disabling Professions. London: Marion Boyars.

23 Jennings D (1992) Interdisciplinary Integration at the Point of Contact with Users' Everyday Work. Paper presented to CSCW '92 workshop on Interdisciplinary Theory for CSCW Design, Toronto, 31 October.

24 Keen P (1991) Shaping the Future: Business Design through Information Technology. Boston: Harvard Business School Press.

25 Latour B (1988) The Politics of Explanation: an Alternative. In S Woolgar (ed.) Knowledge and Reflexivity: New Frontiers in the Sociology of Knowledge. London: Sage.

26 Luff P, Heath C and Greatbatch D (1992) Tasks-in-Interaction: Paper and Screen Based Documentation in Collaborative Activity. In CSCW '92: Sharing Perspectives: Proceedings of the Fourth International Conference on Computer Supported Cooperative Work, Toronto, 31 October - 4 November. New York: ACM Press.

27 Nardi B A and Miller J R (1991) Twinkling Lights and Nested Loops: Distributed Problem Solving and Spreadsheet Development. International Journal of Man-Machine Studies, Vol 34. 161-184.

28 Norman D A (1991) Collaborative Computing: Collaboration First, Computing Second. Communications of the ACM, Vol. 34 . 88 - 90.

29 Pedler M, Burgoyne J and Boydell T (1991) The Learning Company: A Strategy for Sustainable Development. Maidenhead: McGraw-Hill.

30 Robinson M (1991) Double-Level Languages and Cooperative Working. AI and Society, Vol. 5. 34 -60.

31 Schein E H (1988) Process Consultation, Volume 1: Its Role in Organization Development. Second Edition. Reading, MA: Addison-Wesley.

32 Schein E H (1987) Process Consultation, Volume 2: Lessons for Managers and Consultants. Reading, MA: Addison-Wesley.

33 Schmidt K and Bannon L (1992) Taking CSCW Seriously: Supporting Articulation Work. Computer Supported Cooperative Work, Vol. 1. 7 - 40.

34 Schuler D and Namioka A (eds.) (1993) Participatory Design: Perspectives on Systems Design. Hillsdale, NJ: Lawrence Erlbaum.

35 Scott Morton M S (editor) (1991) The Corporation of the 1990s: Information Technology and Organizational Transformation. Oxford: Oxford University Press.

36 Sproull L and Kiesler S (1991) Two-Level perspective on Electronic Mail in Organizations. Journal of Organizational Computing, Vol. 2. 125 - 134.

37 Suchman L A (1987) Plans and Situated Actions: The Problem of Human-Machine Communication. Cambridge: Cambridge University Press.

38 Swieringa J and Wierdsma A (1992) Becoming a Learning Organisation: Beyond the Learning Curve. Wokingham: Addison-Wesley.

39 Winograd T and Flores F (1986) Understanding Computers and Cognition: A New Foundation for Design. Norwood, NJ.: Ablex.4

40 Woolgar S (1991) Configuring the User: The Case of Usability Trials. In J Law (ed.) A Sociology of Monsters: Essays on Power, Technology and Domination . London: Routledge.

Copyright © David Jennings