As a professional Software Engineer, I’ve seen a lot of poorly executed attempts at organizing and preserving a team’s information. This is a particularly acute problem for short-lived projects, as even when a project is cancelled early and its team disbanded and scattered, much of the documentation and other artifacts generated during the course of such a project may prove highly valuable for future efforts. However, even long-running programs in ostensibly well run and heavily process-driven organizations completely neglect Knowledge Management.
Have you ever been the new team member on a project and had to track down documentation that was haphazardly scattered across a poorly organized network share. Even worse, some organizations have attempted to address the problem by enforcing a common directory structure for all of their programs, which tends to make figuring out where to put things even more confusing. This results in seeking out information by trudging through a byzantine labyrinth of deeply nested folders, most of which are empty. Meanwhile, some users simply create folders for their own documents (or even better, store them on their local filesystem). The result is whenever a project is ended or an employee leaves a team (or the company altogether), valuable organizational knowledge is lost.
Knowledge Management (KM) is not a particularly new concept. The simplest example of a KM system would be a wiki, with MediaWiki being the canonical example (used to build Wikipedia, after all). Most wikis, however, center around creating articles for disseminating to a large audience, and weren’t designed for collaborative use by teams. Other, more modern KM tools such as Microsoft’s SharePoint and Atlassian’s Confluence provide a plethora of features centered around collaborate knowledge and content sharing.
Most organizations I’ve worked for as an engineer have had some sort of expensive enterprise KM system. For the most part, however, they aren’t used very effectively (and some are even ignored by employees). Mostly, I think, this comes down to a combination of these systems being difficult to learn and use due to a huge feature set and an accompanying complex and clunky UI/UX, and corporate IT management policies. One particularly dysfunctional IT policy I’ve experienced is not being allowed administrative access of one’s own SharePoint team site. This meant submitting requests for even simple changes through a centralized corporate help desk. IT departments in large organizations tend to carve out little fiefdoms to their users’ detriment, and should be reminded on a regular basis that IT is primarily a support function.
However, assuming users are granted the freedom to adequately use an enterprise solution such as Confluence or SharePoint, most organizations fail to effectively integrate such tools into their daily workflow. Some are used haphazardly only by a few users and some are updated only sporadically (usually because someone in a leadership position noticed how sparse and dated the information in the KMS was, and directed that updates be made – but such efforts tend to die out as soon as the leader turns his/her attention elsewhere).
One solution to this might be to put in place heavy handed policies that enforce entering data into the KMS and exact penalties for non-compliance, but such a thing is usually detrimental to morale 🙂 I submit that if you’re having trouble getting your employees to use a tool, perhaps the tool is at fault (assuming you have a decent hiring process and are hiring mostly quality folks. If not, well, that’s a people problem and you should probably fix that first). While I’m sure there are a lot of organizations that make good use of the litany of features in the major enterprise KM solutions, for many (esp. smaller organizations) the added complexity of these tools just creates too much friction in the average user’s daily workflow. Updating information in the KMS is just annoying enough that people tend to skip it if they can get away with it (and they usually can). In any case, there’s not going to be a “one true KMS” suitable for all organizations of all shapes and sizes, and some experimentation may be required to find the right fit.
Personally, I like lightweight, simple tools that “do one thing well.” I created Contabulo because I wanted a KM tool that focused on collecting information and content into one place, made it searchable, and required a minimum amount of fuss to enter data into the system. It uses a ‘boards and cards’ paradigm lifted from many popular project management tools, modified to suit to the task of organizing, searching, and presenting information and content. If you’re having trouble getting your folks to adopt your current KMS, I recommend you give it a try (yes, of course I’m biased). And, if you aren’t currently using a KMS, why not start with something simple and intuitive first before diving into something more complex (and expensive)?