Policy vs. Process vs. Procedure PLUS How I Structure SOPs

In this video, I'm going to be talking about the difference between process, procedure and policy. And I'm also going to dive in just at the end with a little bit of an explanation of what are the key components I include in my own documentation here at ProcessDriven. Stay till the end and let's dive in. See, now, I got asked this question in a client session a few weeks back and in this, for the moment, I was kind of like, there's not a big difference. I mean, between policy, procedure, maybe there's a pretty big difference there, but between process and procedure, they're more or less the same. And as I got home or as I wrapped up from that meeting, let's be real, I wasn't leaving the house. It's Covid time. Still, as I was wrapping up from that call, I was really thinking about like that wasn't the best answer. I could have given more thought to the difference between process, procedure and policy. And I thought, let's just make it right by making a quick video about it. So. So as I understand it, there is a bit of a divide in the process community about what these terms mean. And I am not an expert by any mean in process stuff. I, as I've talked about on this channel, I am learning alongside with you. This channel is documenting my journey, not my expertise that I've built up in the past 45 years. For obvious reasons, that does not apply to me. What I'm going to explain today is the difference between process, procedure and policy. As I understand it, process is what it is what exactly you're doing. It is your workflows. It is the big picture of what needs to be done. Procedure, on the other hand, is all about how things get done. And you might say what and how feel pretty interchangeable. Yeah, they kind of do. But if you think about procedures as step one, two and three, sometimes I call it documentation. That seems to be kind of the consensus around what procedure actually means. Finally, we have policy. And policy, I believe, is more of the why. Now, this does not agree with all of the different definitions floating around there. Policy can also sometimes be considered the rules of what's right and wrong. But I like to think about policy as why. So why are we not doing it this way? Why do we take a stand? Why we do? Why is this wrong? The policy is there to explain it and to clarify it. Now, I know a lot of policy doesn't make any real justifications, but I think the policy, us as small teams can put together can provide that justification. And that logic. So when we combine all those things, we think about process as what needs to be done. The big picture, the workflows, how as procedure, the actual step by step, the checklists and documentations and templates and drafts and tools and policy as the why. Why are we doing it this way? What is our stance on this? Just defining our line in the sand. And since we are non bureaucratic small businesses that like to make sure everyone's on the same page, that policy could also use examples of why we make this stance, justifying it with logic or tying it back to the bigger picture outcomes. So in my own documentation I include all of these pieces, but the headers might be a little different. At the very top of my documentation, I like to give a clear sense of who are the people who created this, who is the person that's the resident expert on this topic, who is the person that's managing this process to make sure it's always up to date, who's doing the work really, when does this next need to be updated and who's responsible for that? And are there any other related docs or related context that might be useful? Below that I like to give some kind of purpose statement. This isn't some kind of textbook blah blah blah, talking about how this is here for the safety and security of our team. That's. That's just bullshit. The purpose statement, how I look at is really that policy stance. It's why does this matter? This is your time to make it clear to the person who's actually doing the work why the thing that they do matters. Isn't that a flip from how we normally think about policies and procedures? We think about them as these dictatorships, we're saying do it or else. But by having this purpose statement at the top, and we're putting it in these logical, easy to understand sentences, we are not being a dictator, we are teaching and explaining why the work this person does matters. That's a reframe that I think we can stick with. Once we have that purpose section down, we go to the next section, which for me is always our process. Now I use the word process, but really I mean procedure. So maybe I need to clarify this a little bit internally, but really it's just how do we do it? We know why, we know the purpose, how do we actually do it? So this is usually a step one, two, three kind of thing. And that's the main chunk, that's usually the longest portion. Below that we include some examples. So for certain things like social media posts or for responding to client support, we can give examples, good and bad, of how this has been done before. Good and bad examples help you give even more details than what you can in instructions, because instructions say this is what we want, but there's always areas you forget to explain. So by providing a bunch of examples, you can help people read between the lines and recognize the patterns in what's good and bad and maybe amend that overall process. Finally, at the very bottom of every single process that we create internally here we include an FAQ section. Now, a lot of the times this is blank for new processes, but as soon as a process is delegated, you know there's going to be questions. I've been doing a process for, say, the past few years and I finally hand it off to my assistant. I say, here we go, I've been using this process. It's perfectly clear, go ahead and do this. What's the first thing she's going to ask? Who knows? But she's going to ask something and it's really valuable for me to to answer her question and at the end of that answer say and go add that to the FAQ on the sop. The FAQ area allows us to really expand the SOP to answer the questions before they're asked. So when she passes it off to her assistant down the line or her future person, whatever that question is already answered, it doesn't need to come back up to me. I'm really, you know, exiting. And then all of the knowledge is now in her brain to pass along to whoever comes next. In conclusion, that is the difference, as I see it, between a process, a procedure and a policy. I am hugely guilty of using these words interchangeably, so I wouldn't blame you if you did the same. But hopefully the example of how I break out these section in my own SOPs will help you understand how you can maybe divide them up a little bit easier in yours. So if you found this video helpful, if you like to have more content like this, be sure to hit the thumbs up to let me know I did a good job, please. And if you'd like to see more content like this, be sure to hit the subscribe button and the bell so you are notified when things are released here. But otherwise, I think that's pretty much it for this video and I will see you guys in the next one. Thanks for watching. If you are tired of trying to piece together YouTube videos to figure out how to align your workflows, your processes and your ClickUp account, well, maybe it's time that we talk. I work one on one with a select group of clients every quarter to help people build out their systems and processes. Find out more at ProcessDriven. Go.