Is it necessary to formally up-issue a procedure or form for minor changes? Let me clarify "minor" with a few examples. In each example, the item could remain as-is without affecting form, fit, functon, meaning, intent, etc., and risk to the process, product, customer satisfaction, employee, environment, etc. are nill if left as is.

* A link in the procedure to another procedure has somehow become lost.
* A heading that's in lowercase should be uppercase.
* A word is mis-spelled, but the meaning of the word is still clear.
* A full-stop (period) is missing from the end of a sentence.
* Space on a form could be a bit wider

Currently for these situations, I simply go to the master soft copy, turn on change marking, and make the change without up-issuing the document. I don't record (add a comment) to indicate the date, who noticed or requested the change nor to document why the change was made since these types of changes are so evident. When the document is finally up-issued, these minor changes are noted in the change history.

Not ideal, but then these procedures are not dealing with risky jobs, engineering specs or the like. I do it this way because as the only person in Quality handling up-teen jobs at once, it is faster to do a quick change than go through the entire change process (check out, make chagne, update logs, create change request, get 5 signatures (days/weeks), backup, check in, move, notify via e-mail, update the web site.... (For the same reasons I discourage creation of CARs for these minor changes.)

If, however, there are more than 3 or four minor/insignificant changes, I would up-issue the document right then and there.

Thoughts appreciated!

I certainly don't for minor grammatical and spelling mistakes. Only when I start changing and adding words would I update the revision history of the document.

Your not really make changes to the process described by the document which IMO is what the standard requires.

I wouldn't. I wouldn't even bother to note the changes in a future "real revision". But I have written into my procedure that changes to typos or formating or other minor changes that don't change the meaning or intent of the document can be made without issuing revs.

Just fix it and don't worry about the "nit-picking". At some point common sense needs to prevail in all the "system" gibberish we have going on.

But I have written into my procedure that changes to typos or formating or other minor changes that don't change the meaning or intent of the document can be made without issuing revs.

I, too, have written into my procedure that changes for syntax do not require a rev level change.

Christine,
Good thread, I have now added a appropriate phrase to our document change procedure!
Thank you
Paul

Be very careful about these changes. Sometimes a minor grammatical error or spelling mistake can be misinterpreted by those using the document and correcting those errors without notice can cause big problems.

At times an apperant spelling error is not an error. I had a person that change Dulles to Dallas because she thought is was a spelling error. You can imagine the problems that caused.:mg:

Thanks to everyone who has responded thus far - keep 'um comin' as I want to ensure my rationale is sound.

To "ddunn", I'd like to stress that changes are only performed by Quality (yours truly) after careful consideration of their potential impact - not only in the current procedure but also any knock-on effects in others. Part of the review includes impact to the users and their knowledge/experience. In the example you cited (Dulles vs. Dullus), this is a change to a word and because it would affect the understanding of the process. Likewise, I would not change, for example, a "shall" to a "may" since these terms have very different meanings to the intended audience.

Christine

Thanks to everyone who has responded thus far - keep 'um comin' as I want to ensure my rationale is sound.

To "ddunn", I'd like to stress that changes are only performed by Quality (yours truly) after careful consideration of their potential impact - not only in the current procedure but also any knock-on effects in others. Part of the review includes impact to the users and their knowledge/experience. In the example you cited (Dulles vs. Dullus), this is a change to a word and because it would affect the understanding of the process. Likewise, I would not change, for example, a "shall" to a "may" since these terms have very different meanings to the intended audience.

Christine

It boils down to a matter of control, and others here have already made the good suggestion that allowing for "minor" changes without invoking the formal revision process is a good idea. My own preference, though, is for adding a notation to the document that identifies the change(s) made and the person who made the changes. The reason for this is that once a document has been changed without such a notation, it's impossible for a user to know what other (possibly substantive) changes might have been made without doing a detailed comparison.

I wouldn't. I wouldn't even bother to note the changes in a future "real revision". But I have written into my procedure that changes to typos or formating or other minor changes that don't change the meaning or intent of the document can be made without issuing revs.

Ditto! And never had a problem doing it.

.....
Currently for these situations, I simply go to the master soft copy, turn on change marking, and make the change without up-issuing the document. I don't record (add a comment) to indicate the date, who noticed or requested the change nor to document why the change was made since these types of changes are so evident. When the document is finally up-issued, these minor changes are noted in the change history.

......it is faster to do a quick change than go through the entire change process (check out, make chagne, update logs, create change request, get 5 signatures (days/weeks), backup, check in, move, notify via e-mail, update the web site.... (For the same reasons I discourage creation of CARs for these minor changes.)

Christine

Call me Mr. Detail, but we issue a new rev for any change. Even a single typo.

We have had some tough moments when a auditor found a paper copy rev 2 say and then looked at the system rev 2 and found they were "different".

It becomes a loss of face and loss of faith issue.

You then need to go into "explaining mode" and I hate that.

Even though it was only a typo the auditor can ask "how do I know that was the only change?"

It became too much talking too little showing for me.

So, why not consider altering your system to allow a Doc Admin say to make a change and issue it without 5 signatures....at least you have a record of the change.

It feels good to be clean, neat and tidy at all times. The trick is to make it easy and fast to do.

* A link in the procedure to another procedure has somehow become lost.
* A heading that's in lowercase should be uppercase.
* A word is mis-spelled, but the meaning of the word is still clear.
* A full-stop (period) is missing from the end of a sentence.
* Space on a form could be a bit wider




I totally agree with everyone on this subject. However, the first example is not a minor change. A link to another procedure being lost screams that there is an out of control process or soon to be one. I would defineately fix that procedure and issue a new revision else your procedure will not match your process. You won't be doing what you say you do. :mg:

The other changes listed above wouldn't even require noting you did them. IMO.

:cool:

As long as it doesnt change the context or requirement, no rev needed!:frust:

There are two requirements that relate to this topic. First is 4.2.3 c), ensuring the changes and current revision status be identified. There is no requirement for a rev level on a document. The requirement is for the revision status to be identified (rev levels are just one way). The second is 4.2.3 d), ensuring relevant versions be available at points of use. Given that, the question is; can you still trust the document if there is any change to it? If we re-format a document to add color, or to add the company logo, does it mean that the required information (the reason for the document) has changed? Is the older version no longer valid? Far too often, we get wrapped up in our “rules”, and forget about what we are really trying to do. The rigidity of those same rules causes us to trip and fall unnecessarily.

Sorry to descend the majority opinion.


...exceptions:
The document were talking about has already been published.
This would include product labels, standards OP's, any written communications to vendors or suppliers. ...Basically - Everything.

Doc control will probably say any change to a rev controlled document (no matter how insignificant you perceive the change to be) must occur through the revision control process - And, if they are doing their jobs right (as the do here) the only file you can see or print is an un-editable PDF - So you can't change it anyway.


The game now is: Is the error worth the cost of the revision.

C'mon folks!!!!

A change is a change. What needs to be changed here is the process that makes document changes so difficult. Why not investigate an electronic system that would facilitate the changes without the paperwork hassles? Maybe even one that has a spell checker?

The problems here are mistakes not being caught before the doc is issued and a doc change process that is a pain in the rear to administer. Here are 2 areas that appear (from here anyhow) to be ripe low hanging fruit.

Just my opinion, of course.

As I see the situation, common sense should take precedence, but too often, different folks have different views of common sense.

If we are talking about a document of limited circulation/distribution, I can see the reasonableness of a single authorized person making such minor changes without the full-blown rigamarole of multiple checks and approvals, IF all of the outstanding copies with that revision level can be retrieved and either red-lined or removed and replaced with the corrected documents. I would envision this for documents like work instructions, job travelers, and other in-house documents. As others have suggested, it is good practice to FORMALLY modify the document change procedure to allow this and to detail the circumstances under which this change may be made.

Other types of documents which seem [by common sense] to preclude such short cuts are documents meant to be viewed and used by folks outside the organization such as purchase orders, engineering drawings, instruction manuals. Certainly, no RECORD may be altered without leaving a complete audit trail of the alteration and purpose.

Christine,
Thank you for posting this thread. I have been wanting to add something like this to my work instruction for a long time (ability to change a doc for minor typos without bothering others in the loop etc.). I printed this thread to use some of these examples listed. As Randy said- I have been needing to get some common sense into my own system.
As stated by some though, I do feel that it is very important to ensure that the changed document is then posted at all applicable locations. I don't want an outside auditor finding differences in the documents! The documents should be the same everywhere.
Excellent thread- thank you.

This is a great topic! As a Documentation Specialist, I personally uprev everytime a change is made (we recently changed our company logo - what a headache!).

Minor changes, such as typo corrections and logo updates, can be done with only my signature authorizing it, but the changes are fully documented and the documents upreved. This is documented in a procedure.

The way I do it gives me peace of mind because if I (or someone else) audit a procedure book, I don't have to worry which "Rev 2" is in there, just "is it the right rev?"

For 5 years I worked as an engineering drawing auditor, I preformed a technical reviewer for manufacturability and conformance to standards (including ASMEY14.5) – Basically I was a drawing checker. I worked under the umbrella of Document control, and no small part of my responsibility was to archive, and maintain the integrity of our company’s intellectual proprietary in a database.

This company (I don’t want to use names) is huge! Their product have hundreds of subsystems, and tens of thousands of components in each. The product involves complicated processes; gasses, heat, and just about every manufacturing process know to create the end product. As you can imagine, there are millions of documents involved.

The ECO cycle time was truly abysmal, sitting around 45 days for each change. In spite of this obvious cost and damage to logistic concerns; that companies officers understood the value of a “scrub” process. Every ECO, every document, is routed to a “Subject Matter Expert” for review. And doc con maintains a pool of these folks.

The SME issues comments back to the originator, has some limited authority to change the document, but most important, is part of the approval process. The ECO never implements, until it satisfies a review by the SME. No document was archived in our database, without the SME’s (in the case of a drawing, my) approval.

The idea behind this is: If our company adds a few more days to the ECO cycle time, by adding a peer review; maybe, just maybe we won’t have to revise the document again. Maybe, embarrassing minor faux pas, like a typo in the logo won’t happen.

Sorry, this isn’t a great comfort; I can imagine your faces cast downward, at the realization that controlled documents cost more than you’ve realized. One of my favorite clichés is: The fleas come with the dog. Or even: It costs you cream to make butter.

In a past life I worked with many government documents and forms where the document/form stated on it (or in an index) the current revision, but also allowed for the use of specific previous revisions. This was typically used when "minor" changes were made to the doc/form that did not affect the overall intent of the doc/form or its use.

The idea behind this is: If our company adds a few more days to the ECO cycle time, by adding a peer review; maybe, just maybe we won’t have to revise the document again. Maybe, embarrassing minor faux pas, like a typo in the logo won’t happen.


Maybe I was not clear enough - we did not have a typo in the logo, we completely changed the logo (colors, characters - everything). So, all the documents had to be changed. For a minor change like that, it was not worth going into peer review.

I was willing to wait until documents were ready for revisions, before changing the logo. The President of the company however, decided he wanted all the documents that visitors or customers come in contact with to look the same (and have the new logo). So, changes for just the logo were made to the most visible documents.

Back in the 80's, I saw another organization's solution to the problem of changing logos and even company names that struck me as so sensible, I have adopted it ever since. Note, this is not for "discovered" errors, but for normal business transactions not affecting the content of the document.

The organization had a separate "Procedure" which was like a perfect FMEA (Failure Mode & Effects Analysis) solution:

only the text or the drawing comprise the document (company logos, headings, etc. don't count as part of the document.)
there is no requirement for paper size, weight, color, font, ink color, margins, etc.
If the company has a name change, all documents may be automatically edited or amended to reflect ONLY the name change without further approval or revision change. (i.e. engineering drawings could have either an address stamp or an address label added without affecting the revision level of the document.)