How to Test an SOP Before Rolling It Out

If you’ve recently completed a Standard Operating Procedures document (SOP), you may be tempted to roll it out without testing it. After all, you put a lot of hard work into it, right? And there’s no way you made a mistake by failing to recognize a skipped step or issuing unclear instructions.

But the truth is, it happens all the time. You see, when we get too close to something, we oftentimes see what we want to see instead of what’s actually there.

Before you release your new SOP, take a look at why and how you should test it. It just may be the difference between having a project that is a complete success and one that was just almost right.

Why Test an SOP?

No matter how much work goes into the creation of an SOP, it’s a sure bet that it contains errors. And if you created a large document, it probably has a few. But even if you somehow managed to pull off the miraculous and produced an SOP with no errors, you can still benefit from SOP testing.

Here are some great reasons why you should always test an SOP.

Catch Those Errors

Chances are, the SOP contains errors, and testing it is a great way to catch them. And that’s important. Just think, if the SOP contains an error in the customer service processes, and it’s not recognized before rollout, how many customers will be affected by it?

Ensure the Instructions are Clear

People can’t follow a new process unless the instructions are crystal clear.

Eliminate Waste and Duplication

Even if the SOP is error-free, you can still benefit from testing it. That’s because the end user who already has experience with the processes may provide some insight you hadn’t thought of. And that could save the company money by reducing things like waste and duplication.

For example, imagine that the SOP called for a customer service representative to print out a copy of the order. But when the SOP was tested, the representative pointed out that the order is printed in the step immediately following theirs.

How to Test an SOP

Before we get into the process of testing an SOP, let’s get something out of the way: no software can do this job for you.

I know, it’s not fair, is it?

But testing an SOP is a hands-on, unique operation that you will need to oversee.

However, once your SOP is up and running, you can use software like Tallyfy and Process Street to monitor things like issue tracking and task consolidation to improve your SOP even more.

But for now, you need humans to tell you if you got it right.

Now that you understand the importance of testing an SOP let’s talk about the process of doing it. Here is a four-step plan you can follow to test your SOP.

Step One: Identify the Testing Parties

Your first step is to identify the testing parties — but that may not be as simple as it sounds. Here are some guidelines for who you should use to test the SOP.

Don’t Allow the SOP Developers to Test It

Do you remember at the beginning of this article when I talked about how being too close to the SOP makes you see things that aren’t there? That’s why you should never allow the developers to test the SOP.

For instance, imagine that the SOP states that the user should assign a customer to a category and then move on to the next step. The developer knows that the user must hit the “save” button, or the information will be lost. But will a new employee know that?

In this instance, the developer was just too close to the process to test the SOP. But, these two people are perfect for the job:

• Departmental Testers: Identify testers in each department who are affected by the SOP. For example, if the SOP contains new guidelines for the customer service department, you should get people from that department to test the processes that affect them. The people who work the processes every day know them, and they will easily be able to spot an error or an incomplete action.
• Unfamiliar Testers: In addition to departmental testers, you should assign testers who don’t understand the departmental processes. These people will rely only on the information listed in the SOP, and you will quickly be able to identify any flaws or weaknesses in the instructions. New employees or people from a different department are ideal candidates for this role.

---

Step Two: Test Each Process

Now that you know who will be testing the SOP, it’s time to run the tests. To get the best results, when possible, you should do it a couple of ways.

Test it Live

The best way to ensure the SOP instructions are clear is to test it in a live environment. For example, if there are new SOP guidelines for sales representatives, have them test their processes while they’re with the customer and submitting an order or inquiry.

Test it As a Whole

After you’ve run through the SOP department-by-department, it’s time to test the entire SOP as a whole. Assign one group of testers to use the old SOP and perform the processes that way. Then have another group use the new SOP. Keep careful records and after the testing is complete, compare the results. If the new guidelines don’t improve the functionality of the department or make the process easier, you’re not finished. If they do, you’re ready for the next step.

• 

Step Three: Ask for Feedback

At this point, you probably feel ready to roll out the SOP, but doing so will cause you to miss out on a valuable opportunity.

Just because the testers completed the processes without any problems, that doesn’t mean the procedures were perfect. Now is the time to ask the testers for their feedback. Doing so may give you insight into how you can improve the SOP even more.

If you use Sharepoint, make use of DocSurvey to send surveys to each tester and ask them if there is anything you can do to improve the instructions or processes.

Step Four: Make Adjustments and Test Again

Now that you’ve received feedback from the testers, you will need to analyze it to determine whether it can truly improve the processes. And here’s where it gets tricky: you probably don’t want to make any more adjustments to the SOP. You just want to release it so you can move on to the next project.

But you also want it to be as good as it can be — the first time.

So analyze the data, but be sure to give more weight to the recommendations than you do to your desire to move on.

Testing the SOP wasn’t so bad, was it? This extra step could save you a lot of pain in the future, and that’s why it’s so important.

Now, celebrate your accomplishment by releasing and implementing the SOP!