What's the first thing that comes to mind when you think of deliveries? A 30-minute pizza? Absolutely, positively getting there overnight? Well, hold on to your pocket protectors! We are going to talk about document 'deliverables' and deliveries for technical documents.

All of us are aware that many versions of a document can exist, but not everyone knows why or how these versions are used. The experienced technical writers among us have certainly been involved in assembling a deliverable document, so a lot of these points will ring true. For the managers and project planners in our audience, the points we're about to discuss will help you to propose, plan, and budget your documentation projects. Here are the topics we're going to discuss in this newsletter:

• A word about document deliverables

• Which deliverables to develop and when to deliver them

• Making the best use of your deliverables

Let's remember that our ultimate objective is to provide our customer with documentation that meets their needs. So, who can tell us exactly what our customer needs? (Good guess, but The DocuDoctor should be your second choice.) Why, your customer, of course! And the document deliverable is the tool by which you can solicit his feedback.

A word about document deliverables

A document deliverable is a 'formal' release of a technical document that gets presented to your customer. It can be a document in a final form or representative of a "work in progress." It usually has a title of DRAFT, PRELIMINARY, or FINAL and almost always coincides with or is part of a contractually required submittal or delivery. "Making the delivery" is the actual process of relaying the document to the customer by FedEx, Email, Internet, or Sneakernet.

Document deliverables can be referred to as "versions" or "releases" and are often labeled with the version identifier of the system the document represents. For example, the user's manual for the Widget 2.4 system might be titled: Widget User's Manual DRAFT - Ver. 2.4a. Whatever title you select for your documents, make sure it makes sense and quickly identifies the document's subject matter.

Typically, the purpose of delivering a document's pre-final version to your customer is to solicit their comments, criticism, suggestions, and ideas for achieving documentation perfection in the next release. Whether your customer is the U.S. Government, the local software development house, the system's end-user, or your boss, you'll want to give them a document that reflects a solid, competent effort. The valuable comments or "red-lines" that your customer provides you will form the basis for the next version of your document. Keep in mind that some customers will be "steamed" if you elect to ignore their comments.

Let's take a look at some of the most typical document deliverables for technical documentation. Most of these follow common sense but let's restate them as a refresher:

So how do you know which deliverables to develop? Why would you even consider developing anything more than a FINAL? Let's take a look at the answers to these and other questions to consider when planning your documentation project.

Which deliverables to develop and when to deliver them

Before you decide to provide your customer with a particular assortment of documents and versions, be sure to weigh the pros and cons. You want to develop just the right number and types of deliverables to keep your customer happy, assist your development team, and limit the strain on your budget. Considerations like time, money, and the project's schedule, can all have a significant impact on your documentation plan.

As you select the deliverables that will fit your project, consider how much time it will take to develop each version of each document. Ask your tech writers or a Documentation Consultant about all the little "time drains" that can turn estimated minutes into expended hours. If you're delivering hardcopy documents, include time for unexpected disasters. A network crash, a copier meltdown, or an empty printer cartridge are just a few. Remember to have someone verify the document's hyperlinks, check the TOC, and double-check your cross-references. A document should always be read and re-read cover-to-cover before going to press. If you underestimate the time, to accomplish all this, you'll end up asking your writers, editors, and illustrators to work a long, unpaid weekend. Or worse, you'll find yourself pleading with your customer for extra time in your delivery schedule (usually frowned upon by particular customers).

Developing a documentation plan usually begins with determining the effort, followed by the calculation of costs. If you're working in reverse, then you need to select the document deliverables by how they fit your budget. Be careful! Never try to deliver more documentation than is reasonable. Tech writers need time to research, learn, and "experience" the system(s) they will be documenting. Pressuring writers to "knock out" too many document releases in too little time can result in documents that show minimal progress between versions or are riddled with errors. If you don't have the budgetary strength to properly develop many or several versions, then review the tasks to determine which versions you can effectively develop (and deliver), and forget the rest.

Making the best use of your deliverables

Most technical writers and their managers know that technical documentation can be an effective development aid to the engineers, developers, and programmers during the project's lifecycle. It can serve as a historical record and a "snapshot" of the system's development that can support the design review process. As such, it is very important and worthwhile to develop the documents concurrently with the developing system. One view of concurrent development could include the delivery of document versions on or near the completion of major project milestones. Examples of major milestones would be the completion of the first software build or the installation of the first subsystem.

Take a close look at your system's development schedule. Don't expend the energy to create another document release if only a minor change has been made to the system's GUI (graphical user interface). Give your customer the "warm fuzzies" that his money is not being spent destroying trees, one ream at a time. If almost nothing has changed with the system you're documenting, consider delivering "change pages" or "release notes." Don't waste your customer's time by making him search for that one new paragraph added to the second version of the document.

So, once again, experience (and common sense) prevails! By following these few simple rules of thumb for document deliveries: (1) giving your documentation team reasonable time and resources to do a proper job, (2) ensuring that every document your customer receives has your seal of pride and approval, and (3) delivering only documents with the meatiest content, you take yet another step towards happy, healthy documentation. Every great tech writer, editor, and illustrator knows that truly great technical documentation can only be created from a well-developed project schedule and budget.

Until next time ...may your documents be read and enjoyed by all!