The image above is a quick sketch of a concept I'd like to call the "Super Brain". This has to do with knowledge management. Consider that the full "super brain" circle encompasses all the knowledge about a particular topic. The topic can be anything.
Whenever two or more people are working together on a topic, there is a need for communication. Everyone knows that communication is always a tough thing to do well. This is especially true in the workplace or in an organization, where many people are often involved, where there are many competing priorities, where "just get it done" attitudes often exist, where future-proofing knowledge is not often a high enough priority, where disconnected pieces of information on a topic are often locked up in peoples' heads. I see this every day, and I become more and more convinced that workplaces and organizations in general are, on average, operating less efficiently than they could be if they would make "knowledge management" more of a priority -- from a technical and tools perspective, from a "people motivation" perspective, and from a scheduling priority perspective.
Think about a typical project in the context of the image above. It involves several subprojects (subtopics) that have some unique aspects but have significant overlaps with other subtopics. Each person/member/worker is assigned to one or more subtopics.
There will be someone assigned to this project (not necessarily shown on the diagram) who has oversight of the project, controlling the schedule and making sure that the different subtopics are coordinated. However, my observation is that this project lead does not necessarily have enough time or insight to understand the full scope of the project. There is a benefit to be achieved by having all participants in the project have easy access to 'the big picture' in an organized, easy-to-navigate manner. Any one person can just scratch the surface of a particular topic, or delve into the details. The navigation paths between these two streams of documentation should be well-defined and self-explanatory in the knowledge base.
While all project participants often have access to project documentation today, usually this project documentation is disconnected from the project as a whole. Any project has numerous internal logical connections or linkages (terms and definitions, requirements, design criteria, peoples' expertise, tools, external concepts, etc.), and almost without fail those linkages are lost in typical project environments (typical shared storage of Word documents).
I can't necessarily explain it, but Word documents never impress me. They seem to always be silos of information. While Word will support linking within and among documents, it is cumbersome and never seems to be used effectively. Documents are meant to be standalone, and projects are never standalone. Hyperlinks have been key to the World Wide Web since the 1990s. We in organizations should take a hint after 10+ years and realize the power they hold.
As many of you reading this know, I've become a proponent of wiki technology. The simplicity of organization, the freedom to make changes, the community atmosphere, the encouragement to write stuff down, even if it seems only marginally relevant, the focus on searching to "dig out" obscure but occasionally important facts about the project -- I think these are all healthy traits to have available in any project. In my view, the "Super Brain" should logically be implemented as a combination of a wiki and a web-based forum. The forum is a place for users to interact about current project topics, and when information has reached an appropriate level of stability, it is captured and categorized in the wiki. The two go together, and a complete system will make good use of both.
There are some complications to making this a reality:
As I mentioned above, the business world especially, it seems, cannot break free of the Word mold. Even when good documentation is available in a wiki format (or similar), it almost always ends up in a Word document. If external customers demand this, that's one thing, but often it's just internal documentation. I would venture to say that a project captured in a final report is much less future-ready than a project captured in a wiki. The wiki's navigational capabilities can allow a new user or a new team to discover the core tenets of the project much more easily than a final report and a directory structure of other disconnected documents.
Another problem is the inherent laziness and low priority with which every one of us approaches information management. Consider that it's a busy day, there are deadlines to meet, and it's a nice afternoon and you'd like to leave early. You are working through a small but tough problem with someone, say, fixing a development system issue. You track down the error code and resolve the problem. Say that the error is caused by one obscure misconfiguration -- but it took you the better part of an hour to find the problem. What do you do? Do you record your finding? Probably not. You leave early, glad that you made the progress. So the next person to run into the problem will have to fight the battle again. See the struggle of priorities? Everyone is tempted to say, "Oh, we won't have this problem again. We'll be smarter next time. We'll tell everyone not to configure stuff incorrectly." That may be true 90% of the time, but there are always corner cases. Perhaps 5 minutes of documentation is worth the risk that someone WILL run into the same problem and waste an hour on it. -- The other problem with documentation is figuring out where to put these "tiny trinkets" of obscure but important bits of knowledge. Do you make a Word document for each of them? Do you make an Excel spreadsheet to list them all? Again, I'm partial to a searchable wiki. It just makes sense.
The low priority of information management continues in a broader sense: we tend to be short-sighted about our project goals. "We all get paid the same in any case." "I just work here." "We just gotta get this phase completed." These are nice lines, but aren't very motivational. And they aren't very community-focused. And, while it may sound unusual, workplaces are communities -- communities with a determined vision and "way forward." I think people often see themselves as too task-oriented -- "just get it done" -- and don't consider the long-term effects that their immediate tasks will have on others. This, along with other factors, is what causes "brain lock." You've heard the line "What if KeyPerson gets run over by a bus?" There will always be key persons -- hopefully we are all KeyPerson in some area -- but the unexpected loss of a KeyPerson on a project should be a moderate roadblock to progress, not a devastating catastrophe.
How do we make that transition? Make the key people write stuff down! I think this has to be the foundation on which everything else is based. Just watch a busy project worker for a day and think about all the bits of knowledge that float by -- useful now, probably useful sometime later, but either lost completely or locked in the brains of one or two people. If people don't write stuff down, then you'll never build a knowledge base. And if only a small subset of people write stuff down, then you'll always capture a skewed view of the project. The more people who contribute their perspectives, the more truthful and useful the "Super Brain" will be -- and the more latent and hidden miscommunications you will resolve along the way.
Even better than just making people write stuff down, incentivize people somehow so they will want to write stuff down. (And.. if the person fears that he or she will become insignificant (e.g., a candidate for outsourcing) because he or she has contributed domain knowledge to the community: congratulations, you just disincentivized knowledge sharing. Don't let that happen!) Make "dumping your brain" a normal part of your work environment. And have other people analyze and improve your "brain dumps" so the knowledge base (the "Super Brain") can be honed and made more understandable. You will reduce the project risk, and I believe the time spent in "brain dumping" will more than pay for itself in better project understanding for everyone and reduced time fighting stupid problems that other people have already solved -- problems related to technical issues as well as problems related to definitions of project terms, scope, requirements, etc.
So that's my manifesto for now. The moral of my story is: "Write stuff down. And you should write it down in a wiki." Feel free to send me email if you have rebuttals or other comments.