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.
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!
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.