Starting a Documentation Group: A Hands-On Guide

Rating:
Summary: A Must for a New Technical Writer's Bookshelf
Review: I bought this book with an Amazon Christmas gift certificate from my supervisor. It was one of the wisest investments of my career! Hartman takes you through every step to develop a successful technical writing group.

You are taken through the development process and project planning; the tasks of naming your group and getting necessary resources. You learn how to hire new employees, develop a style guide, write functional specs, and an information plan. The product development process is outlined with a summary and definition of the stages involved and the deliverables required at each stage.

Project planning is covered quite well, but I would advise purchasing "Managing Your Documentation Project" (JoAnn Hackos), "Developing Quality Technical Information" (Gretchen Hargis), and "One Minute Designer" (Roger C. Parker). This combination is like having an entire technical writing curriculum at your fingertips.

Rating:
Summary: Good Resource, Especially for Small Groups
Review: When I asked a colleague if he would recommend this book, he said, "Well, there's a lot in there you already know." He's right. After 13 years as a tech writer, there's a lot I already know, but there's also a lot I might have forgotten. Hartman's readable book is a gentle reminder, among other things, of processes we may have forgotten, and of the big picture of writing documentation.

Another reason I found it useful was that it is tailored to small and startup organizations. In small companies, processes are trimmed and schedules are more compressed. If you've worked in large companies during your career and are thinking of joining a smaller company, Hartman's book tells you what to expect.

Hartman's suggestions on how to start, schedule, and staff projects may seem obvious to someone who's done it for years, but I found it interesting to see how someone else did it. My manager, who has not managed a doc group before, also read this book so she could see what the processes are in a well-run doc group. She's also going to try his suggestions for setting up a doc project in Microsoft Project: she and I have spent quite a few days trying to get it right, and we're hoping his suggestions help.

My only disagreement with him is in his statement where documentation groups belong in the organizational structure. Hartman is firm in his suggestion that documentation groups belong under Engineering. He overlooks reporting to Support, which can work extremely well. Nor does he mention that some Engineering groups treat doc personnel as second class citizens because they are not as technical as the Engineers. In extreme cases, they're treated as little more than technical typists; at best, they are not given the respect, authority, and freedom to act that they need to be true user advocates.

All in all, Hartman appears to follow widely accepted rules of good practice and presents his ideas in readable, enjoyable form.

I think it's a great resource for new managers or those who find doc managers in their reporting structure. As I said, it's also very valuable for people who worked in large organizations and are now working for smaller ones. Managers of organizations that are downsizing or spinning off smaller companies might also find it useful.