<?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;Documentation</title>	<link>http://tc.eserver.org/dir/Articles/Project-Management/Documentation</link>
	<description>A listing of the most recently indexed works about Articles and Project Management and Documentation 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;Documentation</title>
		<link>http://tc.eserver.org/dir/Articles/Project-Management/Documentation</link>
	</image>
	<item>
		<title>Managing a Documentation Project Successfully: More Jelly and Ice Cream</title>
		<link>http://tc.eserver.org/35530.html</link>
		<guid>http://tc.eserver.org/35530.html</guid>
		<description>This video on simplifying business, using the metaphor of organising a children’s party, made me smile and consider how successful documentation projects are managed. The presenter is suggesting managers need to, in complex systems, give up rigid control from above. Instead, they should watch for organisational patterns, encouraging the good and discouraging the bad.</description>
	</item>
	<item>
		<title>Managing Documentation Projects: Keeping the Plates Spinning</title>
		<link>http://tc.eserver.org/35434.html</link>
		<guid>http://tc.eserver.org/35434.html</guid>
		<description>A product is only as good as its information. With good information, customers can use the product--be it a piece of software, a hand-held electronic device, or a supersonic aircraft--and are more likely to hold a good opinion of its manufacturer. Without good information, no matter how good the product is, customers will be frustrated and will probably look elsewhere. It&apos;s not a stretch to say that the documentation project manager is instrumental in determining whether a product succeeds.</description>
	</item>
	<item>
		<title>Ten Ways to Save Money When Publishing a Manual</title>
		<link>http://tc.eserver.org/32691.html</link>
		<guid>http://tc.eserver.org/32691.html</guid>
		<description>Several hints on how to produce professional documentation less expensively.</description>
	</item>
	<item>
		<title>Topic-Based Writing to the Rescue: Project Considerations for Managers</title>
		<link>http://tc.eserver.org/32176.html</link>
		<guid>http://tc.eserver.org/32176.html</guid>
		<description>The purpose of this case study is neither to simply rehash the project nor to provide a pressure-cooker story that others can use as a comparative benchmark. This article looks at the decision points within the project and provides an analysis from a real-life, practical approach that other technical communication managers can use when called upon to engage in a rescue project of their own.</description>
	</item>
	<item>
		<title>Making the Case for Explicit Documentation Requirements</title>
		<link>http://tc.eserver.org/31832.html</link>
		<guid>http://tc.eserver.org/31832.html</guid>
		<description>Clearly defined documentation requirements are instrumental in ensuring the appropriate documents are created accurately and in a timely manner. This article will make a case for using explicit documentation requirements and will recommend a method for putting it into practice.</description>
	</item>
	<item>
		<title>It&apos;s In the Numbers: Using Metrics to Plan Documentation Projects</title>
		<link>http://tc.eserver.org/31715.html</link>
		<guid>http://tc.eserver.org/31715.html</guid>
		<description>It&apos;s in the numbers. Creating documentation is not an exact science, yet as communication leaders, we are expected to provide real estimates for how much time we need to document a project, or what we can produce given a predetermined timeline.</description>
	</item>
	<item>
		<title>Documents That No Project Cannot Be Without</title>
		<link>http://tc.eserver.org/31035.html</link>
		<guid>http://tc.eserver.org/31035.html</guid>
		<description>Short deadlines force project teams to quickly design, test, and release the product with little or no design documentation. If these documents are written, they generally are not well-written and are not comprehensive. The fact of the matter is that most project teams do not have enough staff to design the product, let alone write and manage documentation. This situation creates an ideal opportunity for technical writers to assist the project team in more ways than writing a user guide.</description>
	</item>
	<item>
		<title>Information Metrics: Keeping Your Writing Projects On Track</title>
		<link>http://tc.eserver.org/30510.html</link>
		<guid>http://tc.eserver.org/30510.html</guid>
		<description>Keeping information metrics for documentation projects gives managers the ability to more accurately estimate future projects. Publications departments can develop their own tools or they can use existing tools to track such things as page size, hours-per-page spent writing, illustrating, editing, and producing manuals; and the dependencies of each manual. This kind of information can help to determine development schedules, show how late changes affect the documentation process, and accurately determine what it will take to complete quality documentation on time and within budget.</description>
	</item>
	<item>
		<title>Managing Your Documentation Monster: Project Management for the 90&apos;s</title>
		<link>http://tc.eserver.org/30521.html</link>
		<guid>http://tc.eserver.org/30521.html</guid>
		<description>If you&apos;ve ever had trouble figuring out what your boss wants or needs, and how to deliver the project in a timely manner, this is the demonstration for you! From a nuts and bolts approach to developing an iron clad project plan, to managing the process and marching the completed project in a timely and professional manner, this demonstration covers a lot of ground in a short time. Tips, tricks, and checklists will be available to each attendee.</description>
	</item>
	<item>
		<title>How to Plan On-line and Paper Versions of a Software Manual</title>
		<link>http://tc.eserver.org/30314.html</link>
		<guid>http://tc.eserver.org/30314.html</guid>
		<description>On projects for which you must produce both on-line and paper documentation, there are many things you should consider before you start.</description>
	</item>
	<item>
		<title>The Six Biggest Mistakes Project Managers Make with Documentation and How to Avoid Them</title>
		<link>http://tc.eserver.org/30262.html</link>
		<guid>http://tc.eserver.org/30262.html</guid>
		<description>Professional business writers, such as technical authors, typically break a document down into small, discrete units of information, organised around a skeleton of topic headings. If you use this &apos;component&apos; or &apos;modular&apos; approach, you can plan and structure the document using the heading &apos;labels&apos; that describe each section.</description>
	</item>
	<item>
		<title>Using Downtime Effectively as the Deadline Approaches</title>
		<link>http://tc.eserver.org/29703.html</link>
		<guid>http://tc.eserver.org/29703.html</guid>
		<description>Technical communicators are often expected to write manuals and Help systems concurrently with programmers as they develop the product. While this helps ensure the documentation is ready when a product is released, it also creates some headaches for the writer. Many of the features that must be documented aren&apos;t functional until late in the development cycle. The writer must then wait for the features to be completed, while anxiously watching the deadline grow nearer. Fortunately, by keeping a sharp eye on planning and making advance preparations, the writer can minimize the effects of the unavoidable, last-minute rush to the finish.</description>
	</item>
	<item>
		<title>Teamwork and the Product Documentation Process</title>
		<link>http://tc.eserver.org/29415.html</link>
		<guid>http://tc.eserver.org/29415.html</guid>
		<description>Get to know your new teammates. Get to know your audience. Define the product&apos;s features. Create a mockup of the user interface. Begin to document the features and interface.</description>
	</item>
	<item>
		<title>Dealing With an IT Scourge: Process Documentation</title>
		<link>http://tc.eserver.org/29338.html</link>
		<guid>http://tc.eserver.org/29338.html</guid>
		<description>In this article, we outline how IT analysts can effectively make determinations about the value of process documentation, and in the process, transform a potential scourge into a possible blessing.</description>
	</item>
	<item>
		<title>Manage the Document Life Cycle for the Important Documents on Your Project</title>
		<link>http://tc.eserver.org/29349.html</link>
		<guid>http://tc.eserver.org/29349.html</guid>
		<description>Not all documents require a full lifecycle, but if you understand the nature of building documents, you will be better able to plan for the time required to complete them successfully.</description>
	</item>
	<item>
		<title>Managing your Documentation Projects</title>
		<link>http://tc.eserver.org/28138.html</link>
		<guid>http://tc.eserver.org/28138.html</guid>
		<description>Documentation projects require a significant amount of coordination and planning, and managers often find themselves faced with the challenge of successfully integrating a range of new elements including international legal requirements, new players, budgets and scheduling demands to make a product successful. Most often they look around for solutions to develop an effective strategy for their documentation projects that places control in their hands.</description>
	</item>
	<item>
		<title>Ten Rules for Bad Development</title>
		<link>http://tc.eserver.org/26500.html</link>
		<guid>http://tc.eserver.org/26500.html</guid>
		<description>here are advantages to being a bad development manager. For one thing, you don’t stand out from the crowd; most development managers are pretty bad. For another thing, bad development managers have a knack for getting promoted in the face of all evidence to the contrary. With mediocrity as the norm, bad development managers have an edge: nobody expects much of them. Perhaps best of all, bad development managers don’t have to do a lot of original thinking.&#xD;&#xD;This article identifies the 10 most common things that bad development managers know in their bones. If you follow all 10 of these rules, you’ll be able to hold your head up as the baddest of the bad.</description>
	</item>
	<item>
		<title>Document your Database Project to Capture Relevant Info</title>
		<link>http://tc.eserver.org/26262.html</link>
		<guid>http://tc.eserver.org/26262.html</guid>
		<description>Documenting a database during its development is a best practice to ensure that the organizational schema, data objects, and other related information are captured for future reference.</description>
	</item>
	<item>
		<title>Juggling or Struggling: The Art of Managing Online and Hardcopy Documentation</title>
		<link>http://tc.eserver.org/24903.html</link>
		<guid>http://tc.eserver.org/24903.html</guid>
		<description>While company budgets are increasing little or none, the responsibilities of technical writers continue to multiply as they are expected to produce online help as well as hard-copy documentation in short time periods. This demonstration explains how technical writers at Computer Power, Inc. produce usable online and hard-copy documentation from one source file. Participants will learn how to plan the file, create appropriate graphics, and use macros to convert text and other information for use in online help.</description>
	</item>
	<item>
		<title>A Documentation Database for Managing Time and Costs</title>
		<link>http://tc.eserver.org/24703.html</link>
		<guid>http://tc.eserver.org/24703.html</guid>
		<description>Keeping track of a technical writing team’s time can be a tedious task, especially when that time has to be charged to various internal departments. Using Lotus Notes™ (Lotus Development Corporation and Iris Associates, Inc.), we developed a relational database to track this information. This database uses a single form for all documentation status inputs. Then it summarizes the data in a variety of view. Separate forms track SEI statistics and simplify department employee time administration.</description>
	</item>
	<item>
		<title>Improving Publication Quality Through Project Management</title>
		<link>http://tc.eserver.org/24451.html</link>
		<guid>http://tc.eserver.org/24451.html</guid>
		<description>A methodology for developing high-quality software developed by the Software Engineering Institute at Carnegie-Mellon University can also be applied to developing technical publications. This workshop addresses several aspects of this methodology using various project management techniques. By bringing your development process under better control, these techniques will ensure a more uniform quality in your publications.</description>
	</item>
	<item>
		<title>Easy Tools for Documentation Management</title>
		<link>http://tc.eserver.org/24241.html</link>
		<guid>http://tc.eserver.org/24241.html</guid>
		<description>The use of three simple tools can assist the documentation manager, from start to finish, on any new project. A revamped pubs plan, a new concept with engineering worksheets, and a matrix of modularized information are all utilized with a slightly new twist.  The Pubs Plan is redefined to help you launch your project with a team approach, identifying issues, and proposing solutions. The Engineering Worksheets list all the critical pieces of information your writers/illustrators need for each component of the product.  These pieces of information are then tracked by completion date on an Information Matrix. These documents work together as complimentary management tools that can be easily developed and scaled to the complexity of any project.</description>
	</item>
	<item>
		<title>Getting a Count: Recording Metrics in Documentation Plans</title>
		<link>http://tc.eserver.org/24249.html</link>
		<guid>http://tc.eserver.org/24249.html</guid>
		<description>Most large documentation departments are already using some kind of a formal documentation project planning strategy. Many are modeled after the work of Dr. JoAnn Hackos, with information plans, content specifications, and/or documentation plans (Hackos, 1994) 1 . By carefully adjusting the look and feel of the planning documents, adding room for recording actual numbers at the completion of the project, managers can implement a metrics strategy that takes advantage of existing templates and piggy-backs on existing archiving and checkout procedures.</description>
	</item>
	<item>
		<title>Managing a Company-Wide Policies and Procedures Project</title>
		<link>http://tc.eserver.org/23793.html</link>
		<guid>http://tc.eserver.org/23793.html</guid>
		<description>It takes skills in three different areas to manage a company-wide policy and procedures project. First,&#xD;people must be organized and motivated to participate.&#xD;Executive support is critical here. And the persons&#xD;actually performing the tasks must be the ones to&#xD;document it. Second, the project must be clearly&#xD;defined and tracked. The document creation and&#xD;review process must be structured simply, to take full&#xD;advantage of the documentation team’s limited time.&#xD;Finally, the information published must be accurate and&#xD;controlled. Work processes should be analyzed before&#xD;the procedures are documented, and published&#xD;procedures must be distributed to specified manual&#xD;holders.</description>
	</item>
	<item>
		<title>Estimating Time and Cost for Policies and Procedures Projects</title>
		<link>http://tc.eserver.org/23652.html</link>
		<guid>http://tc.eserver.org/23652.html</guid>
		<description>Estimating time and cost for a policies and procedures project can be an adventure in guessing and a ticket to grief. However, planning with a detailed checklist and list of assumptions can you help create a more realistic estimate, please your client, and protect your sanity and pocketbook.</description>
	</item>
	<item>
		<title>Developing a Project Life Cycle for Technical Publications</title>
		<link>http://tc.eserver.org/23643.html</link>
		<guid>http://tc.eserver.org/23643.html</guid>
		<description>Having a technical publications project life cycle (pLC) that parallels an organization&apos;s product life cycle (PLC) greatly facilitates its adoption by engineering or development organizations. A technical publications project life cycle&#xD;relates major documentation project management&#xD;strategies, tasks, and deliverables to the same model used&#xD;by technical organizations to control product development&#xD;in an efficient and cost-effective manner. Some technical&#xD;organizations perceive the documentation development&#xD;process as being “intrusive” into the product development&#xD;process, particularly during the Implementation Phase of&#xD;the PLC. Communicating a technical publications pLC to&#xD;these organizations early in the PLC eliminates this&#xD;misperception.</description>
	</item>
	<item>
		<title>Using PERT to Plan and Schedule Your Documentation Projects</title>
		<link>http://tc.eserver.org/23026.html</link>
		<guid>http://tc.eserver.org/23026.html</guid>
		<description>Program Evaluation and Review Technique (PERT) is a proven project management tool that can be applied to documentation projects. PERT is used to identify: (a) the interrelationships between the various milestones of a project, and (b) the critical path of activities, the path more resources should be concentrated to complete the project on schedule. A PERT network is a graphical representation of the plan and schedule of the project. The technique is effective in non-repetitive documentation projects where project managers have an accurate assessment of their resources.</description>
	</item>
	<item>
		<title>Managing and Documenting Your Project, XML Style</title>
		<link>http://tc.eserver.org/22621.html</link>
		<guid>http://tc.eserver.org/22621.html</guid>
		<description>Here are links to the listings described in &lt;i&gt;Managing and Documenting Your Project XML Style.&lt;/i&gt;</description>
	</item>
	<item>
		<title>Meeting Crazy Deadlines</title>
		<link>http://tc.eserver.org/22602.html</link>
		<guid>http://tc.eserver.org/22602.html</guid>
		<description>We are all against bonded labour and slavery. I ask you: are software professionals (including technical writers), better off than slaves and bonded labourers?</description>
	</item>
	<item>
		<title>Estimating Scope and Schedule for a Help Project</title>
		<link>http://tc.eserver.org/21351.html</link>
		<guid>http://tc.eserver.org/21351.html</guid>
		<description>During this session, we will learn how to create a topic list to determine project scope,&#xD;and then we will begin to calculate how long&#xD;it will take produce all of these topics. When&#xD;we’re done, you will have a methodology for&#xD;doing this for your own project.</description>
	</item>
	<item>
		<title>A Guide for Software Project Managers - Planning User Documentation</title>
		<link>http://tc.eserver.org/20787.html</link>
		<guid>http://tc.eserver.org/20787.html</guid>
		<description>A Guide to the Project Management Body of Knowledge (PMBOK® Guide)–2000 Edition is the main sourcebook in the project management field. Whilst it covers Project Communications Management, it doesn&apos;t extend to user documentation.&#xD;&#xD;This article seeks to provide guidance for project managers as to how the user documentation process fits in with the overall project planning. It examines:&#xD;&#xD;the traditional way documentation is approached and how it impinges on project planning the effects of making changes to this traditional approach.</description>
	</item>
	<item>
		<title>Estimating Scope and Schedule for Help Projects</title>
		<link>http://tc.eserver.org/19785.html</link>
		<guid>http://tc.eserver.org/19785.html</guid>
		<description>Three steps to a more accurate Help schedule.</description>
	</item>
	<atom:link href="http://tc.eserver.org/dir/Articles/Project-Management/Documentation.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>