The Challenge of sharing knowledge and clearing ones head of useless information.


After working in the tech industry for over 5 years I’ve started to notice a trend.  The trend being that most individuals whether highly motivated or slovenly in their technical aspirations tend to horde information.  Now you’re probably saying to yourself “information?” what type of information could people be hiding/hording?  

To be more specific with any product or technical implementation there end up being a number of tips and tricks which arise through out the integration and general up keep.  The documentation of these tips is seldom undertaken because people get caught up in the doing of the task and not focusing on the fact that they should also be documenting any shortcuts or lessons learned that may come up.  Now… I just used the coined phrase that everyone out there either loathes or loves “lessons learned”.  People either jump to the task of creating a lessons learned sheet or run for the hills.  My version of a “lessons learned” document is one that begins when you start implementing a product and continues to grow over time as both you and the product mature.  This makes the lessons learned document less of a chore and more of a reference guide that can be passed along to the next poor sap who has to use the product. It also allows you… YES YOU to be able to clear your brain of all that code and syntax BS that comes up.  Bottom line you end up creating a product integration guide for the product which fits your company. 

So, with every product that I come in contact with I create a document which covers all of the caviates that I run into with that product and how they have been dealt with in the product environment.  It doesn’t have to be lengthly and there is no real scope.  

This brings me to my next topic, product implementation and integration.  We’ve all heard of it and we’ve all experienced it.  It starts when some bloke comes into your organization and attempts to sell a product which is a catch all of sorts. The product is designed to make life easier by simplifying some task or objective which the company has been yearning (yeah right) to fix.  In the end your management is so impressed they go out and buy the whole software suit with little input from anyone else (This issue I will address in a seperate post).  

So… the product is now on your door step and surprise suprise you have been hand picked to implement it. Lets say it’s one of those products which pulls information from other products and makes sense of it. Whether it be SNMP trap interpretation, or host monitoring the product claims to be able to easily integrate into your environment and provide value added in no time.  Any hint of customization is down played and for all intensive purposes it appears to be a real wiz bang solution.  

When integrating the product you WILL customize it.  This seems to put a sour taste in managements mouth.  The word “customize” raises eye brows because uninformed people assume that this means their environment will not meet the standard build or will require endless customization.  Depending on the complexity of the product this may be true, but and I emphasize BUT if the product has a strong support and development group behind it you will be able to implement it with minor tweaks and modifications.  So expect to make some minor modifications to the product, also expect to dedicate one team member (NOT a manager) to cover the care and feeding of the product. The product will be worthless to your organization if no one internal maintains it.  This kind of goes without saying but is sometimes overlooked due to the nature of the content a product may provide. If this is the case you (the manager/management) should be asking yourself why this data is so very important when you didn’t have it before this product was installed.  Visibility can be conceived as dangerous especially when it concerns cost but at the same time keep in mind your employees probably already have a rough idea how much of that $$$ they earn is actually tied up in the organization.  I’m not suggesting that you throw open the doors on your operation I’m only saying you must allocate at least one trusted employee to maintain the new software package.

After the product is installed you will get a certain level of knowledge transfer.  Be ready to learn as much as possible in as little time as the vendor sees fit.  Set your requirements and expectations before getting this valuable training (from the vendor).  This will ensure that your expectations are either met or exceeded. If they are not you can clearly show what you were looking for and how the training fell short.  

Cutting cords with the vendor. At some point you will fall back into the client vendor relationship. The product will be running and the vendor will leave.  Someday the product will hose itself and you’ll end up calling these fine people up (testing the waters of that silly support contract).  Be curteous and direct in your description of the problem and expected resolution time.  Again… set the expectation in terms of how quickly you need it fixed and the impact on the organization.  Call me crazy but this just seems to make sense.  The response may not be immediate but guaranteed there will be a response of some kind.  If necessary escalate.

 

I’ll tweak and edit this post as things settle… the RANT is over. 🙂

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s