This is a great discussion of document of external origin:
********************************
From: ISO 9000 Standards Discussion
Date: Thu, 14 Dec 2000 15:46:08 -0600
Subject: Re: REQ: External Document Control /Eriksen/Kozenko
>I am requesting hypothetical or real examples of procedures
>for the control of external documents. We realize we need
>this procedure yet we are struggling with how to do it and
>what exactly needs to be included (i.e. maintenance/equip
>manuals, safety documentation, software manuals etc.) We
>are utilizing ISO 9002:1994 at this time.
I used to be a Specifications Engineer, so I'll tell you what worked for me in that environment. This gets a bit long-winded and I usually try to avoid that in posts, but I can't convey the concept here using any other method. Bear with me, and you'll probably be able to "transfer" what I can tell you about my situation, to your own.
MIL-Spec's were the most frequently referenced external standards I was involved with. Some applied to equipment, others to (say) construction technique, things like that. I'd guess from your query that there is a MIL-standard for everything you might encounter in your business operations, so I'm only going to talk about MIL's.
I was part of the team that prepared construction documents (where constructors would bid it and build it "this way"), architectural design documents (where architects would design it to parameters we set forth, and a constructor would build it "their way"), procurement documents (where manufacturers would make things "this way" per our parameters) and furnish/install documents (where contractors would make or buy products we specified "this way" and install them "this way"). The project's owner was the Port Authority of Allegheny County (PAT) in Pittsburgh, PA, and my firm was Parsons Brinckerhoff, in joint venture with Gibbs & Hill, Inc.
I was "the bad guy" at PB for about a week when, after my initial assessment of space needs for an internal library, I wouldn't back down from a 10' x 20' room requirement, in order to hold all the copies of cited external standards that I projected we would need throughout the life of this ten year public transit project. (Normally an internal library is a "notch too high" on the redundancy requirement, but I knew from experience we would need our own library -- this is a question you must decide also, based on your environment, experience, etc.)
Axiom #1 -- The only good reason to cite an external standard in a contract for anything (hardware, software, combo-hard/soft-ware, or services) is to keep the hard copy of that standard out of your own contractual documents. (The federal government's contracts have good language you can "borrow" to communicate this concept, if you don't already have text of your own ;o)
The most frequently cited external standards I controlled were MIL-Specs, so I'll stick with those for the remainder of this post, but anything I tell you applies to ALL external standards, not just MIL's.
True story: In the preparation of an early, small $-value contract for construction, a design engineer with my firm cited a MIL-Spec by number only. ( "MIL-Q-9858A dated ______, " is the "quality system" MIL-spec, and that's an example of how MIL-spec's are correctly cited). So in this early contract my firm awarded, the cited MIL-spec have a date. Bids were opened in (say) January, and the cited MIL-spec had been revised the previous December. Worse yet, the revisions made were significant and costly.
The contractor was reasonable with us after some considerable effort was spent at the negotiating table, where (just like the Presidential Election Battles that the world has watched for the past 21 days) the contractor said its bid was based on the December version (less costly) and my firm's engineers said the intent was to use January's revised version (more costly, plus impacts to scope and schedule). We (contractor and my firm) ended the dispute by deleting the MIL-spec requirement completely, and writing in exactly the requirements that we all knew we needed, for a "no cost" change order.
But all that drama led me to create a solution to ward off future problems that otherwise could arise from the lack of control of external standards. That's the MOST IMPORTANT aspect concerning the perspective you should take when preparing your own system for external document control -- answer the question for yourself and your firm's circumstances: "What data do we need to keep track of, in order to minimize or eliminate problems, and to provide a quick source of useful data for our defense position(s) if/when problems arise?"
As any good spec-writer should do, I specified in each contract that either:
(1) the exact version of the MIL-Spec in the contract (MIL-x-#### dated _____) would be used until the "end of time," or,
(2) any MIL-Spec revision that occurred during the life of the
contract would be dealt with under the contract's "Changes" clause. (This "put the ball" in the contractor's court, since the contractor was then required to track MIL-Spec revisions for himself, and then assess the impact of MIL-Spec revisions (scope - schedule - budget), and finally, ask for (and get) a Change Order before proceeding with the change.
Axiom #2 -- If you do not require by contract that your customers keep track of external standards also, you'll lose more claims than you'll win, in this category.
MIL-Specs change over time (just like FAR clauses, for fed. contract administrators, also a job I was cursed with once) and it is not rare at all to find some engineer or administrator that just won't let go of an older, outdated, superceded version. Things get even more complicated too, when (as in my example here) you have a ten year project and you'll be issuing contract specifications for eight of those ten years.
Now, I told you all of that, to tell you this:
Iin order to retain control over external standards, I generated an external standards database with the title, description, current version available, exactly where to get a new copy, a data-field for the Contract Number where the cited external standard appeared I also included the anticipated future revision date for that particular external standard (if such date was available -- sometimes the standard itself will say "revised every five years, like ISO9000).
At the "Pre-Final" or "Final" stage of the bid document preparation, one of my checklist items for the specifications book and the Drawings notes, was to run a date sort on (1) all of the external standards included in that contract; and, (2) all of the anticipated revision dates for all the external standards included in that contract.
I made it routine to get "draft for comment" versions of important pending changes to MIL-Specs that we'd used, (1) so my engineers would have a "heads up" that a revision was about to become official, and (2) to get everyone thinking about what the impact was going to be from those revisions
Axiom #3: *** created "time" so that everything doesn't happen all at once. This axiom applies very readily to 13 miles of public rail transit, especially when you throw in tunnels; at-grade intersections; street closings (temporary and permanent); ripping up a major city's downtown business section in January and "busting chops" to get it covered before that year's Christmas/Holiday shopping season; lots of stations, the frustrations caused by contractor claims, and the normal politics, etc.
That's where the data field for "Contracts that contain this cite" proved to be worth its weight in gold. Most of the construction contracts that dealt with refurbishing the rail along the transit line were bid at different intervals, and a large number of MIL-Specs were changing frequently (sometimes 2 revisions per year). We encountered situations where a contract awarded in (say) 1991 (let's call it Contract A), was well underway, yet the next contiguous contract for the continuing linear segment of the transit system (Let's call it Contract B) wasn't bid for 2 more years (after many revisions to some MIL-Specs). It saved "a wheel barrow" full of money to be able to list all the contractually required MIL-Specs in Contract A, and compare them with all the contemplated MIL-Specs in Contract B, (along with analysis of all of the MIL-spec revisions, A to B) during the document preparation phase for Contract B. Most of the revisions were usually miniscule, but a few revisions (to the MIL's) from Contract A time, to Contract B time, would have been purely embarrassing to my firm (had they gone out) and extremely costly (again, to my firm, since "doing it right the first time" was essentially a scope of work item in our contract with the owner of the transit system). I can recall a few MIL-spec changes from the "Contract A to Contract B" scenario where Contract B just wouldn't have worked, period.
So when you prepare your own tracking system for external standards, think broadly, with scope / schedule / cost in mind, when deciding what types of data fields to include. An absolute MUST DO item is a checklist, at your process-critical point, where someone uses the data fields you've captured about external standards.
Finally, make this question: "Is this nonconformance related in any way to external standards?" a routine question when analyzing your own Corrective and Preventive action data. That way, you won't miss an opportunity for continuous improvement, and maybe someone will generate a useful preventive action (or two, or three) as you go along.
David K
********************************
From: ISO 9000 Standards Discussion
Date: Thu, 14 Dec 2000 15:46:08 -0600
Subject: Re: REQ: External Document Control /Eriksen/Kozenko
>I am requesting hypothetical or real examples of procedures
>for the control of external documents. We realize we need
>this procedure yet we are struggling with how to do it and
>what exactly needs to be included (i.e. maintenance/equip
>manuals, safety documentation, software manuals etc.) We
>are utilizing ISO 9002:1994 at this time.
I used to be a Specifications Engineer, so I'll tell you what worked for me in that environment. This gets a bit long-winded and I usually try to avoid that in posts, but I can't convey the concept here using any other method. Bear with me, and you'll probably be able to "transfer" what I can tell you about my situation, to your own.
MIL-Spec's were the most frequently referenced external standards I was involved with. Some applied to equipment, others to (say) construction technique, things like that. I'd guess from your query that there is a MIL-standard for everything you might encounter in your business operations, so I'm only going to talk about MIL's.
I was part of the team that prepared construction documents (where constructors would bid it and build it "this way"), architectural design documents (where architects would design it to parameters we set forth, and a constructor would build it "their way"), procurement documents (where manufacturers would make things "this way" per our parameters) and furnish/install documents (where contractors would make or buy products we specified "this way" and install them "this way"). The project's owner was the Port Authority of Allegheny County (PAT) in Pittsburgh, PA, and my firm was Parsons Brinckerhoff, in joint venture with Gibbs & Hill, Inc.
I was "the bad guy" at PB for about a week when, after my initial assessment of space needs for an internal library, I wouldn't back down from a 10' x 20' room requirement, in order to hold all the copies of cited external standards that I projected we would need throughout the life of this ten year public transit project. (Normally an internal library is a "notch too high" on the redundancy requirement, but I knew from experience we would need our own library -- this is a question you must decide also, based on your environment, experience, etc.)
Axiom #1 -- The only good reason to cite an external standard in a contract for anything (hardware, software, combo-hard/soft-ware, or services) is to keep the hard copy of that standard out of your own contractual documents. (The federal government's contracts have good language you can "borrow" to communicate this concept, if you don't already have text of your own ;o)
The most frequently cited external standards I controlled were MIL-Specs, so I'll stick with those for the remainder of this post, but anything I tell you applies to ALL external standards, not just MIL's.
True story: In the preparation of an early, small $-value contract for construction, a design engineer with my firm cited a MIL-Spec by number only. ( "MIL-Q-9858A dated ______, " is the "quality system" MIL-spec, and that's an example of how MIL-spec's are correctly cited). So in this early contract my firm awarded, the cited MIL-spec have a date. Bids were opened in (say) January, and the cited MIL-spec had been revised the previous December. Worse yet, the revisions made were significant and costly.
The contractor was reasonable with us after some considerable effort was spent at the negotiating table, where (just like the Presidential Election Battles that the world has watched for the past 21 days) the contractor said its bid was based on the December version (less costly) and my firm's engineers said the intent was to use January's revised version (more costly, plus impacts to scope and schedule). We (contractor and my firm) ended the dispute by deleting the MIL-spec requirement completely, and writing in exactly the requirements that we all knew we needed, for a "no cost" change order.
But all that drama led me to create a solution to ward off future problems that otherwise could arise from the lack of control of external standards. That's the MOST IMPORTANT aspect concerning the perspective you should take when preparing your own system for external document control -- answer the question for yourself and your firm's circumstances: "What data do we need to keep track of, in order to minimize or eliminate problems, and to provide a quick source of useful data for our defense position(s) if/when problems arise?"
As any good spec-writer should do, I specified in each contract that either:
(1) the exact version of the MIL-Spec in the contract (MIL-x-#### dated _____) would be used until the "end of time," or,
(2) any MIL-Spec revision that occurred during the life of the
contract would be dealt with under the contract's "Changes" clause. (This "put the ball" in the contractor's court, since the contractor was then required to track MIL-Spec revisions for himself, and then assess the impact of MIL-Spec revisions (scope - schedule - budget), and finally, ask for (and get) a Change Order before proceeding with the change.
Axiom #2 -- If you do not require by contract that your customers keep track of external standards also, you'll lose more claims than you'll win, in this category.
MIL-Specs change over time (just like FAR clauses, for fed. contract administrators, also a job I was cursed with once) and it is not rare at all to find some engineer or administrator that just won't let go of an older, outdated, superceded version. Things get even more complicated too, when (as in my example here) you have a ten year project and you'll be issuing contract specifications for eight of those ten years.
Now, I told you all of that, to tell you this:
Iin order to retain control over external standards, I generated an external standards database with the title, description, current version available, exactly where to get a new copy, a data-field for the Contract Number where the cited external standard appeared I also included the anticipated future revision date for that particular external standard (if such date was available -- sometimes the standard itself will say "revised every five years, like ISO9000).
At the "Pre-Final" or "Final" stage of the bid document preparation, one of my checklist items for the specifications book and the Drawings notes, was to run a date sort on (1) all of the external standards included in that contract; and, (2) all of the anticipated revision dates for all the external standards included in that contract.
I made it routine to get "draft for comment" versions of important pending changes to MIL-Specs that we'd used, (1) so my engineers would have a "heads up" that a revision was about to become official, and (2) to get everyone thinking about what the impact was going to be from those revisions
Axiom #3: *** created "time" so that everything doesn't happen all at once. This axiom applies very readily to 13 miles of public rail transit, especially when you throw in tunnels; at-grade intersections; street closings (temporary and permanent); ripping up a major city's downtown business section in January and "busting chops" to get it covered before that year's Christmas/Holiday shopping season; lots of stations, the frustrations caused by contractor claims, and the normal politics, etc.
That's where the data field for "Contracts that contain this cite" proved to be worth its weight in gold. Most of the construction contracts that dealt with refurbishing the rail along the transit line were bid at different intervals, and a large number of MIL-Specs were changing frequently (sometimes 2 revisions per year). We encountered situations where a contract awarded in (say) 1991 (let's call it Contract A), was well underway, yet the next contiguous contract for the continuing linear segment of the transit system (Let's call it Contract B) wasn't bid for 2 more years (after many revisions to some MIL-Specs). It saved "a wheel barrow" full of money to be able to list all the contractually required MIL-Specs in Contract A, and compare them with all the contemplated MIL-Specs in Contract B, (along with analysis of all of the MIL-spec revisions, A to B) during the document preparation phase for Contract B. Most of the revisions were usually miniscule, but a few revisions (to the MIL's) from Contract A time, to Contract B time, would have been purely embarrassing to my firm (had they gone out) and extremely costly (again, to my firm, since "doing it right the first time" was essentially a scope of work item in our contract with the owner of the transit system). I can recall a few MIL-spec changes from the "Contract A to Contract B" scenario where Contract B just wouldn't have worked, period.
So when you prepare your own tracking system for external standards, think broadly, with scope / schedule / cost in mind, when deciding what types of data fields to include. An absolute MUST DO item is a checklist, at your process-critical point, where someone uses the data fields you've captured about external standards.
Finally, make this question: "Is this nonconformance related in any way to external standards?" a routine question when analyzing your own Corrective and Preventive action data. That way, you won't miss an opportunity for continuous improvement, and maybe someone will generate a useful preventive action (or two, or three) as you go along.
David K