When Things Go Wrong

woods-2-pathsI don’t know if I believe in superstitions….if Mercury is in retrograde, gremlins get in the system or “ghosts” have something to do with my keys always disappearing. All I do know is something is wrong.

Lately, nothing has cooperated. Technology is not working, plans are falling through and desired outcomes are getting delayed or eliminated. So, whether it’s the cosmos out of alignment or the creatures you’re not supposed to feed after midnight, I am stumped as to the bad fortune lately.

Instead of sulking at the number of mishaps, as a true KM professional, I turn to capturing lessons learned and trying to pinpoint items in my control to look toward the future.

Sometimes we learn that items are not in our control, like technology, so all we can do is communicate the current state, apologize for inconvenience and move to a solution, band-aid or take an alternate path. I find the alternate paths, while vexing at first, can lead to great fortune.

I keep reminding myself that rarely do things go 100% according to plan and we should expect the unexpected. So, mishaps can be good. Conflict can lead to learning. Forced alternatives can lead to a better solution that we never would have thought of!

As long as we take time to reflect and dissect with a clear head, “bad” things can be good, and “wrong” turns can lead to the right path.

Debate Over Learning Lessons and Capturing “Best”

KM imageAt our MW KM Symposium on Friday, a few of us had a lively debate over two cornerstones of knowledge management: capturing lessons learned and vetting “best” practices. While I don’t think we came to consensus on either topic, it was nice to actually discuss and challenge one another.

The debate over capturing lessons learned was centered around that focusing on only what went wrong never leads to what is right. That we should only focus on the positive, identify that and replicate it. I agree and disagree. I think there is still value in discussing what went wrong and then brainstorm on how to prevent what went wrong. And, that’s the key. Only capturing the “wrong” doesn’t do anyone any good but taking it the next step and realizing how to prevent what went wrong is a key part of sharing knowledge and not committing the same mistake over and over again.

I found it interesting that most of our debates centered around semantics and that semantics seem to play an awfully big part in pitching and clarifying knowledge management activities. “Lessons Learned” meant only focusing on the negative for one speaker; while myself and others felt that implied in “lessons learned” is learning. So, in a sense, we agreed that only focusing on the negative is not productive but talking about prevention and sharing how to prevent is learning and vital to any organization.

I presented the premise that we should enable people to simply share stories and not worry about setting up committees to review and vet “best” practices. If something is “good enough” it will meet the need of the person seeking the information to help them not start from a blank slate. That no longer do we have the time or resources to vet best practices. And, while there may be industries where there is truly one best way to do something, I contend those are really standard operating procedures and should be integrated into training manuals and process documentation. For other organizations, however, there may be lots of good ways to accomplish something. We should capture, serve up and let people decide and customize these practices for themselves and re-share to keep the sharing cycle constantly flowing.

Want True Collaboration? Wikify!

The most common question I get about web 2.0 tools is when should we use a wiki? I find this question most interesting. Even though Twitter has been around a lot less time than wikis, it seems like companies have figured out Twitter’s place in their tool box but wikis are still a head-scratcher.

We are so document-centric that it is difficult to understand how wikis could or should fit into the content management – collaboration puzzle. With most wiki software, you can attach files to a page within a wiki but I would not recommend using a wiki as a primary document storage vehicle. Instead, wikis are the ultimate collaboration tool, in my opinion.

When we think of the word “collaboration”, we think of working together, co-creation, teams and even innovation. Wikis are the perfect tool to enable the process of collaboration but require TRUST. To change others’ content, the users of a wiki need to trust each other that if something he or she wrote is deleted or edited, that the person making the change knows better. We also need to have thick skin to accept those changes. Most of us have come a long way from getting deflated at the sight of intimidating red ink our school papers, but one needs to foster a culture that can handle true co-creation just in case!

There can be no ego when using a wiki. Titles are checked at the door when you log in and every person’s opinion counts. If your culture does not accept this then wikis will be difficult to implement but not impossible. Sometimes, it takes new tools like this to prove efficiency and creativity to actually change a culture from being overly hierarchical to more collaborative.

The process requires commitment; the satisfaction is realized in the end result of a great piece of work co-created by many qualified minds. Below are some great applications for wikis:

  • Company Policies: collaboration on a small team (usually Legal and/or HR)
  • Training Guide: collaboration among a specific discipline or management level
  • Lessons Learned Repository: collaboration among one or more project teams
  • Best-Practice Language: collaboration among a project team (document assembly on the cheap)
  • Knowledge Capture/Transfer: collaboration among retiring / exiting population and future population
  • Institutional Knowledge Base: collaboration across the enterprise (great for acronyms, definitions and resource sharing)