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!

The Wisdom of the Crowd: Prologue

A few months back, I hired on at BlobCo. I knew immediately that I was in for a wild ride, because so many people expressed so much delight that I had signed on. (This would relate to biting off more than you can chew.) If you're a technical writer and everybody's glad to see you before they even know about your chocolate chip cookies, it's a bad sign. But now I've been there long enough that people know about the cookies. Long enough to have delivered my first big project, too; and now, long enough that people are starting to ask about other things they imagine I might do.

A couple weeks ago, the VP of Mumble came to me with a new request: BlobCo has a great team of technical people working with our customers, keeping the customers' websites and software working right. But it takes months to learn the ins and outs of figuring out what's going on when a customer's site starts misbehaving, and there's been enough turnover that the VP was very concerned about the loss of brainpower. He asked me to start a project to capture all that valuable information before it walked out the door. I told him he'd have to negotiate with my VP, but I'd say yes if my boss said yes.

The boss was sitting a couple cubicles over, so I hollered his name. "Yes?" he answered. Talk about your comedy set-up - I couldn't ask for better. "Well, there you go. That sounded like Yes to me."

I did actually give the boss a run-down on the situation. He was concerned about how much of my time it would take, so I told him how I planned to work it in:
I'm not going to do the writing.
The people who know the material will do the writing.
I'll manage the project, help them as needed, and let them know what fabulous people they are. I'll figure out how to stitch it all together and make it easy to find and to use.
But I'm not going to write the darn thing.

The boss said yes for real, once he understood the problem and the approach I planned to take in solving it. I went back to the VP of Mumble to talk through the strategy and agree on a list of the people who should be involved.

I'm not going to write this, I told him. I'll need your help no matter how we do this project, and here's what I think will allow me to keep it manageable:

• Let's have the experts each write the bits they know best.
• Each participant should nominate three things to include in the project.
• Everyone's very busy, so let's not ask them to do a lot in any given week.
• Let's not tackle everything people know how to troubleshoot - just the really hot items.
• Let's not ask anyone to write more than three short pieces.
• Let's hold the project to two months.

The VP of Mumble seemed very happy with all this. We called a meeting to kick off the project.

I know that asking technical staff to write stuff is like pulling teeth, so I used the same trick that the dentist used when I was a little kid: Toys. At the kick-off meeting, I slammed through my talking points, asked for questions (there weren't any), and then emptied a shopping bag full of toys on the conference table. Everybody had been silent through the meeting, but the toys broke the ice. People started asking good questions, cautiously voicing approval for the idea of the project and exploring the "how".

Rubber duckies, Gumby figurines, prismatic "robot glasses", wind-up toys...these got the conversation started. I'm going to need to do more than just hand out toys, though, because I have no formal authority. These people are my peers. I can't compel their participation. I must earn that, along with their respect. One of my top priorities will be to make sure that all the project participants get full credit for their expertise - because that's what keeps BlobCo successful.

Over the years, I have learned that when I don't have prior experience to guide me, the best thing I can do is tell the truth about that. So I've let everyone know that I haven't done a project like this before. (Now I can go ahead and freak out - people will understand.) But I have a plan; so we're further along on this than BlobCo has ever gotten before.

We're only a few days into the project, so I don't yet know how it's going to turn out. Stay tuned!