<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Articles&gt;Project Management&gt;Writing&gt;Technical Writing</title>	<link>http://tc.eserver.org/dir/Articles/Project-Management/Writing/Technical-Writing</link>
	<description>A listing of the most recently indexed works about Articles and Project Management and Writing and Technical Writing in the field of technical communication (and technical writing).</description>
	<language>en-us</language>
	<copyright>Copyright (c) 2005-08 by the EServer. All rights reserved.</copyright>
	<managingEditor>tclib-editorial@eserver.org (TC Library Editorial Board)</managingEditor>
	<webMaster>webmaster@eserver.org (Geoffrey Sauer)</webMaster>
	<image>
		<url>http://tc.eserver.org/images/newlogo.gif</url>
		<title>Articles&gt;Project Management&gt;Writing&gt;Technical Writing</title>
		<link>http://tc.eserver.org/dir/Articles/Project-Management/Writing/Technical-Writing</link>
	</image>
	<item>
		<title>How Soon is Now?</title>
		<link>http://tc.eserver.org/35586.html</link>
		<guid>http://tc.eserver.org/35586.html</guid>
		<description>One common complaint a lot of technical writers have is that they aren’t included early enough in lifecycle of a project. The downsides are that by the time work hits your desk you don’t have a full picture of who the customer is, why they want whatever it is you are building, and how they want it provided to them. All of which directly impacts the information being created.</description>
	</item>
	<item>
		<title>Too Many Inputs Freak Out the Technical Writer</title>
		<link>http://tc.eserver.org/35208.html</link>
		<guid>http://tc.eserver.org/35208.html</guid>
		<description>In such a scenario, this article presents some of the practices that have helped me track and address inputs effectively – regardless of their volume and importance.</description>
	</item>
	<item>
		<title>What’s Wrong with PowerPoint as a Document Authoring Tool?</title>
		<link>http://tc.eserver.org/35078.html</link>
		<guid>http://tc.eserver.org/35078.html</guid>
		<description>It is our position that use of PowerPoint for document planning negatively impacts all potential collaborative authoring and review outcomes. Though PowerPoint is commonly used because it is a familiar tool, it is not the most effective tool for managing knowledge either intellectually or financially.</description>
	</item>
	<item>
		<title>When Trust Becomes a Characteristic Flaw in a Project</title>
		<link>http://tc.eserver.org/33551.html</link>
		<guid>http://tc.eserver.org/33551.html</guid>
		<description>As hard as it may seem, lesson one of technical writing is to break the rules and contact the end user. Conduct a mini-ethnography. Sit with the users. Call them on the phone. Send them emails. Do not let it get to the point where you feel you must go through the PM to communicate with the end user. As hard and uncomfortable as it may be, the consequences of not talking to the end user can be crippling to your help.</description>
	</item>
	<item>
		<title>Why Writing Deadlines May Be (Almost) As Good As Money</title>
		<link>http://tc.eserver.org/31902.html</link>
		<guid>http://tc.eserver.org/31902.html</guid>
		<description>As much as we all like and/or need money, getting paid may not be enough to keep a writer motivated. Deadlines often are just as important. Although some of us fear — or even hate — them, the truth is that without them many of us simply wouldn’t write anything. And you can count me among those many.</description>
	</item>
	<item>
		<title>Using the Triage Method in Technical Writing</title>
		<link>http://tc.eserver.org/29426.html</link>
		<guid>http://tc.eserver.org/29426.html</guid>
		<description>Pragmatism is the necessary first step: do the best job you can do under the conditions. Nobody&apos;s going to benefit if you do a superb job on half the manual, then die of stress before you can document the important parts in the second half.</description>
	</item>
	<item>
		<title>The Hidden Relationship Between Project Managers and Technical Writers</title>
		<link>http://tc.eserver.org/29336.html</link>
		<guid>http://tc.eserver.org/29336.html</guid>
		<description>Want to know the secret to better quality documentation and improved software design? Will Kelly outlines how the key is an effective relationship between project managers and technical writers.</description>
	</item>
	<item>
		<title>A Tale of Two Technical Writing Teams</title>
		<link>http://tc.eserver.org/28603.html</link>
		<guid>http://tc.eserver.org/28603.html</guid>
		<description>Sometimes considered an afterthought in the product development lifecycle, technical writers often struggle to become part of a performing Agile team.</description>
	</item>
	<item>
		<title>Empathize with the Writer</title>
		<link>http://tc.eserver.org/27887.html</link>
		<guid>http://tc.eserver.org/27887.html</guid>
		<description>It is my firm belief that every technical writer is passionate about her work and would put in her best efforts to deliver high quality. If you are a manager or an editor and are shaking your head in disagreement, think again. Why would someone want to submit a work of poor quality?</description>
	</item>
	<item>
		<title>Real Costs Of Technical Publications</title>
		<link>http://tc.eserver.org/27462.html</link>
		<guid>http://tc.eserver.org/27462.html</guid>
		<description>This workshop shows a technical publication manager or rising professional how to work in the following technical publishing/financial areas: project management, operating budget preparation and management, and quality control.</description>
	</item>
	<item>
		<title>Six Reasons You Don&apos;t Need a Technical Writer (and Why They&apos;re Dead Wrong!)</title>
		<link>http://tc.eserver.org/26726.html</link>
		<guid>http://tc.eserver.org/26726.html</guid>
		<description>Hiring the right freelancer to do the job correctly the first time around could save you hundreds or thousands in help desk calls, service calls, document revision, and distribution. Here&apos;s why.</description>
	</item>
	<item>
		<title>Developing the Specification for a Document</title>
		<link>http://tc.eserver.org/22051.html</link>
		<guid>http://tc.eserver.org/22051.html</guid>
		<description>Between 25-30 percent of the overall writing time is typically devoted to developing the document specification,  meaning how the document will be formatted and actually present the  information.  This is true even when the organization has a style  guide with a prescribed format, but no “standard” for documentation  overall. Although this may seem an inordinate amount of time and effort  on the front  end, before getting any information onto the paper,  it is far more cost-effective than spending unplanned time rewriting and reformatting  the document late in the production process.</description>
	</item>
	<atom:link href="http://tc.eserver.org/dir/Articles/Project-Management/Writing/Technical-Writing.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>