Contact ITInvolve
x 


Knowledge isn’t free and neither are the donuts

One of my former bosses is a Naval Reservist. Once a month, he goes away for the weekend to do his job for Uncle Sam. In the break room of whatever building he’s working at, there is a sign above a table that says – “Freedom isn’t free, Neither are the Donuts.” The idea is that if you take a donut, you’re supposed to drop some money in the jar so the tomorrow’s donuts can be purchased.

This got me thinking about other things that have costs associated with them, like experience and knowledge. So with a hat tip to the Navy, I submit that “Knowledge isn’t free, Neither are the donuts.”

There is a cost to developing and utilizing knowledge. There is the time it takes to develop the knowledge. For example, someone needs to write it down, make the video, etc. That takes time, which has a cost associated with it. An obvious cost is the knowledge developer’s hourly wage, but what about other costs? What else could that knowledge developer been doing instead of documenting the knowledge? Is their main job to develop knowledge or do they have other duties that have to be put on hold while they document?

We’ve gotten used to having much of the entire world’s knowledge in the palm of our hands via the Internet, Google and our smartphones. We can search for an answer to just about any question we might have, and at least 99% of the time, we can get a reasonable answer. Of course, depending on the question, I may have to spend time weeding through a whole bunch of entries to find it. I may have to ask the question a few different ways, or (heaven forbid) try to remember a little bit of Boolean logic to filter out unwanted results. In this sense, there is a very real cost with not just documenting but also accessing knowledge — my time.  What else could I be working on instead of trying to find this information?  How much time am I spending piecing together information, data or knowledge from other sources to figure out the truth?

Now, let me repeat this exercise, but with my work hat on. I vividly remember a few years ago that I was desperately searching for information to help me with a high priority project I was working on — upgrading the Point of Sales (POS) system. [The project goal was to deploy a newer version with better reporting capabilities for our logistics folks.] In this context, I was no longer going to my phone and googling something, instead I had to find and then go through tons of information about my company’s implementation and use of the POS system. No longer was everything nicely catalogued and key worded. No longer was everything easy to find. There were literally hundreds of places that I needed to go in order to find the data. There were build documents, CMDB entries, a bunch of Sharepoint sites, dozens of emails, file shares, several change management requests, some Wikis, and much more. The stuff was scattered everywhere and I had no idea if the three-year-old Visio diagram that I found was in any way representative of what was currently humming along in our data center 600 miles away.

So that meant I now had to seek out people – experts that could provide me with additional information or at least validate the information that I had earlier found. But first, whom did I need to talk to? The author of the Visio left the company 18 months prior. The VP of Retail Operations, who signed off on the Functional Requirements Spec, now worked for a competitor. Just trying to figure out the people who could maybe get me the information that I needed to do my job was a full time job unto itself. And, this wasn’t my only project, I had 15 other projects at the same time that I was involved with. Unfortunately, those other projects (and their value to the business) had to wait — even though people were waiting on for a number of tasks.

Fast forward a few weeks, and I’ve now got a bunch of information that I’m told through various meetings, phone conversations, and emails is current. I have a bunch of new hard copy documents on my desk, a picture of a white board diagram that a DBA spent an hour drawing for me, lots of emails, word documents, PDFs, you name it. I added that to the information I got from the vendor, information from three of our six CMDBs as well as some reports from three different monitoring tools. Now, I could finally start working on my tasks for the project.

I probably spent at least 30 hours trying to look for and validate this data and information. As an architect, my fully loaded hourly wage was around $75. So just assembling this information cost my company $2,250 not to mention the time that it cost from everyone I talked to which was easily several multiples of that. Plus, they all had other things to do that I was pulling them away from and there is a cost to that too.

Now the fun began. We didn’t have money for new hardware for this project so I had to make sure the new version of the POS software would run on what we had already. I went through all the information I had assembled. The build specs, in particular, were hilarious. Each was 60 pages long and there was so much boilerplate and filler in each one that it was mind numbing to read them all. Our CMDBs were filled with a bunch of useless (for my purposes) information that had been populated by our auto discovery tools, and I quickly started to drown in information. What I really needed to understand were just a couple of configuration settings to see if they were A) required, B) needed to be updated or C) completely irrelevant to what I was doing.

Aside from the Easter Egg hunt that I had to go through just to find the information I needed to do my job, I found the information itself was barely relevant. My company made IT people fill out all of this paperwork when they did something or built something, and most of these folks are IT majors not English majors. The people that came up with the document templates probably had no idea what kind of information would need to be captured, so what you think would be in one section is in another or the information didn’t fit the template so it had to truncated.

At this point, I didn’t have much confidence this upgrade will be successful. There were just too many unknown or little knowns, and it wasn’t from a lack of data. I actually had too much that it was hard to find the proverbial needle in the haystack I needed. What’s worse, what I had was mostly bad, or old or incorrect data. I couldn’t trust it and it didn’t provide the right context for me to effectively use it.

Unfortunately, this situation is very typical of many IT shops – the information and knowledge is not well documented and what is documented is a huge mess. IT information has a lifecycle of its own and the common methods of documenting, collecting, and accessing IT information are inadequate. IT Information is a living, breathing thing that must be nourished and maintained on an ongoing basis as part of daily work, because no one has time to do it after the fact. And even then, we’re really good at burying it in file shares, spreadsheets, emails and Sharepoint sites, so as soon as the information is created, it’s quickly forgotten about and withers and dies.  Then, you’re like me in this story, where all you have left is a corpse of information that might have ben useful once but probably doesn’t have much value today, because we move  so fast and what was true yesterday isn’t true today since that OS patch was put in place or the backup schedule was updated.

So what happened with the POS upgrade? Well, even with my lack of confidence, the change request for the upgrade was approved – because it had to be. There was no testing because we didn’t have a properly configured test environment, but I did ensure we had a full backup just in case something went wrong. We held our breath and we rolled it out. Amazingly it worked out okay, but to this day I feel like we just got lucky. Knowledge isn’t free, and this all to common status quo is no way to run an IT shop when your business depends on it.

 

Leave a Reply