Knowledge Management – Horseshoes and Hand Grenades

As the old saying goes “Close only counts in Horseshoes and Hand Grenades”, so too is the need for accuracy in your good old knowledge locker. As I mentioned in a previous post, WORN – Write Once Read Never, the sky is the limit on the information in which you can retain. However there comes a time when you need to have a policy in which you are able to manage the information that you decide to collect.

Depending on how your organization is set up there may be varying opinions on how and what information should be stored. Sometimes there are inconsistencies from team to team, even within IT on how this data should be managed across the lifecycle.

As an example I will take the launching of a new application for our customers. I will keep this example really simple to illustrate how off the rails this could get.

Our customers wanted an application to manage their beverage refrigerator in the lunchroom. The requirement was to email the office services person when the volumes of the pop(soda) got to a “low level”

From an infrastructure component this was to be managed from “Joes Computer”. Joe sat closest to the lunchroom and since the application required very little overhead this seemed like a good idea.

From a documentation standpoint the inner workings of the application were documented and also stored on Joes Computer.

Over the next few years there were several changes as a result of the needs of the staff with regards to their beverage choices. They no longer wanted soda, and switched it up to juice, diet beverages, and vitamin infused waters. Joe also moved on to another lucrative career at another company. When this happened he did make sure the application and documentation was moved to Chris, who also sat near by.

The documentation which was originally created was never was altered to reflect any of these changes. In addition there were also several issues identified over the time since the application was launched which was also not documented correctly. These defects impacted the way this application worked even if only marginally.

Eventually the office had a fridge full of the pop (soda) it did not want and none of the beverages it needed. What’s wrong with the application?” people asked in the office. Chris, our newly voluntold sysadmin, had no answers. As he went through the documentation to look to make any corrections he noticed that while the information was close it was not entirely accurate. It also showed the last time it was updated – when it was written

This failed mainly because there was no policy to manage this knowledge either manually or automatically. This information would have positioned the support teams to ensure that this application ran smoothly armed with the information to be able to do so.

Overall in this example there was no process to review the documentation and ensure continued accuracy. Think about how your organization manages this application data, is there a formal process or is it more adhoc with best intentions. The end result will determine if you information is close or spot on.