A written method of controlling a practice in accordance with predetermined specifications to obtain a desired outcome. SOPs are written steps to explain good manufacturing practices (GMP), plant safety routines, financial controls to secure assets, or IT security measures that employees are to follow. so we know that SOP is a step by step procedure, so when you ask how much detailed it has to be, now think as it if you would give it to a kid or teenager that they would understand what is been saying you can be well detail but you need to make it very clear that even a kid can follow that's how detail should be, you can always make something de detail but it can be confsuing so just think if u would give it to a kid how he would understand it and be able to follow without a problem.

Chris,

I see this all the time on both ends of the spectrum when reviewing SOPs. There are protocols that lack any clear directions and leave much of the interpretation up to the test engineer while others leave very little room for any sort of deviation. In my experience, the more detail the better since the procedure must be repeatable for any test operator performing this procedure. As such, I don't think too much detail can hurt but at other times it may be detrimental if its for something that is non pertinent to the test or results.

Hi All,

I would agree with those that stated the SOPs should contain as much information as possible. As soon as something is left up for interpretation, issues can occur. When issues occur and the individual followed the SOP to the best of their ability, it is no longer a user error, but an issue with a procedure. This can cause many other problems, thus it is very important to be as specific and detailed as possible to ensure if followed they will know exactly what to do.

-Andrew Nashed

I think writing SOPs are a very hard thing to do. No only do you not know when it is too detailed or not detailed enough, as the author its hard to put yourself in the shoes of someone who knows nothing about your experiment and needs steps. With that being said too much detail isn't always a good thing as you don't want a 30 page SOP as well. It is best to just have plenty of people review it or try to execute the SOP to see where it isn't clear and go from there.

Hi Chris,

I have ran into your situation multiple times. SOPs are supposed to be written in very specific details. It is also supposed to be written in a step-by-step format in order to be easily followed. Each step in the SOP should provide the technician with distinct ques about when to execute the following step. This is the best approach you should take to avoid confusion. As you have mentioned, the SOP have to be written in so much detail in order to allow anyone in the organization to perform the task described in the SOP without much training.

The best way to verify that you have written the best possible SOP that do not cause confusion is to validate the SOP by asking some of your coworkers to run through your SOP and see where they have made mistakes and fix these steps.

Best Regards,
Fady

Agreeing with everyone here, in addition I would say the SOPs should be written so someone with a high school education can read them without any confusion. Also, it varies from project to project. Some projects require a lot of detail while others you can cut down on the detail. Some projects may be very complicated and a step by step detailed version would help. While others may be simple but your over detailed SOPs may just create confusion and have the person following instructions may overthink. So a general rule of thumb, it should be like a lab experiement. Enough detail to replicate the exact experiment to produce the same results.

I agree with the comments above that an SOP is a step by step process that provides guidance to the person reading the procedures. In addition, the type of detail that goes into the SOP is crucial to accommodate any worker so if for instance you bring a person from outside the company with no prior knowledge, they can read through the SOP and be able to still provide a consistent product. One side to the SOP’s that I see that detail can provide an issue is having tight tolerances. For example, if the medical device requires to have a specific length with the tight tolerance and the employee keeps getting the wrong tolerance. It can provide that confusion of the device failing a verification step due to that tight tolerance while in reality the part is still usable. In addition, the goal of SOP’s is to also go to the point on how to do something. There are times that there are sections providing detail on why it works or any other unnecessary details that ultimately can be removed to provide a simplified SOP that gets straight to the point.

The purpose of the SOP is to create a step by step procedure to help workers carry out routine operations. So, I don't believe that there is any issue with having too much detail. The purpose of this document is for a person to read it and understand the steps, so that an individual would not have to bother another worker to figure out how something is done. SOPs should account for all issues that may come up, which is why there are tests run to make sure the SOP provides sufficient information so there are no issues that may come up with executing a task.

Great question, Chris. I had a similar problem at a previous job when I was responsible for writing and updating SOP’s as well.
One problem that I often came across was including troubleshooting instructions in an SOP. As I am sure you can imagine, describing common errors and sounds that can occur while operating was not easy and including instructions for everything that can go wrong was even more difficult. What I would often do to amend this was to include the instruction manual as an official reference document and reference it in the SOP that I was writing for further and advanced troubleshooting. This shortened the SOP drastically, while also including (or having access to) all of the necessary information to correctly operate the machine or technique.

A written SOP can never be made to be too detailed. The SOP is written as a descriptive document containing instructions on how to create a specific product. The more details written in the document, the better off the product will be made. It may seem tedious to write so much information, but it is beneficial to the company. The more details the document entails, the more likely that anyone will be able to follow it step by step. In addition, the more details involved in the document the less likely that mistakes will occur. As explanation increases in the document, it is likely the product can be created at a higher successful rate. It is important to also consider any possible that could arise within the product. This way, there is less chance for backup in the production since possible methods to solve these problems will be given.

I agree with @hm243 that SOPs should be very detailed and descriptive laying out the instructions on how to create a specific product. As Dr. Simon mentions in lecture it should be written at a HS level so that anyone can pick up the SOP and understand it and create the product. It should be written in such a way that you could just provide the SOP and someone who hasn't done it before, would be able to create it. So a little more descriptive than an Ikea manual. SOPs are usually written during or before the Design Transfer, and training must take place on SOPs which is usually done during the Design Transfer. In order to perform an SOP you need to be trained on it and it must be recorded/logged in a validated training system. A general format includes; Purposes, Scope, References, Responsibilities, Definitions, Procedure, Approvals, and Appendices.

One advice that my manager told me when dealing with a complete rewrite of an SOP or creating and SOP is to make it “idiot proof”. This terminology is used to make it clear that whatever is being stated in a procedure should:
1. Be clear: Nothing should be left for assumptions or questioning.
2. Be Concise: Get to the point, remove any detail which doesn’t add to whatever is already being stated.
A great way to test if your SOP is good quality is to have a production employee read it and have them tell you what they interpreted. If they are overwhelmed with details, then you know unnecessary information was included which resulted in confusion. If they ask you questions about the document, then you know you need to be clearer. A senior engineer told me, pictures are more receptive than words. Therefore, include pictures that label critical positions of a fixture so that someone picking up the SOP can visualize what the procedure is referencing to.

When writing SOPs, detail is very important. Your manager is correct, a random person should be able to complete the procedure. However, the in-depth details should also be concise. A concise and detailed procedure is more efficient that unnecessary words. However, it is also very important to have the document reviewed by as many people as you can. Instruction wrote can be very subjective, the best way to make an objective and concise set of SOPs is to have reviews and take note of peoples questions and concerns. I believe the best way is to write an extremely detailed procedure, then focus on making it concise and follow that by many reviews. The end product should again allow a non-versed person to be able to follow the steps.

In my experience, I add as much detail as possible to SOPs such that there is no room for interpretation because our processes are so tightly controlled. For example, right now I am developing a process to create Master and Vendor CD to ship to duplication vendors for software, media, or customer communication artwork. Much of the process would seem like standard CD burning and the user should be able to intuitively step through the command prompts. Based on my experience, the more information the better and using screen shots/pictures makes thinks a lot easier for the future operator. Honestly, my job is so dynamic that I would even forget what some processes needed if the SOP was not super descriptive and I write SOPs based on the way I would like someone to present any unfamiliar process to me.