I’ve got a couple of comments.
Warning: This could turn into a stemwinder.
I don’t do a lot of writing these days.
I’ll try to keep it compact.

Re: Section 3.2 – Who reads this stuff anyway?
I believe you might have an opportunity here to go beyond the usual perfunctory boilerplate on this topic, and offer some innovative advice.

At minimum, you could tell some tales
about the common traps and pitfalls involved in gaining an accurate strategic understanding of one’s customer’s information needs. I’ve seen some way off-target doc set requirements/designs as a writer, and I’m sure you have too as a manager.

I suspect the person with the biggest challenge – when it comes to determining customer needs – has got to be the manager of a doc group embedded within a development organization.
I take it that’s your intended audience for this book, right?
If so, I have found that the writers in an embedded group often know a lot about how the product works -
which they pick up from their day-to-day environment, from the engineers.
But they often don’t have good information about how customers actually use the product – about the customer environment.

I’m inspired to make this comment by your new section of working with HR.
I’d also like to see you stress the importance of the doc group’s establishing both formal and informal relationships with customer support as well.

I don’t know whether this topic belongs in Section 3.2 or in Section 5.3. – Working with the rest of the project. But here are a couple of cautionary tales to give you a sense of what I’m advocating to you.

- When I joined one big BTL project as a writer,
one of my subject matter experts was an engineer who split his time between the development organization and customer sites, doing installs. Through him, I learned that the project’s customer considered the existing documentation useless, because it made incorrect assumptions about the technical sophistication of its audience. I passed this info on to my doc manager (another new hire at the time). In turn, my manager worked with a manager in customer support to wrangle a week’s visit at the customer site for me from the project manager. I returned with a notebook full of information about what sort of docs the customer really needed. The project ended up redesigning and rewriting the entire doc set, and throwing away about 18 month’s worth of documentation. Lesson learned: customer support can be doc’s best friend, strategically.

- Thanks to some scheduling fluke, I once attended a diversity awareness course (at another large corporation) with members of a customer support organization I hadn’t met before. It turned out we both supported the same product. More importantly, it also turned out their organization had developed a formal list of the top ten problems customers were having with the product – eight of which were directly related to deficiencies in the product documentation! But no one in customer support had ever said a word about this to the doc group. This wasn’t surprising to me. The parent company seemed to function as a collection of autonomous fiefdoms, and the two organizations – support and doc – were not accustomed to talking with one another. Lesson learned: #1 something about the lack of organizational diversity awareness in this particular company #2 the doc group’s failure to build a working relationship with customer support was a missed opportunity.

The quick answer is “not fast enough” . Thanks for the kind words. I’ll do my best to live up to your expectations.

Based on your outline, this looks to be an extremely useful resource! How fast can you get this written?

Seriously, I think you’ve done a lot of great work on this already and I can’t wait to read the finished product.

–Scott

Good points. I do need to deal with both outsourcing and localization/translation. And I’ll fix the typo, too. Thanks very much.

Also ,there appears to be a boble in the first bullet under section 6.3:

In particular, do you need new that new content management system/XML…

probably want to drop the first “new”