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.
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.
The Publication Manual of the American Psychological Association—now in its sixth edition since its inception in 1929—is a constant companion to many of our academic writers (whether they like it or not!). We recently interviewed Mary Lynn Skutley, the editorial director of APA Books, who headed up the manual’s latest revision. From Skutley, we learned firsthand just what goes into the making of this slim volume, frenemy to so many.
English PhD, former arts administrator, obsessive cook, native East Coaster, and mom to two rabblerousers.
English PhD, former high school teacher, obsessive organizer, native Midwesterner, and mom to three troublemakers.