How do my specwriting colleagues identify revisions on specifications that have been issued. Do you cloud? Strikeover? Shade? Underline? I have a client who expects me to cloud the revision and number them like he does on his drawings. Comments please?
I use track changes, so I get redline underline and strikethrough. At the end of each change, I insert the addendum number in square brackets. Works well. Clouding could get messy in text.
Bold for new, strike through for old. Rev number and date in footer
Also, updated TOC with publication dates of each section. The revised sections have the updated dates in bold
Like Nathan, track changes, with an issue date and description in the document footer and a corresponding Table of Contents indicating the latest issue date for each document or section. For subsequent issues of previously revised documents the previous track change annotations are removed by accepting all so that only changes for the particular issue are indicated.
Where all changes have to be indicated (say republishing a project manual to incorporate all prior addenda and negotiated changes for final contract) Ill use track changes for everything but also use the endnotes function to provide a notation of the origination of each change.
Tracked changes with a revised issue date. Previous changes are incorporated into the text so only the most recent changes are highlighted.
Ditto Ron. Also note on TOC.
I like Nathan’s Bold for new, strike through for old. Rev number and date in footer. I’ve used this method with success.
Track Changes can be messy, especially if there are already underlined items in spec that are not changing. Clouding is at best difficult in electronic form and also can renser some text illegible. Shading can also result in illegible text. Strikeout and bold make it very clear asto what changed.
I agree with Sheldon, Ron and Bob above
We avoid the auto “track changes” features of MSWord.
Deletions shown with manual strikethrough.
New text shown with manual underline (Ctrl+U).
Both additions and deletions flanked in the right margin with the method for issuing the change: [CCD1] or [ASI1]or [CO1] or [AD1] as noted by Sheldon.
Rev number with issued date in footer at left margin
Original issue and subsequent issues archived for an audit trail.
Entire revised section reissued.
TOC kept current as noted by Bob.
Previous changes are incorporated into the text so only the most recent changes are highlighted as noted by Ron.
I avoid narratives in Addendum cover page.
File name suffixed with trail of change cover acronyms without dates.
I use track changes throughout but these are usually hidden in the published document.
For revisions to published sections I underline new text and strikeout text being removed. I then add a double line in the margin (border tool) to indicate where a change has taken place so it can be easily found by the end user (Contractor) when it is issued. For sections that get revised more than once (not recommended but it does happen) I remove the double line from any previous revisions and only include the indicator to show where the changes actually took place for the individual submittal being published.
I include the date and revision title in the header of the revised section per our in-house formating standards.
I also keep a running TOC with the date and a title after the section title for each revision indicating when it took place.
Ditto - Bold for new, strike out for old, with or without track changes.
We have a project that wanted the bubbles in the spec text, but we talked that one back. But we do need to use the same delta symbol (triangle with the revision number inside) that is used on the drawings in the left page margin no matter how messy this can get with formatting.
That is a new chore, creating the delta symbol graphic and sending it to all spec providing consultants.
I use the same method as Richard and Steven (pseudo-track changes). I find true track changes to be cumbersome. In subsequent re-issues of specifications (no, one revision is not always enough 
the writer has to be careful to delete all previously struck-through text and “un-underline” all previously added text. A macro to find struck-through and underlined text can be helpful.
I have not had any problems with Word’s “Track Changes” feature. I used strikethrough for deleted text and italics for added text. It updates the paragarph numbering and puts a bar out at the side to indicate that there has been a change (even if it is a renumbering change). This can be modified by the user within certain limits for office practice.
If I have to change a section more than once, I update the section, accepting all the changes (can be done as a single operation), and then make more changes. This is analogous to deleting the clouds from previous changes.
Don’t know what I would do if I had to put in the delta numbers although a response of “Are you daft” might be appropriate followed by a request for additional services. What I have done is change the footer to track when the specification was reissued. Because I am an independent, it is difficult for me to do document tracking for the entire project, and I usually push that back on my client (the architect).
I take a similar approach to Peter - i use track changes with not problem. I find it is easier to underline added text (rather than bold) because it stands out better (IMO). I then use the TOC as a running tally to show whether a sections is “revised”, “new” or “deleted” on any given revision.
Ditto Ron, Peter and Robin.
I do not find Track Changes messy (do not underline any regular text) or cumbersome - by contrast it makes it easy with minimum manual work. Why create work for yourself?
Modify file name, turn Track Changes on and make changes, turn it off and modify footer issue info. Use Track changes to note revisions in TOC with modified file name and revised footer issue info.
Second changes to same file - modify file name again, turn Track Changes on and accept previous changes (one key stroke), make new changes, turn it off and modify footer issue info. Follow same routine in TOC (file name modification, turn Track Changes on, accept previous changes, then note new revisions, turn Track Changes off and modify footer issue info).
Keep historic files for information on what changes were made at various issues. TOC includes revision history.
Great comments except I use Wordperfect.
I use the Word document to create PDF files. I keep the multiple PDFs, but a single Word document which keeps changing.
Same here, Peter. A big advantage is realized when you have a client that wants a final set of documents that incorporates all changes. Some of our clients want that set to be the final version, with no indication of when the changes occurred, others want them to show. Either way, track changes makes it easy.
I edit the specifications first, then write the addendum or other modification document. Describing the change first, outside of the section, sometimes results in a surprise when the section is updated - it doesn’t read the way you thought it would.
Ditto on the Track Changes in Word. I change the file name with an embedded date so when I accept changes in the newest document I can always go back to a previous version if needed.
Sheldon, like you I like keeping a running tally in the Addendum narratives. Since I can rarely get anyone else to proofread content, the narrative is my best opportunity to be my own ‘second set of eyes’.
We do pretty much the same as Wayne stated above, except we add nothing in the margins. Our “current” folder is just that - the most current version of the section. We PDF sections for whatever the issuance is as a permanent record of what was done.
Because there are 4 of us in the firm, and “track changes” appearance can be set individually, we decided to use manual features to achieve the same appearance.
I use the “find” feature of Word (Format or Special) to find instances of underlining or strike-through before making new changes. It’s easy enough.