In 2004 Fujitsu asked PARC to carry out an ethnographic investigation of their software business, focusing on their development processes, and while doing so to build an ethnographic capability in their own organization. One of our biggest challenges was to convince Fujitsu’s system engineers – and the development organization more generally – of the value of ethnography for their business. They are used to translating what they hear from customers about the workflow into a standard framework of system requirements and specifications; it was difficult for them to see the relevance of putting any significant focus on understanding what is going on in the workplace at the level of everyday work practices. Moreover, in their work with customers, system engineers commonly proceed in a carefully planned and highly structured manner, where every activity is expected to yield predictable outcomes. For them, the open-ended nature of ethnographic fieldwork seemed dangerously chaotic and unpredictable. The lessons learned from our experience with both our initial teaching of the engineers and the organizational fieldwork we later did together helped us design a new ethnography-training course that incorporates the task of conveying the full value of organizational and business ethnography.
INTRODUCTION
Only recently has corporate or business ethnography — the labor-intensive method for investigating organizational life — gained in popularity; the establishment of EPIC has certainly contributed to recognition of our field by the business world. A number of organizations have added professional ethnographers to their research staff and many more hire ethnographers as consultants for internal projects or market research. But even with these achievements, the recent commitment by the management of Fujitsu’s software and services organization to ethnography stands as remarkable. Fujitsu contracted with PARC to engage six researchers from our Computing Science Laboratory’s ‘Workscapes and Organizations’ area in developing a significant ethnographic capability inside its software business. Initially, the target audience for the ethnography training was the twenty Fujitsu members of the project working with us directly. Two thirds of them were system engineers (hereafter SEs) and the rest were researchers from Fujitsu Laboratories. Later, when the value of ethnographic research for and with Fujitsu customers became clear, we were asked to start training more SEs in the business units so that Fujitsu could make ethnography part of a new way of working with its customers. Training such a large group of young professionals in ethnography was not without its challenges, of course. In this paper we will describe our experiences, the results and the lessons learned. The outline of the paper is as follows. We begin with an overview of the project to set the context. Then we describe the initial training we gave and the challenges we came across. We used this experience when we later had to design the course aimed at educating a much larger group of SEs, and so we describe these courses in some detail. Finally, we describe how the organization has adapted fieldwork to fit in its own culture and ways of working with customers.
INITIAL TRAINING
Our project began in 2004 with two related goals: PARC was asked to use its ethnographic expertise to investigate Fujitsu’s organization and we were to do so in close cooperation with a Fujitsu team (the Fujitsu members had been pre-selected before we started the project) (see Churchill and Whalen 2005). We were to also teach this team how to do such investigations on their own. This paper will focus on the latter of these.
The first challenge for us was how to train the Fujitsu members in ethnographic fieldwork methods. Reflecting on our own experience of learning how to do ethnography we realized that we had acquired our skill in (diverse) academic institutions through a mostly unstructured and, to be honest, self-directed process. We had taken a few courses in which ethnography was explained as method, read a variety of writings on the topic (mostly actual ethnographies), had the disconcerting experience of being sent out to a field site on our own, and had written field notes that, if we were lucky, an instructor might later comment on. We learned mostly through informal discussions with fellow graduate students and advisors. We tried to mimic at least some of these experiences in a week-long training for the Fujitsu members that consisted of a set of lectures and exercises and also provided the students with relevant papers on and by ethnographers they could read.
Although these lectures were received politely, we learned over the course of those first months that many of the members of the organization were only marginally convinced of ethnography’s value as a method for their business. As it turned out, the problems that team members had with ethnography were actually quite profound; our method and way of conducting our research stood in marked contrast to what they considered sound working practices.
To understand the members’ problems it is important to consider their different backgrounds. As we explained above, the project team was comprised of two groups, members of the solutions and services organization (i.e., SEs) and members of Fujitsu Laboratories (i.e., researchers). These SEs had diverse academic training; some had a background in the physical sciences, some had been trained in engineering, computer science, and still others had non-technical background: linguistics, communication studies, sociology, and the like (Japanese software companies often hire young people for their overall intellectual skills not necessarily putting the highest priority on their educational background). Some of the SEs in our project team used to be in charge of managing projects, including such things as budgeting, scheduling, coordinating with subsidiaries and subcontractors, and managing the customer relationship. Others had led project teams. Software projects have clear development targets and phases, with their schedule ‘planned backwards’ from delivery (or cut-over) date using standard software engineering methods.
We explained to these SEs that one of the important principles of ethnographic research is that it is open-ended and that one cannot determine beforehand what the outcome of the research is going to be, and that therefore, there was little point in trying to create a terribly detailed project plan with a predictable trajectory. However, to SEs who had a highly structured approach to managing projects and developing software, this way of working – without well-defined and largely pre-determined deliverables at set time intervals – was not just unusual; it was a sign of poor project management. The reasons we gave for this approach were taken to be excuses or at least evidence of our unwillingness to embrace proper accountability standards (indeed, some thought our approach was irresponsible).
Many of the laboratory members felt similarly, but there was an additional aspect to their skepticism about ethnography. In their research, which had been overwhelmingly technical in nature, they always started out with a well-defined hypothesis and took a positivistic approach. Moreover, quantification was always preferred over qualitative description; without quantification there could never be any real ‘proof’. We repeatedly and carefully explained how this way of working, however valuable for other kinds of research, was at the end of the day incompatible with doing good ethnography. Although our arguments in this regard ultimately held sway and the project proceeded more or less in line with our strategy, it nevertheless became obvious that a number of members remained unconvinced. For instance, when we were preparing for field interviews they would persistently ask: “What exactly do we want to find out in this interview?” While this question in and of itself was not a problem for us, they expected the answer to it to then drive the interview process by creating a set of structured, quite specific questions. They had great difficulty with the way we wanted to carry out these interviews – relying on a set of open-ended queries with the goal being to let interviewees express themselves, to listen more than interrogate, and to normally raise specific questions only in response to what we heard (to clarify, for example) or when certain information was missing.
Another challenge for us was to convince the project team members of the need to go into the field as much as possible and to look at people’s work holistically, considering everything they see in its local context and without judgment. SEs commonly think in terms of the functionality of a system. They are used to working within a well-established paradigm in which they basically translate what they hear from meetings with the customer into their ‘system framework’. So SEs typically would seek just enough information to define the functionality of the system. The relevance of taking a first-hand look at an actual workplace, the physical environment, the way work is conducted and oriented to by people in the field, was not always apparent to them, let alone looking at other dimensions of the job or features of the site that were related to the work in question. Sometimes we were able to convince them of the relevance of looking more holistically at work, but even if they could see the value of this they wondered about the efficiency of such an approach especially since we would insist that just what one would discover in this regard could not be specified in advance.
Another challenge was the way the team members made their observations. Whereas seeing and listening closely were skills with which they came equipped, the steps of becoming aware of what they are seeing even when those things are very ordinary and then to be able to articulate the observations does not come naturally to all. When the SEs would go to field the observations they would come back with would often contain judgments about the efficiency or efficacy of what they had observed. So when looking at a workplace they routinely assess which part of the work they observe is not efficiently done. Whereas passing such judgment is not problematic per se, we found that all too often project team members’ judgment would prevent them from uncovering a deeper understanding of the workplace. 1 This situation was only exacerbated when the SEs went out to observe other SEs, i.e., when they saw people do ‘their’ work they were even less able to look for the underlying logic of their work practices but were always judging whether the SEs were doing their work well. In our analysis sessions with project team members we repeatedly told them that they should suspend their judgment while doing observation, and instead probe deeper into the actual work practices but, ultimately, we found that it was difficult to overcome.
Finally, one of the challenges we faced was the project team members’ motivation. Whereas some were very motivated to learn and saw it as a new career opportunity, others were concerned about their career as SEs not knowing exactly what they could do with the fieldwork skills.
Lessons learned from the initial training
In part, the trouble we faced during the initial training had to do with the fact that we had to convince people of the value of ethnography for the organization. We had assumed that as the organization had hired us for our skills in ethnography the value of our approach and way of working would not be questioned (Jordan and Dalal 2006). However, we found that the members of our project team–who had been selected by the organization without regard for their interest in fieldwork (and without regard for their English skill) had to be convinced individually of fieldwork’s value. Moreover, we had not yet been able to show them the effectiveness of ethnography within their own organization; we had only given them examples of our previous work in other organizations and not everyone found these examples compelling (the fact that they all came from our work with American organizations which many Japanese consider – rightly – to be a completely different culture certainly added to their skepticism). The main thing this taught us was that it was always necessary to convince Fujitsu members of the value of ethnography, and that the ways in which we had successfully convinced many of our American clients and partners of the value of fieldwork did not necessarily transfer to the members of the this organization.
Ultimately, the thing that convinced most of our project members of ethnography’s value was when they actually started doing fieldwork themselves. Experiencing first-hand being in the field, making observations, developing a relationship with people in the field, and especially thinking about how they could make a difference in these working people’s lives was what turned out to be truly convincing. And over the course of the project, we were able to convince more and more members of the organization and the results of our internal investigations were met with some enthusiasm. Consequently, they asked us to train other SE students in doing fieldwork. So, how did Fujitsu then make use of (and culturally and organizationally adapt) ethnographic fieldwork in their business, and how did our training enable their efforts in this regard? The remainder of this paper addresses these questions in some detail.
NEW TRAINING COURSE
Increasingly, customers would come to Fujitsu with requests to solve business problems rather than just make a request for a specific kind of computer system. In these cases, the customer had learned that their internal IT department’s knowledge of the possibilities for using new technologies to help solve such problems – formerly quite strong – was no longer sufficient, and so they turned to Fujitsu for help and guidance. This created a problem for Fujitsu as its SEs were trained to think primarily about technology and not about solutions to customers’ business problems. As a result, Fujitsu decided it needed to develop new skills in a group of its most promising young SEs. These SEs would engage with customers as consultants before any system development project was started. In line with their waterfall software engineering methodology this phase of work was called ‘super upstream’. The work in this phase is primarily concerned with understanding and perhaps re-designing the customer’s work processes or business activities rather than just developing an information system.
We had just three days to teach this course, including the presentation of students’ fieldwork results. Of course we knew that in such a short span of time we could not make professional fieldworkers out of them, but at least we could introduce them to the method. Most of all, though, we could try to convince them of its power, which was considered to be sufficient for they were not expected to immediately conduct fieldwork on their own. Our approach had four parts. First, as we had learned that the most convincing aspect of doing fieldwork was to have them experience fieldwork itself we designed the course around an exercise, and incorporated the presentation of fieldwork results to the manager from each site so that the students can experience what kind of effect fieldwork can bring. Second, as we had by then done some fieldwork in customer organizations, we invited a system engineer to give a guest lecture and talk about his experience of doing fieldwork. Over time, SEs from our own project led this lecture, as they gained more and more experience doing fieldwork in customer sites. Third, we then allocated some time to have an informal discussion with the students on how they could incorporate fieldwork into their work. Fourth, we developed our lectures (in response to student feedback) to include more and more concrete examples on how to make observations.
LECTURES
As we had only the three days (including a half day presentation) and had to teach between eight to fifteen people at a time, we had to rely on classroom-based training for a large part of the course. We developed a series of lectures between 30 and 120 minutes long that we gave before and after the fieldwork exercise (the exact schedule of which is always fluid as it depends on the constraints and location of the organization that is willing to host the fieldwork). Below we provide a brief summary of the different lectures.
Fieldwork introduction
In this lecture we highlight the difference between fieldwork as a method for studying human behavior and other ways of conducting research –interviews, telephone surveys, and controlled experiments. We stress that fieldwork includes the doing of in-situ observation. We also give a short history of how the method was developed in early anthropology to study of foreign cultures, but then adopted by sociologists of the Chicago school to study local culture (city life in neighborhoods) and finally how some corporate research centers have started to use fieldwork to study people at work and PARC’s leading role in establishing the use of fieldwork to evaluate and inform technology design, highlighting the work of Lucy Suchman (1987) among others. Fieldwork has been used to study cultures and to study the details of people’s work practices. We also compare the advantages–it is the most ‘real’ access you can get to really understanding people’s work–and disadvantages of fieldwork–it is very labor intensive and not necessarily best-suited when you are pursuing a more narrowly defined hypothesis. Finally we stress how fieldwork can be particularly important for SEs because designing a new system involves redesigning work, and so going into a system engineering project with an understanding of the current work practices heightens the chance that the system will be successful and accepted by the user community.
The fieldwork way
In this lecture we explain that the aim of doing fieldwork is to understand people’s work from their perspective and give an example of the difference between describing things from an outsider’s and insider’s perspective. The example we use was inspired by a paper on fieldwork written by other PARC researchers (e.g. Jeanette Blomberg et al. 1993). Then we give a number of practical tips.
- Stay close to the work. Being in the location where work takes place and directly observing people doing that work is what fieldworkers should strive for.
- Do not dismiss anything as trivial or non-important. It is important to open one’s mind and see, hear, sense and smell as much as possible and to record your impressions faithfully.
- Be an observer and stay out of the way. Know when to ask questions and when to shut your mouth.
- Be an apprentice and take a learning stance. See the natives as teachers. It is helpful to consider what one would have to learn and what one would have to be able to do if one were to this job oneself.
- There is always something going. Pay attention to whatever is going on even if it is not work.
- Reflect on what you have collected. Resist the urge to just collect more data; instead take time to reflect; a little fieldwork goes a long way.
Fieldwork hints
This is a lecture with many practical suggestions for what a fieldworker could look at when studying people’s work practices; the hints are both observational and analytic in nature. Perhaps the most common challenge for new fieldworkers is to determine what of the many things one ‘sees’ ought to be ‘noticed’. Fieldwork does not appear to be much of a method when you don’t know what you should be looking at especially since ‘unmotivated observation’ is what seems to be at the heart of the method. To help the trainees in making observations we developed a set of ‘fieldwork hints’ that contains a lot of examples of different aspects/themes of work and workplaces that a fieldworker can examine. The current list of topics includes the following:
- The organizational context. One perspective to take on organizations is that they are social structures that pursue goals. To an extent, at least, organizations are designed rationally, and therefore one approach you can take when observing a particular person do a particular job is to consider what the function or role this piece of work has within the overall organization. Naturally, it is important to understand members’ perspective in this regard: what they think their role function is, and where the section they belong to is located within the organization, e.g. a section which earns most, or a section which does not directly make business, etc.
- The division of labor. Similarly to the organizational context just how the work is divided into different jobs was at some point a rational decision. The division of labor is the very thing that gives rise to ‘an organization’. So one should always consider how this has been done, what the organizational structure is, and what a group’s responsibility is. Then, one can consider whether this division and the rational for it still makes sense when one considers the way people actually collaborate.
- Working relationships. Usually there are organization charts which represent different relationships among different groups and people in each section and in other sections. Yet, observation of how members relate to each other in the workplace can yield a more complex picture of the organization and how it actually works. How do colleagues relate to each other, how do they relate to their boss? Are there informal groups? Especially, how do people talk about themselves and others in the organization?
- Official vs. real work. It behooves fieldworkers to pay special attention when workers have found ways around official procedures to get their work done and the rationale for not following the official procedures (if there are, and we encourage people to collect as much as they can official documents that describe procedures).
- Organization of work. When observing someone at work, a fieldworker should always consider: How do people decide what to do next? Often there is a certain rhythm to people’s work. In some cases, members’ work is reactive to the environment, i.e., in a restaurant waiters’ and chefs’ work is driven by the customers that walk into the door. In other work, the work can be self-organized and people are free to organize their own day to get their work done.
- Space. How have people organized their workplace, arranged their tools into physical space, for doing their work. Oftentimes, the organization of their workspace is quite deliberate. We give an example of a worker in a call center, who has pasted a number of documents next to his computer within easy reach, has learned to use the mouse with his left hand in order to keep his right hand free to jot down notes while on the phone with the customer. We also give an example of how the design of a workplace can either impede or enable collaboration between workers and give an example from the research of Heath and Luff (2000) as well as our own work.
- Technology. What technologies and tools are taken up in the course of work? Fieldworkers should consider how those tools support (or hinder) the subjects’ work. Such consideration can lead to suggestions about how tools could be modified in order to better fit with the actual work practices. Documents are, in this sense, a special and ubiquitous technology in most workplaces but should also be considered technologies. We give some examples, including the affordances of paper (Sellen and Harper 2002).
- Troubles. Troubles are especially helpful for fieldworkers because they often reveal the hidden, normal organization of work. Therefore fieldworkers should pay special attention when troubles occur (although when they do it is also especially important not to interfere with the subjects’ work).
- Local language. One aspect of the language in a workplace is the jargon, specialist words with particular technical meaning. However, the local language is more than jargon; quite ordinary words may be used in a different way in a worksite as well. Understanding the local language is so important because it teaches a fieldworker how members organize their experience.
- Local knowledge. Consider what the members need to have learned in order to do their work. Often, even simple jobs require an enormous amount of local knowledge, knowledge about people, their relationships, about the members’ work and its relative importance, about the organization’s history, etc.
- Organizational culture; values and norms. An organization can promote certain values and norms and these are reflected in the actual actions of the organization’s members.
We end the lecture with some general guidelines for doing fieldwork, which is to use one’s own experience as a backdrop for understanding the particularities of an organization. And to try to understand the local nature of human actions by subjecting them to the ethnomethodological question of “why that now”.
Data session
This is an exercise in which we use a short piece of video and guide the students in making observations. We have used video data we recorded in a call center some years ago. Using multiple video cameras we recorded the phone-call between the telerep and the customer as well as the ambient sound in the call center, the interaction with the computer system, and a wide-angled shot which captures the telerep in his cubicle environment. We provide the students with a transcript and play the video several times. We prompt them to make observations, giving hints if they have difficulty. The video has several key points. For instance, the telerep reads a wrong line, which a casual observation cannot reveal. We guide the students to notice the mistake by reviewing the video carefully and then let them state analytically the practical reasons – pushing them to think further than to attribute the mistake to the rep’s lack of capability—such as pressure not to keep the customer waiting, the design of the system and various documents, which the rep had to use quickly and sequentially.
Ethnographic interviewing
This is a lecture on how to conduct ethnographic interviews (as opposed to the more formal, highly structured – and thus more serially interrogative – kind). SEs may be familiar with doing interviews, but if so those interviews are conducted to specify what kind of functionality the customer requires, rather than focusing on the work per se. We stress that the goal of the ethnographic interview is to get the interviewee to talk – an ethnographic interview is about the interviewee not about the interviewer. Although you must prepare an interview guide with topics and perhaps even specific questions, interviewers should be flexible and it is a good practice to base next questions on what they just heard from the interviewee rather than doggedly following the prepared list of topics. In ethnographic interviews it is better to ask broad, descriptive questions, which will naturally lead to the interviewee giving longer answers that the interviewee him/herself can design. Using a transcript of an interview that one of us conducted we illustrate how to conduct interviews to get rich information by being ‘persistent but polite,’ asking for more detailed descriptions from the interviewee. Finally, we talk about some practical matters such as how to set up interviews, how to do a proper interview introduction, to bring recording devices and how to ask for permission to record, and to write field notes as soon after the interview as possible because many details will fade from memory quickly.
Fieldwork planning
This is a lecture containing some practical tips for planning a fieldwork engagement. First, we remind the trainees of the advantage of fieldwork over other methods and techniques which may be used to persuade members of an organization that fieldwork is a good idea. Since organizations are hierarchical, it is usually a good idea to start by doing interviews with higher level manager and work your way down until you come to the level of the people that are the target of observations. In getting an introduction to the organization it is very helpful to get a manager to give you a ‘Grand tour’ in which they walk you through the organization and introduce yourselves to various members. When creating a fieldwork schedule you should consider how much time you have, how many people you can ‘sit’ with, and who those people should be. It is important to allow for enough time to write field notes and do analysis and not just fill one’s time with making observations. Finally, we talk about how to report back to the organization and how it is important to protect individuals by not revealing their identities even if it means not telling your strongest stories. We remind them that fieldworkers are not there to debunk the organization they investigate, but to be neutral and take an ethnomethodologically indifferent attitude.
Co-design
This is a lecture on the approach to organizational interventions. Since our audience was SEs who develop new systems we also developed a lecture on co-design: the process of working closely with users to design new technology. In the lecture we talk about the rationale for co-design as well as its principles. We argue that a system designed by the users may well be better suited to their work than a system the designers come up with and more readily accepted and adopted. We elucidated some of the principles for co-design inspired by literature in participatory design such as the work by Schuler and Namioka (1993). As we do not normally have sufficient time to illustrate the many techniques of participatory design, we use Muller, Wildman, & White’s taxonomy (1993) to refer the students to literature where they can learn about different techniques.
Writing field notes
In this short lecture we make a distinction between writing while doing fieldwork and writing field notes afterwards. The prime purpose of writing in the field is to jot things down so that they can be remembered later; there is no need for elaborately written down observations. We urge the trainees to make detailed notes about the environment and to record conversations as literally as possible. Also, we talk about when it might be wiser to refrain from making notes (when your subject is telling you something potentially embarrassing, for instance). When returning from the field the first stage of writing field notes is to get as much down as possible and not to worry about the readability of your notes for other people, these are notes that capture your own observations, so it does not matter that not everything coheres. For more ‘finished field notes’ different styles can be used (van Maanen, 1988).
Fieldwork exercise
In order to let the students experience the value of fieldwork we designed the exercise to mimic the situation they would face if they conducted fieldwork in a customer site. We sought cooperation from different organizations within Fujitsu, focusing on organizations whose work was quite different from the work of SEs. We did fieldwork in the mailing room, the security offices, with secretaries, and the kitchen staff in the cafeteria. The students were divided into small groups of 4-5 students who had to work together during the analysis and presentation parts of the exercise. The level of access the students had to the subjects varied greatly as some organizations did not want the students to interact with the subjects at all, a situation we have tried to address with only limited success. We accompanied the students to the field and answered any questions they might have and sometimes even did some fieldwork themselves.
After the fieldwork, which lasted for about two to four hours, the students would write up their field notes individually, and then do analysis in small groups. We would sit in on these groups and work with the students and help them develop their analysis. On the third day of the course, the students would develop presentations of their observations and present them to managers of the organizations whose members they had observed. The requirement that they present to a manager created considerable pressure for the students and they invariably took the fieldwork exercise quite seriously. Invariably, these managers would be impressed with the detail of the things the students had observed and this reaction helped us considerably in convincing the students of the power of ethnography.
RECENT DEVELOPMENTS
The cadre of SEs we initially trained in our project is to carry out fieldwork at customer sites and then present to the customer how work is actually done at these workplaces, as well as what kind of problems the customers’ organization needs to solve in order to improve their current performance. While they expect their findings will eventually lead to customer orders for information systems they try not to narrow their observations to members’ use of technology.
As they accumulate their experiences, they started customizing fieldwork into a more systematic method in order to cope with constraints they have on the overall schedule. To help them we participated in these customer engagements at first, but as they gained more experience we started to review only the results of their work. The challenge was for them to go beyond merely recording their observations to deeper analysis, a skill that only comes with practice (and talent, certainly). Nevertheless, they have developed a quite effective way of doing team ethnography. Further, they have also now taken over teaching our course on ethnography to other members in the organization. As they accumulated experience and cases, and the fieldwork service continued to take shape, it became obvious that students should learn what they will be expected by customers to do, based on Fujitsu’s most recent experience.
CONCLUSION
Naturally it is expected that the professionals in one area would react to a new method, especially if the particular method comes from a different discipline. There are genuine differences in the approach to work between ethnographers and system engineers. These differences do not just have to do with introducing a novel method to their work, but have to do with what is considered competent work in the different communities; they are deeply moral issues that cannot be glossed over lightly. In our experience, the most successful way to overcome these differences is to have the system engineers experience first hand the value ethnographic observations can yield for their own work. Ultimately, the experience of teaching ethnography helped us understand system engineers work better and helped shape our message when we reported our ethnographic results; it helped us to be heard by the organization.
Inspection of projects at the maintenance and operation phase was another area where Fujitsu applied fieldwork methods (Obata et al 2007). This made it possible to look at projects operating in this phase more closely and understand why certain troublesome issues persist that may escape the standard checklist based inspection method. Thus fieldworkers were able to make managers reconsider the existent policies when they were presented with some compelling fieldwork findings. In both cases, it was SEs and Fujitsu Laboratories members who customized the fieldwork method in order to meet their own needs. It was a very positive development. After all, they know far more than we about SEs’ work and are therefore in the best position to decide how to implement fieldwork methods within their own work environment and practices. For this reason, fieldworkers in Fujitsu should be in a very good position to overcome some of the issues frequently raised in the CSCW community about making an effective bridge between design and workplace studies (Plowman et al 1995; Dourish 2006). As far as we know Fujitsu is the only software development business to train and operate a fieldwork team inside the business itself, staffed and managed by SEs (versus by researchers in a laboratory organization that must then find some way to cooperate with and effectively support the business side). We believe this is a huge step forward for ethnographic praxis in industry.
NOTES
1 For instance, when they found their fieldwork subject needing to search for a certain document in a stack of files they might write down that these documents could more easily be searched if they had been on-line, and did not pay much attention to how the searching was done, why the document needed to be found, what the significance of the document was, etc.
REFERENCES
Blomberg, J., Giacomi, J., Mosher, A., and Swenton-Wall, P
1993 Ethnographic Field Methods and Their Relation to Design. In D. Schuler & A. Namioka (Eds.), Participatory Design: Principles and Practices. Hillsdale, New Jersey: Lawrence Erlbaum Associates.
Churchill, E. F., and J. Whalen,
2005 Ethnography and process change in organizations: methodological challenges in a cross-cultural, bilingual, geographically distributed corporate project. In Proceedings of EPIC, 2005, Seattle, WA. November.
Heath, Chr. and Luff, P.
2000 Technology in Action. Cambridge, Cambridge University Press.
Jordan, Brigitte and Dalal, Brinda
2006 Persuasive encounters: ethnography in the corporation. Field Methods, 18(4).
Muller, M. J., Wildman, D. M. and White, E. A.
1993 Taxonomy of PD practices: A brief practitioner’s guide. Communications of the ACM, 36(4):26–28.
Obata, A., Yamada, S., Harada, h., Ito, S., and Hirata, S.
2007 Ethnographic inspection: identifying project risks. EPIC 2007.
Plowman, L., Rogers Y., and Ramage, M.
1995 What are workplace studies for?,’ in H. Marmolin, Y. Sundblad, and K. Schmidt (eds.), ECSCW ’95. Proceedings of the Fourth European Conference on Computer-Supported Cooperative Work, 10-14 September 1995, Stockholm, Sweden, H. Marmolin, Y. Sundblad, and K. Schmidt (eds.), Kluwer Academic Publishers, Dordrecht, 1995, pp. 309-324.
Sellen, A.J. and Harper, R.
2002 Myth of Paperless Office. Cambridge, Mass. MIT Press
Suchman, L.A.
1987 Plans and Situated Actions: The Problem of Human-Computer Communication. New York: Cambridge University Press.
van Mannen, J.
1988 Tales of the Field; On Writing Ethnography. Chicago: University of Chicago Press.