Anyone who’s worked with me knows I have a love/hate relationship with documentation.

If you’ve been in the middle of an issue, documentation can either be useless or the panacea from the gods.

Writing it on the other hand is BORING! It also takes you away from working on problems, and creates stress to get it done fast, but also have it high quality enough to justify the time spent on it instead of something that makes the business money.

This is where Knowledge Centred Service (KCS) comes into play.

Instead of documentation as it’s own task where you have to carve out a chunk of time, and work on it & remember what you did to fix a problem, you integrate documentation into the problem solving process, so that when the problem’s solved, you already have documentation for the next person to come across it.

Friend of mine’s workplace whenever they’re working on a problem, if there isn’t already documentation on the issue, the first thing they do is start a document on the issue before they start working on the problem, and work on the documentation while working on the problem. It does mean that documentation can be a little train of thought’ish instead of a perfect step by step, but there’s nothing saying you can’t improve the documentation later.

As a mate of mine put it, you’re making it just in time, not just in case.

So I know it’s a process change, and will require modifying habits to ensure it’s happening every time, but you will definitely see results. Plus documentation’s like any skill, the more practice you have with it, the better you’ll get at it.