Improving Knowledge Management when you are not a Knowledge Manager

Being a part of an IT team one would expect that we have a good grasp on knowledge management. The trouble is that there needs to be method to the madness for your knowledge. Considerations for how it is to be created, curated and consumed should be taken into account.

I was reminded of this recently as I was speaking with a colleague who was asking about an article I wrote entitled “WORN – Write Once Read Never” they indicated that they own ability to capture knowledge seemed a bit ad hoc at best.

I explained that while we are all capturing knowledge on some level or another we may not be positioning ourselves to be able to put this to use in any way which outlines a measurable amount of value.

Just because you are not a knowledge manager doesn’t mean that you can’t help improve the process.

Knowledge management can benefit all areas from a service delivery perspective. The challenge is getting people to stop thinking about this as a “side of the desk” activity. As I have said in many posts before, start small. Look at what you do today and where you can inject a healthy dose of knowledge management. In the beginning this might only apply to some core processes like change or incident management, which is ok. Use the success you gain to leverage some positive marketing for the process so that you can apply it to other teams.

IT Operations or Application Managers

Imagine if your operations teams were able to look at documentation which outlines the post incident reviews for the last 3 incident outages your team was called out on for a particular component of infrastructure. Documenting after these issues is important for continual service improvements. The challenge is finding the balance for knowledge to keep it simple enough that you are in a position to easily create, curate and consume the information. In my opinion this is where most people outside service management teams start to lose some level of traction. Using the example of a post incident review the ops and apps folks might build out these elaborate processes which include an initial PIR meeting which spawn multiple page documents with additional meetings to review findings and so on. The trouble with this is that this might not be re-producible, and in time these are simply not being done.
Having a simple template with a few key questions will allow you to build on something. While your incident team may facilitate these reviews, ultimately all of IT is accountable to providing service and has a vested component in these reviews.

Start with a few key questions like:

What was the issue?
Who was impacted and how?
What was the resolution?
What was learned?
How could this be prevented in the future?

Everyone plays a part in knowledge management activities, whether the process is formal or not. While many people might equate knowledge to the service desk from a self-service perspective or even for problem management. There are many other benefits that can be realized when we apply these principals to other teams within IT and beyond.