<?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;TC</title>	<link>http://tc.eserver.org/dir/Articles/Project-Management/TC</link>
	<description>A listing of the most recently indexed works about Articles and Project Management and TC in the field of technical communication.</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;TC</title>
		<link>http://tc.eserver.org/dir/Articles/Project-Management/TC</link>
	</image>
	<item>
		<title>Why Technical Publishing Shouldn&apos;t Be Art</title>
		<link>http://tc.eserver.org/32174.html</link>
		<guid>http://tc.eserver.org/32174.html</guid>
		<description>The work may start with the author, but to get it from the author to the end reader means it also has to go through an editor, copy editor, book designer, typesetter, printer, sales and marketing team, distributor, book buyer, and, eventually, a retail store.</description>
	</item>
	<item>
		<title>Managing the Monster, Managing the Zoo</title>
		<link>http://tc.eserver.org/29661.html</link>
		<guid>http://tc.eserver.org/29661.html</guid>
		<description>Every technical communicator, whether controlling a single large project or a dozen small ones, must develop a set of management skills appropriate to the task in order to remain a qualified member of the communication team. This calls for being part diplomat, part technical expert, part salesman, and part rhinoceros.</description>
	</item>
	<item>
		<title>Project Management for the Technical Communicator</title>
		<link>http://tc.eserver.org/26065.html</link>
		<guid>http://tc.eserver.org/26065.html</guid>
		<description>Tasks need to be managed to be completed on time, with available resources to achieve the required result.</description>
	</item>
	<item>
		<title>Collaborating in Project Management, Long-Distance</title>
		<link>http://tc.eserver.org/19891.html</link>
		<guid>http://tc.eserver.org/19891.html</guid>
		<description>From early 1993 through July of 1994, three STC chapters jointly managed a research project on Technical Communication in Western Canada. Based in Winnipeg, Calgary and Vancouver, the managers were thousands of miles apart, relative strangers and simultaneously engaged in running their own businesses. In this volunteer assignment, they involved committees within their own chapters. As team building and collaborative arrangements become more prevalent in technical communications projects, it can be instructive to look at how such a farflung research project fared. We will relate this experience&#xD;briefly to some research results reported in &lt;i&gt;Technical Communication.&lt;/i&gt;</description>
	</item>
	<item>
		<title>Project Management in a Home-Based Environment</title>
		<link>http://tc.eserver.org/19519.html</link>
		<guid>http://tc.eserver.org/19519.html</guid>
		<description>Acxiom Corporation provides a wide spectrum of data&#xD;products, data integration services, and mailing list&#xD;services, as well as data warehousing and decision&#xD;support services to major firms in the United&#xD;States and United Kingdom. Effectively supporting the company¡¯s documentation needs requires a project process that keeps work flowing. The Documentation team developed a process consisting of four phases: planning, design, validation, and delivery. This triedand-&#xD;true process contributes to the success of our home-based&#xD;team.</description>
	</item>
	<item>
		<title>Conducting a Postmortem</title>
		<link>http://tc.eserver.org/18651.html</link>
		<guid>http://tc.eserver.org/18651.html</guid>
		<description>A postmortem is a meeting of all members of the project team at the end of the project to identify what went well and should be repeated on future projects; and what did not go well and how to avoid these situations on future projects.&#xD; &#xD;&#xD;In addition, the postmortem should provide time for the members of the project team to thank one another for their contributions. Often during the course of a project, team members become so comfortable working with one another that they do not thank each other for their contributions or acknowledge exceptional work. As a result, team members might not realize that their colleagues appreciate their contributions. The postmortem provides a formal opportunity for team members to offer one another such recognition.&#xD;</description>
	</item>
	<atom:link href="http://tc.eserver.org/dir/Articles/Project-Management/TC.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>