Dear Gentlefolk,

Please find attached updated software design specification (issue 1 to issue 2).  This is a document of many parts (okay, three parts, one Word document, one tif and 1 pdf file) and has had the following Change Notes implemented:

ZZR-00006
ZZR-00007
ZZR-00008
ZZR-00015
ZZR-00022

Please note that, on further reflection, ZZR-0008 did not actually result in any changes to this document, but has been logged as a valid change because nobody cancelled this Change Note.  Please therefore check that ZZR-0008 has NOT been implemented.  This should not be too difficult as no part of ZZR-0008 references the document anyway. 

Can you please do whatever it is you do to satisfy the criteria required by you to feel comfortable with the concept of agreeing the changes (by the addition of your signature to the signatories page of the document.) Please note that as this is an electronic version of the document, there is in fact no signatory page to sign, the included signatory page (page i) with this electronic distribution is for display purposes only. The signatory page will be circulated after all are happy that the Change Notes (above) have been implemented correctly (or closely enough to give you a nice warm feeling inside) and have agreed the changes and any corrections required from any
incorrectly implemented Change Notes (or part thereof), found by yourselves, implemented.

Due to some confusion on my part with regard to issue conventions, the electronic configuration management tool, the old Configuration Management Procedure and the new Configuration Management Procedure (as issued only last week in order to document our current process in order to satisfy the auditors who would otherwise have issued several non compliances and
probably withdrawn our accreditation), the attached Word document (the one from the electronic configuration management tool) is now suffering an issue identity crisis and thinks it is issue 1.2, but should think 2.  There will therefore be a dummy issue 1.2 in order to maintain traceability in line with our configuration management procedures (take your pick - that's one section of the procedure which hasn't changed) and I will issue a change note requesting the change of issue from 1.2 to 2. 

The issue 2 document will be circulated once issue 1.2 has been approved, signed, photocopied, distributed, ignored and probably lost in the upcoming move from this building to the new building (providing that the new building has been completed  - oh well, third time lucky!).  I will then ask you to check Issue 2 against the appropriate Change Note (serial number to be allocated by configuration control in line with whatever the damn procedure is at the time) for compliancy, to whit that the document issue details in the header and footer have changed and that there is a record of the Change Note in the Change Record section.

Issue 1.2 will then be withdrawn and Issue 2 will be signed, approved, printed, copied, bound, distributed to all concerned - and quite a few unconcerned - parties, some of whom will simply ignore it, others will lose it and several will deny ever having seen it and will continue to work to Issue 1.2.  Since Issue 1.2 is in all respects identical to the proposed Issue 2, except for the issue number and change record entry, this will be of no concern to anyone except for our auditors who will threaten to withdraw our accreditation due to poor configuration management processes. We can then update the configuration management procedure with a clause about documents identical in all respects except for issue and change record and that will give them something else to audit us on.  Unless of course anyone else wants to raise, approve and implement a Change Note to go into Issue 2, in which case it might give our SW Quality Department something to actually check when the document is reissued.

Thank you for your patience and co-operation in this matter. 

SEVERAL WEEKS LATER, THE SAME PERSON SENT THE FOLLOW-UP ...