4.2.4 Control of documents - Redlines

Jkc3usc12

Involved In Discussions
Looking to streamline our doc control process.

Currently they are asking for a relined doc along with an exact detail summary of what was changed. So every change made on the redline I need to re write on the change summary. It seems like over kill to me. If A doesnt match A exactly in all aspects, they reject.

Can I not just write a high-level change summary and say reference redline attached? Or could I just say in the change summary reference redline attached? I also do not feel like content needs to be reviewed by doc control as that is on the author and approvers. doc control should make sure template, approvers, attachments, etc are correct.

Thanks for your help.
 
Last edited:

Tidge

Trusted Information Resource
I was at a company that went through a phase of this:
Currently they are asking for a relined doc along with an exact detail summary of what was changed. So every change made on the redline I need to re write on the change summary. It seems like over kill to me. If A doesnt match A exactly in all aspects, they reject.
I want to say the phase lasted almost a couple of years. I think what finally did it in was a combination of:
  1. The person pushing for this (for compliance, natch) ended up having to be a document writer on at least one QMS dcoument
  2. There was a predictably long series of rejected change orders, which manifested as a hot mess during management review
  3. There was at least one set of documents that had three pages of "change order content" tacked on to the actual document.
I grok all the reasons why someone might think it is a good idea for any given document to contain its complete change history, but at that point you may as well add all the approver names to every document. Redlines make it easy to review, but the change order is where the specific details of a change belong. Approvers are supposed to review BOTH the change order and the contents of the documents they are approving; duplicating CO content in documents strikes me as an opportunity for lazy(*1) reviewers. Including an appropriate summary of the changes in a revision history table ought to be enough for all users of the document.

(*1) "lazy" is the first word that came to mind; if this offends anyone feel free to substitute "inexperienced", "hurried", "untrained", or "shallow".
 

ChrisM

Quite Involved in Discussions
Who is the "they" that are asking? A Notified Body, a customer, someone internal higher up the organization than you ?
 

Jkc3usc12

Involved In Discussions
Who is the "they" that are asking? A Notified Body, a customer, someone internal higher up the organization than you ?
Sorry Internal Doc control is saying this. I dont see anything in the standard that requires all of this.
 

Tidge

Trusted Information Resource
Sorry Internal Doc control is saying this. I dont see anything in the standard that requires all of this.
It was the "internal authority" of the Change Control group (primarily a manager, no so much the lower levels) that was responsible for the chaos I experienced and that @Jkc3usc12 predicts. I want to write: At this company, I don't think any "internal authority" ever consulted with an external resource (like an auditor or an experienced consultant) about the implementation with examples of what was being required... In the abstract, this is a blunt rule that is an effort to take critical thinking out of a basic quality function, and quality managers typically don't take the concerns of underlings (or users) seriously once they've made a decision in an area for which they feel like they have ownership. No external authority is going to say "doing this is wrong", and there aren't (m)any independent authorities that will go out of the way to point out self-inflicted inefficiencies.

On its face, it completely makes sense that a revision history block provides a clue as to the nature of the revisions because users of the (new) procedure should have their attention drawn to which areas have been changed from (previous) versions they have been executing. Yet users don't benefit from seeing trivial revision history comments (e.g. "em dashes changed to en dashes in section 7.1.2, 7.1.4, etc.") that tend to obscure vital content changes.

The most straightforward argument against the proposed practice leverages the following:
  • A new requirement for 100% correct traceability between the change order records, the content of the document and a new "trace matrix" (the revision history) has introduced a new place for non-conformances in quality records.
  • The new requirement for detailed traceability in the revision history of each document has introduced a new element of the records which will require additional review time, as well as one more area of documentation that will need to be corrected/reconciled when mistakes/inconsistencies are found.
  • Documents with extensive revision histories will inevitably have the "vital few" changes obscured by the "trivial many."
It is entirely possible that the recommendation for extensive revision histories is coming down because of some defect elsewhere in the review process for document control change orders. I can easily imagine that there is some fraction of "good reviewers" who leverage some set of documents (the change order details, the current version of the document, the proposed version of the document) in a way that "not-so-good reviewers" do not... likely because they only want to look at "one document". The unwillingness to follow the basic tenets of document review does not mean that it is the documents that are defective.
 
Top Bottom