Write standard operating procedures
Communication is key to a program manager’s job. That includes communicating to your future self and to your successors. When you document how to execute a process, that ensures you’ll do it right the next time. This documentation is called a “standard operating procedure” (SOP). That’s a fancy name for what is essentially a recipe.
Why have an SOP?
Even if you perform a task regularly, having a documented standard operating procedure helps you perform it consistently. Successful program management is the absence of surprises. Don’t interject your own surprises by being inconsistent in how you handle routine tasks.
If you don’t perform the task regularly, you almost certainly can’t rely on memory to compete it. Plus, if you want to spend a week on a lush tropical island, documented procedures mean that someone else can cover your work.
SOP philosophy
Your documentation should be easy to understand. Avoid jargon where possible and expand acronyms. Be direct. Explicitly say who does what.
Remember that the goal is not to explain why the process exists, provide historical context, or ruminate on philosophy. You can (and should!) write additional documentation that provides this information, but the SOP should focus on the steps.
SOP format
There’s no One True SOP Format, but it’s best to be consistent. This is the format that works well for me:
- Description. One or two sentences about the procedure, with links to additional information.
- Trigger. What causes the procedure to happen? This could be a time on the calendar or the release schedule. It could also be an event.
- Procedures. The actual steps you take. More on that below.
Writing the procedures
I prefer to write procedures as an ordered list. This makes each step clear and allows you to easily refer to other steps. If you have related-but-separate tasks, you can put them on the same page as separate lists, perhaps separated by headings.
Each step should be as copy-pastable as possible. Give the exact command to run and arguments needed. If that varies based on conditions, clearly articulate the conditions and how the commands change. If the step involves a query, include a link to the query when possible.
Sometimes you need to give a warning about what could go wrong with a particular step. Include the warning before that step occurs. Otherwise, you may be sad.
Test the SOP
Once you’ve written your procedures, you need to test them. Try them out yourself. What did you do that you forgot to write down? Give them to someone else. What knowledge did you assume that needs to be documented?
Over time, your procedures will change. Make sure that after you use an SOP, you go back and update it with any necessary changes.
This post’s featured photo by Thomas Bormans on Unsplash.
