A Step-By-Step Guide to Making Sops

We need to talk about shoelaces.

How do you tie yours?

Silly question. You probably couldn’t care less.

I found out today that there’s scientific research being done on the topic (lol).

But I digress…

You learned it from your parents or at school, and that’s probably how you’ve done it all your life. No questions, no thinking - Just do it (shoe pun intended).

Imagine if a routine task like this would take brainpower every time. Every time you want to get out of the door, you’d wonder how you would solve this today.

Crazy, right?

But that’s exactly what we’re doing in our projects all the time.

And to stop that, you need to make Standard Operating Procedures (SOPs).

Your SOPs set the bar for quality

Now, I hear you thinking…

“Wait” .. You’re the guy who tells me to build a team, tell them why & what, and they’ll figure out the how.

“And now you’re telling me to write procedures?”

I know. Hear me out.

I’m here to argue that SOPs create freedom. They don’t take it away.

You don’t create an SOP for complex problems or creative work. Instead, you standardize anything that occurs 3x or more.

Why?

Just like with tying your shoelaces, it frees up mental capacity for the stuff that matters and ensures you don’t trip over poor quality (last pun, I promise).

But my project is special!

I know. Every project is unique by definition.

But think about it for a minute. What are some things you do within a project on a regular basis? Here are a few to get your brain going:

• Time reporting

• Travel expenses

• Publishing a revision

• Onboarding a contractor

• Producing a regular report

• Getting signoff from the client

• Setting up a test plan for something

I bet anyone on your team does these on a regular basis. And the first thing they do? They search their “sent items” for how they did it last time.

So they’re actually using an SOP already. It’s just a personal one, and it’s probably wrong and/or outdated.

Time for an update!

Let’s get on the same page

SOPs often get confused with processes, systems, or policies. Let’s start with my quick definitions.

A policy is a description of “how we do things here” - a guiding principle. Usually set on a company level, they describe things like the norm for wining & dining clients or business travel.

A system is a multi-step process. It involves multiple stakeholders, uses multiple data sources, can happen at different moments in time, and takes something from A to Z. Example: billing a client.

A process is a subset of a system. It’s multiple steps but done by a single person at a single point in time. Example: sending a newsletter.

A standard operating procedure is a detailed set of instructions someone needs to do an unclear task, as part of a process. This is the scaleable version of having someone next to you, walking you through the task step by step. Example: logging your travel expenses.

SOPs are an opportunity for everyone

Before your team cancels you for the idea, it’s important to see that an SOP is an opportunity for everyone. Sell them on this, and they’ll be convinced an SOP is the next best thing since sliced bread.

Let’s take three quick examples from someone on your team.

A junior hire will be happy with any kind of guidance, as it’s a learning opportunity. They see how someone with more experience would do something, and they don’t have to disturb anyone to get the job done.

The senior people on the other hand? They’ll be happy you take away some cognitive load, and that they don’t have to answer the same question every day.

That leaves us with the eager beavers on your team. They’ll want to shine, and letting them create SOPs is the opportunity.

It forces them to think through why they do a task a certain way, see the big picture, and explain themselves in a concise way. They can take ownership and show their clever way of solving something to everyone.

And you? You’ve just helped different people in your team in different ways with the same document while increasing quality and efficiency.

Everyone wins.

What makes a good SOP

A good SOP answers a whole list of W-questions.

• Why do this?

• Who does this?

• What steps are taken?

• When is this performed?

• How do you do it in detail?

• How does it fit in the big picture?

It sets a clear expectation, gives the reader everything they need, and takes them from A-Z through the task.

Let’s look at each element of a good SOP in detail.

1. Title: a clear description of the task being performed.

2. Purpose: explains why this task is done, and how it fits in the big picture.

3. Scope: shows the beginning and end of the task. In complex processes, a visual of the total process helps a lot here.

4. Timing: shows when this task is done, and how long it should take.

5. Responsibilities: identifies who performs this task.

6. Risks & pitfalls: what are common mistakes or risks?

7. References: points to any document or application that’s needed to perform the task, including login instructions.

8. Escalation & questions: shows where someone who is stuck executing the SOP can go with questions.

9. Owner & approver: Shows who is responsible for maintaining this SOP, and who approves it.

10. Version history & update cadence: shows changes and when the next revision will be made.

11. Success definition & example: link to an example of a successfully completed task using this SOP.

12. The steps to complete! In detail, one by one, so they can be checked off during execution.

How to turn a good SOP into a great SOP

One word: visuals.

Show, don’t tell. Use screenshots, diagrams, or my personal favorite: a quick video.

I use Loom for this (not a sponsor, I’m just a fan). After you’ve made the SOP, record a quick video of you performing the task exactly like you describe in the SOP.

Loom lets people see, hear, and follow along like you’re sitting next to them and showing them exactly what to do.

I’ve found that 90% of people will just watch the Loom and use the written SOP as a reference afterward. It’s a fantastic use of everyone’s time.

Sounds like a lot of work? Just steal my template!

So how do you ensure that all SOPs are up to snuff?

You guessed it. You make an SOP on how to make SOPs.

Or you save yourself the headache and steal my template:

Join the list and reply “Template” to the welcome email - I’ll send it to you ASAP!

Tying it all together

I’ve said this 100 times: your job as project manager is to make the implicit explicit.

A clear SOP is the perfect example of that. Help your team to do something efficiently and correct the first time trying, without turning it into micromanagement. Simplify it without dumbing it down.

If the above seems like a lot of work, remember two things:

1. SOPs carry over from project to project. It’s an investment you’ll make once, and the savings & standards you create will carry you for years.

2. 90% of the above will only be referred to if needed. Every time that’s done, it’s a question you didn’t have to answer. That’s leverage right there!

Put all your individual SOPs in a catalog, and start saving your entire team time today.

What’s the first thing you’ll standardize?

Cheers,

Jasper