The Tribal Knowledge Project: Getting off the ground

When the VP of Mumble approached me about capturing the knowledge floating around in his technical support staffers' brains, I realized instantly that I knew what to call this kind of project. But for political reasons I don't dare call it what it is. So for now I'm not calling this project a knowledge base; I'm calling it the Tribal Knowledge Project. The phrase seems to resonate with the people involved.

I laid out to the team my view of how the project should work:

• We need to think of this as a pilot project. If it works well, there will be others like it - just not back-to-back.
• Scope needs to be tightly controlled; we shouldn't try to address more than about 25 technical issues.
• I'm not going to do the writing. The subject-matter experts will do that, because they're the ones who know the material.
• Nobody will be asked to document more than three technical issues.
• Nobody will be asked to document more than one thing in any work week.
• We'll meet for half an hour, once a week. Meetings start and end on time.
• I don't want the project to run past the end of January.
  

People seemed relieved that I put so much emphasis on keeping the project from becoming a huge time-suck. Hey, we're all busy, and if we don't respect each others' schedules, we'll end up not respecting each other. We can't afford that.

At last week's meeting, I asked project team members what kinds of things they thought it would be important to document. The consensus was that we have lots of information about how to do things, but virtually no guidance on how to choose the right thing to do. We needed to capture the sequence of questions and decisions that allow a technical specialist to solve a customer's problem quickly.

I know the name for that: Troubleshooting. It's the part that gets left out of most documentation, because it's hard.

Somebody used the phrase "decision tree", and someone else mentioned that some people have flowcharts that they stick on the wall by the phone. I don't know about you, but I like flowcharts. It's often easier to diagram a sequence of decisions than to describe it in sentences.

I asked the team: Would flowcharts be a better way to capture this information than writing it out?
The consensus was that yes, flowcharts would be the best way to represent the information.
Does everyone have access to a tool that you can use to make flowcharts?
Yes, we've got Visio.
Is everyone comfortable creating flowcharts?
Yes.
That was last week's big "Aha!" - I hope it was as exhilarating for everyone else as it was for me.

Well, all righty then. We're off in a completely unanticipated direction, but that is OK. This can only work as a collaborative project, and the collaboration goes away the instant someone starts telling everyone else how they ought to do it. The wisdom of the crowd says that the way to capture the really valuable product knowledge is to make troubleshooting flowcharts. The VP of Mumble was surprised when I told him about this, but after he had some time to think about it, he agreed that we're going in the right direction.

I asked people to nominate three technical issues that need to be documented - they might be things that come up a lot, or that are very difficult to explain to new people, or that hardly anyone knows how to handle. We used a document in Clearspace (the collaboration tool available to everyone in the company) to capture the technical issues to be documented.

This morning we had a list of 26 suggestions. This afternoon we met to talk about them. We started by categorizing them, and people sometimes popped off the questions that customers would ask - in layman's language - that pointed to the topic under discussion. One of the managers said that we need to include the customers' questions in each topic, and we realized that we needed to take that thought a step further: Customers' questions, in layman's language, need to be our starting-points. When our people field the phone calls, they need to be able to look up a customer's question and link to the right troubleshooting topic.
That was this week's big "Aha!"

It's becoming a very exciting project. Not only do I have the rare privilege of watching a bunch of very smart people as they discover how information works, I get to learn from them and with them!