Build SOPs People Will Actually Follow
Most SOPs are written to exist, for someone to point to when something goes wrong, to show how it should have happened. They're usually not built to be actually used. They are comprehensive, carefully formatted, stored in a drive somewhere, and completely ignored 90% of the time by the people who are supposed to follow them. The problem isn't the people (albeit sometimes a culture shift has to happen as well), often it's the way the SOPs were built.
So, why do SOPs get ignored? Usually they were written by someone who doesn't do the work and therefore describe the ideal process, not the actual one. So many processes get labeled as "edge cases" that the process ends up not reflecting the day-to-day that workers experience, or every edge case is included and the document becomes illegible. Whether or not they include edge cases, they often end up so long-winded that they're not useful in the moment, especially since they're usually in a separate document or drive that requires a separate trip to find. Finally, usually nobody is ever accountable for whether or not they were used, as long as the job gets done to some degree.
When developing SOPs, to ensure they are actually followed, I like to follow these basic principles:
Write with the practitioner, not for them - the best SOPs are co-created with the person doing the work. They validate the current process, capture the best practice, and identify decision points that require other stakeholders or guidance.
Optimize for usability - in my opinion, the most important. Keeping the process as succinct as possible and creating guidance systems to support it in the more complex areas is much more effective than creating an overly complex SOP. Visuals, checklists, and decision trees are also helpful.
Put it where the work happens - embed it into the workflow, either physically or digitally. Make it organized and easy to access and, ideally, within arms reach within a few seconds.
Build in a review cycle - SOPs will always evolve, and a dated or inaccurate SOP is worse in some ways then no SOP, where employees are actively mislead on what they should be doing. Adding in a review cycle every quarter or every 6 months is critical.
Add accountability into problem solving - this does NOT mean pointing the finger. When something goes wrong, because things always go wrong, walk through the process that was followed, and see if it aligns with the SOP. If not, ask what about the SOP was hard to follow at that stage and try to improve the usability. If yes, see how it can be improved or what edge case hadn't been considered. And in the rare cases where an employee is purposefully not following the SOP, this approach can help understand why.
A great use case I like to reference on implementing these principles is when I was building a new SOP for an estimating department.
Before building an SOP, I shadowed the team for a couple of weeks, then dove in and worked the job for a couple more weeks alongside them. I spoke with sales and the shop, understanding our inputs and outputs and what the challenges were. Taking the information from the people that had done the work, I built the first draft of the SOP (Principle #1). Using a simplicity-first approach, I built a one-page-or-less document for each of the major processes; this brevity let newer employees learn and understand the process very quickly. To that base, I added supporting materials called "Quick Reference Sheets", which were geared towards helping streamline some of the more complex estimating tasks, and were clearly broken out and marked. (Principle #2) I printed out the SOP and the Quick Reference Sheets, put them in binders and put them at everyone's workstation. (Princple #3) I gave everyone two weeks to try out the SOP and the Quick Reference Sheets and asked them to mark up their binder copies with notes, comments, feedback, and criticisms. When they gave their feedback to me, I evaluated it and almost always implemented it. (Principle #1) I added a review cycle for every 6 months (Principle #4) and built a regular feedback loop alongside it. I also used the SOP as a tool to not only discover where in the process problems were coming from, but figuring out how to fix those problems and hold the team accountable to a high standard (Pricinple #5). The result is that the department is more efficient and effective now and is still adherent to the SOP over 2 years later.
