Obviating Knowledge Leaks

Obviating Knowledge Leaks

  • We did this before!!
  • Umm! Yes, kind of, I remember encountering this one.Oh No! We had this in another project. I don’t recollect what we did to fix it.
  • This was not passed on during transition.
  • I had a ticket opened and they helped me solve that. I guess I lost that Kbase article.

Are any or all of these statements familiar? It must be. Any resource, any practice or any organization have been through these scenarios. In IT we do not produce repetitive products. We are into Knowledge work. Knowledge is ever changing and is very volatile. That is the main reason that it leaks fast and easily. One main reason why it can be called as a leak is because it can be obviated. The exact meaning of obviate is to hinder, prevent, avert or stop.

The above statements are an indicator that there is knowledge leak. What do we do to prevent anything from forgetting? We write it down. Based on the criticality we write it and store it in a place where we can find it every time or we place it where it is easily visible, something like a Post It note.

Knowledge about anything is very vast. In our work area what we need is a quick solution or pointers to overcome the hurdle or eliminate the risk and deliver within Project constraints.

It is called as Standard Operating Procedure or Checklist or Install Guide or something else. Generally, we term it as Documentation. None of the terms are really attractive enough for motivation. Documentation is the last thing on anyone’s mind. It takes a lot of time to create a document, adhere to documentation guidelines, version control the document and many more reasons to flee away from this task. Output of avoiding this task is the statements that we saw above.

Project team members will definitely not want to create any of the documents that are mentioned above simply because they won’t use it when they move to next project. What if Operations is going to be handled by another team of the same organization? How is that team going to ensure that whatever is delivered by the Project team will continue to function smoothly? If at all there are troubles then how are they going to fix it? Is that team supposed to go back to the Project team or the Project team is supposed to pitch in for troubleshooting?

Another scenario to consider is that the operations are transitioned from some other organization with no documentation. Now, how does the Production support team ensure seamless operations? Who suffers for delay in trouble shooting? What happens to the Customer Satisfaction Index for previous and current organization in this transition scenario?

  • Standard Operating Procedure
  • Checklist
  • Install Guide
  • Application Landscape
  • User Guide
  • Technical Guide
  • SDLC Documents
  • Sharepoint
  • Zoho Workdrive
  • Google Drive
  • Home grown applications

Above are some examples of documents that could help obviate knowledge leak. Creating a document containing screens and relevant verbose matter is a starter. Next in line important is having a central repository or document library with appropriate version control on those documents. Sharepoint or any similar application would be helpful to act as a Central repository, control versions and also controlling access to those documents. Last but not the least is a search facility for those documents. It is not a good idea to have a very strong documentation and storage practice but no index to quick search.

Final word is to keep the documents alive. All efforts should be directed to maintain the documents in such a way that they are always current. This also means that some of the applications may need to be retired or even may need to be revamped.

Customer Satisfaction
Smooth Operations
Faster Resolution

Organization strives for all of the above

Leave a Reply

Your email address will not be published. Required fields are marked *