Although the communication product is now published, your responsibilities to it continue. Some of these responsibilities pertain to "closing out" the project. Some pertain to tracking its impact on users and clients. And some of the responsibilities pertain to preparing for revisions.

Specifically, your ongoing responsibilities consist of the following:

Conduct a Post Mortem

Because people learn best by experience, one of the most significant activities you can conduct after completing a project is identifying the lessons learned on this project that you will carry forward to future projects. One of the most effective methods of identifying these lessons is a special meeting of the project team called the post-mortem.

A post-mortem is a meeting of all members of the project team at the end of the project with the purpose of:

• Identifying what went well and should be repeated on future projects
• What did not go well and how to avoid these situations on future projects

In addition, the post-mortem should provide time for everyone on the project team to thank one another for their contributions. Often during the course of a project, project team members become so comfortable working with one another that they do not thank them for their contributions or acknowledge exceptional work. As a result, team members might not realize that their contributions are appreciated by their colleagues. The post-mortem provides a formal opportunity for team members to offer one another such recognition.

Here are tips for conducting a post-mortem:

1. Send a meeting notice to team members at least 2 weeks in advance. Invite all team members to participate.
2. Prepare and distribute an agenda before the meeting. A typical agenda for a post-mortem:

• Is no longer than 90 minutes, 60 if possible.
• Contains separate items for:
1. What went right (at the end of a project, team members are often so focused on what went wrong that they want to understand what went right).
2. What to improve on future projects (do not use the post-mortem as a "blaming" session, instead, use the post-mortem as an opportunity to identify problems and suggest solutions to them)
3. Acknowledgements and thank yous

3. At the meeting, create a positive, productive environment by doing the following:

• Identifying a recorder. The recorder should prepare minutes, which will be distributed after the meeting.
• Setting the right tone for the meeting by:

• Emphasizing the positive
• Providing each team member with an opportunity to speak. For example, when asking "What went right" and "what to improve on future projects," rather than asking people to simply provide suggestions, go around the meeting table and ask each person to provide at least one suggestion before opening the question up to the floor for feedback
• Avoid passing judgment on comments. Different team members, because of their role or because of their personalities, have different experiences with a project. Some team members might have a positive experience, others may not. Only be hearing how each team member perceived the project can the entire project team better understand their interactions with one another.
• Closing with some sort of celebration. For example, you might provide a cake that says "Congratulations" or a small gift for each team member.
4. Send the minutes of the post-mortem within 2 business days.
5. For those suggestions that require changes to your organization’s policies and procedures, provide a follow-up memo to team members within 1 month of themeeting to tell them whether or not the policy and procedures will actually be changed.

Post-mortem meetings provide valuable closure to projects, letting participants emotionally separate from one project so they can move onto the next. Therefore, post-mortem meetings are beneficial whether or not members of the team will work together on their next project.

Top

Track Response to the Communication Product

After the communication product is in use, track responses to it. You receive these responses both formally and informally. Specifically, you might receive responses in these ways:

• Comment forms from users, sent by mail, fax, or electronic mail. When receiving comments, do the following:
1. On a master copy ofthe form, track quantitative responses. For example, when users provide an overall evaluation of the communication product, keep track of how many evaluated the communication product as a "5" and how many as a "4"so you can keep a main evaluation of the product.
2. Also track qualitative responses, such as the terms people use to respond to the question, "In a word, describe this online help." Especially track these responses to the question, "If you were to make one improvement to this communication product, it would be..." When several users offer the same suggestion, you probably should consider making it in a future edition.
3. For inaccuracies in the technical information or passages that need rewriting for clarification, mark the suggested changes on a hard copy of the published document. Mark the source of the changes (user comment) and date it. Put a paper clip on the affected page so you can easily locate it in the future. Mark these changes on the hard copy at this point because you might not be responsible for preparing the next edition of the communication product and you want to make sure that the suggested changes are implemented.
4. For comments requiring responses, make sure that you respond to readers within 5 business days of receiving the comment. You need not respond in writing; in fact, users appreciate a telephone call and the opportunity to speak directly with the author.

For record keeping purposes, maintain a log of your contact with clients. For example:

	User	When and How Contacted	Notes
	Jon Greaves	June 18, 1996 Phone E-mail Letter	Customer expressed appreciation of help file, wanted information on how to purchase programming reference.

• Feedback from co-workers and other people within the company. The feedback may come to you informally, as in casual conversations with others, and formally, through memos and corporate reports. Keep a log of these comments, both positive and negative and, if appropriate, mark suggested changes on the hard copy master of the communication product that will be used as a source of ideas for the next edition of the information. As with comments from users, mark the suggested changes on the hard copy, identify the source and state the date, then put a paper clip on the affected page.
• Feedback from industry sources, such as competitions and trade press. For example, an industry magazine might review your communication product separately or as part of a review of the product it supports. Similarly, you might submit your communication product to a competition sponsored by a professional organization like the Society for Technical Communication. Whether or not you receive an award, many professional organizations provide you with feedback on your entry.

Maintain a file with clippings from trade press, feedback on competition entries, and other types of industry feedback.

Top

Maintain Contact with Your Client

Although the project has ended, your relationship with the client should ideally continue. At the least, you should determine how your client felt about the process of working with you and whether the communication product that you produced has met the intended business goals. At the most, you would start future projects with the client.

To determine how your client felt about the process of working with you, first conduct your own assessment. Honestly answer the following questions:

• How well did I meet deadlines? How did the client react when I was early? Late?
• How well did I keep within the budget? If I did not keep within the budget, how did the client react?
• How closely did the final communication product match the one that was planned? What was the client’s role in determining changes? How did the client react to these changes?
• How closely did the final communication product meet the editorial, technical, and production guidelines set for it?
• How accurate is the final communication product?
• How does the client respond to you? Does the client greet you enthusiastically? Indifferently? Hostilely?
• What feedback have you directly received from the client?
• What feedback have you indirectly heard? Although you should not act on second-hand information like this (if the client did not directly tell you, the client does not want you to know). Instead, second-hand information provides you with a background on the situation so that you can gauge how openly and honestly the client is responding to you. Or, after speaking with the client, you may determine that the second hand information is not correct.

To determine how well the communication product is meeting its intended goals, you might be interested in the following information:

• Business measurements of bottom line impact. For example, if the bottom-line goal of an communication product is reducing the number of suppport line calls, then you would be interested in the change in the average number of calls per license for the first six months after the communication product is released. If the bottom-line goal is reaching a certain sales figure, you would be interested in seeing the sales figures for that period.
• Qualitative assessments of the communication product, from the client’s perspective. Business statistics do not persuade some clients; they like qualitative assessments. For such information, you would be interested in the reaction of the client have to the communication product.

Without the project to provide a reason for ongoing communication, maintaining contact at this point requires a special effort on your part. Here are some suggestions for maintaining contact with your client:

Thank You Letters

Immediately after a project is complete, send a thank you letter to a client, expressing your appreciation for their business and how you have personally gained from this project. Even if you have mixed feelings about the project, send a thank-you letter. It provides much needed closure and leaves everything on a positive note.

Following is an example of a thank you letter:

Post Mortem

If you feel comfortable doing so, invite your client to the post-mortem meeting with the project team. You might do so in cases where the client has worked closely with the team or when the client has good relations with the team.

Otherwise, you might conduct a private post-mortem with the client. You might ask your manager or project leader to join you in the post mortem if you would believe that having that person with you will enhance the quality of the information you receive.

In a post-mortem with a client, you ask the same types of questions that you would ask in a project post-mortem. The only difference is that the focus of the meeting is on the relationship between the client and you, rather than the relationships among members of the project team.

Informal Contact

Take advantage of opportunities to maintain contact with clients. Invite them to lunch. Send them copies of articles that might interest them. Call them occasionally just to "check-in."

During these informal exchanges, casually ask clients how well the communication product that you produced is meeting their needs. See if you can get current business information so that you can assess for yourself whether the communication product has met its bottom line impact.

For example, in a follow-up telephone call, one client casually mentioned that sales of a product for which I developed a training course were 4 times the expected level. The senior vice-president of the division attributed the success to the training course. The client also mentioned that he would need a revision of the course in a couple of months, providing a lead on future business.

Annual reports

Publish an annual report that tells clients (and potential clients) about the business results your orgnization has helped them achieve in the previous year. Generally, an entire technical communication department or firm might produce a single annual report for all of its clients, rather than separate reports for the clients of each technical communicator. Producing a consolidated report not consolidates the work, but also provides clients with a broader perspective on the capabilities of your organization. By familiarizing clients with the diversity of your department’s or company’s skills, clients might consider you for projects that they might have otherwise taken to other organizations.

Whenever you communicate with clients about completed projects, recognize that each client assesses completed projects in their own way. By identifying early in the project the type of data that the client uses to assess a completed project, you can provide them with the type of information that best meets their needs.

Top

Track Changes to the Technical Information

Technical information is living information. Like most other living beings, technical information grows and changes. If you have ongoing responsibility for maintaining the communication product, you need to keep track of these changes so that they can be communicated to users on a timely basis.

As you maintain ongoing communications with your clients, so you should maintain ongoing communications with your subject matter experts. Use these methods of communication:

• Post-mortems, through which you might ask SMEs about changes planned for the product
• Informal communications, during which SMEs might provide you with leads on upcoming changes and problems with themost recently released version of the information
• Changes to product specifications, other formal planning documents, revisions to applications for funding, and similar documents, through which the development team documents its intensions to change the technical information

When tracking ongoing changes, consider the following:

• "Fixes" or corrections to aspects of a product, policy, or information that do not work in the field as they were intended
• Enhancements, or other additions to, products, policies, and technical information

As you track suggested changes to the communication product from users and other sources, so you should track likely changes to the technical information. At the least, you should keep a log identifying the likely change and the parts of the communication product most likely to be affected. At the most, you might mark the suggested changes on a hard copy of the published document. As with other types of changes, mark the source of the changes (user comment), date it, and put a paper clip on the affected page so you can easily locate it in the future.

Top

Plan Revisions to the Communication Product

As the number of technical and suggested changes grows, the need to publish an updated version grows, too. As your last responsibility for an communication product, you need to determine when and how to publish the revisions.

1. Whenever you plan a revision, you first need to consider the scope of the revision: total revision, major, or partial. Unless users have a significant problem with the existing communication product, based your decision on the the extent of the revision on the amount of technical change to the product.
• Total revision involves completely rewriting the communication product. Consider a total revision in conjunction with a complete change to the look and feel of the product.
• Major revision, which involves the addition of new sections and the complete revision of some sections. Major revisions usually coincide with "major releases" of a product or policy, when the client introduces significant changes and additions. When making a major revision, you might alsomake editorial changes to parts of the communication product that could be made more usable, but would not completely rewrite it.
• Minor revision, which involves techical changes only. When planning a minor revision, you attempt to limit the work by only inserting changed information and correcting incorrect information.
2. After determining the scope of the revision, determine how you plan to distribute it. Following are distribution options for revising printed materials.

Option for Revision	Issues to Consider
"Change pages;" that is, only publish the pages that are affected by changes	Reduces the cost of revision and lets you publish revisions on a timely basis. Can only be used with information distributed in binders. Note that users rarely insert the changed pages into the binder. As a result, users might be working with incorrect or outdated information. This is an especially serious issue with price and parts lists; users might order parts that are no longer available or at prices that no longer apply.
Notices, in which you publish a brief memo listing information that should be changed. Users mark the changes in the communication product.	The most efficient and cost-effective means of producing a revision. If users are not likely to insert change pages into their manuals, they are even less likely to mark changes communicated through these notices.
New editions, in which you publish the entire communication product again	The most costly form of revision because it requires a complete reprinting. You might be able to reduce costs by limiting the number of pages revised and re-using the plates used to print the original edition. This assumes that you do not change the page numbers. Although the most costly version, also the most effective. Users will discard the old version and replace with the new. When you publish a new edition, you need to find some way of telling former users about the changes. One common method is publishing a section at the beginning of an communication product called "What’s New?" Another method is placing a marker by the new information saying "New!"

When choosing an option, consider both the cost and effectiveness of the proposed solution. For example, if you choose to publish revisions on changed pages but users do not insert the changed pages into their manuals, the cost of the resulting errors might be so high that the solution costs more your client than merely reprinting the entire communication product.

The manner in which you distribute online information often governs your ability to revise it.

How the Information Was Originally Distributed	Issues to Consider When Publishing a Revision
CD-ROM or diskette	Publish the information again and re-install it. If you are distributing the information within a single organization, you might be able to press a few CDs or diskettes and pass around among users to re-install. As with changed pages, useres may or may not install it. For commercial software, you would release a new version of the communication product. Users who want the latest version of the information would have to purchase the new software. Most organizations notify licensed users about these changes and offer them incentives to purchase the revised software (two good reasons why users should register their software)
Server	Technically, information on a server can be updated at any time. You might limit these revisions to a certain schedule, however, or you might be inundated with requests to publish unscheduled revisions and not have time to work on your scheduled projects.

3. With all changes to online information, you need some way of calling users’ attention to the new information. You might publish a special topic called "What’s New?" or you might place an icon near the new information indicating that the information is new or changed.
4. Last, set the schedule for publishing revisions. Try to limit the to scheduled dates. Scheduled revisions give clients an incentive to provide you with updated information in a timely maner and help you control your workload by including this work in your schedule. This is especially important for information distributed on a server. Clients and users feel that they can request changes at any time and expect you to make them available soon afterwards. But doing so interrupts your work on other projects.

Once you have established a plan for publishing the revisions, the actual process of preparing the revision begins a new information development cycle. That is, you return to Phase 1: Defining the Problem. As you review the definition, you will likely go through some of the steps more quickly because the revision has a smaller scope and because you are more familiar with the information now.

Top

Summary

Link to a check list of items to consider for the maintenance phase.

Top

Project Management | People Management | Business Management | Information Design Models, Processes, and Techniques | Home

(c) Copyright. 1999, 2000, 2001, 2002. Saul Carliner. All rights reserved.