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.
For organizations or departments that don't have a dedicated project manager, it's no small thing to get big comms projects out the door. In our last post, we talked about how not to let the actual writing process gum up the works—namely, by allowing adequate time for writing and editing, and by uncoupling the writing process from the design process.
While that advice may be easy to heed in theory, it can be tricky in practice: Creating large documents involves tracking a lot of moving parts, including points of collaboration and project dependencies that can be challenging to accurately time. That's why creating a detailed, realistic project timeline at the outset of any big writing project is key.
Luckily, there are a lot of tools that can help—many of them free. If you're new to creating project timelines, you can start simple: Microsoft offers a free template for Excel that's incredibly easy to use (if devoid of bells and whistles).
The template allows you to enter dates, tasks or milestones, and people, and to manipulate the visual representation to optimize its readability.
Depending on the project or document management system used by your organization, you may already have tools you can configure to create project timelines. Sharepoint, for instance, offers a customizable project task list; and online tools such as Trello offer options for making more complex Gantt-style project roadmaps.
Whatever route you take, developing a project timeline for big writing projects will make your life easier, and your final product better.
Let's take a quick mental tally: In the past month, have you received a tone-deaf email from a colleague and were left to ponder what he actually meant? A memo so full of jargon that it required two or three reads to decipher? A set of instructions poorly written enough to require its own manual? A rally-the-team note from a manager or the c-suite that fell completely flat because of insipid or vague writing?
If you answered yes to any (or maybe all) of those questions, you're not alone.
It's not breaking news that Americans spend a lot of time communicating at work. But unfortunately, a lot of that time is wasted.
To be more precise, as Josh Bernoff reported in the Harvard Business Review, 81% of businesspeople say that poor writing wastes a lot of their time. All those vague emails, poorly organized presentations, and jargon-laden reports add up—and take a major blow to an organization's productivity.
Of course, it's not just the internal workings of an organization that suffer under a culture of bad writing. Bad writing filters out to customers, clients, partners, and stakeholders, too. It signals a lack of professionalism, lack of organizational self-awareness and integrity, and lack of respect for your audience. We can probably all agree that those are un-good signals to send.
So what's an organization to do?
Small steps can make a difference, if you're willing to commit time (and possibly money) to improving your organization's writing.
1. Make sure you've got polished templates and models for anything your employees routinely produce, such as project reports, slide decks, or blog posts. Templates not only save time, but they ensure that materials are consistent—and consistently well written.
2. Model good writing from the top. Management sets the tone and the standard for team members to rise (or fall) to. Even casual emails from a team lead or a department head (not to mention the ED or CEO) should be thoughtfully and properly crafted.
3. Design your organization's workflow with the writing process in mind. Make sure that all public-facing communications are adequately reviewed and vetted—for example, by building in a beta release for larger projects. And if your staffing allows it, consider providing dedicated in-house writing support for those who routinely create communications.
4. Provide training for employees, whether new hires or veterans. Everyone brings different levels of comfort and experience to writing, so it's crucial to periodically create the opportunity to ensure that everyone is aware of organizational standards and able to use best practices.
5. Bring in external support when needed. Sometimes an outside perspective helps, both to identify problems, and to conduct the necessary training to get staff up to speed. Experienced consultants can bring fresh ideas to new communications projects or old communications inefficiencies.
Now, go forth and write (better)!
The good news: your organization is growing. Maybe you've got new funding sources, your client base has expanded, or you've rolled out successful new services. You're expanding your reach, your impact, and your team. All of this requires strategy.
Growing your communications does, too.
In many ways, communications don't scale like other organizational functions. This is especially true of internal communications, which for small organizations may be completely organic. But whereas organic communications processes may be adequate (even efficient) for a team with a handful of people, they quickly become inefficient (even hazardous) when that team grows.
Growing organizations face two big problems when it comes to internal communications: lack of documentation, and lack of formalization.
Because small teams tend to function organically, there's often little or no documentation of roles and procedures. Team members know each other's strengths, pick up tasks as needed, and fall into familiar routines. But when too much lives in employees' heads, an organization can be on precarious footing when it starts to grow.
Ensuring institutional memory by creating and maintaining external records of communications is crucial for future growth.
Similarly, the organic functioning of a small team can hinder the development of formalized internal communications procedures. After all, maintaining a regular meeting schedule or planning and tracking workflow can seem cumbersome when you interact with everyone on your team every day.
But when an organization relies too much on informal communications to keep its wheels turning, it risks those wheels grinding to a halt. By formalizing communications procedures, you create the conditions for sustainable growth.
So what does it actually look like to document and formalize communications?
While the specifics are different for every organization, it means determining and codifying what works. It means finding the right tools—from calendars to trackers to meeting procedures—to accommodate your organization's growth. And it means creating and regularly updating written documents that detail communications operations in a way that makes them clear and easily adoptable for new team members.
Consciously scaling internal communications is crucial when it comes to organizational capacity-building. It's a forward-looking task that helps ensure the health of growing organizations.
We've been doing a bit of mental spring cleaning at MWS—namely, how best to package our most requested services. That's led us to a bit of spring cleaning for our website: check out our new Services page!
Our three packages (Comprehensive Communications Plans, Review of Public-Facing Communications, and Review of Communications Operations) describe the support we provide for the challenges we see most often among our nonprofit clients. We created them to offer the most efficient, effective means of determining and resolving organizations' needs.
But we also offer support for discrete projects such as grants, websites, blog writing, reports, workshops, and presentations. If you don't see what you need, reach out! Let us know what's on your communications spring cleaning list—we can almost always help.
This is the third part in a series about communications plans, which are crucial tools for nonprofits and businesses. Check out part I and part II for more!
A communications plan lays out a comprehensive picture of an organization's communications goals and offers executable steps for how to achieve them. It can be created or updated annually to align with the fiscal year, or it can be developed as a companion to a 1-, 3- or even 5-year strategic plan.
It’s an incredibly useful tool for mapping out future growth. But it's impossible to create without first understanding where you are now.
That's why, when we create communications plans for our clients, one of the most important steps entails laying out a comprehensive picture of an organization's current communications channels. This includes digital publications such as blog posts and email blasts, social media, print publications such as annual reports and newsletters, and events and in-person communications such as fundraisers or tours.
This can be a simple list, but it should be as comprehensive as possible. For some organizations, it might include five channels; for some, it might include 50. And for each channel, all relevant details should be included: give bullet points to the goal of the communication, the target audience, the timeline or frequency of the communication, who is responsible internally for producing the communication, and any budget and production specs available. That way, there are multiple angles available for easily slicing through the communications picture: Which members of your team currently bear the greatest communications burden? Which projects require the largest chunks of your budget? Which audiences aren't hearing from you frequently enough?
By laying out a complete picture, you can begin to see where you're putting most of your energy, what's being neglected or underutilized, where you're doubling up unnecessarily, and how content can be leveraged from one channel to another. If, for example, your primary goal is to grow your organization's membership, but all of your resources are going to annual reports and blog posts, it becomes clear that changing tack is merited.
In other words, this part of a communications plan is from whence the planning commences.
This picture can be used to develop and prioritize new communications projects, strategize ways to streamline workflow, design upcoming campaigns, revamp existing collateral, or create tools or templates for internal use. In short, it's the best foundation for an organization to ensure that it's moving in the right direction to efficiently align its communications with its long-term goals.
Our post on beta readers offered a strategy for soliciting structured feedback before project release. But it didn’t discuss strategies for handling that feedback once it arrives in your inbox.
Reading criticism is hard. After all, writing requires time and self-expression. No matter how professionally oriented, criticism can sting.
But integrating criticism is even harder. It's never easy to judge which critical feedback is useful and which isn’t.
The simplest strategy? Look for repetition.
Repetition can be straightforward. If more than one beta reader (or more than one feedback form) specifies the same weakness, well, it’s a weakness.
But repetition can also be oblique. Consider the beta-reader responses to a question that asked about the translation of SME material into everyday language:
And repetition can be overwhelming. It's no fun to read about the many different problems with your project. Luckily, these can usually be condensed into just one or two actual issues. For example:
Criticism might not be fun, but it's so fruitful. And not just for you. Soliciting critical feedback and then actually (and visibly) using it sets in motion a positive feedback loop that strengthens your project, your team, and your business’s commitment to your organizational end game.
While a beta release refers to the rollout of an early, mostly untested version of software, the beta phase (and the iterative form of software development in general) is an excellent way to pretest communications projects, too.
Software development usually proceeds from a pre-alpha phase (where R&D is completed), to an alpha phase, (where core functionality is built), to a beta phase, and finally to release.
That beta phase is so crucial because it puts the software—usually ugly and incomplete—out into the world. Chosen users can then play with it and provide the targeted feedback so necessary to completing and releasing the work.
Communications projects (reports, technical manuals, strategic plans) follow a somewhat similar route. First, there is the research and development; then, the outlining, drafting, and collating; finally, execution and testing.
But a beta release is rarely figured into this execution—and it definitely should be.
While most of us pay close attention to after-the-fact metrics, a beta release tests whether content is functional in a way that meets readers’ needs before delivery. Communicators can use the release to gain on-the-ground feedback and integrate it into a project ahead of publication.
To make the most of this opportunity, make recruiting beta readers (using a generic application like Google Forms to help identify members of your target audience) a part of R&D. Later, when the project is almost complete (but still malleable!) push it to beta readers with another form soliciting the feedback required. Common questions include responses to SME material or to calls to action.
For any client-facing project with a long development phase, a beta release creates a space in which meaningful info can be gathering and used. It's a bit of a time investment, but the payoff makes it absolutely worthwhile.
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.