WARNING: The following is likely to ruffle some feathers but it needs to be said.
Documentation groups are usually treated as afterthoughts because they allow themselves to be treated that way. There is much talk about how documentation is a "craft" and involves special consideration, but really it's no different than any other piece of a product. There's also (for some reason) a belief that Technical Writers (and thus documentation) are inferior to Programmers (code/application), and this belief is held by all sorts of people, including many writers themselves. I can't tell you how many times I hear things like "oh but I can ask Joe Developer that... he's so much smarter than me." It really bothers me, because there is no "smart" qualification that makes a developer that does not also make a writer. The skill sets are merely different. A mechanic is no smarter than a carpenter... why do we (and others) assume a programmer is smarter than a technical writer. Anyway, I'm getting off topic a bit. The point is that you need to treat each involved functional area and their deliverables to the project equally if the project is to be a success. By promoting one group over another, you're only accomplishing one thing: jeopardizing the quality of the project or the project itself. Beth has offered some sound advice below. I'd only add one thing other than self-esteem, which was harped on above: accountability. Hold yourselves accountable for the documentation, for the user experience in the product itself (this should be shared by QA should you not have a Human Factors group), and TO the project team, as well as TO each other. Believe you me, other groups will follow when they see how well the documentation is going, and you can bet they'll be seeking your advice. On 1/10/07, Beth Agnew <[EMAIL PROTECTED]> wrote: > "Like everyone else" is the key. Why are documentation groups > consistently treated as afterthoughts in so many organizations? If we > approach projects in the same way as everyone else, with plans, project > schedules, milestones and deadlines, reviews, and management of scope, > we should be given the same consideration as everyone else. If a product > manager notifies development the release date has been moved up, s/he > fully expects to be told that something has to be sacrificed in order to > make that deadline. When documentation says it, those blank looks Bill > talks about are priceless! -- Bill Swallow HATT List Owner WWP-Users List Owner Senior Member STC, TechValley Chapter STC Single-Sourcing SIG Manager http://techcommdood.blogspot.com avid homebrewer and proud beer snob "I see your OOO message and raise you a clue." ______________________________________________ Author Help files and create printed documentation with Doc-To-Help. New release adds Team Authoring Support, enhanced Web-based help technology and PDF output. Learn more at www.doctohelp.com/tcp. DITA West 2007--Use a discount code of "TECHCOMMPROS" to get a discount rate of $200 off the $800 price if you register before close of business January 15, 2007. http://www.travelthepath.com/conf/dita2007.shtml _______________________________________________ Technical Communication Professionals Post a message to the list: email [EMAIL PROTECTED] Subscribe, unsubscribe, archives, account options, list info: http://techcommpros.com/mailman/listinfo/tcp_techcommpros.com Subscribe (email): send a blank message to [EMAIL PROTECTED] Unsubscribe (email): send a blank message to [EMAIL PROTECTED] Need help? Contact [EMAIL PROTECTED] Get the TCP whole experience! http://www.techcommpros.com
