Last week, I mentioned the important communications processes that help keep tech writing projects running smoothly. This week, I want to reiterate their importance by rationalizing their use.
For most project participants (and general readers, too), communications processes are basic logistics management: They're in the background, they're boring, and they feel inconsequential.
However, if you’ve worked on a tech writing team (or any writing team), you know that projects often fall (gently or painfully) apart. Project managers forget to reply-all; SMEs miss their interviews; writers edit old versions; proofreaders fail to update and send out style guides.
Most of the time, the problems can be traced back to ineffective communications processes.
A successfully completed multimember team project (where “success” equals an excellent product and the mutual respect and good will of team members), requires a project lead, weekly team meetings, uniform file-naming system, and general team investment in the efficacy of the communications processes.
An identifiable and self-identified project lead updates everyone and holds everyone accountable. Without a recognizable lead, it's hard to identify a "team," and a project may not even get off the ground.
Weekly team meetings that are written into the project calendar make the project an obvious priority. Ad hoc meetings theoretically work, but the work calendar self-populates at a rigorous rate, and it’s almost always impossible—especially with far-flung team members—to schedule a meeting tomorrow that everyone can attend.
The utility of a rigorously used file-naming system is obvious. But it requires use and enforcement. If a project lead doesn’t establish and apply it, a file’s dead versions are resurrected and important updates get lost.
Boring? Maybe. But most definitely consequential. If you work on writing projects (or aspire to), do yourself a favor by establishing the communications processes that will make your project a success.
Partly because they’re team-based, partly because they’re produced over an extended period of time, and partly because production is iterative, tech writing projects require rock-solid communications processes to ensure completion.
Communications processes refer to the ways that team members provide reviews, comments, revisions, approvals, and updates. Sounds (somewhat) simple, but a typical white paper often includes a client, a project lead, one or two writers, two or three subject-matter experts, and an SME liaison (sometimes affectionately called the “wrangler”). This 7- or 8-person team may start their project on the same page, but when a file is misnamed or misplaced, or an SME interview is missed or mis-scheduled, the project can easily run off track.
Wayward writing projects stretch scope, but they also stretch the patience of participants, which can be even more frustrating.
To help mitigate mishaps associated with files or individual schedules (because they can never be completely avoided), establish a sound communications process while setting the project scope. This means:
Next-level communications processes include ensuring team members cc the communication lead on all emails, putting Zoom or other conferencing info numbers and links in all project-specific emails, and sending out a weekly project calendar with relevant updates.
Implementing and practicing effective communications processes can be arduous, but by helping to navigate the pitfalls that throw projects off track, rock-solid communications ease the load and lead to quicker completion.
If you’ve ever looked to produce a yearly report, a white paper, a series of tech sheets, or any other project that falls under the broad and rather complicated category of “tech writing,” you’ve probably felt overwhelmed and unsure about where to start. This post can help.
Approaching and efficiently delivering any tech writing project is a big job. However, it’s a job worth learning more about because it can encompass many different projects, can be enormously beneficial across a range of business, and can resonate with a variety of audiences.
In this post, I’ll discuss some of the best approaches to effective and efficient tech writing. In posts to follow, I’ll identify useful tools to aid execution and completion.
Starting and finishing tech writing projects depends on setting scope, communicating progress, soliciting feedback, and submitting or publishing the final work.
Setting a rigorous scope constitutes the first step, and it is key. When you set a scope for a tech writing project, you determine:
Although tech writing projects are built to suit, with a prefigured topic and audience, it's still important to explicitly identify every project's topic and readership.
The identification is necessary because most tech writing projects are produced by a team, often with an outside writer. Ensuring that every team member knows what they're writing about (and for whom) ensures consistency. It also helps project leads get as specific as possible about their marketing objectives: After all, a tech-based Q&A offered as a download on a business’s website reaches a different audience than the same content published through a trade organization.
Setting scope also requires identifying subject matter experts (SMEs) who can contribute objective and evidence-based material. Designating SMEs before a project begins—and often bringing them into the process of setting scope—can gain their timely and invested participation.
Finally, setting scope requires a calendar and schedule. There’s really no way around the fact that tech writing is an iterative process, and each iteration requires review. Identifying the team and gaining their early buy-in can help manage touchpoint fatigue (aka, “You need me to look at this again?”). Creating a granular schedule can ensure maximum efficiency. When SMEs and others can anticipate the commitment required from the jump, they can better rise to their role.
Setting scope is the most important step in completing tech writing projects. Sharing the scope ensures that objectives are met, that SMEs understand and anticipate their commitment, and that the project moves along as efficiently as possible.
English PhD, former arts administrator, obsessive cook, native East Coaster, mom to two rabblerousers.
English PhD, former high school teacher, obsessive organizer, native Midwesterner, mom to three troublemakers.