Don't let Knowledge Walk Out the Door

In a recent post I sounded off about needless complexity in Information Systems and pointed out how it creates, among other problems, a huge knowledge burden: it gets more and more difficult for anyone to understand the system. But even if you try to keep it simple, making sure you have an adequate organizational knowledge base to manage your information system - your hardware, software, website, database, and processes - is quite a challenge. The boundary line between the technology and business practice is a domain where the knowledge problem is particularly hard to manage - because the IT staff cannot get this knowledge from any single source. For example, we as software developers can document how our routine to automatcially draft monthy dues from members bank accounts works, and how to use it. But we do not necessarily know what day of the month an organization runs it on, or how long their bank takes to process it. So IT staff may feel they have this monthly process well documented - but when the staff member who has been running it walks out the door, and a new person takes over, problems arise, people are billed incorrectly, and suddenly something that had been running smoothly month after month seems out of control. A key staff member quitting like this really exposes a knowledge gap. But there are numerous early warning signs for us that this boundary area is getting out of control. Users ask for specific business rules to be added to the software, and then sixty days later request they be removed. Users will create user-defined fields and then next year ask us what they are for. Sometimes we get the same question over and over again from the same organization - clearly it has become a problem for them to keep track of the answers we give them The knowledge challenge is increased when multiple outside consultants are involved in critical projects - maybe one group doing the business and relationship management software, another group working on the website, and a third coming in to do network maintenance. In this case it can even become a problem just to track who did what work. The other day, a client called, trying to track down documentation for the scripts that pulled data from our application out to his website. The problem was he didn't know whether we or the web designer had written the scripts, so he did not even know where to turn for documentation. It's not that he is disorganized - he's new, he's the net admin, and he was left with no internal resource to find out who did this work. You may be buying services from a lot of assistance providers - but it is your organization alone that is ultimately responsible for being able to retrieve working knowedge about the system. It's just like your health: you may see various specialists at your HMO - but really its up to you to remember you have diabetes. Your IT folks are already overwhelmed and understaffed - how can they rise to this documentation challenge? I have an idea I will share in the next post in this series. I think the secret to building an organizational IT knowledge base with minimal cost to the organization is the efficient re-use of documents that are already being routinely exchanged as your system grows and changes. Tags: nptech, km