From Workplace to Classroom - Document Workflow and Engineering Communication Pedagogy

Engineering educators recognize the importance of communication in the development of their students. And yet, given the constraints of offering professional and technical communication courses in the college and university setting, engineering students are often not taught communication in the context of actual engineering workplace practices. To remedy this gap, we have chosen to focus the forthcoming IEEE Guide to Writing in the Engineering and Technical Professions (IEEE Wiley 2016) on communication as it is practiced in engineering workplaces. Using interviews with working engineers, we introduce the concept of document workflow. Workflow provides students with a more realistic view of the kinds of documents and types of communication they will confront when they enter the engineering workplace. Index Terms Document workflow, engineering communication, professional communication. Introduction Engineering educators recognize the importance of communication in the development of their students. Not only is the ability to communicate effectively a named outcome in the ABET student learning outcomes, it is often cited as one of the key professional skills—like teamwork—that employers look for in prospective employees. And yet, given the constraints of offering professional and technical communication courses in the college and university setting, engineering students are often not taught communication in the context of actual engineering workplace practices. These constraints include the fact that the individuals hired to teach writing courses are themselves experts in communication pedagogy and not familiar with engineering workplaces. The IEEE Guide to Writing in the Engineering and Technical Professions (forthcoming in 2016 from IEEE Wiley Press) provides an alternative view of engineering communication that can be used by engineering communication teachers because it presents project documents within their workflow.1 Central to the document workflow approach is bringing the authors of the documents into the discussion of how engineering communication is constructed. The IEEE Guide is supplemented with online resources that will be available at the IEEE Professional Communication Society webpage (pcs.ieee.org). These resources include a suite of document workflows that cover engineering and technology projects that are annotated and narrated by the professional engineers who produced them. These individuals can speak to the process by which the documents are initiated, written, and revised while they highlight the specific workplace constraints that determine the document’s content, format, and style. The website also includes open access teaching materials to allow both communication instructors and engineering instructors to adapt the materials to their own classrooms. The purpose of our ASEE presentation is to introduce the document workflow concept and to show its application through the documents and commentary of the professional engineers who are providing narration as part of our project. Background The notion of using real world engineering documents to teach communication is not new. In fact, technical communication researchers have conducted field studies of engineering workplaces in an effort to understand the nature of engineering communication and to allow working engineers to comment on their own communication work. Dorothy Winsor, for example, took an anthropological approach when she conducted observations and interviews for her influential book Writing Like An Engineer: A Rhetorical Education.2 Using the engineering workplace as the site for her study, she interviewed engineers regarding their communication work in order to understand the rhetorical particularities of the engineering context. While her research subjects did not utilize the terminology that we associate with rhetoric, such as the rhetorical appeals, she found that these writers did indeed understand the contextual requirements of their communication. Understanding the rhetorical demands of engineering writing has also been explored by Rachel Spilka and Clay Spinuzzi, both with the eye toward understanding how engineers adapt to multiple audiences and use genres in their communication in the workplace.3,4 These three example highlight the situated nature of engineering communication; they also suggest that part of an engineer’s development on the job is identifying and adapting to the forms of workplace communication that are appropriate. While the work of communication researchers has helped us understand the situated nature of engineers’ communication, there have been inherent difficulties with bringing the actual documents from the workplace into the communication classroom. First, much engineering communication is proprietary, meaning that example documents may not be used in the classroom without breaking intellectual property agreements. Second, experts in rhetoric and communication generally teach communication courses for engineering students, but these instructors may not have worked in engineering workplaces; this may limit their understanding of the nature of engineering communication as it is practiced by professionals in the field. Third, even if documents could be lifted from an engineering workplace and displayed to students, many of these documents in and of themselves do not reveal the rich context in which they are produced. The documents themselves lack meaning without the contextual knowledge possessed by the engineer who wrote them. We have decided to address these three difficulties through the use of recorded interviews with the document authors. By recording the engineer discussing the documents, we provide a means to capturing the rich context of each document. We are also addressing the issue of intellectual property by selecting workplace documents that avoid compromising confidentiality. Finally, as teachers of communication, but not working engineers, we are providing the necessary bridge between engineering professional practice and the needs of technical communication instructors. We do this by interviewing the engineers and placing their workplace-specific communication practices into the larger context of rhetoric and communication theory. In this way, we are building a bridge between the academic and industrial settings with a view to improving engineering students’ understanding of the importance of communication work. Software Engineering Project Example Understanding engineering document workflow begins with the insights of the practitioner who can provide their industry-based perspective on the role of communication in their technical work. Dr. Sriram Mohan, associate professor of computer science and software engineering, spent his sabbatical year working for a software consulting company. As a contributor to the IEEE Guide, he provides his insights on a particular project he worked on for his company. In order to capture his descriptions, he was recorded in interviews as he verbally annotated the series of written documents that were produced as part the project from start to finish. One of the inherent difficulties of the use of workplace documents is clearly illustrated in Figures 1 and 2. It would be possible to bring these documents to an engineering communication class, or a software engineering class, but without Dr. Mohan’s verbal narration, it is possible that neither instructor nor students would have an idea of the important context that surrounds the documents. For instance, Figure 1 shows the original email that initiated the software project. The purpose of the document is explicit in the first sentence: “to outline a small data acquisition project for Amadeus.” In his narration, however, Dr. Mohan reflects on the long-standing and positive relationship between his consulting company and the client company. He also states that the written document is part of an ongoing series of phone calls and emails about the project. Thus the written document that initiates the project is not the only contact between company and client. What we find interesting about the example document is the use of specific terminology, such as “hadoop cluster,” that Dr. Mohan explains in order to make the document itself understandable to students and instructors who are not experts. Figure 1: Software engineering project document 1 (excerpt) From this initial email, Dr. Mohan walks his audience through the multiple documents that comprise the workflow for this particular project. All along the way, he brings his listeners into the software engineering workplace context, identifying the client company as only one “audience” for the multiple documents that are produced. In this way, he employs the language of rhetoric that many communication instructors are familiar with, but he shows the use of the term in a real world context. When Dr. Mohan arrives at the final documentation of the work product—in this case, a diagram of the workflow produced by this piece of software and accompanying explanation from the final project report—his listeners have a clear understanding of the interrelations between technical work and the communication he has produced as a part of it. Figure 2: Software engineering project document 2 (excerpt) Other Project Examples We believe that the IEEE Guide can be of greatest benefit to engineering students and their instructors (both those who teach communication and those who teach engineering) if we include a variety of workflow documents from multiple engineering disciplines. Our plan, therefore, is to add workflows with accompanying narration to the website regularly. We have additional example workflows currently in development. For instance, an engineer working for a major insurance company reflects on a series of documents that allow multiple groups—insurance agents, software developers, insurance company executives—to provide input on new tools that can serve the need