Importance of a Release Checklist
For all those release-time-pressure-cooker situations, the importance of a release checklist cannot be stated enough.
Why a release checklist?
As any tech writer can vouch for - release times are tough times with reviewers breathing down your back, your tool putting its hands behind its head and smirking at you with a "gotcha" smile, the only savior I can think of is a release checklist. And all that it takes to keep minor goof-ups out of your way are a few checks on a list.
There is nothing to gain by crying over spilled milk, and nothing to gain by staring with remorse and self-pity at a published document that probably has fallen into customer hands. By the way, I have found that documents with mistakes land faster into hands they should not, and also are definitely read even if none of the previous 1000 manuals that you have written have ever been opened by anyone except the QAs and the Product Manager. Murphy's law in full force.
What if my team does not follow it as a process?
Even if you do not follow the ritual of a release checklist as a matter of process in your team, it is worth the while to use it as a self-discipline tool.
If you wish to use a release checklist as a self-discipline activity, do it yourself, or request a peer to do it for you if they have the time. Should not take more than 10 minutes.
If you wish to use the release checklist as a part of your formal workflow but you don't have a dedicated editor, assign the responsibility to anybody on the team, or you could take it up as the manager. A rule then gets set in the team that no document is released without the release checklist being signed off by the appointed person. And to say the least, much blood and gore gets saved and blame-games do not mar the performance of your team.
What should a release checklist contain?
Remember that it is a final check before the document goes out the door! So keep it straight, simple, and relevant.
Make a list of what has gone wrong in your and other people's projects at the last minute. Anticipate, from your experience as a writer and or manager, what can possibly go wrong.
How to approach the making of a checklist?
Keep a few simple things in mind before you start the process of making a checklist.
Remember that a checklist should be:
For all those release-time-pressure-cooker situations, the importance of a release checklist cannot be stated enough.
Why a release checklist?
As any tech writer can vouch for - release times are tough times with reviewers breathing down your back, your tool putting its hands behind its head and smirking at you with a "gotcha" smile, the only savior I can think of is a release checklist. And all that it takes to keep minor goof-ups out of your way are a few checks on a list.
There is nothing to gain by crying over spilled milk, and nothing to gain by staring with remorse and self-pity at a published document that probably has fallen into customer hands. By the way, I have found that documents with mistakes land faster into hands they should not, and also are definitely read even if none of the previous 1000 manuals that you have written have ever been opened by anyone except the QAs and the Product Manager. Murphy's law in full force.
What if my team does not follow it as a process?
Even if you do not follow the ritual of a release checklist as a matter of process in your team, it is worth the while to use it as a self-discipline tool.
If you wish to use a release checklist as a self-discipline activity, do it yourself, or request a peer to do it for you if they have the time. Should not take more than 10 minutes.
If you wish to use the release checklist as a part of your formal workflow but you don't have a dedicated editor, assign the responsibility to anybody on the team, or you could take it up as the manager. A rule then gets set in the team that no document is released without the release checklist being signed off by the appointed person. And to say the least, much blood and gore gets saved and blame-games do not mar the performance of your team.
What should a release checklist contain?
Remember that it is a final check before the document goes out the door! So keep it straight, simple, and relevant.
Make a list of what has gone wrong in your and other people's projects at the last minute. Anticipate, from your experience as a writer and or manager, what can possibly go wrong.
How to approach the making of a checklist?
Keep a few simple things in mind before you start the process of making a checklist.
Remember that a checklist should be:
- Easy, simple, and quick to complete, or you will end up wanting to make a checklist to manage the checklist!
- Easy to access such that everyone and anyone can access the checklist at all times.
- Easy to update so that you can quickly add or delete items from the checklist at any time.
- Given enough time to evolve because a good, robust, and useful checklist is not an overnight effort.
- A living document that reflects the needs and changes that your documentation and writers undergo over time.
How to come up with a release checklist?
Based on my experience as an editor and a writer, here are a few things that can rightfully find their way into a release checklist:
- Check if the book cover appears all correct - all images and logos are displayed properly and it displays the correct Book Title, Book Number, and Version Number. Remember this is a checklist, so we are assuming that the structure of your publishing projects and documents is such that you make correct use of variables for such information that is likely to change in every release and likely to change in multiple places in the document or set of documents.
- Check the copyright and trademarks notices page - one thing that often gets missed on this page is the copyright year. You must pay special attention to this part especially when you have just finished celebrating the new year. There are also instances when the work for a release spans over several months, and your book has been open for quite a long time, and you do not realize that the previous year's calendar is already in the trash!
- Check the list of attribution statements on the copyright page - this is especially important of your product has recently undergone integration with other or newer applications, or the product technology stack has undergone a change. Make sure to consult your manager, editor, or the respective company's website for the correct legal attribution statement to include.
- Check for the line "All other products, names, and images are copyrights or trademarks of their respective owners." This makes sure that you are covered if you accidentally miss out a dedicated attribution statement for a product.
- Check the table of contents - check if the chapter numbers and titles are all present and in the correct order. Inspect chapter names for correct capitalization as decided by your house style. Look for any orphan page numbers with preceding leader dots. Look for capitalization of four-lettered words such as from, with, and so on, and use upper or lower case for these words depending on what your house style dictates.
- Check the first page of every chapter for the chapter name, style, and chapter number.
- Check page numbers on every page, and whether they appear in the correct location if you have different left and right page numbering style.
- Check the headers and footers on every page and look for incorrect chapter names, book title, or version number.
- Check the back cover of the book for all information elements. Generally, back covers are boilerplate material and do not change from release to release, but it is better to err on the side of caution!
After you have looked through the major elements of the document, look for the following finer details:
- Click all links to check if they work properly, and also open the correct destinations or targets URLs, documents, or topics.
- Check all images to see if they have the appropriate numbers and captions. If your images are numbered, for example, Figure 3.1: Dimensions View, make sure the chapter and image numbers are correct, and that the captions follow the correct structure and style. For example, you must avoid Figure 4.1: Edit a Contract Online and Figure 4.2: Editing Contracts Offline. (Stay tuned for an upcoming post on parallelism in writing).
- Check use of bullet lists and numbered lists - scan to see all lists and procedures to see if bullet and numbered lists have been used correctly.
- Check numbered lists for procedures to see if they are numbered properly. Look for missed numbers such as step 7 after step 5, or two steps having the same number.
- Run a final spelling check.
After the devil in the details has been taken care of, perform some post-publishing tasks, and you are all set to call it a day!
- Check in the document source and the published documents to your official repository.
- Upload the documents to a wiki or SharePoint site, as your process demands.
- And send an e-mail announcing the readiness of the document to all stakeholders with links to places from where they can access the document.
Pat yourself on the back for a good job done, and head home! :-)
Sample Release Checklist for PDF Documents
Write to me to request the source document for this checklist at praneetaparadkar@praneetaparadkar.com.
Write to me to request the source document for this checklist at praneetaparadkar@praneetaparadkar.com.
 |
Sample Release Checklist for PDF Documents |
Enough for today! :-)
