clock works and gearsLast 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.