<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Articles&gt;Documentation&gt;Management</title>	<link>http://tc.eserver.org/dir/Articles/Documentation/Management</link>
	<description>A listing of the most recently indexed works about Articles and Documentation and Management 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;Documentation&gt;Management</title>
		<link>http://tc.eserver.org/dir/Articles/Documentation/Management</link>
	</image>
	<item>
		<title>What Information Developers Can Learn from Software Developers</title>
		<link>http://tc.eserver.org/35677.html</link>
		<guid>http://tc.eserver.org/35677.html</guid>
		<description>The shift in information development from a narrative to a modular writing style reflects the established shift towards modularization of source code. What can information developers learn from software developers? What are the challenges and benefits of the modular approach? </description>
	</item>
	<item>
		<title>Documentation Collaboration Service</title>
		<link>http://tc.eserver.org/35617.html</link>
		<guid>http://tc.eserver.org/35617.html</guid>
		<description>Collaboration happens when multiple people work simultaneously towards a common goal. Collaboration software are tools which try to make working together easier and more productive.&#xD;&#xD;There are hundreds of methodologies and approaches out there to collaboration. We want to bring the focus on one particular dimension: open vs. structured collaboration.</description>
	</item>
	<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>A Few Surprises in Using a Wiki for Documentation</title>
		<link>http://tc.eserver.org/35438.html</link>
		<guid>http://tc.eserver.org/35438.html</guid>
		<description>Recently I’ve been working on a simple calendar project that uses a wiki for documentation. Although I’ve heard a lot about using wikis for documentation, and have even used them in the past, I ran into a few surprises this time.</description>
	</item>
	<item>
		<title>Did Technical Documentation Play a Role in the White House&apos;s Decision to Move to Drupal?</title>
		<link>http://tc.eserver.org/35423.html</link>
		<guid>http://tc.eserver.org/35423.html</guid>
		<description>The reasons for the White House&apos;s decision to run its Web site, whitehouse.gov, on the open source content management system Drupal are being discussed on various Web sites. Alongside Drupal&apos;s functionality, flexibility and openness, some are suggesting that Drupal&apos;s documentation was also a key factor for deciding to use this system.</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>Wiki as Forum, FAQ, HTML Editor, XML Editor, or CMS?</title>
		<link>http://tc.eserver.org/35403.html</link>
		<guid>http://tc.eserver.org/35403.html</guid>
		<description>A wiki can be a Frequently Asked Questions repository, much like the knowledge bases in their heyday in the late 80s. My favorite line from the blog entry has to be its closer: &apos;It&apos;s about a different way of thinking around how to interact with the community.&apos; And that is what I have explored with my wiki presentation, about how to build community with a wiki and be an active member of that community. But what are other uses of the wiki?</description>
	</item>
	<item>
		<title>Getting Content Into and Out of Wikis</title>
		<link>http://tc.eserver.org/35154.html</link>
		<guid>http://tc.eserver.org/35154.html</guid>
		<description>As wikis mature, we’re using them for more complex business cases such as technical documentation, business analysis and project management. It’s becoming more and more interesting, if not essential, for wikis to support the import and export of content to and from other formats. Most wikis allow you to convert their pages at least to PDF and HTML. But what of other formats, and what about tools for getting content into wikis as well as out of them?</description>
	</item>
	<item>
		<title>Authoring with Eclipse</title>
		<link>http://tc.eserver.org/35047.html</link>
		<guid>http://tc.eserver.org/35047.html</guid>
		<description> The topic of technical publishing is relatively new to the world of Eclipse. One can make the argument that technical publishing is just another collaborative development process involving several people with different backgrounds and skills. This article will show that the Eclipse platform is a viable platform for technical publishing by discussing how to write documents such as an article or a book within Eclipse. In fact, this article was written using Eclipse. </description>
	</item>
	<item>
		<title>Community and Documentation</title>
		<link>http://tc.eserver.org/35027.html</link>
		<guid>http://tc.eserver.org/35027.html</guid>
		<description>This chapter explores the idea that a small group of people who have a sense of belonging in an online community may provide content much like a technical writer does. Regardless of their background, education, or training, more people are becoming providers of technical information on the web.</description>
	</item>
	<item>
		<title>Care to Write Army Doctrine? With ID, Log On</title>
		<link>http://tc.eserver.org/35025.html</link>
		<guid>http://tc.eserver.org/35025.html</guid>
		<description>In July, in a sharp break from tradition, the Army began encouraging its personnel — from the privates to the generals — to go online and collaboratively rewrite seven of the field manuals that give instructions on all aspects of Army life.&#xD;&#xD;The program uses the same software behind the online encyclopedia Wikipedia and could potentially lead to hundreds of Army guides being “wikified.” The goal, say the officers behind the effort, is to tap more experience and advice from battle-tested soldiers rather than relying on the specialists within the Army’s array of colleges and research centers who have traditionally written the manuals.</description>
	</item>
	<item>
		<title>Producing Documentation and Reusing Information in XML, Part 1: Document Publishing Using XML</title>
		<link>http://tc.eserver.org/35017.html</link>
		<guid>http://tc.eserver.org/35017.html</guid>
		<description>XML provides a way to identify data items and subcomponents within any structured data set, but has its roots in documentation development and production. Robust, open standards for XML document markup and a rich set of freely available tools for XML document parsing and format conversion make it easy to install and configure a complete documentation development and formatting environment on any UNIX® or Linux® system.</description>
	</item>
	<item>
		<title>Producing Documentation and Reusing Information in XML, Part 2: Reuse Information in XML Documentation</title>
		<link>http://tc.eserver.org/35018.html</link>
		<guid>http://tc.eserver.org/35018.html</guid>
		<description>Discover simple solutions to reuse information in XML documentation, such as how to use XInclude to include other documents at a given point in a document and how to use XPointer to include small document fragments from other documents or a similar pool of information in XML format. Also, get tips for structuring XML documentation to simplify information reuse, and learn how to maintain stand-alone documents that you can incorporate into larger documents.</description>
	</item>
	<item>
		<title>Pick a Card</title>
		<link>http://tc.eserver.org/34704.html</link>
		<guid>http://tc.eserver.org/34704.html</guid>
		<description>There are obvious benefits to single sourcing, the ones that roll off the tongue the minute single source is mentioned: multi-format publishing, consistency of information, quicker updates of common content, lowering translation costs and so on. But beyond all those, what else is there? In this guest blog post, Gordon McLean discusses just that.</description>
	</item>
	<item>
		<title>Firefox’s Revolutionary Community Approach to Customer Support</title>
		<link>http://tc.eserver.org/34557.html</link>
		<guid>http://tc.eserver.org/34557.html</guid>
		<description>The Firefox Support Knowledge Base is a collaborative work of dozens of contributors, the Support Forum is bustling with people answering questions, and Live Chat is manned by dedicated team of community members.</description>
	</item>
	<item>
		<title>The Medium is the Delivery Method</title>
		<link>http://tc.eserver.org/34549.html</link>
		<guid>http://tc.eserver.org/34549.html</guid>
		<description>A question that technical communicators frequently ask about wikis is &quot;How do I get the documentation out of a wiki?&quot; A simple answer: &quot;Don’t worry about it.&quot; Because the wiki is the delivery method.</description>
	</item>
	<item>
		<title>Daisy: WYSIWYG Wiki for PDF Books</title>
		<link>http://tc.eserver.org/34492.html</link>
		<guid>http://tc.eserver.org/34492.html</guid>
		<description>If you need the collaborative aspects of a Wiki combined with DITA&apos;s modular topics and publishing capabilities, then DAISY might just be the system you need--and it&apos;s free. DAISY provides WYSIWYG editing for Wiki pages that can be combined to publish books, either in a PDF or as a single HTML page.</description>
	</item>
	<item>
		<title>Architecting User Assistance Topics for Reuse: Case Examples in DITA</title>
		<link>http://tc.eserver.org/34468.html</link>
		<guid>http://tc.eserver.org/34468.html</guid>
		<description>In this column, I’ll review what user assistance architects mean by reuse and what its benefits can be. I’ll then describe some different scenarios for reuse and offer guidelines that user assistance architects and information developers can follow. My examples show how DITA (Darwin Information Typing Architecture) can be an effective reuse framework. But the principles I discuss go beyond DITA, and you can apply them to any structured information framework or toolset.</description>
	</item>
	<item>
		<title>Wiki-fying Docs: Is Using Customer-Accessible Wikis for End-User Documentation Gaining Momentum?</title>
		<link>http://tc.eserver.org/34417.html</link>
		<guid>http://tc.eserver.org/34417.html</guid>
		<description>While the effort to provide more interactivity and power to the end-user seems to suggest that we open up a wiki to allow them to add and edit content, the basic idea of a set of edited documentation is now challenged with a social network of participating customers, all of whom may now edit, add, and delete content. How social can you go? This article is an attempt to look at the process of evaluating the use of a wiki for end-user documentation, if such a thing can exist. Are the two types of customer content — wikis and end-user documentation — mutually exclusive?</description>
	</item>
	<item>
		<title>The Many Faces of Content Management: A Primer</title>
		<link>http://tc.eserver.org/34411.html</link>
		<guid>http://tc.eserver.org/34411.html</guid>
		<description>None of the technologies mentioned so far support the production of content for purposes of producing technical documentation. Such a system is a specific type of content management that has specialized functions for technical communicators doing multi-channel publishing, yet it hasn&apos;t spun off its own specific acronym. </description>
	</item>
	<item>
		<title>Editing Modular Documentation: Some Best Practices</title>
		<link>http://tc.eserver.org/34350.html</link>
		<guid>http://tc.eserver.org/34350.html</guid>
		<description>The authors have come up with eight guidelines and three concrete suggestions on best practices for editing modular documentation, including ensuring that all topics are standalone, that titles are unique and descriptive, and more.</description>
	</item>
	<item>
		<title>Hey Rocky – Watch Me Pull a CMS Out of My HAT</title>
		<link>http://tc.eserver.org/34351.html</link>
		<guid>http://tc.eserver.org/34351.html</guid>
		<description>When companies decide whether or not to adopt a CMS or continue using a HAT, there are many factors to consider. Perlin outlines elements of both CMSs and HATs that could help you determine which is best for your organization.</description>
	</item>
	<item>
		<title>Authoring Eclipse Help Using DITA</title>
		<link>http://tc.eserver.org/34274.html</link>
		<guid>http://tc.eserver.org/34274.html</guid>
		<description>This page contains information about how to use DITA for authoring Eclipse Help.</description>
	</item>
	<item>
		<title>Advantages of Using Microsoft SourceSafe While Writing Your Technical Documents</title>
		<link>http://tc.eserver.org/34032.html</link>
		<guid>http://tc.eserver.org/34032.html</guid>
		<description>Microsoft’s Visual SourceSafe was not created with technical communicators in mind. It was created for engineers writing software source code. But it is successfully used by technical writers in offices around the world to control documentation.</description>
	</item>
	<item>
		<title>Web 2.0, Wikis, and Books</title>
		<link>http://tc.eserver.org/33645.html</link>
		<guid>http://tc.eserver.org/33645.html</guid>
		<description>The founder of FLOSS manuals discusses the intersection of books and Web 2.0 and the continuing evolution of publishing and technology.</description>
	</item>
	<item>
		<title>Consolidating Content Delivers More with Less</title>
		<link>http://tc.eserver.org/33636.html</link>
		<guid>http://tc.eserver.org/33636.html</guid>
		<description>Software products have found ways to share content and reuse content to deliver more value with limited resources. For example, fantasy football web sites share player news, injury reports, and game statistics. Security products often reuse security announcements and warnings from trusted sources, and present them as rebranded content. We are also seeing software vendors using Twitter and RSS feeds to distribute information and announcements. The next step is when these information feeds are integrated into the product user interface itself, making it the one stop resource for all the information needs of its users. No more need to use google when your product itself delivers the answers to all your questions from the sources you trust.</description>
	</item>
	<item>
		<title>It&apos;s In The Mix: The Next Generation Of Open Source Publishing</title>
		<link>http://tc.eserver.org/32680.html</link>
		<guid>http://tc.eserver.org/32680.html</guid>
		<description>The same principles behind music remixing are at the heart of a hugely important open source software documentation experiment, taking place on the web today. It’s called FLOSS Manuals, a content remixing project that provides its website visitors with the ability to read, write and remix documentation.</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>Proving Worth: What Technical Communication Managers Must Do to Prove the Value of Their Deliverables</title>
		<link>http://tc.eserver.org/32192.html</link>
		<guid>http://tc.eserver.org/32192.html</guid>
		<description>If the documentation is not being used and used effectively, it will never help the bottom line. The trick to increasing value with internal and external users is to identify areas where documentation can save time and money, to create agreement that the documentation can save time and money, and to ensure that the documentation does save time and money.</description>
	</item>
	<item>
		<title>Raising Your Documentation Team&apos;s Visibility</title>
		<link>http://tc.eserver.org/32212.html</link>
		<guid>http://tc.eserver.org/32212.html</guid>
		<description>Whether the documentation department has a staff of one or a team of 12, visibility within the company is a frequent concern. The reasons for this concern range from personal to professional. You want to be remembered when promotions and bonuses are handed out. You want new challenges to add diversity to your workload, and new projects to add skills to your resume. You want to defend your turf against budget cuts and layoffs during lean economic times. And you want to be more than an afterthought that lives in the back 40 of the cubicle farm.</description>
	</item>
	<item>
		<title>Five Questions to Ask Yourself While Creating a New Documentation Department</title>
		<link>http://tc.eserver.org/32217.html</link>
		<guid>http://tc.eserver.org/32217.html</guid>
		<description>You&apos;re the manager of your company’s emerging documentation department -- and your work has just begun. To create effective documentation for your customers, you not only have to build a sound team, but also build working relationships with all other departments in your company.</description>
	</item>
	<item>
		<title>How to Market a Documentation Department</title>
		<link>http://tc.eserver.org/32221.html</link>
		<guid>http://tc.eserver.org/32221.html</guid>
		<description>When you first ventured into the tech writing ranks, marketing the department was likely the furthest thing from your mind. You already had work to do, so marketing was somebody else’s job.</description>
	</item>
	<item>
		<title>Behind the Scenes: Marketing Documentation Services through Leadership</title>
		<link>http://tc.eserver.org/32222.html</link>
		<guid>http://tc.eserver.org/32222.html</guid>
		<description>When you think of marketing, do press releases, brochures, presentations, direct mail, and web sites come to mind? Those pieces are certainly parts of the puzzle.But a lot must go on behind the curtain to make those on-stage pieces worthwhile. These often hidden goings-on are the leadership techniques of a successful documentation manager. The result is a documentation department that warrants the effort expended on marketing. After all, marketing succeeds only if services are reliable, communication channels are open, and products meet expectations.</description>
	</item>
	<item>
		<title>Getting FLOSSy: Acrobat Killer Or HAT Replacement?</title>
		<link>http://tc.eserver.org/32146.html</link>
		<guid>http://tc.eserver.org/32146.html</guid>
		<description>Some writers truly hate Adobe Acrobat and any tool that can do the job better is worth a shot, particularly if it’s open source and easily navigated. Flossmanuals.net introduces FLOSS which does a lot of the single desktop Acrobat Pro’s job - collaboratively and open source.</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>Managing SMEs - Part 1: A Primer for Success</title>
		<link>http://tc.eserver.org/31719.html</link>
		<guid>http://tc.eserver.org/31719.html</guid>
		<description>Just the thought of dealing with Subject Matter Experts (SMEs) can create stress in the life of any documentation manager. Philip Rastocny provides in-depth insight on how best to deal with SMEs.</description>
	</item>
	<item>
		<title>The Why and How of Content Convergence and Integration</title>
		<link>http://tc.eserver.org/31729.html</link>
		<guid>http://tc.eserver.org/31729.html</guid>
		<description>Content producers are about to live through interesting times, to adapt the popular saying, with the dawning of The Age of Content. Industry is discovering content as a commodity; the rules are changing, and fast. What have traditionally been seen as the lowliest form of commercial content within an enterprise, technical manuals, are starting to take their place alongside the other valued corporate assets.</description>
	</item>
	<item>
		<title>The Return on Investment of Documentation and Support</title>
		<link>http://tc.eserver.org/31145.html</link>
		<guid>http://tc.eserver.org/31145.html</guid>
		<description>The benefits of user documentation (reduced support calls, increase in the perceived value of the product, happier customers, better customer retention, increase product usage etc) can be identified, but it can be hard to measure them and accurately quantify the Return on Investment.</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>Moving Legacy Documentation into DITA: An Interview</title>
		<link>http://tc.eserver.org/30799.html</link>
		<guid>http://tc.eserver.org/30799.html</guid>
		<description>JoAnn Hackos, content management and information design expert, gives her best advice on what organizations need to know about moving legacy documentation to DITA.</description>
	</item>
	<item>
		<title>The New World of Product Labeling: Alternative Architectures and Approaches</title>
		<link>http://tc.eserver.org/30798.html</link>
		<guid>http://tc.eserver.org/30798.html</guid>
		<description>A discussion of the shift to structured content in pharmaceutical product labeling, which builds upon SPL and PIM regulations and the fundamental concepts of enterprise content management.</description>
	</item>
	<item>
		<title>Structured Document Processors: Customizing Software to Control Document Development Processes</title>
		<link>http://tc.eserver.org/30583.html</link>
		<guid>http://tc.eserver.org/30583.html</guid>
		<description>Structured document processors (SDPS) enable companies to make document production more efficient and accurate, while improving reliability of documents that must be updated frequently or written to very strict format standards. Achieving these goals requires elaborate and highly technical customization of the SDP. This paper emphasizes the importance of collaboration in customizing SDPS to particular document development processes. Three case histories illustrate the spectrum of ways industry is using SDPS for writing, showing three different approaches to customizing SDPS.</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 Documentation Projects in an International Environment: The Supervisor&apos;s Role</title>
		<link>http://tc.eserver.org/30518.html</link>
		<guid>http://tc.eserver.org/30518.html</guid>
		<description>The technical publications department of a major corporation is always a complex environment. When this environment also involves dealing with the issues of an international company and almost daily interaction with international counterparts, the opportunities and challenges are greatly increased. Joining a large-scale, ongoing publications project under these conditions requires quick learning and the rapid acquisition of new skills. For a project of this type to succeed, a supervisor must successfully solve a unique set of problems and is rewarded with enhanced opportunities for growth and professional development.</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>Is a Documentation Wiki in your Future?</title>
		<link>http://tc.eserver.org/29554.html</link>
		<guid>http://tc.eserver.org/29554.html</guid>
		<description>If we can solicit user participation in a Web 2.0 knowledge community (a volunter wiki documentation, for example), we might have a powerful means for creating high quality content. But how should this process work?</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>A Case of Exhaustive Documentation: Re-centering System-oriented Organizations Around User Need</title>
		<link>http://tc.eserver.org/28553.html</link>
		<guid>http://tc.eserver.org/28553.html</guid>
		<description>Braun Corporation&apos;s home-grown documentation processes served the organization well for its first 50 years as it grew from a local to a nationally-competitive producer of mobility and accessibility products. Now poised to become a global leader in its field, this corporation found its efforts hampered by ineffective and outdated documentation practices, which were hurting the company&apos;s competitive advantage. This article describes Braun Corporation&apos;s curious mixture of global reach and local isolation. By bringing in a technical communicator with expertise in user-centered design, Braun has begun reforming its formerly exhaustive documentation and communication practices.&#xD;&#xD;While technical communicators have incorporated a variety of strategies to develop user-centered and task-based documentation, less attention has been placed on changing the cultures of these organizations. The case presented here represents a shift from establishing documentation procedures to critically assessing and reforming existing procedures for the global workplace, describing the shift from ineffective and exhaustive processes to effective processes with defined goals and measurable outcomes. The article concludes with an inventory for determining whether other organizations are over-documenting processes and products, and offers suggestions for creating better documentation procedures.</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>Meaningful Microcontent</title>
		<link>http://tc.eserver.org/27593.html</link>
		<guid>http://tc.eserver.org/27593.html</guid>
		<description>Microcontent refers to small, granular, and possibly representative (that can provide a summary of or a navigation to a larger set of information) bits of information, typically available on the Web. An example in the domain of journalism might be headlines and news summaries, small bits of content that can be used on a front page of the news with links to more in-depth articles. The definition has grown in scope as much as in its application.</description>
	</item>
	<item>
		<title>Enterprise Agility: SOX and Enterprise Information Integration</title>
		<link>http://tc.eserver.org/26733.html</link>
		<guid>http://tc.eserver.org/26733.html</guid>
		<description>The intent of Sarbanes-Oxley (SOX) can be characterized as risk reduction: reduce errors, inhibit fraud, and provide shareholders with transparent equal-access to material knowledge. But implementation is principally procedural controls and documentation, under threat of penalty. The vague parts of SOX are where the real leverage lies: principles of intent, and corporate transparency.</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>An Overview of Single Sourcing with an XML Content Management System</title>
		<link>http://tc.eserver.org/25378.html</link>
		<guid>http://tc.eserver.org/25378.html</guid>
		<description>Creating an XML-based Content Management System to single-source technical publications is as simple as 1 - 2 - 3. OK, maybe it isn&apos;t quite that easy, but this article discusses how it can be done.</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>Implementing a Document Control System</title>
		<link>http://tc.eserver.org/24700.html</link>
		<guid>http://tc.eserver.org/24700.html</guid>
		<description>Document control is a major component of any quality system. To implement a document control system, first establish Policies/procedures for generating, approving, issuing, and revising documents. The next step is to design and implement forms and a filing system/data base for managing quality documents. Teamwork and established guidelines can help ease the complexities of implementing a document control system.</description>
	</item>
	<item>
		<title>Sarbanes-Oxley and Financial Accountability</title>
		<link>http://tc.eserver.org/24661.html</link>
		<guid>http://tc.eserver.org/24661.html</guid>
		<description>In the financial documentation realm, there are so many new buzz words, but they all boil down to the documentation equivalent of bean counting.</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>A Case Study in Developing Dynamic Content at Ontario Systems</title>
		<link>http://tc.eserver.org/23634.html</link>
		<guid>http://tc.eserver.org/23634.html</guid>
		<description>Charles Cantrell, an Information Engineer, describes Ontario Systems&apos; process for delivering dynamically assembled and populated documentation for Artiva, its &apos;highly customizable&apos; accounts receivable management application.</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>What Do We Manage? A Survey of the Management Portfolios of Large Technical Communication Groups</title>
		<link>http://tc.eserver.org/22170.html</link>
		<guid>http://tc.eserver.org/22170.html</guid>
		<description>Finds that user&apos;s guides, reference manuals, and help account for most products, and about half are print. Reports that no widely used method or metric of assessing effectiveness exists</description>
	</item>
	<item>
		<title>Customizing the Appearance of Your Manual, Help System, and HTML Help System</title>
		<link>http://tc.eserver.org/21474.html</link>
		<guid>http://tc.eserver.org/21474.html</guid>
		<description>Doc-To-Help gives Help authors complete control over the look, feel, and content of a project&apos;s printed manual, Windows Help system, HTML files, and HTML Help system. Maintaining different content is controlled using Doc-To-Help&apos;s conditional text feature, which allows authors to mark content for print-only, online-only, WinHelp-only, and so on. In this article we discuss how you control the appearance of the printed manuals and Help using Word templates, and HTML output using cascading style.</description>
	</item>
	<item>
		<title>Relative Costs of Paper and Online Documentation</title>
		<link>http://tc.eserver.org/21388.html</link>
		<guid>http://tc.eserver.org/21388.html</guid>
		<description>This article compares the costs of development, production and maintenance for paper and online documentation.</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>We Neurotic Amateurs: A Commentary on Edmond H. Weiss&apos;s &quot;Egoless Writing: Improving Quality by Replacing Artistic Impulse with Engineering Discipline&quot;</title>
		<link>http://tc.eserver.org/20349.html</link>
		<guid>http://tc.eserver.org/20349.html</guid>
		<description>The assertion that technical communicators tend to be &apos;amateurs&apos;--that is, lovers of our own work--is a claim with little foundation. Arguments toward regimentation and systematization of documentation writing are not calls to professionalize a currently-immature field, but rather attempts to emulate the hierarchy we have seen implemented in microprocessor engineering in the 1970s, software development in the 1980s, and content management in the 1990s. Such &apos;egoless&apos; methods may offer advantages to employers, but should not necessarily be considered &apos;progress.&apos;</description>
	</item>
	<item>
		<title>Going Online: A Case Study in the Development and Implementation of Netscape NetHelp</title>
		<link>http://tc.eserver.org/20332.html</link>
		<guid>http://tc.eserver.org/20332.html</guid>
		<description>Computerized Medical Systems, Inc. (CMS) - the worldâ*™s leading radiation therapy planning (RTP) company with over 1000 installed RTP systems and over 400 installed dosimetry systems - decided in late 1996 to move existing FOCUS documentation online. Reasons for this&#xD;included: the existing documentation set perceived as too&#xD;difficult to use; increasing printing cost; and customer&#xD;feedback. Using Netscape NetHelp as a basis, the CMS documentation staff reduced printed documentation size by two-thirds while making the information more&#xD;accessible. Reactions to FOCUSHelp have been highly&#xD;favorable. Future plans include migrating to the&#xD;NetHelp2 framework and reducing topic lengths.</description>
	</item>
	<item>
		<title>TQM Case Study: Time-Cost-Productivity Improvements for a Documentation Department</title>
		<link>http://tc.eserver.org/19878.html</link>
		<guid>http://tc.eserver.org/19878.html</guid>
		<description>This data- and process-driven presentation describes how Total Quality Management (TQM) saved a company $2-to-$3 million in printing costs over a four-year period, reduced cycle time by fifty percent, and increased productivity three hundred percent.</description>
	</item>
	<item>
		<title>Planning for Factors That Affect Project Cost</title>
		<link>http://tc.eserver.org/19834.html</link>
		<guid>http://tc.eserver.org/19834.html</guid>
		<description>Documentation projects often change to respond to changes or obstacles in the system development process. Sometimes, these changes increase project costs. However, as corporate budgets tighten, project managers are frequently asked to work within their original&#xD;estimates despite the changes. To minimize these&#xD;situations, project managers need to identify the factors&#xD;that can increase the costs of a project, evaluate the&#xD;chances of problems arising, and adapt the work plan&#xD;and estimate to anticipate the problems that are outside&#xD;of their control.</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>
	<item>
		<title>Information Planning for Successful Online Documentation</title>
		<link>http://tc.eserver.org/19781.html</link>
		<guid>http://tc.eserver.org/19781.html</guid>
		<description>Creating an information plan should be the first phase of any publication development life cycle,&#xD;whether hard copy or online. The plan is a tool for&#xD;reporting the results of your research about your&#xD;audience, their tasks, the market, and the product.&#xD;The plan presents the basic organization and content&#xD;of the publications you intend to build, effectively&#xD;directing the documentation team to produce a publication&#xD;with very specific goals in mind.</description>
	</item>
	<item>
		<title>Restructuring Your User Information</title>
		<link>http://tc.eserver.org/19383.html</link>
		<guid>http://tc.eserver.org/19383.html</guid>
		<description>Details a process for improving the usability, consistency, and organization of user information within businesses that maintain medium to large documentation libraries.</description>
	</item>
	<item>
		<title>Egoless Writing: Improving Quality by Replacing Artistic Impulse With Engineering Discipline</title>
		<link>http://tc.eserver.org/15086.html</link>
		<guid>http://tc.eserver.org/15086.html</guid>
		<description>When technical communicators have a strong personal attachment to the publication they are preparing, this attachment may interfere with the design and testing of the publication itself. Documents developed by solo authors tend to be late, buggy, and exceedingly difficult for others to maintain. &apos;Ego-less&apos; methods---collaborative and structured---break the proprietary connection between the writer and the book; in so doing they permit the most powerful tools of engineering and testing to be used. But they also reduce the satisfactions of the communicator&apos;s job.</description>
	</item>
	<item>
		<title>Quality Time: How Good Documentation Cuts Development Costs</title>
		<link>http://tc.eserver.org/15178.html</link>
		<guid>http://tc.eserver.org/15178.html</guid>
		<description>Discusses several ways project managers can control the sometimes-chaotic process of documentation development.</description>
	</item>
	<atom:link href="http://tc.eserver.org/dir/Articles/Documentation/Management.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>