Balancing Ethics and Expediency

Within Oranges Corp., there is a project called APPLES, a complex software product designed to teach military personnel about damage control on transportation systems, showed equal complexity in the inter-department communications. The company motto is, paraphrased, “Within budget, within time, and with top excellence.” Oranges shipped out the product over-budget, past-deadline, and full of bugs. Now that Oranges has acquired (somewhat miraculously) and begun a sister project, GRAPES, management is trying to develop a plan to avoid a replay of the calamities in the APPLES project.

Development of a good action plan for GRAPES necessitates a study of the problems experienced in APPLES. APPLES was a practice in poor planning and, therefore, poor communication—the technical writer was left out of the initial analyses stages. The project manager did all the planning, in isolation, for courseware development. Big mistake. While project managers are supposed to act as the central hub in any given project, their goal, or telos, is to make sure that the project meets requirements set by the client. Their job is to be efficient above all else, to bring in the biggest profit margin. Yet, as Cezar Ornatowski, notes, “organizational efficiency is always involved with politics” (180), and this phenomenon interferes with the objectivity required in the project, objectivity that a technical writer is better equipped to have since he interacts with all members of the team to write documents. Unfortunately, the project manager accessed the technical writer’s objectivity too late in the process. The writer found errors in the lessons which needed more time to resolve, but at this point in the project, time was an unaffordable luxury. In analyzing and writing the damage control lessons, the technical writer kept bumping against what Ornatowski enunciated as the inherent contradictions in the goals of technical writing: “to serve the interests that employ his effectively and efficiently while being objective, plain, factual, and so on” (175). Obviously, the technical editor wanted to appease his manager and get the job done quickly, but he also needed to be objective.

Why would objectivity be necessary for such a project? APPLES itself is a range of documented steps that military personnel follow to control or prevent emergencies that happen on a transportation vessel. The technical writer’s “internetworked” position, as James Porter puts it (211), allowed him to speak to subject matter experts and engineers who knew how these transit vessels really worked, and so he came to understand the content matter of these documents better than the project manager. The technical writer saw that the APPLES documents, written by various government contractors, had numerous typos, bad grammar that occluded meaning at times, and bad logistics—the damage control steps were in the wrong order. The technical writer was also able to see the consequences of using faulty data: the military personnel would follow the steps exactly as they appeared in our courseware, in the wrong order, and . . . hopefully, there would be no exploding ships in the sea that day.

Everyone below the project manager was tasked to follow the APPLES documents to the letter, and sure enough, ethical questions arose. Was the project manager aware of such complications? No, but the technical editor was, when he finally started working on the project, and by then it was too late to reorganize the courseware development plan. The scenario was similar to when the Thiokol vice president was asked to “take off his engineering hat and put on his manager hat” during the Challenger analysis meetings (Driskill 118): the project manager demanded that no more changes were to be made to the project, “just get this thing out of the door before we run out of time and money.” Numerous changes were made to the product already since the software engineers, on their own, found errors in the courseware (“how can the officer give the order if the watchman hasn’t told him about the fire yet?”). As Porter would predict, “there . . . [were] competing policies and guidelines to be negotiated and reconciled” and the technical writer was left “to reconcile . . . competing sites of ethical authority” (212).

The manager wasn’t an evil person, no; he was simply following his own set of what Steven Katz called corporate, capitalistic ethics: “Expediency often takes precedence over human convenience, [sic] and sometimes even human life” (198). So the technical editor found a way to balance his own sense of ethics with the ethic of his manager. While the steps on the courseware screens had to stay in the same order prescribed by the government documents, the technical editor ensured that recommended instructions were written into the screens detailing each individual step; for example, “It is recommended that you do this step before doing [x, y, z] to the machine.” This tactic, or rhetorical social action, worked with the given constraints since the recommendations did not overshadow the government documentation and would not disturb the logistics architectures built by the software engineers. Might there be a better solution? Perhaps.

For GRAPES, suggestions have already been made to build in more time for document analyses by the instructional designers and technical writers. The technical writer is actually involved in development planning from the very beginning. In practice, this method had been working well, and the technical writer has been able to summarize information from the different development departments and relay advised action plans to the manager. The manager is now making much more informed decisions when planning courseware development, and the staff is less disgruntled for it. Such an organizational plan also stresses more accountability. Though the technical writer is burdened with extra responsibility, that responsibility is an ethical one, and it should have been his to bear in the first place.

Works Cited