Work Instruction for Writing a Work Instruction

C

ccsher77

Guest
#1
Hi,
I am very new to this site but have already found a wealth of good advice and some fantastic examples on here!

Anyway I thought I would ponder this with all of the learned scholars on here;)!
My Boss has just walked into the office and said "Here's something to ponder over the festive break, how would you go about writing a work instruction/sop/tecnique card to... tell somone how to produce a work instruction/sop/tecnique card !?!?!?"

That is basically boss code speak for "Hey guess what your first job is after christmas?????:confused:

Sounds simple huh? or Maybe not!

Any input/examples would be extremely welcome
 
Last edited by a moderator:

ChrissieO

Inactive Registered Visitor
#2
Re: Work instruction for Writing a Work Instruction????

Can't offer you any examples at the moment but my main advice would be to keep it simple. Flow charts and pictures, depending on the process, are always a good simple way of doing it and easy to follow for operatives.

Keep away from loads of words:yes:

Cxx
 

Stijloor

Super Moderator
Staff member
Super Moderator
#3
Re: Work instruction for Writing a Work Instruction????

Hi,
I am very new to this site but have already found a wealth of good advice and some fantastic examples on here!

Anyway I thought I would ponder this with all of the learned scholars on here;)!
My Boss has just walked into the office and said "Here's something to ponder over the festive break, how would you go about writing a work instruction/sop/technique card!?!?!?"
That is basically boss code speak for "Hey guess what your first job is after Christmas?????" :confused:
Sounds simple huh? or Maybe not!

Any input/examples would be extremely welcome
Welcome to The Cove Forums! :bigwave: :bigwave:

A quick search on "instruction" in the "Post Attachments List" revealed this.

Stijloor.
 

Pancho

wikineer
Super Moderator
#4
Here is an excerpt of ours.

Good luck!
Pancho.

P.S. Text in green is a link to another document in our system.

=========================

a. Objective.

Explain how to write documents for our Management System and how to add them to indexes and navigation pages.

b. Scope.
Applies to all non-record documents of our Management System. Records are a special type of document. To generate records follow instructions in the applicable Form.

c. Owner.
Quality Manager.

d. Procedure

  1. Detect the need for a document: When (a) a new activity is started, or (b) a RCA reveals that documentation for a particular activity is missing (see SP: Continuous Improvement), or (c) an employee detects that an activity relevant to our quality delivery has not been documented, the proper method to perform such activity shall be described in a document as per this procedure. Before writing a new document, check if no other document exists already that describes such activity (in case such document exists, then that existing document shall be modified as may be required, in lieu of preparing a new document). To perform such check, conduct a search in the following wiki spaces:
    • QMS,
    • general wiki, or
    • Safety.
  2. Open a wiki page by adding the links in the index and navigation pages: The person that detects the need of the new document or the person assigned to resolve the applicable RCA opens the wiki page for the new document:
    • Name the new document in accordance with WI: Document Names.
    • Add a link in the applicable index by editing the index page and adding the document name in square brackets (i.e. "[AA: DocName]"). Upon adding this link, the wiki software automatically creates the link to a new blank page named "[AA: DocName]". Index pages are listed in Home and in the navigation bar at the top of all wiki pages.
    • Add a link to the relevant navigation pages. Navigation pages are linked from the Index pages.
  3. Appoint an initial author for the document: Each new document in the Management System shall be drafted by a person experienced in the activity to document. This person is the "initial author", and may be any one of the following provided that he or she knows the activity:
    • The person that created the new wiki page,
    • The person assigned to resolve the relevant RCA,
    • The owner of the process or manager of the functional area to which the document applies (or whomever this person designates), or
    • The person appointed by the RE: Administration Committee.
  4. Appoint an owner for the new document: The owner of the process or manager of the functional area to which the document applies shall be appointed as the person in charge of the new document, and she may later delegate the charge to someone that reports to her. The person in charge of a document must monitor and control the document following the SP: Document Control.
  5. Write the Content: Open the new wiki page, click on "edit this page", and type the document. Content shall preferably be as follows:
    1. Text: all text shall be in editable form, and not as an image or attachment.
    2. Tables: The wiki format is preferred for tables, but these may also be uploaded as images (see next item).
    3. After all images and screenshots, always include the source file used to produce the image in an editable format that preserves the content.
    4. Photos shall be added as viewable images, not as attachment files.
    5. References to other documents shall be added as active links.
    6. When adding files:
      • Use "Attach File", and do not compress the file.
      • Verify that the upload worked by downloading the file.
      • Certain file types may not be compatible with the wiki. In such cases, zip the file and upload as a .zip.
    7. Do not duplicate content already existing in other system documents. Instead of duplication, use links and includes. See wiki help.
    8. Annexes here describe the minimal content for the most common document types in the Management System.
  6. Add the navigation menu to the new document. Simply add [nav:start][include: Nav Area][nav:end] at the beginning of the document, substituting "Area" for the name of the Process to which the document belongs.
  7. Maintenance of the Document: every document in our Management System is maintained and controlled in accordance with SP: Document Control and improved following SP: Continuous Improvement.
 
Last edited:

db

Inactive Registered Visitor
#5
welcome to the cove! :bigwave:

My question is why do you need a work instruction? And will you need a work instruction on how to write the work instruction on how to write the work instruction on how to write the wor.........

Where does it end?

I was at a place that once has a sign that said "light switch" with an arrow pointing to a light switch. I told them that that was kinda silly. If someone did not know what a light switch was, they probably would not understand the sign. And since "ISO requires everything to be labeled", they needed a label for the sign to read "light switch sign".

The point is to use common sense. In the case of work instructions, they may vary greatly from task to task, and writing a work instruction may actually hamper the ability to have effective work instructions. For example, as a welder all i needed was a blue print as a work instruction. I would not allow anyone to weld if they could not show competence in using the equipment. An assembler might need a picture of the assembly process. A chemist might need a receipe card. Work instructions come in all sorts of shapes and sizes.... writing a work instruction for work instructions might not allow for the variation in needs.
 
#6
It's interesting you asked that question. I was hired on right out of college to write all the work instructions and procedures for a company, and had NO CLUE what I was doing in the beginning! A work instruction on writing a work instruction would have been wonderful!

However, besides all the examples in the cove, the following link was a really helpful resource:

http://www.docsymmetry.com/

Hope this helps!
 

DrM2u

Inactive Registered Visitor
#7
Hi,
I am very new to this site but have already found a wealth of good advice and some fantastic examples on here!

Anyway I thought I would ponder this with all of the learned scholars on here;)!
My Boss has just walked into the office and said "Here's something to ponder over the festive break, how would you go about writing a work instruction/sop/tecnique card to... tell somone how to produce a work instruction/sop/tecnique card !?!?!?"

That is basically boss code speak for "Hey guess what your first job is after christmas?????:confused:

Sounds simple huh? or Maybe not!

Any input/examples would be extremely welcome
Here is what I have done on how to produce an instruction. I provided a template for the document and let the creators decide on the content and format. After all, it is their document for their use so they better write it in a way that they can understand it. We use this template for procedures, forms, visual instructions, etc. So far it has worked great for everyone, although sometimes I do get asked if I am sure that it is all right to just go to town on it. I guess the light at the end of the tunnel can be blinding sometimes ... :mg:
 

Attachments

Q

QA_RA_Lady

Guest
#8
Hi there. I have, in the past written work instructions entitled "How to Write a Work Instruction." It does sound kind of silly, I'll agree with those that share that opinion. Here's the thing... I've also written work instructions entitled "How to Write a Functional Specification", "How to Wrtie a Use Case", "How to Compile a DHF/DMR". Not quite as funny are they. I think that a Work Instruction writing document is just as relevant for the quality staff, or whomever is compsing the work instruction as the other "How To Docs" are for those authors. In fact, if your work instruction author is an engineer, then the work instruction is likely to be MORE intimidating than writing a specification. I don't have a current example for this work instruciton how to, nor would I want anyone on my staff to use a sample provided by another manufacturer. Work Instructions mean different things at different companies. I've seen examples of WIs used in the place of SOPs, as well as WIs used as "best practice type documents. What I have today is a template. If you have a template that is used for the creation of Work INstructions, I'd start with that. I usually will just insert instructions with carats into the template that I'm writing the instructions for. I've tried a couple of methods for things like this, and adding instructions to templates has served the purpose very well. Example: Section: Introduction <<In this section you should describe the purpose of the work instruction. Include the person or group responsible for the creation and maintenance of the document as well as the intended audience. The introduction should include a brief, yet consise description of the purpose of the process being described in this work instruction..." You get the idea. I would do that in every section of your template. Use as much detail as is required for your employees. People who write technical documents for a living will prob pick up the work instruction riting VERY quickly, while staff members on an assembly line, etc. may requrie more instruction.

Good Luck.
 
I

ISO 9001 Guy

Guest
#9
IMO: Don't copy procedures or work instructions expecting them to fit your operations. It will never work and will cause more trouble than its worth. Instead, tailor your documents to fit your operations.

To write a procedure or work instruction, understand the objective is to convey how to "DO" a process, weaving best practices and process controls into the story of the procedure. Although "how to write a work instruction" is hard to cover in a post like this, a taste of it can be offered. IMO. Writing them can actually be fun! Be a horse whisperer.

Find someone regarded as being knowledgeable about the process (or activity) at hand. Interview them. First, ask them to describe how the process works. You might be surprised how well people understand the processes they operate every day. Once you have a general idea of what the process entails, go back to the beginning and start to document the procedure. Where a process begins and where it ends really doesn't matter, so long as it is well defined, responsibilities are clear, and it is consistent/links up with upstream/downstream processing.

A procedure describing a process describes the flow of the process, answering the following questions along the way (non-exhaustive):
What is the objective of the process? What value does it add or what function does it serve? Upon what inputs does it operate and what outputs does it produce?
What processing steps are required to achieve this output? How do you know? What constitutes "a good one"? How do you know? Is the process efficient? How do you know? What metrics are in place and what targets have been established against which to evaluate performance? What resources are required of the process . . . work space, equipment/tools/machines, personnel, methods/instructions, inspection equipment, other process controls, etc.?

To start the flow of a procedure, start with the assumption that an employee at rest will remain at rest until acted upon to do something. Ask what that something is, it very well might be an INPUT to the process. Describe how the process works, given the controls identified above. You can weave all of the above information into your description of the process while at the same time describing the flow of the process.

Describe how the inputs are transformed into outputs, being careful to ensure for example, that some form of verification is applied to product (as appropriate) at the conclusion of each required operation before it is released to subsequent operations. Again, how did you know to make this one, and how did you know how to make it right? How did you verify what you made was a good one? How can you tell? How can you tell good product from bad product? (In companies using a Traveler to control production, you hear the story once for the first operation and it's basically the same for each operation thereafter.) At the end of processing and before product is released to customers, ensure the procedure is clear what final approval is required to release product to customers, and be clear about what the record of that approval is.

Once all relevant questions have been exhausted, go draft the procedure. Write it at a sensible level, careful not to paint anyone into any corners--unless management wants the paint to control the process. Once you are happy that the procedure you have written is a sensible representation of what your process expert told you, print it and hand it to that process expert.

Ask, "Is this what you said?" Instruct the process expert to red-line the document. Based upon the red-lines, amend the document and re-submit it until no redlines are generated. Now you have a work instruction that meets the approval of one expert. (In some cases, there is just one.)

Now take the document to another expert, or to the expert's boss, as appropriate. When redlines arise, if they are significant to the process, the process experts must come to an agreement. Once agreed, the agreed language is used in the document. And so forth, until agreement is at hand. If another approval is appropriate, go through the same exercise. Once all experts are happy with it, who is there to tell you the document is not correct? It IS the procedure. Be sure it complies with any upper level documentation that might pertain. THEN it can be approved and rolled out to personnel with the expectation that it is to be followed.

This method is basically the same method for writing QMS procedures. Because QMS procedures are used to demonstrate conformity to the standard, it's useful to perform a document review of the completed procedures against ISO 9001:2008 to ensure they address/comply with the applicable requirements of the standard. Many processes naturally comply, or at least begin to comply. But where you think a process does not comply with requirements of the standard, please look at it again. If a process does not comply with the common sensical requirements of the standard, you might have real problems. Take a step back and re-evaluate.

The trick is to recognize how existing processing meets the requirements and document procedures accordingly. Don't be quick to change a process to comply with the standard; rather, try changing your idea of how the standard applies to the process at hand. If process modifications are required, bring it up to the experts as an action item. Determine sensible solutions and implement them into the process, updating procedures as appropriate.

I hope this helps! :)
 
Last edited by a moderator:

Groo3

Quite Involved in Discussions
#10
Even though it sounds kind of funny, it seems to me that it is simply a matter of perspective... Sounds like you need to create the high level control of documents (system level) procedure to tell others at the department level how to create a document?

How are your procedures controlled? if you use an electronic system, what requirements do you need every procedure / work instruction to have? what items are optional? how are they reviewed/approved? how are they controlled? etc...
 

Top