Knowledge Management for an IT Department?

Laurentiu asks: "In every IT department out there there's a wealth of heterogenous information floating around: code snippets, HOWTOs, FAQs, docs, spreadsheets, post-it notes etc. Asking Joe where he put that file won't work forever. So what is, in your experience, a good way to manage this knowledge? And what software would you recommend for such a task?"

Comments

Use a Wiki - MoinMoin

[egriebel]

As some have said already, and many more will, a Wiki works well for unstructured knowledge. We had one where I worked last and it was good for brain dumps. Unfortunately, people mostly brain-dumped when they were leaving the company or they were very bored or were looking for something to help procrastinate. We even used it to keep track of on-call schedules.

Software: moin-moin http://moinmoin.wikiwikiweb.de/. It worked well enough, easy to install, and it was easy to set up credentials and permissions for groups on the diretory and page level for editing and even visibility. It's easy to get in and make simple changes to the code and there's a bunch of modules available of varying quality, though.

Funny anecdote, our group's manager pulled a Lundberg: "I uhh like the program and it works well, but is there a WYSIWYG editor for it?" [Although somewhat idiosyncratic, Wiki markup is trivial to learn and use, HTML looks like C++ in comparison.]

usenet?

[TheGratefulNet]

I always liked the idea of simple ascii commentary on ideas. and if you need to refer to something, well, use a link - people will 'get' that even if their ascii browsers don't.

I started in vax/vms with 'vaxnotes' and there was the notion of a base topic and its replies. it was simple, but it held the knowledge of DEC in a reasonable fashion, for many people, for many years.

then in the unix world, there was nntp/usenet. same basic idea. and also ascii-based. it scaled well and it worked well (and was well understood and simple enough to manage).

its worth considering. you can enable 'news' on linux boxes as clients (browsers) and servers. people can add (and edit and delete) content and its simple, free and best of all, it works.

Sudden adoption of WIKI

[Centurix]

After taking over the developement for a telemarketing application, with no prior documentation, I immediately started a Wiki using OpenWIKI (they lean towards Microsoft servers for their stuff, so a basic IIS installation is all I had to work with), I convinced the admin guy to give me web space on it plus their SQL server, installed it and started entering everything I came across as I was either fixing or adding stuff. After about 3 months pretty much the entire system was documented to some degree, from the UI to nearly every technical aspect. Then, one of the execs found it, figured out how to add stuff, and now 8 months later it's probably 25% my stuff, and 75% is now full of up to date company practice and communication.

Re:The answer is not *just* software.

[dunee]

I must de-lurk for this topic.

My company is currently centralizing all of its IT functions from the 42 Europe-wide sites it has. Knowledge management is a nightmare, as the institutional knowledge is spread too thin among the old timers to make any impact for the new people. We have some processes documented, but by far not all of them. We decided we needed a written repository of knowledge, as we are growin at a rate where we can not afford to waste time.

We finally decided on MediaWiki, just like some of the others here have suggested, for pretty much the same reasons. It is just great for unstructured information, and the ability to categorize and very quickly link to other pages has turned out to be very useful. It is very quick to update - no need to muck around with HTML and uploading a page. Just hit Edit, change that IP from 223 to 23, click Save and you're set.

Converting existing Word documents to wiki format is essential for quickly populating the wiki with content. We have a lot of support documents with screenshots. I found out that the best way to do that is to save the Word file as HTML. It will export the images both as JPEGs and PNGs. The PNG is the image as it was imported into Word, at its native resolution, while the JPEG is a result of how it has been processed within Word itself (cropped / framed / recolored). I generally just grab the PNGs, unless the cropping was significant, as the JPEG resolution is fairly low. As for the text, I just grab the plain text from the document and mark it up with wikicode. Fairly painless.

Additionally, I also found a nice tool for converting Excel tables into wikicode, for all those worksheets with server IPs, domain functions and other stuff. Save your Excel as CSV then fire up the converter at http://area23.brightbyte.de/csv2wp.php. Just copy-paste (or upload), and presto! You have a nice wiki table. You can then mark it up with colors and other bling-bling if required. Again, I found the process to be relatively fast and painless.

Keeping with the wiki way, the majority of our pages have unrestricted access. Since I'm not a great believer in security through obscurity, we needed something to protect sensitive information - mostly passwords. The privileged few that need to know can get bumped to a higher security level and access these restricted pages.

http://conseil-recherche-innovation.net/index.php/ 1974/04/10/31-restrict-pages-under-mediawiki is a good page on how to restrict certain pages in MediaWiki. There is only one level of restriction though - the page is either restricted, or it isn't. To my joy I also discovered that while restriced pages also get indexed for searching, they do not show up among the search results if the user is not on the restricted level himself.

By the way, I full agree with the parent - the wiki by itself is not enough, you do need a librarian / knowledge manager to categorize all the braindumps and also to educate people on its mere existence. I also found that you need to pour a certain amount of info into the wiki before it reaches critical mass and people start to really use it. You do need to work a lot on it, especially in the early stages, with importing content. We didn't bother with scope definitions and categories and stuff - since all of this is so easy to change once the data is up, we'll just build it as we go along.