Friday, February 22, 2013

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: 

by Karl W. Palachuk 

Now only $39.95 at SMB Books!

Ebook or Paperback

Learn More!


  1. Anonymous9:22 AM

    When Policies and Procedures Become Obsolete

    This is an excellent topic and with over 30 years experience in the business, I would warn against the advice given to make your procedures/policies so generalized that they never need be updated.
    I would start by saying policies are those items from top management which give lower management their direction and procedures define how things either are done as a form of interaction of business departments or specifics of how a specific task is performed (the latter often called work instructions).
    The failure mode among business and more specifically manufacturing is the paralysis related to the idea of either continually improving or seeking the “root cause” of existing processes. Almost non-existent is the question of the continued validity of a current business process or system, even in the face of continually emerging technology, where innovation takes place seemingly overnight.

    Just count the number of smart phones strapped to the sides of your workmates or contained in the purses and ask yourself;… is the ability of that technology being harnessed to the benefit of the business? I would bet in 95% of the cases, the answer would be no. The reason behind this phenomenon is simple, businesses were geared in the 1980s and 90s toward the idea of PDCA (not PDSA) and therefore completely struck down the idea of Re-Engineering (now days called Kaizen Blitz). The reason was simple; it was a war between avid supporters of Deming and those who supported Michael Hammer. The truth is, they were both Deming and Hammer were correct.

    The failure occurs when businesses take their eye off their desired goal and start to think about singular components of a business system without keeping focused upon the desired state of the business and its processes.
    1) Processes which are capable of continually providing an end result which achieves the desired state of the business, should be considered for improvement of correction, upon discovering some non-conformance or failure. 2)
    2) However business process which are disconnected and have become convoluted and are very week or incapable of continually achieving the desired result, need to be re-engineered.

    It’s both the activity of evaluating business systems and or process, and the idea that some become obsolete, which has eluded business for nearly 3 decades now. Many mundane hours and vast sums of money are spend attempting to seek out (usually without knowing about variation) the root cause to a particular problem in order to fix a system or process which is in the end, simply obsolete.

    Therefore your consideration is valid and your business should have an event which allows as part of its corrective action, the ability to determine the continued validity of a current system or process. But you asked about policies and procedures, not systems and processes. However, a policy or procedure is nothing more than a stated or written version of a system or a process, is it not? So include this simple step in your process of corrective action, have an initial phase where the state of the existing system or process, is compared to the desired state and then step back and watch the eyebrows raise up. It’s easy to perform this using a cross functional flow chart. Convoluted processes tend to go unnoticed for vast periods of time for a plethora of reasons. However, once challenged, it’s usually more beneficial for the business to streamline and replace the process than it is to spend time fixing it.

  2. Thanks for the excellent comments, Jeffery.

    Since my audience is generally small businesses, I think it's much easier to replace obsolete policies and procedures - IF they are acknowledged to be obsolete. Still, inertia is an amazingly powerful force.



Feedback Welcome

Please note, however, that spam will be deleted, as will abusive posts.

Disagreements welcome!