Optimizing the Wrong Part of Knowledge Management

I sat in on the report-out session from a kaizen event this week, and something occurred to me as I reviewed a ton of interesting findings in a very short time …

Best Practice

Self-contained deliverables are the most powerful tools for knowledge knowledge transfer you can have in your organization. I’m talking about a document that stands on its own, and effectively communicates an idea without needing the author nearby to explain anything.

The topic doesn’t matter – conceptual white paper, status presentation, process map / instructions, design specifications, etc. The format doesn’t matter – Word (document), PowerPoint (presentation), Excel (spreadsheet), Project (plan), Visio (diagram), and so on. The telling event is when this deliverable is sent out as a pre-read before a scheduled meeting or review. If written well, the time allocated for the meeting is spent discussing questions, clarifications, exceptions, and/or additions – as opposed to explaining the document itself.

Reality Check

Creating self-contained deliverables is hard; it takes skill in a number of different areas to create clear and concise prose, relevant statistics and metrics, relevant and impactful visuals. It’s also time-consuming – well structured examples, screen prints, illustrative diagrams require skills in multiple technologies. Of course, before all the fancy words and beautiful pictures, you have to be able to lay out the opportunity / problem / situation so the reader can quickly get up to speed on the relevant points.

The other challenge, of course, is finding the time to create the content, capture the message, make the connections. It’s always hard to manufacture enough time.

So, what ends up happening? People tend to optimize the knowledge capture process; minimize time spent creating documents by putting together enough material to facilitate the conversation, capture the main points, and help them remember everything that they want to review when in front of the team.

The Problem

Unfortunately, this misses the bigger picture. By reducing the time I spend capturing the knowledge, I’m increasing the time required to pass it along; I am sub-otimizing the knowledge transfer process. If I don’t give my content out for a pre-read, I’ll burn half of the meeting time getting roomful of people up to speed on stuff they could have read the day before.

It doesn’t stop there; the same content would need to be discussed with anyone else who might be interested. And, since we’ve already established that time is scarce for all, these next conversations rarely occur; the opportunity for transferring the knowledge to more people is lost, and as memories dim, the value captured in the original meeting is, for the most part, gone …

… or (more likely) concentrated in the head of the person who originated the whole thing. And people wonder why organizations have trouble retaining knowledge, or why groups develop “super users” that create unfillable voids when they move on.

Catch-22

Unfortunately, when confronted with this situation, most people under time pressure will make the obvious choice – stick with what you know. If you’re facing a deadline, capture the information that you need and deliver the details face-to-face. There’s safety in numbers with this approach; I think 80-90% of the business world takes this route. It gets the job done and no one is really faulted for going this way.

Breaking the Cycle

However, as I’ve noted before, there is a lot of power and possibility when you can leverage your knowledge across many people, without regard to time or place. If you want to do more in your organization, leverage more of your time, and/or get your ideas across quicker than the next person, you need to develop skill in creating self-contained deliverables.

There is no single method or style to create self-contained deliverables. Anyone can do it, but you need to figure out how to adapt and adjust your personal communication style, and change the things that are ineffective. My favorite methods:

1. Borrow Liberally: Most of the things that I’ve learned about documentation and communication came from other people, other things I’ve seen, read, or heard that particularly worked for me. A writer’s effortless prose, a presenter’s terse yet effective pitch, a diagram’s elegant visualization. Develop the habit of looking for stuff that works, and the curiosity for decomposing it into methods you can use for your own communication.
2. Study Minto and Tufte … and other practitioners of the art of communication. Minto’s Pyramid Principle is very effective when introducing a reasonably complicated new idea in a short amount of space. Tufte will teach you how to strip out the extraneous information while packing in the pertinent; he’s talking about diagrams and visualizations, but it works for your words, too!
3. Use the Right Tool for the Job: Every MS Office application has the ability to draw squares, circles, and lines – diagrams in the midst of your spreadsheets, project plans, and documents. But nothing beats Visio for quick diagrams that give precise control of placement, size, and alignment. Similarly, I love Excel’s ability to quickly create beautifully structured tables of information, in a way that gives me fine-grained control over row heights, column widths, font sizes, number alignment, and other effects. Sure – PowerPoint can do a diagram or a table, but it’s much quicker to build it in Visio or Excel and paste into PowerPoint.
   Note: Learn how to paste as an Enhanced Metafile, not as an OLE object – you’ll thank me for it.
4. Get Feedback: Ask someone whose opinion you trust, and who is at least a decent communicator themselves. Ask them if your written documentation was clear, and did it explain everything they needed to get the whole picture. Better yet, become your own harshest critic; use the voice recorder or videotape your presentations – are you convinced by what you see / hear? Pick up a old document or diagram you created – can you still get meaningful information out of the content or was it really dependent on context?

Take responsibility for the communication – if only to save yourself from the hassle of repeating yourself again and again and again …