Drafting SOPs
Tips and Standards of how to writeup a Standard Operating Procedure
This page will discuss how we write and format SOPs to be included in our SL-OS site, this isn’t intended to discuss the content but more about how to technically draft the pages.
Resources
Editing SOPs
The publishing sop page has information on how to publish this your changes, but this page will discuss how to make those changes.
Techniques and Parts of our SOP
Although there are no hard-and-fast rules as to how our SOPs should be formatted, we want all our documents to look relatively close to the same and contain roughly the same information. A good guide for this would be to look at the source code or mark up for this page by clicking on Edit in Git Hub.
The top section should contain a header block that contains the title, key words and status as well as how updated and when the page was updated. This block should be on all pages and follow the format. Again for an example, you can review this page. Providing this header block will let us maintain the status and some basic information as to changes that were made.
The first line should be a title such as
# My Title
This should jut be a couple words and should be the same as name of the links.
The second line should be a little more of a description of the content such as
## This is a little more help
Again look to this file for an example.
Note the # signs, 1 is the top level title 2 for the second level.
After that have one or two sentences that describe the content of the SOP, this will just be in plain text
This is a sentence or two that will describe the what's and the why's for this SOP or give a brief overview.
The rest of the body should be dictated by the needs of the SOP but we should make use of headers with the # sign, have ample white space, and use list notation such as order lists with
1. Item One - a sentence paragraph or what ever we need to make the point
2. Item Two - a sentence paragraph or what ever we need to make the point
3. Item Three - a sentence paragraph or what ever we need to make the point
Which translates to:
Item One - a sentence paragraph or what ever we need to make the point
Item Two - a sentence paragraph or what ever we need to make the point
Item Three - a sentence paragraph or what ever we need to make the point
Or bulleted lists such as:
* Item One - a sentence paragraph or what ever we need to make the point
* Item Two - a sentence paragraph or what ever we need to make the point
* Item Three - a sentence paragraph or what ever we need to make the point
Which translates to:
Item One - a sentence paragraph or what ever we need to make the point
Item Two - a sentence paragraph or what ever we need to make the point
Item Three - a sentence paragraph or what ever we need to make the point
A section of resources might be helpful but not required.
Tips for writing our SOPs
Understanding the right level of detail
In most cases, the goal of an SOP is not specify in very detailed steps on how to do a particular task. People work differently and things that work for one person, don’t work for another. The real goal here is to provide guidance on the things that must be done as part of performing the work.
In some cases, we want to provide a very specific set of steps that need to be performed. This is usually the case when we need to use some sort of tool or software. Providing that level of guidance here is critical in that if you don’t do things in the right order the right way things just won’t work.
Less is more
If you write a long procedure, chances are no one will read the whole thing and it won’t be adopted. Try to make your SOP as concise as possible and only add in the required information.
Key it simple
As with the previous tip, the more complex the press the less likely the SOP will be adopted.
Use existing resources
We have a SOP on how we use GIT. We should define our expectations as to how GIT will be used on our projects. Creating material on how to do specific things on GIT might not be the best use of our time, however finding some good web sites, video or tutorials and providing those as links/resources would be a good use
Consider the audience
If you are developing an SOP on how to code an algorithm, it’s likely fair to say your target audience knows how to open visual studio, create a new project and so on.
If you are developing an SOP for how to draft SOP’s and it’s using Visual Studio code, providing resources on how to install and use that product would be helpful.