SOP Friday: When Policies and Procedures Become Obsolete

From time to time, policies and procedures become obsolete. So ... of course ... there has to be a standard operating procedure for "decommissioning" policies and procedures.

- - - - -

Sidebar: What's the Different Between Policies and Procedures?

Policies are general rules. Procedures are steps taken to implement those rules.

Policies should be general so they are flexible and scalable, and do not have to change whenever products or technologies are adopted or retired. For example, your organization needs a policy requiring that systems must be protected against viruses and malware. That is all that the policy should say.

You should also have written procedures identifying the tool(s) you will use and your configuration requirements to comply with the policy. If you change products, you can change your procedures without going through the organizational process to modify policies. As new technologies like tablets and smart phones (and who know what will be next?) are adopted, you will not have to change policies as long as you did not address specific technologies.

- - - - -

Changing Procedures More Frequently

Given the different nature of procedures vs. policies, you will change procedures much more frequently. For example, your checklists for new servers and new desktops are likely to change at least once a year. Changes to service packs, hardware choices, and software versions may require these procedures to be updated more frequently than that.

In a perfect world, policies will change very rarely. But changes will happen.

Three Places to Record Changes

When Policies and Procedures become obsolete, you will need to make changes in three places: Paper records, your PSA, and your electronic files.

Paper records may exist in your SOP binder, in client Network Documentation Binders, and in various places around your office (such as pinned to a bulletin board). But don't freak out. That's about it. Your policies and procedures should not be scattered all over the place in paper format.

Depending on how automated you are, you may not have anything in paper format. But I doubt that you're 100% paperless.

It is very important that you do not destroy old written paper documentation - especially if it includes client-specific information such as IP addresses, passwords, ISP configurations, etc. Instead, draw a single line across the page. Do not scratch out the information so it is unreadable. Just one line, so you can read the old information.

You literally never know when you will need old information. Ghosts from the past show up when you least expect it.

After you cross out the page, simply place it in the back of the appropriate section of the SOP binder or Network Documentation Binder.


Documentation in your PSA is treated pretty much the same. In this case, however, you simply rename the procedure with the prefix "!Old" or "!Retired". (The ! is there simply to be consist with the next subject: Your electronic files.)

In some PSA systems, you can move obsolete configurations and procedures to a subfolder or some other place so that they are away from the main area where you look for current information. In some you can mark items as "inactive" or some other status so that they do not show up unless you are specifically looking for them.


Your Electronic Files should be stored in a logical, usable location. See the post Organizing Your Company Files and Folders.

Notice that one of the categories there is \Operations\Processes and Procedures. Well, within that, you will eventually need to rename files so that it's clear they are no longer in use. For example, you might replace the file "Phone Tree Text.docx" with an updated version.

Best practice is to rename the old file and not delete it. You might rename such files with !Old or !Obsolete. For example, "!Old Phone Tree Text.docx". Or your could create a directory such as  \Operations\Processes and Procesures\!Old and put all retired items there.


I hope you see the big pattern here: Never throw away any old policies, processes, or procedures. Yes, the world changes. Things grow old. Policies evolve. Processes change. So you need to make sure you have a process for keeping that stuff - but keeping out of sight.

Someone will ask for an example of why we need old information. Here's a perfect example: The client changed ISPs and move email from the old ISP to in-house Exchange server. A year later, they need to open the PST file for a former employee. But it is saved with the password used at the old ISP.

If you have that old password list, you can simply open the file. If not, you have to find a program to crack the password . . . and pass those costs on to your client.


As always, you don't have to use the same process we use, but you should have some standard procedure for dealing with obsolete policies and procedures. The most important thing is to never lost old information because you don't know when you might need it. Once you accept that, you simply have to figure out HOW you're going to keep track of the old documentation.


Comments welcome.

- - - - -

:-)

Still the best Quick-Start Guide to Managed Services:  Service Agreements for SMB Consultants: A Quick-Start Guide to Managed Services by Karl W. Palachuk  Now only $39.95 at SMB Books! Ebook or Paperback Learn More!