Zen and the Art of IT Support, Part III: Knowledge Management
This is a continuation of a larger discussion of ITIL within IT support I started a few months ago. The first part is an overview (and explains how the Metaphysics of Quality could affect topics within IT support) and the second part focuses on incident management. They aren’t required reading, but I may refer to portions of those posts in here (just think about what you would deal with if you tried to watch Return of the Jedi without watching The Empire Strikes Back first).
I will put this bluntly: Knowledge management within most IT organizations is woefully handled and treated as not only an afterthought but a non-thought. That is one of the most tragic things any IT organization can do to itself. Google cannot be the external memory device for your organization’s users and support staff… and many organizations do not realize the proactive value in having properly created and maintained documentation.
Poor documentation can kill credibility. Poor documentation can kill any assurances a user might have from your staff. And no documentation can drive people (both users and staff) away in droves.
As the underlying theme of “Zen” and its aspect of the absorption of knowledge is what’s driving this discussion, then knowledge management is extremely important for any service organization. Sharing the knowledge with users and staff is the start. Doing so in a clear, concise manner is the next part. Finally, maintaining it and ensuring the knowledge is up to date and pruned is vital. After all, do you really need to keep an article on how to install Trumpet Winsock on Windows 3.11? And shouldn’t you have an article about editing the hosts file in Windows 8 (regardless of your personal dislike for the OS)? And shouldn’t the staff be kept informed of changes to processes and given tutorials when new systems are brought online or changes occur to how they need to operate?
Knowledge management is work.
It’s a lot of work.
Because of that, the issue that arises with documentation is there is a perception by many IT professionals that documentation is a waste of their time. When/if those individuals do document something, it’s lost in email inboxes, or in documents on shared file servers, or just locked away on a local hard drive or two. When you consider how many of those professionals pay lip service to Stuart Brand’s “information wants to be free” adage, we see an ironic (and not in the Alanis Morrisette sense of that word) situation emerge.
That’s a failure. There is no other word for it than “failure” when knowledge is not properly managed by an organization and the information, striving for its freedom, isn’t being presented to those who need it and can best use it.
The answer is simple: Do the work (yes, I am evoking Steven Pressfield on purpose here).
I’m not saying everyone should now have to learn how to properly spell and grammatically form sentences (though that might not be a bad idea for their personal development, but I can understand looking past that for now). There’s no need for them to be the ones managing the knowledge. They (and everyone else in the organization) need a process to share the information to those who will maintain it.
It’s those staff members (technical writers, documentation specialists, etc.) who can take “sysadmin-ese” (or “accountant-ese” or “manager-ese”), translate for the intended parties (users and/or staff), ensure the resulting documentation fulfills what the originator was hoping for, share it with the necessary parties, and then maintain it in the future.
Postponing the work doesn’t help either. Depending on the size of the organization, an individual, a team, or an entire department needs to be assigned to managing knowledge (for both users and staff). The process (using ITIL’s view of knowledge management) should be held by them and communicated to all of their colleagues throughout the organization. By implementing a knowledge management process, the organization is allowing the information to be free and giving the staff the ability to properly share it with those who need it. Knowledge management is a sign of a truly mature organization because of that.
From an IT support standpoint, this process will share information with the front line of support, allowing them to handle more at the point of first contact with a user and removing the need for escalation of lower level issues. Not only does that make the user happier, it enables the first-tier staff with knowledge and it frees the higher levels of support from dealing with minor issues when they need to focus on the larger ones. Indeed, if the information can be shared with the user through a self-support portal, then the issue may never have to be presented to support staff and the user can move on with their day never needing to call or submit a ticket. That, as Martha Stewart would say, is a good thing.
Finally, knowledge management (in coordination with incident management and request fulfillment) is the final building block in allowing your organization’s support to become a true service desk (not just a help desk). Once you move past the reactionary state of the help desk, the service desk becomes something much more different as those staff members step into a larger world.
But that will be a topic for another time.Posted in: Nexcess