#83 – How Standard Operating Procedures Can Help You Focus on High Value Tasks
Did you enjoy the show?
Please consider subscribing and dropping us a honest review on iTunes as well. If you do, we will send you our free training "From $0 to $1,000 / month with affiliate marketing".
What You Will Learn in this Podcast
Subscribe to Authority Hacker!
On this week’s podcast, we are joined by special guest Nigel Moore. Previously, Nigel was the Managing Director of his own IT company.
There, he and his team created over 1,000 SOP documents to record every aspect of their business from efficiency through to customer service. It basically allowed his business to run without him.
Many authority sites owners want to free up their time so that they can focus on high value activities.
So today, we are going to break down everything involved in SOPs and find out what we can learn from Nigel’s experiences.
What is an SOP?
SOP stands for Standard Operating Procedure. It is a document or a checklist or outline of how you perform a particular task or process in a business. Usually, they are part of a bigger document or set of standards such as a company manual or handbook.
Each SOP is some kind of checklist or step by step process to follow.
At McDonald’s it is how to cook and serve the chips (fries). There is a set of 15 steps or so that they have to follow. That in written form is an SOP.
At McDonald’s they are big on consistency where everything is the same all over the world - even down to the way that they fold the bag towards you when giving you your meal.
Nigel’s company didn’t need to go to that level of detail but it is around 30-40% there. It was an IT support company with around 150 clients so they tried to document the recurring processes as much as possible.
There are a lot of moving parts in IT, so when it got into infrequent queries, they documented the general approach to that topic but not the step by step process itself.
Why would a business want to create SOP Documents?
Nigel knew why he wanted SOPs. Simply because he knew he wanted to scale the business but it took some work to get buy in from the team.
The team were working really hard in the day to day. There is never enough time in the day as it is, so brining in another element where they not only have to do the work but the need to document it as well.
It took a bit of effort to win the team over.
He read a book called The Checklist Manifesto by Atul Gawande. One of the aerospace companies was building a fighter plane to go and fight in the war. During one the test flights, it took off and crashed.
After doing a review, it turned out that the plane was too much for one person to handle without a checklist. There was too many controls and too much going on for a person to keep in their head.
This became a turning point in flight. It changed flying from being a thing where a pilot can just jump in a plane and go. From then on, it became a process with checklists that required preparation before taking off.
Nigel took this story to his business. Over the past 5-10 years, the complexity had increased to such a level that it was impossible to follow each and every step without forgetting something. As smart as the team was, it was beyond the level of the human brain to keep each of these steps. It allowed them to move away from focusing on remembering the steps to increase the level of service and other things.
It obviously didn’t happen overnight, but over a couple of years, it really cemented itself in the organisation and made a big difference.
Refining and Improving Processes
A big part of SOPs is that they force you to think about the process.
When you are actually writing down the steps involved, you start to think why you are doing things the way you are or notice little things that are not necessary.
For example, Nigel’s company used to have a 20 step process to setup computers for clients. They knew how to do it so there was no need for written processes.
After they started the SOP project, this process was also checklisted. Once this was done, the 20 steps were on paper instead of in the engineers’ heads. This allowed them to focus on how to make the experience amazing for clients.
They decided to leave a hand-written note with their contact details on it with a little chocolate attached. As trivial as this may seem, this little bit of extra effort showed how much the company cared and differentiated them from the competition.
It was only when the process was written down that they could remove themselves from the day to day and see the bigger picture.
The only way for this to work is to have a culture of documentation.
A top down approach will not work because single person cannot know all of the processes of an entire organisation. You need to get everyone involved in creating documentation, editing processes, creating processes and improving processes.
The whole team was engaged in how and why they were documenting process rather than dictating to them how to do it.
How to Get Initial Buy-in?
At first, Nigel was telling the team how to do it but it didn’t really take off.
So, Nigel got the team involved and they had a whiteboard session. The team had their own ideas on how to do things based upon their day to day experiences. This really opened Nigel’s eyes to how things could be done differently and, because it was their won idea, there was buy-in form the team.
But, to actually get the team to do it, Nigel used a special technique that he likes to call “bribery”.
He bought a big stack of movie tickets. Whenever someone did things well, they were publicly rewarded with a movie ticket. This inspired the rest of the team to think that if they did something well that they would also get a reward.
How Much Were You Initially Involved in Creating the SOPs?
For the first 50, Nigel was probably about 90% involved. He wanted to make sure they were at a certain level before he let go of the reigns.
In fact, Nigel create the company’s first ever SOP which was “How to create an SOP”.
It's like SOP inception
He wanted to set an example.
Nigel started off by doing it himself and kept on doing it until he got the rest of the team involved.
The Framework for Creating an SOP
Although there was a framework for creating SOPs, the team found a way of creating them that was really easy for the people who would be using them to follow.
At this point they were kind if deviating from their own SOP for creating SOPs.
One of the issues was that the team did not find themselves updating the old SOPs when processes updates or morphed into something else.
This was definitely something that the team needed to improve upon.
On the other hand, you cannot detail every single step for every single process.
The SOPs were more based upon outcome rather than the process itself.
What Can You and What Can You Not SOP?
Going back to The Checklist Manifesto, an interesting part of the book is where they discuss surgeons in operating theatres. The debate here is what parts of an operation should be involved in a checklist and what shouldn’t.
As an IT company, Nigel’s business could have thousands of different issues raised per year. Instead of creating an SOP for each and every issue, they created SOPs on how to handle any issue.
It is more providing a framework to complete a task within rather than necessarily as step by step guide for every SOP.
What Should be in an SOP Documents?
Nigel and his team used a tool called Confluence. It is a wiki tool.
Within there, there as three areas that were mapped to areas of the business. There was finance & accounting,
Finance & accounting was broken down further into areas, such as procurement.
There was a sales/ admin role in the business. Inside the sales/ admin areas of Confluence there was a daily tasks SOP. This SOP was simply a 12 links to the other SOPs that the person has to complete that day. This works really well for transactional roles.
There was also a client area.
In here, there was an area for client specific issues. There was another area for client specific SOPs and checklists. Then there was also client documentation.
The final area was the service delivery area.
In here, there was a list of all of the global tasks.
When Do You Create an SOP?
The goal was to create an SOP every time.
Even if an issue has only occurred once, they would still map it.
The loose rule in the business was that “at any one time, you should be creating an SOP, editing an SOP or following an SOP”.
The team wasn’t perfect but they probably followed this rule around 60-70% of the time.
The lesson here is that you don’t have to be amazing at it. You just need to do it regularly. Just starting it id good enough and as long as it is consistent it will grow well from there.
How Did You Improve Your SOPs?
For the most commonly used checklists, there was a formalised improvement process where more than one person would sit down and look at ways to improve the process.
However, in general, it was ingrained in the culture that when you are working through a checklist, you try to think of ways that you can improve it.
Do You Monitor and Sign Off on SOPS?
The company had to be careful with certain topics (such as security, passwords, etc.) so these couldn’t be updated.
But, in most cases it was the people doing the day to day jobs that were updating the SOPs. Nigel has the philosophy that if he can’t trust his staff to update them then they had hired the wrong people.
Occasionally, the inputs were not amazing. In these cases it was just about helping people understand why it wasn’t so great. Luckily, everyone updating the system was doing so for the benefit of the company, even if it was not a great update.
How to Get a New Hire to Buy In to the Culture
The best way to do this is follow a simple process.
The first time doing it, you write the SOP while the new hire watches.
The second time, get the new hire to do it while you watch.
Finally, leave the new hire to do it themselves the third time and be on hand to support if needs be.
For the new hires themselves, it can be really useful for them to find written processes that they can follow and complete. There will be a lot of value from these SOPs immediately for a new hire.
What are the Biggest Mistakes in Creating SOPs
The biggest mistake initially was not getting the team involved in the problem.
At first, telling people what to do didn’t really work. It was only when the team got involved in solving the problem that there was real buy-in.
How Old Was the Business when SOPs Started?
In Nigel’s opinion, he waited too long before he implemented SOPs.
He realised that he was a holder of knowledge who was involved in too much at the same time. He needed to remove himself from some of it.
It was hard for everyone to find the time to document tasks. So, instead of documenting the full process each time, the team were asked to spend up to 5 mins adding to the SOPs.
It’s the Team Sky Procycling approach. They always talk about the aggregation of marginal gains. All of the tiny little improvements and details that they pay attention to add up into making them a winning team.
Did SOPs make the business easier to sell?
When the business was sold in 2016, it made the due diligence a lot easier.
It meant that the new people were able to jump in and take over rather than have Nigel and his business partner stick around and commit time for a period after the sale.
In the IT support industry, there is generally a 12-24 month transition period. For Nigel, this was nowhere near the industry standard when he sold his site because of the documented SOPs.
There is a new person coming into the Customer Support team. What would that SOP look like?
The first thing to do is to make sure that there is one person leading and responsible for that, even if there are multiple people involved.
In Nigel’s business, this was the operations manager. Her good was to liaise with payroll to make sure they set everything up there.
One of the steps was for Nigel to have a welcome call with the ew hire to introduce himself. So, written in the SOP, the task was for the operations manager to go and ask Nigel to arrange a welcome call.
You can see here that the task is not Nigel’s but the operation manager’s. This is because she is responsible for the entire process.
If there was a more feature rich system, it would be easier to have people responsible for individual tasks that allows the checklist to be owned by multiple people but if you are using a basic system it only really works if there is one person in charge making sure things get done.
Is there a definition of Success for an SOP?
The biggest definition of success for an SOP is whether or not people actually use them. If people do not use them, they are probably too complicated.
If it is easy to use, it can be found within 5 seconds, if they can use it and follow it then it is successful.
The whole point of SOPs is that it has to be useable for those who are going to use it. It has to have a good structure, be easy to create, edit and understand. It also has to be easy to find.
Were there any naming conventions?
There were some tagging conventions but things were organised in a way that was easy to find.
There was only three levels. This meant that every single SOP was no more than 3 clicks away from being found.
A great book to help you categorise things on your site is Traction by Gino Wickman. It discusses business structure and how things should be broken down.