Customer Reviews

Managing Your Documentation Projects

5 star:		(10)
4 star:		(9)
3 star:		(6)
2 star:		(2)
1 star:		(1)

 

 

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.

Any technical writer seeking to move into the upper levels of the profession will find that "Managing Your Documentation Projects" is one of the most useful books to read. I agree with other reviewers' comments about the dreadful illustrations and the problems one would have putting the entire bulky method into place in many technical environments. Many of the sample conversations Hackos includes as examples of what can happen when the process is applied are almost unintentionally ironic.

However, my experience is that the process and information that Hackos offers in this book will give you some of the tools you need to land a senior-level position. As Hackos herself writes, the ideas and material she offers are there for you to use, to try out, to modify so that they fit the requirements of your particular environment.

Some readers may be a bit put off by Hackos' focus on planning and delivering print publications. I have found that the ideas are flexible enough to transfer to different media. The important thing is to use project management for technical communications projects.

There is considerable ongoing debate within the technical writing profession as to the value of process and planning for the work. One argument is that process and planning takes us away from our real work and provides a convenient excuse when projects do not progress as required. Proponents of this idea often say something like, "Shut up and write." Another side holds that careful analysis and planning are integral parts of our work and we cannot succeed without a defined process. I find that a lot of high-tech companies are looking for process. They know that they need structure to produce quality products in a predictable, reliable way.

One caution worth noting, as Hackos herself advises, is that the model would have to be modified extensively to work in a Rapid Application Development (RAD) environment. Another caution is always to remember that the method is not the goal. At times, it is more important to produce documentation than it is to revise the project management materials to keep up with the latest twist or turn in a project.

I recommend "Managing Your Documentation Projects" for technical writers looking to move ahead in their careers. It is a bit pricey, but I think that many people would find it money well spent.

I have very mixed feelings about this book. Clearly Hackos has a tremendous amount of experience and has seen many successful projects from start to finish. Nonetheless, I'm troubled by the length of the book and the heavy reliance on project management methodologies from other disciplines. Hackos has correctly recognized that a documentation project has to be broken into stages, and the stages she suggests are (pretty) good. But the sheer number of deliverables produced in each phase is overwhelming. By bombarding developers with doc deliverables (information plans, content specifications, etc.) during the development cycle, you risk becoming the ninny on your software project--or more precisely, the schoolmarm. And that, I think, is what bothers me about this book in general: the schoolmarmish tone that resurfaces throughout. There is just too much detail.

Hackos is correct to suggest that writers must establish better rapport with developers. I think the way to do that, however, is to get closer to real development methodologies (rather than writing methodologies) that are gaining steam today. (Best example: Rational Software's Unified Process.) If the profession is ever to get the respect it deserves, technical writers will have to become more like programmers, and less like English teachers.

Hackos book is often extolled as the universal Bible of technical documentation. However, in reality many of her methods are impossible to implement and unrealistic. Hackos has a very traditional view of the tech pubs department. A view that is rapidly disappearing. The real world of tech writing is considerably muddier and dynamic. Last-minute changes and chaos are more often the norm than people want to accept.

Hackos book is a good place to get ideas to help define your own methods and practices. However, most of the ideas here are absurd and time consuming. Attempting to implement all her methods would quickly turn a tech pubs department into a mire of bureaucracy and unnecessary work.

As somebody who thinks developing documentation processes and extensive planning are often used as an excuse to avoid the real work of tech writing (namely *writing*), my bias is pretty obvious. Personally, I think many tech writers use Hackos' book as justification for wasting time building meaningless documentation processes when they should be out there talking to engineers, writing text, and designing graphics.

However, there are some good ideas in here. If need some basic guidelines for completing documentation projects, this isn't a bad place to pick them up.

This is an excellent source for documentation managers. I was thrust into a managing role after 1.5 years as a technical writer. This book really helped me make a mole hill out of a mountain. My only complaint is the extranious graphics/illustrations (which offer no profound insight or information). These graphics may add white space, making the book less intimidating to the green reader, but this is a specialized topic for a specialized audience, which doesn't need such pedestrian graphics. If you can learn to ignore the illustrations and stick to the content (which is excellent, by the way), this book will help you get a grip on managing documentation.

For novice or experienced writers, this book offers more insight into good documentation processes than any other book I have read. The approach advocated by the author is applicable in any documenation development effort, be it hardware or software, commercial or mil spec. There really is something for everyone.

This book focuses on the need for a solid planning effort as the basis for all major decisions. Information planning, content planning, scheduling, and resource allocation are all covered in a comprehensive and thorough manner.

Throughout the book, the author chooses as an organizing principle the concept of a documentation life cycle. Thus, readers have a conceptual framework that they can use to relate what the author has written to their own experience.

As well, the author classifies the stages of development of a publications group from chaos to a team capable of a managed, repeatable, and worthwhile effort that enhances the product. I have had both the misfortune and good fortune to have worked with each type of organization that the author describes. The descriptions are breathtaking in their accuracy.

This book is written in a very readable style. There are numerous case studies and examples. Clearly, the author has extensive experience and has drawn upon this to provide a very useful book.

This book should be on every technical writer's shelf.

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.

I have used this textbook twice instructing advanced technical writing courses at Portland State University. I have found it easy to use, well-written, and organized the way I expect it.

The main point Hackos makes is that every publications department sits somewhere on the planning continuum. She introduces the concept of the Publications Development Life Cycle (PDLC). Your department may range from Level 0, oblivious, to Level 5, continuously incrementally improving. She identifies the main tasks needed to move from one level to another.

The three main tools used to plan for projects are the information plan, a high-level strategic document; the project plan, a set of timelines and estimates for page counts and money; and a content specification, a detailed outline of every deliverable.

Hackos has done a masterful job of setting forth the theory behind the reasoning. Her examples demonstrate not only how important planning is, but the commitment that has to be made to make it succeed. If every technical writer had this book on their shelf, our profession would take a huge step forward.

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.

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.