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.
Labels: Knowledge Management, Service Management