7 Keys To Successful Knowledge Sharing

By Scott Ryser 

When knowledge sharing initiatives sputter or fail—and a depressing 70% to 80% of them do— one approach is guaranteed not to work: 'The system's fine, but the users need fixing.' More than any other enterprise endeavor, collaboration systems and processes must conform to team culture and behavior or they simply won't work. Successful initiatives have seven principles in common. 

1. Start with the people, not the technology 

Every knowledge sharing initiative has three components: people, processes and technology. Every successful knowledge sharing initiative tackles them in precisely that order. No exceptions. 

It's easy to gravitate toward the technology part right off the bat. (It's the most manageable item on the list, after all). But there's no way around it: you must understand the complex interconnections among people and processes first. It's impossible to make good decisions about a knowledge network until you really know how your team thinks and works. 

Do this by making the first step of your requirements-gathering process an environmental scan. Objectivity counts, and using a third party for this fact-finding mission virtually always produces the best results. 

This exercise isn't intended to build a feature/function checklist. It's a systematic, non-judgmental observation of how work actually gets done in your organization. Who knows what? Where do pockets of expertise and influence reside? How do your people make decisions? What does it really take to get a deliverable out the door? You're looking for subtleties, cultural clues and informal networks—the intangibles that have life-ordeath power over every knowledge management initiative. 

When (and only when) you've absorbed the findings from this scan, you're ready to look at software. Vendor claims notwithstanding, the number-one feature on your evaluation checklist (assuming all the systems meet your security and expansion requirements) is usability. Features and functions aren't worth much if people can't (or won't) take advantage of them. 

How intuitive is the software? How well does it support the team's day-to-day activities? How quickly does it adapt and scale? How much control do people have over their own work? These are the questions that matter. Until you’re satisfied with the answers, everything else is secondary.

THE NUMBER-ONE FEATURE ON YOUR EVALUATION CHECKLIST IS USABILITY (ASSUMING THE SYSTEM MEETS YOUR SECURITY AND EXPANSION REQUIREMENTS). 

2. Set the stage for an immediate win 

Any knowledge sharing system on your short list should be designed to give workers the satisfaction of mastering basic functions the first time they log on. This initial experience is crucial. If you saddle employees with clunky software they'll just ignore it until it goes away. (And sooner or later it will.) 

Vendors all describe their interfaces as 'user-friendly,' but users don't necessarily agree.  Like it or not, they're going to compare their new system to MySpace and other social networks that raised the bar for software usability once and for all. Requisites include straightforward navigation, plain English commands and taxonomies your users already know and understand. Yakabox™ users configure their Activity Viewer right from the desktop using an interface that is literally as intuitive as facebook. They see, share and publish their own content immediately. 

3. Nurture a champion 

Every team has at least one person who 'gets' collaboration right off the bat. This person may be so low-key that you'll have to do some digging, but finding an internal champion is well worth the effort. 

Forget technical credentials, titles and job descriptions. None of that matters. You're looking for someone who's got an open mind, available (probably not a road warrior, in other words) and enjoys mastering new skills. Acknowledge him or her as an early adopter, solicit feedback, and listen carefully. This person will be your team's de facto knowledge management expert and the system's best evangelist.

4. Let users have their way (within reason) 

Remember how we installed transactional systems in the old days? Plug in the new one, unplug the old one, and bingo: everybody went live at the same time. 

Knowledge sharing just isn't that tidy. Command-and-control doesn't work with knowledge management. Certainly, some aspects of knowledge sharing have to be tightly defined and managed—permissions and security settings, for example. But at the operating level, technical flexibility is vital. A knowledge network is a work in process, so why not give users control over their own enhancements? 

THERE'S A GOOD LESSON TO BE LEARNED FROM TWITTER. IF YOU GIVE PEOPLE AN EASY WAY TO CONNECT TO COLLEAGUES AND CONTENT, THEY'LL UPDATE ALL DAY LONG. IF YOU FORCE PEOPLE TO UPDATE THEIR STATUS, THEY'LL CALL IT AN INVASION OF PRIVACY. 

Yakabox™ users don't wait for the IT department to deliver custom applications. They can do it themselves. The system's architecture supports fast, frequent customization with no 'one size fits all' restraints, so each work group, department and division can make the system its own without compromising privacy or security. Every team on the network builds (or retains) its own secure web sites, taxonomies, applications and workflows. 

5. Keep the stuff that works 

Every work group has tried-and-true ways to get the job done. People take them for granted—until you try to take them away. To avoid that flashpoint altogether, choose a knowledge network that doesn't require your employees to abandon existing systems. There's no reason to start from scratch. Your goal is a smooth knowledge management transition, not wholesale change. 

6. Take it one step at a time 

The previous point is worth emphasizing. It’s important to roll out knowledge sharing in small steps. Unlike most enterprise technologies, a knowledge network generates immediate benefits from incremental deployment, and those benefits multiply at every step. This is why scalability matters: if you start too small and you're forced later to replace an outgrown system, the interruption takes a huge toll on momentum. 

MAKE YOUR PROGRESS MEASURABLE. 'OUR GOAL FOR JANUARY IS 100 CONCURRENT USERS' IS SOMETHING PEOPLE CAN GET BEHIND. NOBODY GETS PUMPED UP ABOUT 'OUR GOAL IS BROAD USER ACCEPTANCE.' 

Make your first goal something the team can accomplish quickly and definitively. ('Success early and often' is a Yakabod mantra, and we've never seen it fail.) Some clients start by hooking their Yakabox™ into an existing system—SharePoint, for example—so team members see first-hand how much more they're able to do with a familar tool. 

No matter where you choose to start, make your progress measurable. For example, 'Our goal for January is one hundred concurrent users' is something people can get behind. Nobody gets pumped up about 'Our goal is broad user acceptance.' 

The one-step-at-a-time principle also holds true for major system customizations. Traditional software development is poorly suited to these applications because it's too linear, too slow and too rigid. Nailing down five years' worth of requirements before writing a single line of code is massively inefficient: the world just doesn't stand still that long. 

Agile development is a better bet. This iterative approach to building software chunks the work into a series of closely spaced deliverables, and it reduces cycle time from months (or years) to weeks. There's no better way to demonstrate the value of users' input. When they feed recommendations into the development cycle and see them live shortly after, there's no question in their minds about who drives the system.

7. Communicate clearly and frequently 

The minute knowledge sharing plans go public, the first (unspoken) question in everybody's mind will is 'What's in it for me?' Be prepared with clear, specific answers and expect to repeat the message over and over. 

Create a written plan that defines what, why, how and when changes will take place, how the information will be communicated, and who will do it. Go into detail about what people can expect at each step. 

EVERY ORGANIZATION IS LOADED WITH INFORMATION STOVEPIPES, BUT FORGET THE WRECKING BALL. IT'S MORE EFFECTIVE TO POKE HOLES IN THESE SILOS UNTIL THEY COLLAPSE UNDER THEIR OWN WEIGHT. REMEMBER, TOO, THAT IT'S IMPORTANT TO ACKNOWLEDGE SMALL GAINS. DON'T WAIT FOR MAJOR MILESTONES. 

Spell out how team members will benefit, personally and collectively, from knowledge sharing. Make these benefits tangible, relevant and personal, and communicate them in various ways. Mix it up: small-group meetings, brown-bag lunches, email, memos, newsletters, a Q&A sheet tacked to the break room wall. Consistency and repetition are important. Nobody can absorb the message fully until they hear it several times. 

People want credit. Don't set up a system where contributions are unattributed. Privacy is good, anonymity is not. Employees want credit for their work. 

Recognition matters as much as money. Most employees need some incentive to put in the extra time and effort it takes to get knowledge sharing off the ground. Monetary rewards are always welcome, but they are not a substitute for timely, frequent recognition. 

Forget your high school English teacher. Drawing attention to grammar, spelling, and composition over every post or shut down altogether. Knowledge sharing thrives on a steady stream of ideas and experiences captured while still fresh, not carefully edited management reports. 

NO MATTER HOW SIMPLE OR COMPLEX YOUR INITIATIVE, UNIVERSAL TRUTHS ABOUT HUMAN BEHAVIOR APPLY. YOU CAN AVOID COMMON MISTAKES BY KEEPING THEM IN MIND. 

People don't always realize the value of their opinions. It's surprising how much we take our own experience for granted. How many times have you thought to yourself, 'Oh, everybody knows that!' when asked for advice? Well, it takes courage to put your personal opinions in writing, and even more courage to assume your experience could be useful to someone else. Don't be surprised when people are hesitant to contribute at first. They'll get over it.