Managing Your Documentation Projects

Rating:
Summary: Uniquely Useful
Review: I've been writing tech docs for 20 years. I've implemented bits and pieces of Hackos' techniques everywhere I've worked since the book came out in '94. They always work, as long as (a) you aren't the kind of idiot who prefers to swat every gnat with a jackhammer, and (b) you aren't working with three or more of the following: (1) cowboy coders, (2) clueless engineering managers, (3) marketing people who've stopped taking their meds, and (4) the usual species of techpubs dino who prefers extinction to following *any* process s/he didn't actually invent. Even if you disagree violently with some of her approaches (as I do), you'd have to be mighty ignorant to disagree with all of it. If you're a techpubs newbie, buy it right now. Very soon, you will be managing a doc project on your own, and if you don't have a rabbi somewhere, Ms. Hackos will be your only hope.

Rating:
Summary: Must-read for documentation managers
Review: If you are or are going to managing documentation projects, read this book. Even if you don't completely agree with Hackos' methodologies, they act as a baseline.

Like another reviewer, I'm not thrilled with the examples. Most of the text was valuable and well-written, but I found the examples (and accompanying graphics) to be stilted and somewhat condescending.

On the whole, however, a volume to keep close at hand.

Rating:
Summary: A little idealistic.
Review: In the perfect world, this would be THE book to have. Unfortunately, this is anything but a perfect world and this book falls short in dealing with the realities of the profession. There is too little information and guidance for those that don't have a document-centred employer.
Also, the book is purely for those creating user documentation - if you write any technical material (such as requirements, design, UAT, or implmentation documents) this book will be of minimal help. Don't expect any realistic help in dealing with developers either.
Fine book, but only for a narrow field.

Rating:
Summary: Best guidebook available for Technical Publication Managers
Review: Joann's recommendations come from the everyday experiences of managers. She did her homework by benchmarking best practices in the industry.

Rating:
Summary: Not the Gospel
Review: Joanne Hackos is widely acknowledged as a leading authority on technical publications management, largely because (a) she has some good things to say and (b) her _Managing Your Documentation Projects_ is one of the few books on the topic. This book offers some valuable insights about basic project management, but tries to shoehorn publications project management into a particular software development methodology -- Carnegie-Mellon's Capabilities & Maturity Model. Hackos acknowledges her debt to CMM and warns that trying to implement the model described in this book is tough sledding if the development organization is not using CMM.

After 20 years as a technical writer and publications manager, I've come to believe that all publications lifecycle systems are doomed unless they map directly to the development methodology engineering management supports and uses.

(I've also come to believe that most development methodologies are more often than not honored in the breach.)

If, as a publications manager, you're not aware of the development methodology your engineering managers have adopted, you need to get over and talk to them now. Even if they haven't adopted a formal, academic model, they do have some idea about how they produce technical products. Tailor your publications lifecycle to their lifecycle -- don't seek to impose an alien "order" on their process.

(If your engineering managers can't articulate a methodology or say things like "We just code until we're done", you have bigger worries than your publications lifecycle, such as the near-term viability of your company.)

Too often I've seen tech pubs managers adopt the "Hackos model" and fail because it doesn't fit the organization's development style. A organization that adopts the Rapid Application Development (RAD) or "Extreme Programming" model, for example, isn't going to be too thrilled about endless sign-offs on planning documents that take nearly as long to write as the manual itself.

Instead, tailor your approach toward the high degree of interactivity inherent in such methods -- quick review cycles of small portions of text, for example, instead of waiting for a full draft of the book to be ready.

Too many erstwhile pubs managers skim this book, then adopt the project documents provided as models in the book as "fill-in-the-blank" busywork for their writers.

Tech pubs managers might be better served by learning the basics of project management (especially the interplay between resources, time, and scope) and reviewing the development model of the engineering organization than adopting the CMM-inspired approach Hackos describes in this book.

There is no one-size-fits-all method for producing documentation. And Joanne Hackos would be the first to tell you that.

Rating:
Summary: Text: good. Pictures: bad.
Review: The graphics, besides being useless, look like stories illustrated with Fisher-Price toys, so don't read it in public or people will think you're a moron. The text, however, is great. If you have to manage documentation projects, buy this book, hide somewhere, and read it.

Rating:
Summary: Great information but difficult to achieve in reality
Review: This book contains many years of compiled wisdom, not only from the people JoAnn bases her Publications Maturity Model on, but the many doc managers she interviewed and her own consulting experiences. The PMM is an ideal model and not one that can be applied across all industries. The book and process is heavily slanted toward software development and that's where it finds its biggest application, but the process breaks down for many industries outside of that arena. Most tech writers are paid to produce documents, not create and refine processes to such detail as suggested by the PMM parameters--but that's not the book's fault--it's the fault of engineering/technically driven organizations that would rather force tech pubs groups to reinvent the wheel with each new project than spend the time creating and fine-tuning a repeatable process.

Perhaps the biggest stumbling block to widespread acceptance/adoption of the PMM is the underlying need of "enlightened" organizations that appreciate (with time, money and resources) and understand the value-add such a process can provide, and those organizations are few and far between. You can have JoAnn's company perform a PMM audit for PMM certification (not sure how much that counts for in the business world--yet), or you can try to be compliant by following the suggestions outlined in the book. But if you're not a software shop, you'll have to make your own adjustments to the PMM requirements and scale appropriately.

All in all, I think the book provides some great direction for a documentation project management process that has to be scaled to meet your business/industry needs. This book has and will continue to serve as a springboard for more discussions and new initiatives in the technical communications field.

Rating:
Summary: Another illustration? Oh no!
Review: This book has excellent content. No doubt about it. Essential to any doc pubs manager or tech writer in charge of managing a project. IF you get this book, get it for the good content. You may not use all of the content (It is extensive) but it is very useful.

But what's the deal with the artist? The pictures look like Old Skool Saturday Night Live Mr. Bill. (Another illustration? Oh no!!!)

Rating:
Summary: A MUST HAVE for Technical Communicators
Review: This book is about the process of managing documentation projects. Since my company adopted the methodology described in this book, all of our projects have come in ahead of time and under budget...no matter what the size of the project.

The methodology helps communicators and clients focus on what is important in the development of information products. By focusing on what information users need to do their jobs, content becomes obvious.

Understanding the process of information development is critical to being able to measure the quality and effectiveness of the work. Only by adopting a policy of continuous process improvement can we increase our value to our organizations and to our customers. Dr. Hackos provides the method for doing this. While it was written in 1994, I still find it applicable in 2001!

Rating:
Summary: A Must-Have for any documentation manager.
Review: This book is absolutely excellent. The information is laid out well and the suggestions have helped me beyond words. I now create Information Plans and other documents prior to starting a new project and the results have been wonderful.

The results of this "pre" documentation have proven very effective further down the road and have assisted me in gaining larger budgets for my team, as well as additional projects.