Stan Dicks
Introduction
It is a pleasure to comment on the articles that Benjamin Lauren and Joanna Schreiber have assembled for this special issue of Technical Communication. The articles show the breadth and diversity of enterprises and industries in which technical communicators work and must manage their information development projects. I will bring to this task my 40 years of experience managing technical communication projects and/or teaching and researching how we can best manage the difficult business of developing information products.
The Prescriptive/Descriptive Dichotomy in Project Management Research
One convenient way of discussing project management literature is to look at where it stands on the description/prescription continuum. Some refer to description/prescription as a dichotomy, but I prefer to see them as on a continuum. Rarely is there a purely prescriptive statement about project management, because it is necessary to describe the methodology in question first in order to prescribe it. And rarely is there a purely descriptive treatment of project management methodologies without at least some implied judgment about it and hence a degree of prescription. If we look at articles in the Society for Technical Communication’s conference proceedings and in other literature, we see both types. A common article describes a method that a group has tried and found successful and advocates for other groups to try it also; hence, it contains both description and prescription.
By far, the most prescriptive of the articles in this issue are those of Hackos and Fisher, who report on standards for information development issued by the International Organization for Standards (ISO) and, more specifically, on ISO/IEC/IEEE 26511: Systems and software engineering—requirements for managers of information for users of systems, software, and services. The ISO standards are largely prescriptive; they assert what practitioners must do in order to conform to the standards and to have their projects ISO certified. They require that organizations develop systematic, repeatable methodologies for product development and that they follow those methodologies on every project they undertake, documenting that they have done so in order to allow ISO auditors to verify that they are continuing to adhere to the standards.
For a further point of discussion related to project management literature, it is informative to compare each article to the highly prescriptive requirements of ISO standards and to examine whether the industry under examination concerns itself with such standards, or to question whether it even should. So, in this commentary, I will examine each of the articles with a consideration as to where its methodologies stand on the prescription/description continuum and where it stands related to ISO standards.
The Articles in the Special Issue on the Prescriptive/Descriptive Continuum
In “Information-Development Project Management as an International Standard,” Hackos explains the history of the development of the ISO standards and makes the case for their more widespread adoption by developers and for their use in technical communication training and education. Hackos’s two books, Managing Your Documentation Projects (1994) and Information Development: Managing Your Projects, Portfolio, and People (2007), describe the philosophy and methodologies behind the ISO standards and explain how to implement and use the necessary methodologies. I have used both of her books, along with my own, Management Principles and Practices for Technical Communicators (2004), in our graduate course in project management for technical communicators. I believe in the philosophies proffered by Hackos and in the basic ideas of the ISO standards. I am willing to concede that in smaller companies and in some industries, strict adherence to the standards might not be necessary, but I would still contend that following the basic concepts outlined in Hackos’s texts, and, for example, in my chapter in Solving Problems in Technical Communication (2013), is necessary to produce consistently high-quality information products.
Lori Fisher elaborates on the reasons for ISO standard 26511 and on the methodologies it requires, “the revised ISO standard continues to require a base set of metrics to be used across an organization for all projects, and a documentation plan that includes the metrics to be used and the data to be collected, at the outset of any given project.” This standard defines the key roles that project managers must play, “related to quality:
- Identify the set of metrics to be used to assess quality across projects, including defects and customer satisfaction.
- Ensure a process is in place as necessary to collect the specific measurements for each project.
- Use the measurements to correct defects and, through root-cause analysis, improve the document process.
- Where possible, use customer feedback to validate the measurements of quality and customer satisfaction.
- Strive to develop predictive metrics that can be measured in-process (during development) to take preventive action before content is delivered.”
As Fisher points out, these steps should be followed regardless of the project methodology being used, even on agile and other newer approaches.
Again, while the highly prescriptive requirements of the ISO standards might not apply in all cases, it is difficult to prepare consistently high-quality documents without using a consistent methodology and measuring the results of the information products that it develops.
In “Project Management, Contradictions, and Textualized Activity: Supporting Reflection in Project Based Organizations,” Doug Divine and Mark Zachry propose that technical communicators have an excellent opportunity to improve project communications by identifying contradictions and providing reflective feedback loops for project team members. They propose doing so by studying project emails and attachment documents. The authors use the Project Management Book of Knowledge (PMBOK) to analyze project email exchanges, following the PMBOK’s five types of artifacts: initiating, planning, executing, monitoring, and closing. Using emails from Enron, one of the few corporations for which we have an entire email corpus, they analyze a specific project and, on that project, a specific employee. They study the interactions of that individual, via email, with other members of the community and the complex variations in those interactions in terms of power, subordination, equality, and liaisons with non-employee sub-contractors. They suggest that technical communicators could perform similar analyses to help show fellow project workers what kinds of messages and attachments are most effective during the various phases of a project, thus improving those workers’ communication and, hence, the overall project. They point out that actually using this capability might be problematic due to privacy considerations, but, assuming that the technical communicators are trusted by their fellow employees, it would still be possible.
The authors use an ingenious combination of activity theory and the PMBOK to show how workplace email might be analyzed and categorized, and how it might be used to improve project communications. They describe the methodology they used and prescribe its use for other practitioners. Because it relates to internal communications and not to information development per se, their proposed practice does not fall under ISO considerations.
In “‘Filling to Capacity’: An Exploratory Study of Project Management Language in Agile Scrum Teams,” Erin Friess uses discourse analysis to study transcripts of scrum team meetings over a period of time on a single project that is using agile scrum methodology. Her analysis shows that much of the language used in such meetings follows somewhat predictable patterns, depending on the type of meeting; however, one interesting exception seems to be an inordinate amount of “team maintenance” discussion occurring in almost all of the meetings. It is not surprising that extra team maintenance discussion would occur when a relatively new project management method such as scrum is being employed. It would be interesting to see if the amount of such discussion diminishes over time or if it is somehow inherent in and a necessary part of the scrum methodology. And indeed, Friess states that her study should be considered preliminary and suggests other areas of research where the methodology she followed could be used to further investigate how scrum teams function. Her article is more descriptive of what is occurring in the field than prescriptive, although additional research following her methods may lead to some prescriptive guidelines for how scrum teams can operate more effectively. Also needing further study is the lack of planning language she noted, even in the planning and kickoff meetings, where one would expect a high concentration of such language. If we grant the assumption that ISO standards for planning should still be followed when teams are using alternative project managements methods, then the lack of such language could be problematic.
In “Flexible Project Management Processes: A Case Study of a Distributed Trade Organization,” Katherine A. Robisch conducts field studies of a trade organization and argues that this may be a case where less formal project management methodologies work better than more strictly codified systems such as those espoused by ISO standards. She shows how the extensive technical communicator interaction with audience members leads to new and unexpected rhetorical situations, and how flexibility is needed to respond to the unusual partnering/authoring opportunities that arise. As she puts it, “This rhetorical situation also means a top-down, prescriptive approach to project management could constrict writers or limit their agency to develop expertise. With multiple points of interacting with the audience, writers have to develop and refine flexible processes for managing projects.” Even with that philosophy, the organization she studied eventually saw the need to document some of its processes, which “helped to stabilize work into repeat processes.”
Robisch makes the case for organizations doing distributed work, such as most trade organizations, that overly prescribing project work flows would impede the “unofficial feedback loops and multiple methods of communication.” The nature and goals of a trade organization may be so different from those of a large software firm or manufacturer that nimbler, less codified systems will in fact work better.
In “Novice Engineers and Project Management Communications in the Workplace,” Elaine C. Wisniewski reports on a mixed-methods case study she performed of novice engineers in the workplace. She analyzed the project management activities of a group of novice engineers and also studied their managers and researchers to triangulate data collection from various points of view. She discovered that novice engineers begin project management activities immediately, and that they often have responsibilities that they may not have needed or encountered while in their academic studies. She found four main themes that novice engineers need to work on, and that, by implication, might be introduced into engineering curricula:
- knowing how to provide context, the “big picture,” before discussing technical details with an audience, particularly if it contains non-engineering personnel
- providing clear and appropriate written and visual communication
- providing confident and timely content to the audience
- increasing interactions with downstream audiences, such as technicians and operators
So, she is prescribing that engineering pedagogy should cover these areas, although she acknowledges that in some cases that is difficult to impossible to do. Because her study primarily concerns engineering communication, it does not interact with the ISO standards.
Finally, in “Toward an Encounter Team Model of Clinical Project Management: A Needs Analysis of a Family Health Center,” Dawn S. Opel, Cathy Abbott, and William Hart Davidson conduct a needs analysis of a medical clinic with an eye toward improving communication and, hence, workflow before, during, and after patient encounters. As they put it, “technical communicators’ expertise is needed to ensure the quality of the writing processes and communication culture of an organization.” However, as they experience themselves, cultural and professional role habits can undermine making the changes necessary for improving communication processes.
It is interesting that among their findings are that daily team meetings, similar to those employed in scrum, greatly benefit the communication flow of a clinic, but because staggered work schedules make such meetings difficult for large parts of the clinic, the practice does not take hold. They also find that more planning is needed, along with more of the sort of structure called for in the ISO standards, but that, as they put it, “cultural changes are difficult in professional settings.” The paper describes methodology for studying communication and workflow in a clinic, and prescribes more technical communicator involvement for improving that communication and work flow.
Embracing A Prescriptive/Descriptive Continuum
It is interesting that this set of articles contains some articles that are almost entirely prescriptive and some that are almost entirely descriptive. However, as I maintained earlier, even the prescriptive articles contain plenty of description and the descriptive ones either imply or state explicitly that they are prescribing that practitioners and/or researchers should follow the methodologies they are describing. It is not surprising that this prescriptive/descriptive continuum should appear prominently in the area of project management, which is a part of practice that nearly all technical and professional communicators must perform, whether reluctantly or not.
The tension we see related to project management literature is actually a part of the larger tension we see in the entire field of technical and professional communication between practice and research, between doing and observing, between the “real world” and academia. It is good for us to visit this tension occasionally to remind ourselves that our discipline, as any other, has its own body of literature but, at the same time, is based on the work that practitioners do every day.
Mirel and Spilka’s collection, Reshaping Technical Communication (2002), explores this tension and has chapters suggesting ways the two worlds can interact so that academics are more aware of practice and practitioners are more aware of academic thinking and insights. See, for example, Bernhardt’s “Active-Practice: Creating Productive Tension Between Academia and Industry.” The authors suggest many other ways that practitioners and academics can interact, such as internships, field trips and studies, guest lectures, usability testing, joint meetings with STC members and student chapters, and collaborative research and design projects.
Conclusion
Taken as a whole, it is very interesting to read through this collection of papers and to see which of them take primarily descriptive approaches, which take primarily prescriptive approaches, and which contain both. Further, it is interesting to note how strongly the authors advocate for highly prescriptive approaches, such as those outlined in the ISO standards, and which of the authors proffer approaches that vary considerably from those standards. Aside from those two considerations, they also show the current state of practice and of research in technical communication project management.
I am happy to see a collection of articles such as these that show that tension and that concern themselves both with the practice and the discipline of technical and professional communication. I would encourage everyone involved to keep doing what they are doing. We need practitioners like Hackos, Fisher, and Dicks prescribing, based on our own work experiences and our observations of many best practices in the workplace—practices and methodologies that will help practitioners. And we need researchers observing, analyzing, synthesizing, and reporting on the practices they witness. If both groups continue to contribute in those ways, the profession will grow richer and fuller both in its day-to-day practice and in its academic study of that practice.
References
Bernhardt, S. A. (2002). Active-practice: creating productive tension between academia and industry. In, Mirel, B. & Spilka, R. (Eds.), Reshaping technical communication (pp. 81–90). Mahwah, NJ: Lawrence Erlbaum Associates.
Dicks, R. S. (2004). Management principles and practices for technical communicators. New York, NY: Longman.
Dicks, R. S. (2013). How can technical communicators manage project? In Johnson-Eilola, J., Selber, S. A. (Eds.), Solving problems in technical communication (pp. 310–322). Chicago, IL: University of Chicago Press.
Hackos, J. T. (1996). Managing your documentation projects. New York, NY: John Wiley & Sons.
Hackos, J.T. (2006) Information development: Managing your documentation projects, portfolio, and people. Indianapolis, IN: John Wiley.
Mirel, B., & Spilka, R. (2002). Reshaping technical communication. Mahwah, NJ: Lawrence Erlbaum Associates.
About the Author
Stan Dicks began his career in academia at Wheeling Jesuit University and then left for industry, where he worked at United Technologies, Bell Labs, and Bell Communication Research managing technical communication groups as well as other functions. He returned to academia when he moved to NC State 20 years ago. At NC State, he directed the MS in Technical Communication for some 15 years. His book, Management Principles and Practices for Technical Communicators, was published in 2004. He is available at sdicks@ncsu.edu.
Manuscript received 5 March 2018; revised 9 March 2018; accepted 10 March 2018.