A Software Deployment, like Avatar, should be neither seen nor heard.

description

A friend (who also happens to be a system management admin) tried a very interesting experiment several years back. System admins the world over will be able to appreciate this one…

His boss told him to deploy a security patch for an application that was present on ALL of their computers which ran Microsoft Windows. My friend, Mike, knew that if he made an announcement that he was going to deploy a patch, he would be inundated with support calls, questions and complaints that had zero, nada, nothing at all to do with the patch. This is the whole “Correlation Does Not Imply Causation” argument that scientists, nutritionists, medical personnel and certainly 
system administrators have to deal with all the time.

So Mike did something very interesting. He deployed the patch to 1,500+ computers on a Friday afternoon. He told NO ONE that he was doing this. He stayed late that weekend to ensure that the patch didn’t break anything. He printed different reports showing time/date stamps and success rates of the deployment.

The following Monday there were no complaints other than the usual run-of-the-mill tech questions from users.  The following Wednesday he sent out an email stating that he was going deploy a patch that evening. He didn’t specify what, exactly, the patch was for. Of course he didn’t allude to the fact that he had ALREADY installed the patch the previous week. The following morning a slew of calls kept coming in with frustrated users complaining that his carelessness had caused their systems to go “down”. What were some of the problems caused by this patch? As I recall a few were:

“My scanner stopped working”

“My printers are no longer there”

“AutoCAD is broken”

“Power Point no longer shows my slides”

and a whole bunch of “My computer is running slow, thanks a lot!” 

There were others but I was too busy laughing to commit them all to memory.

After he had collected dozens of complaints he sent his email stating the facts of the deployment. I don’t know if he opined in public about his findings and conclusions of this little sociological experiment, but whether vocalized or not the results speak volumes.

As the old scuba diving axiom goes: “Plan your dive and dive your plan.” We all need to document what we do and understand any dependencies (internal and external) of our actions. We need to understand that the general population will almost always confuse correlation with causation. “Oh, you installed an application on my computer and suddenly my printer toner ran out!” 

If you are in an environment where you don’t need to announce every step you take, then utilize this to your benefit. This doesn’t mean not to document and track your administrative tasks, it just means you don’t have to spend your time announcing to the world every time you modify a GPO.

If you ARE in an environment where you need to announce every change or thought, then it is wise to state what common outcomes may occur from your modification. This is actually standard Change Management procedure. Let your users know that you are going to patch versions of Attachmate Reflection. If they notice changes in their terminal emulation duties, these MAY be related to the update. If Peachtree, Quicken, or Solitaire don’t work as expected the issue is almost certainly NOT related to the recent changes. If they think the change caused their printer to stop working then take that moment to send an email to the CEO explaining the importance of “thinning the herd” and call for mass lay-offs in certain departments. ahem.

Want deployment that your users will neither see nor hear? Start your trial today.