For many of us, particularly those supporting government contracts, the beginning of the new year means the start of new projects. It's the time to plan and prepare for documentation success! So, the buzzword for the new year is PREPAREDNESS. And, in our world of technical documentation, preparedness frequently equates to the timely completion of our milestones.

In earlier newsletters, we've discussed many ideas to help us with our documentation tasks, such as hiring the right people, soliciting feedback from our peers and customers, and developing a plan for completing our documents. We've even covered some important reasons for maintaining our project schedules. Well, now we're going to take a more microscopic view of the entire documentation process and break it down to a series of sub-tasks. We're going to develop a list of documentation milestones that WE can use to manage ourselves and our documentation team. And, following my approach for Y2K survival, we're going to be as prepared as our calculated and reasonable limits will allow. Here are the ideas we're going to discuss in this newsletter:

     1) A Milestones Refresher: What are they and are they worth the effort?

     2) Selecting Milestones for Each Task

     3) Linking Your Milestones: A Sample Project

A Milestones Refresher

A 'Milestone' is a point where the completion of a specific task and a particular calendar date coincide. For example, if we have a milestone to complete Chapter 1 of our user document by October 15th, then our milestone has been met if Chapter 1 is indeed completed on or before this date. If the job is not completed on or before that date, then we have missed a milestone. Simple enough!

Milestones are important and very likely necessary if you are organizing a project that will be adhering to a schedule. Should you be fortunate enough to be working under a configuration management (CM) plan, milestones will help keep the project moving smoothly. (This point alone makes them worth the effort.)

Milestones can take on an official or non-official status depending upon whom you tell about its existence. It becomes official once you've notified your customer or made a contractual promise to meet the milestone. An unofficial or internal milestone is one that you set for yourself to help YOU keep the schedule for the overall project. An unofficial milestone could be a reminder, a deadline, a status meeting, or a small that you must complete before you're able to complete the larger or parent task.

Milestones are commonly intermediate steps in the development progression that are used to evaluate and maintain the project's completion schedule. When used for evaluating the project's ongoing development, they can serve as a crystal ball in projecting a missed delivery date. In this case, meeting a milestone can have a great importance as its completion is a pre-requisite for starting work on the next one.

Selecting Milestones For Each Task

Selecting milestones for any type of project is done by identifying each major and minor step towards completion of the project and estimating the amount of time needed to complete each step. Identifying the steps that will lead towards a finished product can be accomplished by 1) understanding the task's objectives, 2) identifying the available resources, and 3) relying on prior experience with similar projects. The estimation of the hours-to- complete should be left to those that have prior experience with similar projects, know the abilities of the personnel, and have access to the budgetary constraints.

In the same manner that project milestones can be official or unofficial, documentation milestones can be made official by linking them to one of the project milestones. These should be considered the critical milestones as they will be visible to other project groups. Since you are no-doubt planning to complete your assigned documentation on-schedule, your milestones should be tied to the project schedule and its milestones.

You may recall that several opportunities for a design review can occur during the project lifecycle. These design reviews, as well as code reviews, project status meetings, customer reviews, and interim deliveries (See "Types of Deliveries" June 99) are all good project milestones to which you may want to link some of your milestones. Now that you are done identifying all of these highly visible milestones and know when they will occur, it is time to think about the not-so-visible milestones. These are the little documentation tasks that are so insignificant or near-trivial efforts, that you probably don't even think they deserve consideration.

Some of these little jobs might include reviewing an illustration, verifying your TOC, or ordering sufficient printer paper. Your ability to complete all of these little, and sometimes annoying tasks now become the gauge by which you stay on schedule. (I shudder to think what would happen should you discover a shortage of printer paper the night before delivery!)

Tying Your Milestones to the Project's Milestones

Now comes the meat of the matter, and doing it right is easier than many people think. It is time to create a "time-line" for everything you have to do to get your documents completed and delivered. The reason for creating the time-line is to help you visualize what you have to do and the schedule that your work must follow. The greatest benefit is that your peers, team members, and superiors all know what you are working on and how it is progressing. What a concept! Never again will you have to endure misunderstandings with your boss, omissions in your documents, or slipped schedules. (Ok, so what if I exaggerate a little.)

The concept is the same as "story-boarding" used in proposal development, thus a graphical representation of your time-line is usually most useful. If you can place your documentation time-line on the wall and be able to look at all of your milestones, you will have a stronger grasp on your pending tasks (not to mention greater inner peace.) Let's look at the example of ACME Software, who just happens to be developing a new (and hopefully fictional) application called NewWidget 1.0.

The project milestones that we are going to use for this example are pretty typical. We will leave out all but a few of the high-level milestones you would probably encounter on an actual project just to keep things simple. We'll select five project milestones to work with.

      1)Project kickoff

      2)Requirements Review

      3)Critical Design Review

      4)Perform Testing/QA

      5)Deliver to Customer

These are the milestones facing your boss and the development team. Your job is to now come up with a list of documentation milestones that you must meet to keep in step with the project. It is a simple matter of breaking down the large steps into much smaller ones. We will demonstrate this by stepping through each of NewWidget's project milestones, followed by a break-out listing of your documentation milestones that must be met. Let's start with the first big step: the Project Kickoff Meeting. We will abbreviate Project Milestone to "PM" and Documentation Milestone to "DM."

PM-1) The Project Kickoff. Date: January 3, 2000.

   DM-1.1) Obtain a copy of the Technical Proposal, Statement of Work (SOW), and any customer correspondence. Completion Date: December 20, 1999.

    DM-1.2) Read and make notes from the Tech Proposal, SOW, and other correspondence. Completion Date: December 24, 1999.

We've identified two "big" documentation efforts that should be completed BEFORE the project's kickoff meeting. Get the idea? (I told you this was easy.) Remember we are starting at a high level to identify the big tasks. The smaller tasks should be added later as your milestone map and time-line develop. Let's address the remaining four project milestones and identify our first-level documentation milestones for each.

PM-2) Requirements Review. Date: February 1, 2000.

   DM-2.1) Create a detailed requirements list addressing all documentation-related items. Completion Date: January 15, 2000.

   DM-2.2) Develop outlines for all documents required. Completion Date: January 30, 2000.

PM-3) Critical Design Review. Date: May 1, 2000.

   DM-3.1) Develop draft versions of all required end-user documents. Completion Date: April 1, 2000.

   DM-3.2) Develop outlines of all test-related documents. Completion Date: April 15, 2000.

   DM-3.3) Develop draft version of the test plan. Completion Date: April 30, 2000.

PM-4) Perform Testing/QA. Date: September 1, 2000.

   DM-4.1) Develop draft versions of all test-related documents. Completion Date: July 1, 2000.

   DM-4.2) Incorporate comments received from review of draft documents. Completion Date: July 20, 2000.

   DM-4.3) Develop final versions of all test-related documents. Completion Date: August 1, 2000.

   DM-4.4) Incorporate all corrections made from the "dry-run" of the test procedures. Re-submit test procedures document to test team for final verification. Completion Date: August 20, 2000.

PM-5) Deliver to Customer. Date: December 1, 2000.

   DM-5.1) Complete the final version of all user documents and conduct final validation on all user documents. Completion Date: November 15, 2000.

   DM-5.2) Compile all deliverable documents into required hardcopy and CD-ROM formats. Verify that number of copies for each are correct. Completion Date: November 22, 2000.

   DM-5.3) Prepare all documents for shipping/delivery. Submit document packages to shipping department. Completion Date: November 31, 2000.

As you can see, this can quickly evolve into a complete task list for your entire documentation effort. You should be able to create the next level of milestones for each of the first-level tasks and identify them as DM-1.1.1, DM-1.1.2, etc. You'll want to make your milestones as specific as possible so that you can assign each specific milestone to a member of your team. And, as each milestone is completed, it can be crossed out to show the world (i.e., your boss, customer, etc.) that you are working hard and on schedule.

Mapping out your milestones and checking them off one-by-one really is a simple and enjoyable process when performed properly and completely. (Just don't expect to have a social life!! - just kidding.) A solid budget, plenty of available time, and an executive staff that supports your efforts are certainly helpful to your success. However, you should always be willing to make adjustments and concessions where your manager deems it necessary.

In summary, you should identify and understand the project's milestones as received from your manager, identify the high-level documentation tasks that must be completed to satisfy the project schedule, and break down each documentation milestone to the smallest sub-task reasonable.

So, as you can see, managing a documentation effort can be very similar to managing the entire project. The difference lies in the details. The project manager knows very well that a milestone of "Project Delivery" can only be achieved by the successful execution and completion of hundreds or even thousands of very small sub-tasks. Engineering is defined as the solving of a problem through skillful or artful contrivance.

Guess what?! - You've just been given a problem!