AS9100 - 7.2 Contract Review - How others do Contract Review in a documented fashion

G

Garry

Hi

I am looking for ideas to see how others do Contract Review in a documented fashion. Purchase orders often refer to codes and other specifications (SQAR). In essence, a purchase order can be a very complex document. What tools do you use to translate the requirements on the p/o into something easy digestable for other departments within the organization? How do you capture the essence of all clauses so it is understood and followed on all levels of the organization? Any examples are most appreciated since this kind of contracts is new to us. We used to have a simple Contract Review checksheets (1 page), but as you can appreciate, this isn't good enough anymore.

Thanks
 

Wes Bucey

Prophet of Profit
Garry said:
Hi

I am looking for ideas to see how others do Contract Review in a documented fashion. Purchase orders often refer to codes and other specifications (SQAR). In essence, a purchase order can be a very complex document. What tools do you use to translate the requirements on the p/o into something easy digestable for other departments within the organization? How do you capture the essence of all clauses so it is understood and followed on all levels of the organization? Any examples are most appreciated since this kind of contracts is new to us. We used to have a simple Contract Review checksheets (1 page), but as you can appreciate, this isn't good enough anymore.

Thanks
All contract reviews are essentially the same - it doesn't matter whether your organization is registered to ANY Standard or couldn't give a fig if it ever got registered:

Everybody necessary at the supplier gets together (cross-functional team) and determines:
  1. Do we understand everything the customer wants or expects?
  2. Do we have the capability to make this product or perform this service as we understand the customer wants it?
  3. Do we have the capacity to make as many as the customer wants within the time frame he wants them without injuring ourselves or any of our other customers?
The customer should be asking similar questions when he looks over a contract:
  1. Does this supplier really understand what we want and expect?
  2. Does this supplier have the manpower, equipment, and knowhow to make this product or perform this service as we want it?
  3. Does this supplier have the capacity to make our product or perform a service for us without injuring itself or any of its other customers?
When anybody on the team is unsure of the meaning of any part of the contract, he just asks questions until he is sure.

The only kicker I can see for an organization seeking registration to a Standard is for them to document they perform the contract review substantially the same way every time, just as a pilot should make his preflight check regardless if he is flying to the next town or the next continent.

Added in edit:
(Did I need to say that part of "as we want it" includes the net cost in place of the product or service?)
 
Last edited:
G

Garry

We use a cross functional team and sign off team feasibilities both, for quotes and contracts. However, the contracts I am talking about are really complex with lots of hidden codes and clauses. What tools do you have to capture these codes and clauses and translate them into action on all levels within an organization? How do you ensure repeat contracts are capturing the same information’s? How do you do it if you have several customers all with their own special codes and clauses? Do you have a memory jogger a team runs through and becomes a traveling work sheet for the various departments to adhere too? Any examples?
 

Mike S.

Happy to be Alive
Trusted Information Resource
If I understand your question...

What do you normally use to get info to the production floor for "simple" jobs? A "traveller", "router", "job sheet", "work order"?

Someone has to translate the customer requirements, including the meaning of various codes, clauses, etc. into words the production people understand and put this info. on the router or whatever.

Does this make sense?
 

Wes Bucey

Prophet of Profit
Garry said:
We use a cross functional team and sign off team feasibilities both, for quotes and contracts. However, the contracts I am talking about are really complex with lots of hidden codes and clauses. What tools do you have to capture these codes and clauses and translate them into action on all levels within an organization? How do you ensure repeat contracts are capturing the same information’s? How do you do it if you have several customers all with their own special codes and clauses? Do you have a memory jogger a team runs through and becomes a traveling work sheet for the various departments to adhere too? Any examples?
In my career, I have reviewed, "vetted," and edited literally hundreds and hundreds of "contracts" ranging from simple purchase orders to complex hundred page contract documents. I have also written dozens of multipage contracts from scratch.

Over the years, I have found several techniques (none created by me, but willingly adopted and adapted by me) to organize such documents to ensure nothing gets lost or misinterpreted or skipped over in the fine print. Some of them may be workable in your situation.
Create a basic outline of the 6 bare bones elements of a contract
1. Intention to create legal relations
2. Offer and acceptance
3. Consideration
4. Capacity (legal capacity to contract)
5. Genuine Consent (without a mistake about the nature of the contract or undue pressure or misrepresentation)
6. Legality of objects

Use these as major headings throughout the contract. Use subheadings below each major heading to identify (for easy and ready retrieval or inspection) sub elements and consider adding a Table of Contents or even an Index (both easily added using features of modern word processing software.)

There is an added part of contracts which is "shadowy" under most laws - that is the list of "representations" made by either party, which may need additional proof to make the contract valid or can merely be accepted as true by the other party unless later events prove them false. (Under "capacity" for example, supplier may represent itself as legal distributor of brand X, but may lose its status as legal distributor before delivery of the goods listed in the contract.) Each situation is slightly different on the amount of "proof" required as an exhibit to the contract for each representation made. Where such proof is added as an exhibit, the contract should refer to that exhibit as the representation is made ("Proof of which is attached as Exhibit 15A.")

So, if each contract you deal with is held up to a Standard Outline, the drilling for information contained in the contract can be eased considerably by grouping the information according to that outline.

A real sticking point with complicated contracts is the reference to obscure codes and definitions which are NOT contained in the document itself. The important point here is to consider whether the likely audience reading and using the contract has those references readily available. If not, they should be attached as exhibits or, in the case of definitions, as a GLOSSARY, which defines the terms as they are meant in the contract. (For example, I might know what a PPAP is, but my CFO, who has to sign off on a big contract, might not.) One technique I have used recently is to put such words or phrases in bold face with an explanation at the beginning of the contract that bold face material is defined in the glossary. Therefore, the flow of the contract is not disturbed by inserting the definition with the regular text, hindering the reading of folks who do know what the terms mean.
[Added in edit: electronic versions can have links to notes or "popups" with the definition of the word or phrase as intended in the document.]

If we are creating a contract for services, the Consideration section of the contract ought to spell out plateaus of achievement, at which point the supplier may receive partial payments, or the contract canceled if the plateaus are not reached by fixed dates.

Most important - regard for the audience of the contract
In all regards, the most important factor in creating a contract is to ensure the proposed parties to the contract are able to understand every portion of the contract and ambiguous or special terms are fully explained and that referenced documents are readily obtainable and available for the parties to use as a reference. (Lawyers are expected to be familiar with statutes and have ready access to them. A machine shop owner may not. Similarly, that same machine shop owner may not have access to Daimler Benz customer specific requirements if he is fourth or fifth tier down in the supply chain.)
 
Last edited:
G

Garry

Thanks so much Wes, your explanations are most appreciated. I suppose, there is no generic template, it really depends on the organizational structure and the contracts.
I will take your suggestions and put something together and maybe after some time we find a "standardized" version.

Thanks again
 

Caster

An Early Cover
Trusted Information Resource
Look towards QS 9000?

Garry said:
I am looking for ideas to see how others do Contract Review in a documented fashion. Purchase orders often refer to codes and other specifications (SQAR). In essence, a purchase order can be a very complex document. What tools do you use to translate the requirements on the p/o into something easy digestable for other departments within the organization? How do you capture the essence of all clauses so it is understood and followed on all levels of the organization? Any examples are most appreciated since this kind of contracts is new to us. We used to have a simple Contract Review checksheets (1 page), but as you can appreciate, this isn't good enough anymore.Thanks

Hi Garry

Life is a little simpler for us auto suppliers. QS 9000 tells us exactly how to translate PO requirements into actions for departments.

In QS 9000 contract review morphs seamlessly (at least we wish it did) into Advanced Product Quality Planning APQP. Customer requirements are rolled out from the PO to production over a series of project stages.

If you are unfamiliar with APQP, Marc has a fantastic slideshow on the home page. It may be what you are looking for.

Another thought is to do the exact opposite. Create a standard capabilities list that details what your company can do day in and day out. Tolerances, deliveries, etc. Then compare the PO to this to generate gaps and actions.

Contract review needs the best and the brightest. Someone who will stay awake as she wades through 400 pages of "SQAR" (sounds awful). The company can be lost through not understanding the requirements. Sadly, this activity often does not get the attention it deserves.

Good luck
 
Top Bottom