IMO: 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!