Introduction
Standard Operating Procedures (“SOPs” or “Procedures”) capture business processes at a granular level of detail such that individuals with the requisite skills, tools, and access can execute them by following the work instructions they provide. SOPs provide the basis for continuous improvement efforts to increase organizational efficiency and effectiveness and enable the pursuit of high standards of quality by improving employee communication and coordination, increasing productivity through process improvement and reduction in organizational bottlenecks, and reducing productivity losses (as well as employee and customer frustration) due to avoidable error and associated rework.
Guidelines
Requirement to Document
All reoccurring workflows supporting defined process areas or required for delivery of defined services or execution of related service requests must be documented in accordance with this guideline.
Scoping Procedures
Consider the following factors to ensure the work in question constitutes a cohesive, well-scoped procedure, which should unite a series of related steps designed to advance toward accomplishment of an organizational goal without duplicating or requiring multiple dependencies on work defined in other procedures.
Group by goal and task dependence
Consider the immediate business objective first to identify the steps that must be followed to reach that goal, regardless of who will execute them. Any steps that are interdependent or must otherwise be properly sequenced should be part of a single procedure so that those following it can understand those dependencies and the part they are playing in achieving the goal. However, if steps may run in parallel without dependency and especially if they are executed by different people or workgroups, it probably makes sense to create separate procedures for each.
Segment by triggering condition
An actionable procedure has a limited scope, defined by the triggering condition which initiates it and the goal of the work it accomplishes. While it’s tempting to include everything related to a topic in a single procedure, doing so can overwhelm or confuse readers and prevents it from being easily used to coordinate and track work. For example, “Asset Inventory Management” is a process area too broad to be captured in a single procedure and should instead be broken into at least four separate procedures, according to the independent condition triggering execution:
| Procedure Name | Trigger |
| Asset Receipt | Procured asset physically received |
| Asset Assignment/Transfer | Asset (re)assigned to employee or location |
| Asset Disposal | Asset is physically disposed of |
| Asset Audit | Annually, April |
Naming Procedures
Use concise, descriptive, unique, subject-action noun phrases
Start your procedure name with the subject it addresses, followed by the specific action executing the procedure accomplishes, for example: “Expense Report Filing”, “Expense Report Generation”, “Expense Report Reconciliation”. Starting with the topic keeps related procedures automatically alphabetized together. Ending with the action (“filing”, “reconciliation”) makes the activity carried out clear. Using a phrase instead of a full sentence makes the name easily comprehensible and short enough to show up in list views.
Omit unnecessary words
Avoid using words that are applicable in all procedure names, such as starting the name with “How to” or ending with “Procedure”, as these redundant words obscure the topic and make searching more difficult.
Use title case
Capitalize each important word in the name to differentiate them as unique entities.
Use symbols, acronyms, & typographic symbols
While you should be cautious about using unfamiliar acronyms or abbreviations that may be ambiguous or difficult to read, using well-understood or previously defined acronyms and abbreviations, as well as common typographic symbols to substitute for words (& for and, % for percent, / for or) can keep names short and easy to parse.
Describing Procedures
Procedure descriptions provide important context for those who carry out the work. Include information making the applicability of the procedure clear by answering the following basic interrogatives as applicable in a structured manner within the description, marking any that don’t apply “/” or “-” or “Not Applicable”.
| Who |
|
| What | What is the immediate objective or end result of carrying out these work instructions? |
| Why | What is the higher-level goal that motivates executing this procedure? |
| When |
|
| Where |
|
| With What |
|
Presenting
Step-by-step Outlines
While SOPs can take many forms, from freeform narratives to checklists to , the simplest to implement and most effective for most uses is likely to be the lowly outline: easy to write, easy to read, and familiar to nearly everyone as a note-taking technique taught in school.
Since the overwhelming majority of procedures are a linear sequence of steps, outlines lend themselves naturally to their description; their list format mirrors the structure of task sequences. In addition, the outline form goes beyond a simple list, allowing the steps in any process to be grouped together into logical sections. Since human working memory is limited, such hierarchical organization allows the reader to understand the “big picture” of the procedure without getting lost in the individual steps.
Use either numbered lists (see Numbered Steps below) and/or nested Heading Styles to create outlines. See the Step-by-Step Outline Appendix for examples.
Step-by-step Tables
An alternative to an outline for especially technical procedures is one or more tables with headers. See the for an explanation and example.
Defining & Organizing Steps
Defining steps
Each discrete action necessary for the completion of the procedure’s objective should be a separate step. Sometimes it can be challenging to determine the granularity of description needed and it’s tempting to include a lot of detail which can end up leading to the creation of an overwhelming number of steps, making the procedure hard to understand and follow. If information is being provided for reference or training only, it should probably be included as content within a step (see Describing Steps), rather as a separate step or sub-step. Create steps or sub-steps when the task required for the completion of a higher-level objective (1) is critical and also likely to be forgotten or skipped if not called out , or (2) must be tracked separately for reporting.
Group related steps
When a series of steps are closely related and can be summarized by a higher-level objective or phase in the procedure, consider grouping them together as sub-steps to make the procedure easy to grasp at a glance.
Keep steps at the same logical level
For simplicity of understanding, the nature of tasks or activities should be consistent at each level of the outline. A “nit-picky” detail such as a specific action to take (“Send an e-mail with the title “Time Off Request”) should not be at the same level in the outline as a general description of work (“Request time off”). Likewise, such general descriptions should not be at the same outline as even broader section/phase headings (“Request”, “Approval”, “Appeal” …) that may be appropriate to include for particularly long procedures.
Keep subsections short
The commonly quoted “magic number” of 7+/-2 maximum items in human working memory may not be empirically validated, but it’s still probably a reasonable rule of thumb for the number of steps in an outline level. If the number of steps in a logical grouping exceeds that range, consider breaking it down into several smaller groupings at a lower level in the outline.
Include edge cases and error-catching
While it may not be possible to foresee and plan responses to every contingency, when a procedure contains known exceptions that require conditionally executed branches, or steps with a high probability of failure, include relevant decision steps with sub-steps for each conditional path or at least a general exception path for handing failures, not just the most common “happy path”.
Consider the skill of the assignees
Those already familiar with the procedure’s work requirements need much less specific instructions than those who have never done the work before. (Yet another advantage of the outline form!) An employee very familiar with the work may need only to scan the top-level steps in the outline, while someone unfamiliar can drill-down into as much detail as needed.
Use sub-steps for alternatives
As appropriate, add sub-steps describing the decision branches or alternatives in executing a given step. End the last sub-step with a period and the preceding with semicolons. Starting all but the first with “Or,” or “Alternately,” if the decision is a matter of preference, or with “If/Otherwise” clauses describing when to take a decision branch.
- Select the Assignee:
- Choose the appropriate user from the User dropdown menu;
- Or, type in an appropriate address in the E-Mail field.
- Determine Priority based on Severity Level:
- If Level 3 count >= 3, select High;
- If Level 2 count >= 3, select Medium;
- Otherwise, select Low.
Naming Steps
The effectiveness of an outline is dependent on its contents being well-written and easy to digest at each step. Since an outline allows additional details to be described at lower levels in the outline, each step should be kept short and consistent with its siblings.
Use phrases, not complete sentences
To make the procedure easy to execute, each step should be understandable at-a-glance. A concise and clearly descriptive phrase quickly conveys intent: “Return completed W-2 to HR”, not “When completed, the employee should return the W-2 form to HR.”
Use symbols, acronyms, & typographic symbols
While you should be cautious about using unfamiliar acronyms or abbreviations that may be ambiguous or difficult to read, using well-understood or previously defined acronyms and abbreviations, as well as common typographic symbols to substitute for words (& for and, % for percent, / for or) can keep step names short and easy to parse.
Name action steps with verb phrases
Lower-level steps that prescribe a concrete action should use the imperative mood to give the action prominence by starting with the appropriate action verb, for example: “Send e-mail to HR”, “Complete W-2 Form”, …
Name grouping steps with noun or gerund phrases
Very long procedures may benefit from being grouped into logical sections that describe a phase of the process rather than particular actions. If an outline level does not prescribe any particular action but merely groups together steps that in turn describe actions to be taken, start the step name with a noun phrase, such as: “Project Planning”, Project Initiation”, “Project Execution”, “Project Completion”. Alternatively, use a gerund phrase, such as: “Initiating the Time Off Request”, “Completing the Pro Forma Submission Requirements”.
Use decision verbs for branching logic
If a procedure has multiple possible completion paths based on a decision that must be taken at some step, use a decision verb (or equivalent gerund) like “decide/deciding” or “determine/determining” in the verb phrase (for action steps) or gerund phrase (for grouping steps).
Indicate actors if important
If a procedure includes hand-offs between multiple actors, consider including the role in the step name parenthetically at the end: “Complete W2- Form [Employee]”, “Approve or deny leave request [Supervisor]”). Alternatively, this information may be included as additional detail within each step, as described below.
Number steps
Use legal numbering (1, 1.1, 1.1.1, 2, 2.1, 2.1.1, …) to allow for easy cross-referencing of steps when tracking and communicating progress.
Describing Steps
While an outline has many advantages in presenting procedures, sometimes a written description is just not enough. Sometimes “a picture is worth a thousand words” (or a video, a million). In these cases, linking to additional explanatory content or reference information in the form of narrative explanations, lists, screenshots, tables, diagrams, or videos allows you to provide just-in-time training and materials for additional understanding to employees who need them without breaking the flow of the outline-based standard operating procedure.
When choosing whether to include explanatory detail as a sub-step in the outline or whether to reference it as additional content, ask yourself if the information is for reference or training only. If so, it should probably be content within a step. If not—if it’s an activity that must be performed to complete the higher-level objective of the step in the outline level above it—it should probably be a sub-step. Always create sub-steps when the task required for the completion of a higher-level objective must (1) be tracked separately for reporting, or (2) when it is critical and also likely to be forgotten or skipped if not called out independently.
Provide just-in-time training
A primary purpose of providing such additional explanatory content is to provide the detailed work instructions and training on how to perform the step’s action if it’s not obvious to everyone who may carry out the step solely from its name.
Identify acceptance criteria
Detailing the feedback or end states that demonstrates that the step’s action has been performed properly or improperly can be helpful in quality assurance.
Always include any notice of safety or other hazards that may arise while performing the step. Use the following language, styling, and ordering to consistently communicate the hazard level, in decreasing order of severity:
- Danger: Near certain likelihood of death or serious injury [call out before step explanation in red boldface]
- Warning: Possible injury or death OR serious damage to equipment [call out before step explanation in orange boldface]
- Caution: Possible minor injury or damage to equipment [call out before step explanation in yellow boldface]
- Note: clarification [call out in boldface]
Writing Style
To ensure readability & consistency in presentation, follow these standards in all formal written communication, in particular, the creation of procedural, system, and end-user documentation.
- Write with concise & formal language, written for clarity & readability, employing correct grammar & spelling.
- Dates: Use the ISO 8601 YYYY-MM-DD when specifying dates
- Time: Use 24-hour time notation when specifying times.
- Phone numbers: 10 digits separated by dashes: 847-234-2350 x170; Fax numbers prefaced by Fax:.
- Style Graphical User Interface elements as follows:
- Button: The name of any single-clickable GUI element, such as a button or hyperlink should be boldface & underlined.
- Filename: The name and/or path of any filesystem object (file or folder) should be monospace and underlined.
- Icon: The name of any GUI icon not of any other defined type in this guide should be boldface & italicized.
- Menu: The name of any pull-down or pop-up menu or menu item should be boldfaced.
- Prompt: The name of any computer prompt, including dialog box or window text, should be monospace & boldfaced.
- UserInput: Any text the user should type into the computer should be monospace & italicized.
Typography
When referencing Graphical User Interface (GUI) elements, use the following typographical conventions.
| GUI Element | Typographical Convention |
| Menu Items | Boldface, using > with spaces for submenus |
| Navigation Paths | Boldface, using > with spaces for paths |
| File Paths | Monospace, with / separating folders without spaces |
| Hyperlinks | Underline |
| Buttons & Tabs | Boldface |
| Field Names & Labels | Boldface |
| Fieldsets, Dialogs & Windows | Italicize |
| Icons | Boldface, optionally including icon image |
| Check Boxes & Radio Buttons | Boldface |
| User-entered text | Monospace with <angle brackets> surrounding parameters |
| Messages & On-screen Text | “Surround with double quotation marks” |
| Keyboard Keys & Shortcuts | Boldface for keys, using + without spaces for combinations |
Appendix
Step-by-Step Table
Description
This is an example of the Step-by-step Table documentation format, which is especially suitable for technical system configuration documentation. Divide the Setup or Procedure section into as many labeled tables as necessary to document discrete configuration or procedural steps.
Normally, the title would be the system name (Manufacturer/Publisher/Service Provider + Hardware Model/Software Title/Service Name) + specific setup steps described. These overview paragraphs would provide explanation introducing & providing context for the documentation, including the purpose of the system, its primary users, the particular topic of the documentation, any major “gotchas”.
Resources
- Replace this text with links to Web sites or other relevant documentation
- For example, relevant to the Exchange 2000 live example below, Microsoft Knowledgebase Article #Q149203
Setup/Procedure
| Format & Content Explanation | ||||
| Context | Action | Notes | Actor | Control |
| System hierarchy name: Hierarchical identification of context in which action occurs, for example server/hardware system name, software application name, window title, dialog box title. Use one double quote mark to continue the previous context to the next line. | A single, unitary step in the configuration, following Style Guide conventions. | Any necessary commentary or explanation | Which IT position or which login account, … must perform the action. Use one double quote mark to continue the previous actor to the next line. | Any looping/repeating control instructions [optional]. |
| Example (Setup): Exchange 2000 Configuration | ||||
| Context | Action | Notes | Actor | Control |
| CocoaPuffs/Windows Explorer | Activate Start > Programs > Microsoft Exchange > System Manager | LFCDS Domain Administrator | ||
| System Manager | Activate LFCDS (Exchange) > Global Settings > Internet Message Format | “ | ||
| “ | Double-click on Default * | “ | ||
| “ | Activate the Message Format tab | “ | ||
| “ | Under Message encoding, select:
|
“ | ||
| “ | Activate the Message Format tab | “ | ||
| “ | Under Exchange rich-text format, select Never Use | Kills the dreaded WINMAIL.DAT problem with attachments, per MS KB #Q149203 | “ | |
| “ | Activate OK | “ | ||
| Example (Procedure): Adding Tutors to WhippleHill | ||||
| Context | Action | Notes | Actor | Control |
| WhippleHill Pillar | Select Advising from the Current Console drop-down menu | LFCDS WhippleHill Academics or System Administrator | ||
| WhippleHill Pillar > Advising | Activate Roles | “ | ||
| WhippleHill Pillar > Advising > Roles | Enter Tutor in the field | “ | ||
| “ | Activate Add Role | “ | ||
| WhippleHill Pillar > Advising | Activate Parameters > Advisory > Add Advisory | “ | ||
| WhippleHil Pillar > Advising > Advisory > Add Advisory | Enter:
|
“ | ||
| “ | Activate Add | “ | ||
| WhippleHill Pillar > Advising | Activate Advisory > Offer Advisory | “ | ||
| WhippleHill Pillar > Advising > Offer Advisory | Select Tutoring from the Advisory drop-down menu | “ | ||
| “ | Activate Offer Advisory Course | “ | ||
| WhippleHill Pillar > Advising | Activate Advisory > Advisories | “ | ||
| WhippleHill Pillar > Advising > Advisories | Activate Tutoring — Add Advisory Section | “ | Loop 1 Start | |
| “ | Activate No Advisor Assigned | Entry created in previous step | “ | |
| “ | Activate Teachers from the Related Tasks drop-down menu | “ | ||
| WhippleHill Pillar > Advising > Advisories > Add Teacher | Select:
|
Where tutor name is the appropriate tutor. | “ | |
| “ | Activate Add | “ | ||
| WhippleHill Pillar > Advising > Advisories | Activate Add Student to Roster from the Related Tasks drop-down menu | “ | Loop 2 Start | |
| WhippleHill Pillar > Advising > Advisories > Add Student to Roster | Enter appropriate student search term in the search field | “ | ||
| “ | Activate Find | “ | ||
| “ | Select the correct student from the list | “ | ||
| “ | Activate Add Student | “ | Go to Loop 2 Start; Exit when section filled | |
| WhippleHill Pillar > Advising | Activate Advisory > Advisories | “ | Go to Loop 1 Start; Exit when Tutors entered | |
History
| Date | Reviewed By |
| YYYY-MM-DD | Replace this text with the full name & title of reviewer |
Step-by-Step Outline
Description
Following is an example of a simple outline-based procedure using a (legal) numbered list. Use hyperlinks as possible to referenced resources and related instructions. Add explanatory detail and graphics/screenshots as necessary within steps by pressing Shift-Enter to add a new line while preserving the outline level. Alternately, one may use the Heading 1-7 styles built into word processors and HTML editors to create a similar outline, a method which typically also allows the outline hierarchy to be automatically generated from the heading styles and displayed in a separate pane for easy navigation.
Departing Employee—Last Day (Example)
- Reclaiming Assigned IT equipment
- Verify unit is in good working order with all accessories
- Update Assignee, Location, & Date Inventoried in Asset database
- System Account Security:
- Delete Active Directory User Account
Doing this will automatically delete SkyDrive account at next sync. - Delete Roaming Profile folder
- Move professional development folder under \\APPLEJACKS\Employee$\ALL SCHOOL\Professional Development\ to corresponding location in ARCHIVE
- Schedule deletion of Home Directory (After yearly summer archive)
- Rename or move any shared folders on Employee or Student share
- If desktop user, remove Home Folder from Employee Server indexer
- Disable ShoreTel telephone extension access
- Delete ShoreTel account
- Remove long distance access code from ShoreWare Administrator
- Update E-911 record
- Whipple Hill Panther Portal
- If faculty, verify with registrar WhippleHill account is marked as Past Faculty
- If Staff, mark account as Past Staff
- Remove any roles assigned to person
- Remove any Content Editor Access (On Message > Settings > Pages & Content > Content Editor Access > Display By User)
- Remove any special access to persion (e.g., credit card access)
- Disable login access if deemed necessary
- Impersonate user and delete any lists created by them that they should no longer have access to
- Delete Active Directory User Account
- Record-keeping
- Enter Account Deletion date on all deleted accounts in Person section of ITIL-do
- Mark Person record as Inactive in ITIL-do
- Remove user from Employee Expertisetable (Actions > Edit in Datasheet)
History
| Date | Reviewed By |
| YYYY-MM-DD | Replace this text with the full name & title of reviewer |
Step-by-Step Outline Table
Description
Following is an example of a hybrid step-by-step outline in table format, which allows a column for the detail/explanation of each step, instead of using the Shift-Return technique in the simple legal outline above. However, the numbering to show the outline level must be done manually.
Create & Deploy Standard Operating Procedure
| # | Name | Explanation | |
| 1. | Prepare | ||
| 1.1 | Identify topic & scope | What will the procedure cover? What’s not included? Capture this in a concise summary of the contents to serve as the procedure Description. | |
| 1.2. | Identify purpose | What’s driving the creation of the procedure? Review the Documentation Drivers. Capture the purpose in a concise statement of the motivation for executing the procedure to serve as the procedure Rationale. Keep the purpose in mind when selecting a presentation format and writing the procedure. | |
| 1.3. | Identify audience | For whom is the documentation written? Capture a list of the role(s) or position(s) responsible for executing the procedure to serve as the procedure Audience. Keep the audience in mind when selecting a presentation format and writing the procedure. | |
| 1.4. | Choose presentation format | Given the topic, scope, purpose, & audience, -elect a suitable format for the procedure:
· Step-By-Step Outline, · Step-By-Step Table, · Checklist, · Slide deck, · Flowchart, · Screencast, · Video tutorial. |
|
| 1.5. | Review style guide | Review the style guide from the Documentation Policy. | |
| 2. | Compose | ||
| 2.1 | Compose first draft | Keeping in mind the needs of the audience, the emphasis dictated by the purpose, and the best practices embodied in the style guide, write a first draft. | |
| 2.2 | Edit the draft | After a break, come back to the draft with fresh eyes. If possible, offer the draft to others familiar with the procedure and/or style guide to comment on. Edit the procedure to conform to the best practices in the style guide | |
| 3. | Test | ||
| 3.1 | Test the procedure | If possible, test the procedure with someone with the relevant skills for identified role/position but who has not completed the procedure before. Observe them performing the procedure according to the documentation and note any areas of difficulty. Solicit feedback for additional improvements. | |
| 3.2 | Repeat Edit/Test cycle until acceptable execution ensured | Repeat steps 7-8 until acceptable execution reliably achieved. | |
| 4. | Deploy | ||
| 4.1 | Formalize | Complete all sections of the presentation format and route for approvals as necessary, as specified in the Documentation Policy. | |
| 4.2 | Publish & distribute | Publish the documentation and distribute to the audience with any necessary instructions to begin implementation. | |
| 5. | Maintain | ||
| 5.1 | Establish maintenance schedule | Set the necessary reminder to review the procedure for updates or termination per the Documentation Policy. | |
History
| Date | Reviewed By |
| YYYY-MM-DD | Replace this text with the full name & title of reviewer |