<?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</title>	<link>http://tc.eserver.org/dir/Articles/Project-Management/Writing</link>
	<description>A listing of the most recently indexed works about Articles and Project Management and 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</title>
		<link>http://tc.eserver.org/dir/Articles/Project-Management/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>Lying in a Hammock, or, Having a Single Goal without a Purpose</title>
		<link>http://tc.eserver.org/34890.html</link>
		<guid>http://tc.eserver.org/34890.html</guid>
		<description>When you live in the moment, completing the activity itself is the success. And because writing is so multifaceted in effect — the effect both on me and others — having an open purpose doesn’t limit the results. I’m not narrow-mindedly searching for a specific achievement to happen. Instead, I’m open to unconsidered possibilities, if any of those possibilities decide to unravel.</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>Project Management for Writers</title>
		<link>http://tc.eserver.org/30546.html</link>
		<guid>http://tc.eserver.org/30546.html</guid>
		<description>Project management skills are part of every writer&apos;s life, in some form or another. However, the more you use these skills to manage your daily work, the more you will grow as a writer. Estimating, controlling scope, and tracking your progress are all part of delivering the product that your &quot;customer&quot; wants. Your primary tool is your documentation plan. In this workshop, we will discuss why these processes are important to you and how to implement them on your job.</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>Writers in the Classroom</title>
		<link>http://tc.eserver.org/28193.html</link>
		<guid>http://tc.eserver.org/28193.html</guid>
		<description>What does it take to get a newsletter out each month? Well, I spend about 16-20 hours a month on the newsletter at home, which doesn&apos;t include copying.</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>How to Ruin a Writing Project in 10 Easy Steps</title>
		<link>http://tc.eserver.org/25950.html</link>
		<guid>http://tc.eserver.org/25950.html</guid>
		<description>Does your job involve writing? Here&apos;s a surefire recipe for bringing on writer&apos;s block and making the whole process seem so onerous that you&apos;ll vow never to put pen to paper again.</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.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>