We have to talk about legacy issues

I put an informal poll out into the field, recently—that is, to my Twitter and Facebook followers—asking what the biggest issues are for knowledge management in their workplace. Apart from the general apathy towards KM and knowledge centered support (KCS), the most common complaint is the large amounts of legacy documentation still on the network that are stored in unstructured ways or with inconsistent labelling.

Inconsistencies in content or labelling can be solved by peer review and discussion prior to publishing, but some KM tools (such as wikis) don’t provide an easy means of gathering feedback. Unless you have a formal approval process before sending your KB articles into the wild, you’ll be dealing with the same legacy issues down the track.

So how do we deal with the hands our predecessors dealt us? You could throw time at it by just accepting that it will take a while to bring it all into line, piece by piece. You could throw money at it by giving the project to an existing employee or contract technical writer.  You could spread the load across the whole team and have each of them do a piece.

Any approach is valid but it needs to be championed as a recognised effort throughout the organisation. Dealing with legacy documentation is a lot of work on top of what could already be an overloaded schedule; and it’s especially thankless if there isn’t a successful KM process already in place. Incentives and contributions to KPIs are a couple of ways to motivate staff to work towards resolving legacy issues with KM. Do you know of other methods that have worked? What would you try?

Thanks to Michael, Jason, @ITILgirl and @ISB_SYD for your input.


Post a Comment: