Rating: 
Summary: A MUST for every tech doc manager
Review: This book is an indispensable tool for anyone who is assigned the task of managing a technical documentation project. Every phase of the project is addressed. Good examples and thoughtful questions prompt the reader to assess aspects of a project that may have slip past the most critical eye in prior projects. I have read and re-read this book. Each time I pick it up I learn another salient fact about the art of project management. I am currently on my fourth copy of the book as I keep giving my copy to those in need.
Rating: 
Summary: Bulky book about the documentation process etc
Review: A thick book which endeavors to fit the whole business of technical documentation between its covers. Surprisingly enough, it is fairly successful. However I found the style surprisingly is abit "talky", and the approach could have been a bit less general and a bit more focused on tips and prticalities. But all in all it provides an interesting read. Especially the project model.
Rating: 
Summary: Managing your Documentation Projects
Review: Another long-winded academic thesis. It lacks the ONE thing that documentation managers and writers need: the tool. There is not a single example of a project plan or documentation design doc. There is no CD with templates. What a disappointment. By the time I finish reading this, my project will be due.
Rating: 
Summary: A Key to Senior Technical Writing Positions
Review: 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.
Rating:
Summary: Very good reference for effective documentation process
Review: 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.
Rating:
Summary: Interesting but unrealistic
Review: 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.
Rating:
Summary: Benefits pub. departments from one person to 1,000
Review: I am the lone writer in a chaotic startup software environment, trying to develop our company's first documentation development process, and this book is an absolute dream come true - there is no more accurate description! The writing style alternates between academic and anecdotal, with true examples from many companies. I believe that this style ensures that the book offers something to everyone, no matter the size of their department or experience level. A large amount of information is presented, which makes the work pretty exhaustive, but Hackos provides a guide in the first section to which sections are essential to the reader based on the reader's needs. If you are a documentation manager, or if you ever want to be, this book is essential. I can see myself flipping through this book 30 or 40 years from now.
Rating:
Summary: Must-have for anyone trying to plan a large project
Review: 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.
Rating:
Summary: Should have been shorter
Review: 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.
Rating:
Summary: useful, exhaustive
Review: I'm glad I bought the book. Many of the things you learn in a hands-on fashion in technical writing have been collected into a proven, workable volume. I haven't finished the book yet because it's so thick. Even though I like reading it and am learning and formulating new ideas, I think 250 pages rather than 600 would make it even more useful. Maybe some of the sidebar discussions could be shortened or deleted, but who am I to critique such a masterful writer?
| 
