But sometimes there is not enough time or resources to do it per fectly or even right. So the question is whether it is worth doing at all. It could be that with an 80 percent solution, you could be much better off than with a perfect solution that will never come. Speed is very important. Time to market is an important factor, whether exter nally to your customers or internally in competition with others in your organization.

It is worthwhile to realize that there are many situations where a suboptimal solution is actually more successful. I am not advocating striving for general mediocrity but for you to realize that a solution that misses its time to market might be useless, while one that hits the market quickly can create high value. One thing often overlooked is that results today are much more team oriented and collaborative then they were in the past. If you have a single actor creating something to be used in its final stage and have an organization that expects everything it receives in that final state, you will need people to produce near-perfect results. If instead you are building on collaborative forces (e.g., when building on social media and Web 2.0 technologies and processes), then handing some thing “imperfect” to the community “fast” can be a lot more valu able than if you held a contribution back just to improve on it in your hidden little office. One of the core principles of these types of knowledge exchanges is to have a high flow of knowledge, so you are better off with a larger number of building blocks versus a few black boxes.

The next sections discuss some aspects of this line of thinking including a look at quality and time-to-market delivery.

The top 10 responses were:

The interesting part about the order of the responses was that the top two each got over 70 percent of the responses, while items 3 through 10 got only between 30 and 40 percent. So the two top barriers were seen as the major barriers for knowledge management to succeed.

I will discuss the top three in more detail and suggest some methods to attack those barriers.

It was interesting to see that in 1997, the respondents to the survey considered the IT structure as significantly less important than a number of softer factors. Nevertheless, in the years after that survey, technology was very often the main point of focus.

I will not go into detail on all the barriers that made the list, but one that is worth a deeper discussion is the fourth, knowledge is power.

Today’s organization is much less about the knowledge you have. It is a lot more about the potential of knowledge that you can build. In the thirteenth century, the city of Venice moved all of its glassmaking facilities to the island of Murano in order to preserve the secret knowledge of glassmaking. It took until the end of the sixteenth century for the knowledge finally to slip out. At that time, Venice lost some of its power to its competition. In spite of harsh measures (i.e., death penalty for any glassmaking expert trying to leave), some of the knowledge made it into other parts of Europe, but there is still a lot of special expertise on Murano.

Things have changed since the thirteenth century. Most of the knowledge that people need today renews itself at breathtaking speed. Today we are talking more about days, months, maybe a few years but not centuries before knowledge might become obsolete. Due to this speed of change, it is usually dangerous for an individual to think that having knowledge represents power and to rely on it. The real power comes to those who are best at building and transferring knowledge, not at having knowledge. We are living in dynamic times. The most valuable people in the organization of the future are not those with knowledge that might be out-of-date tomorrow but those who are most capable of building new valuable knowledge. And to build knowledge, you need a network. But the network will not continue to share with you if you do not give something back. Hence it is those who invest in their network who are most likely to be good at building new (very much needed) knowledge. But people are often still stuck in the old model.

There is one more aspect to the “knowledge is power” barrier. I usually urge people to turn themselves into moving targets. One big misconception is that if I share my knowledge, the person I shared it with will automatically be at the same level as I. But as I explained before, this is not true; there is no one-to-one knowledge transfer. So I share some information with somebody, who then needs to re-create knowledge in his head out of that information. People learn during the sharing process. Learning happens during the formulation of the information about the knowledge I want to share. I usually learn something every time I formulate the information, and by doing so, I am basically getting ahead of where I was the minute I started the sharing process.

Those who are very much afraid of competition often underestimate this effect. They fear that the person they share with will use the information to get ahead. But through the complete learning that comes from frequent interactions, you can turn yourself into a moving target. Each individual you share with gain from the information, but you can get even further ahead in your area of expertise. Some recent studies confirm what I have experienced over the years.³

These effects are often not visible. Via some education, stories, and examples, you can educate people to realize how wrong they are. In some cases, it is also a matter of getting the right people into your organization. It could very well be the smarter choice to pick people who show potential to build knowledge in dynamic environments over those with knowledge from the past.

Those expectations are unrealistic. It is important to acknowledge that there are barriers to overcome. It takes time and effort to talk to somebody, to lay down information in documents or produce assets that then can be moved around the organization and used as pointers to experts. If you acknowledge that a certain amount of effort needs to be spent, you can start looking at ways to minimize that effort.

Sometimes people want to share, but they want to expend almost zero effort doing so. But if people do not put any effort into the sharing, the contribution is often of very limited value. In the ToolPool initiative, for example, people might complain about the time it takes to describe a tool in a good introduction. However, everyone expects that the tools they explore will all start with a great introduction. A good introduction and categorization are very hard to produce automatically. Sometimes people complain about missing information in others’ contributions, but their own contributions lacked the necessary diligence as well.

More effort is not always better. The trick is to shoot for the perfect amount of effort to get the best possible output for that effort. Finding the best effort-to-result ratio needs regular tuning of processes. Finding that right balance is critical as spending effort of this type represents cost to the organization. You want to minimize the cost but maximize the result. If you tune effort to zero, you will not get any value; if the effort is too high, you might get great contributions, but at what cost? Is it worth it for those involved in day-to-day activities to spend that much time on sharing their knowledge and cut into other activities? At the same time, conditions change constantly. People get more sophisticated, topics change, or you are facing different and changing cultures. This is why continuously looking at the effort-output equation is very important. Analyze frequently whether you are asking too much from your contributors and might lose them, or if you are not asking enough of them and might lose the ones who are expecting a certain level of output quality.

A quick word on quality. This is an area where people often say: “In my knowledge initiative, I only want the highest-quality knowledge being shared.” I do not want to dispute that quality is important. In an ideal world, all contributions are very nicely prepared and present extremely useful knowledge. But you have to define what quality you are talking about. With ToolPool, we primarily have two types of qualities: technical and contribution quality.

To tune the effort-to-outcome ratio, it is important to check where the effort is spent and whether it is actually a smart effort. If people are asked to spend a lot of effort to prepare a contribution or provide support information with it and it is never used, the effort would have been wasted.

It is not easy to get the tuning right, but I always try to teach contributors to think about their contribution not like a contributor but as if they were a reuser. Contributors should keep in mind the basic and most important pieces of information they would expect from someone’s contribution. It is fine to make it easy for yourself, but put some smart effort into making it easy for users. Put yourself into their shoes.

A very good example to illustrate this point comes from a few years back with ToolPool. A consultant sent in a tool (a collection of SAS programs) and she had put in some effort to write a special service routine to package the tool. While from her point of view, this type of packaging service routine was very useful, it would have been more sensible to provide a service routine that unpackaged the tool. She was probably one of very few who needed to change the tool and then repackage it; likely there were hundreds who needed to reuse the tool; all they needed was to unpackage it.

Often it is not about more or less effort but the right effort. Knowledge intermediaries can help to tune the effort on a case-by-case basis by working with contributors to help them find a good balance of effort to outcome.

Instead of giving the potential contributors two weeks, I encourage them to contribute the tool now; in the documentation under limitations /notes, they should write down what they would be doing if they had two more weeks.

If they contribute the tool and someone else uses it, that user knows that it is not perfect, since the status has been indicated. For example, say Consultant A provides a tool that is missing features a, b, and c. The author puts the tool out there, describing in a positive way its limitations. Consultant B finds the tool and thinks, “Well, not bad, but I need features a and b.” So she uses the tool as a basis and develops features a and b on top of what she picked up. Here comes the big difference to Consultant A adding features a and b. Consultant A would have done it on normal company time or maybe in free time on the weekend. If Consultant B needs the features of the tool for a customer, likely she will develop it as part of a project; that is usually paid time. This is a much more effective method. Because it is in a real project, it is a lot more likely that features a and b are implemented not how a consultant thinks it should be done but how a customer really needs it. And if things work out well, Consultant B will contribute the enhanced tool back to ToolPool, or at a minimum let Consultant A know that she actually did features a and b. Together they might figure out how to best contribute it so others who might find it useful can also get it.

Because a tool might get shared early, a lot of people might think that the quality of the contribution might be poor. However, this brings up a good question on how to define quality. Knowledge quality is very hard, if not impossible, to judge because a small raw idea can be much more valuable than a cleaned-up and finished big programming system that is seldom needed or hard to fit into existing environments. This type of quality is dependent on the person judging it. It is difficult to predict if something will be a success or not. Spending a lot of effort to get it to a level that I call “presumed perfect” could be a waste of time and effort. I am not trying to encourage the production of low-quality material, but without an easy way to judge a tool’s worth, trying to focus on finished contributions only can be too limiting.

Exhibit 6.1 exemplifies what often happens during the creation of a potential contribution. A consultant has a great idea and implements it rather quickly, getting a good amount of functionality done in only a few days. The functionality/quality curve rises sharply. At one point the curve flattens; it takes more and more effort to standardize and raise a tool to perfection, which it never reaches. For innovation, a good time to share is in the time frame depicted by the shaded area. There is no perfect sharing point, but picking one in that area has some advantages.

When we looked at more detail on how people reuse contributions in ToolPool, we found that unless it is a small component or a complete system, they will not be able to reuse it exactly as is. With some exceptions, they will need to adapt it to the specific (and dynamically changing) environment of the customer they are working for. So if Consultant A puts really big efforts into ensuring that the tool is “standardized” and cleans it up to be really nice looking before contributing, there is a likelihood that Consultant B, who picks it up, will spend a considerable time to restandardize it for his customer potentially pulling out changes that were added based on preferences that Consultant A had. In that case the effort is wasted twice.

There are reasons other than the need-more-time argument that keep people from contributing. Sometimes the argument might be—and this is somewhat in contrast to the time-to-market argument—that a contribution is for a product or solution that is not the very latest or does not support the current strategy. In the case of solutions to older products, you will have to ask: How likely is it that there will be a customer problem with that product? From a marketing point of view, you do not want to push old messages, but from a technical support point of view you are likely to have customers still using a solution prior to the latest version. It is not possible or wise to force an upgrade in all cases; sometimes it can be very convenient to have a solution for this older product that the customer dearly loves or is not ready to throw out.

Similarly, when you have a solution that does not support the current strategy, you could either police it or position it:

I have found the positioning approach to be the smarter one. Realistically it is hard to control knowledge that appears very valuable to some people by trying to ignore its existence. If you cut it out of the open knowledge-sharing process, it will usually trade under the table. In contrast, if you let it enter your initiative but add a clear positioning, you are bringing it into the open. People will know it is there, but they will also know that they should be making use of the contribution in only very limited situations, if at all. Positioning should always include a pointer to the official supported version that is fully in line with strategy. The knowledge will flow whenever people see value in it, no matter if they are correct or if it supports current strategy. You can divert that flow into the main knowledge stream that you are managing, or you can let it sink under the surface.

There is another issue with high numbers: attention. As part of ToolPool, we send a weekly e-mail to about 1,600 technical people worldwide every Sunday. Announcing between 5 and 15 new and updated ToolPool contributions per week produces a manageable e-mail that people like and find time to browse through. If the same e-mail had 100 new entries, you might think that it would be of higher value. But most people would not even read the first 5 to 15, as they are overwhelmed with the choices offered. The best you might get is that they scan over it but do not have time to look at any of them in more detail. From an attention point of view, I strongly believe that less can be more.

There is a similar effect on the contribution side of things. When you are asking for contributions and want 100 parameters (meta-information), a lot of people might give up at the third parameter, because they are overwhelmed and frustrated by what is ahead of them. If, however, you are asking for 10 parameters, you are more likely to get 9 good ones, and 9 are better than 3.

Usually the quality of the meta-information for each of the parameters is also better with a small manageable set. Finding the right amount needs regular tuning. This is not always easy to do if there are systems involved. Systems are not always flexible enough to add/ remove or change the meta-information structure.

Therefore, it is best to err on the low side and be firm on pushing back on requirements from somebody who is asking for all those parameters, especially if it is not clear whether the information will ever be used. Also, define parameters in an open way to cope with future changes. You are putting so much effort into launching and embedding an initiative that you want it to survive long term. This is possible, however, only if you are not getting tied down in today’s details and are open for the future.

The less-is-more theme can also be applied to system interfaces and underlying processes. Start with a smaller set of features, but make the interface flexible so users have room for adapting to changing processes, possibly by customizing the interface itself. Processes should be flexible as well to cope with changing conditions.

Collect frequent feedback and enhance the interface in small steps based on user input. The average user will be happier with the simple interface than with something overloaded that does not provide any immediate value. Of course, less is not the only guiding rule. Often users want the “perfect” amount of information in front of them. Not more and not less. Unfortunately, that perfect amount is different for different people, and what is considered good presentation will vary as well.

Portals are an example because they can be a flexible system that allows for customization. But a note of caution regarding customization: An argument often heard from the technical side is “This system is perfect because the users can customize it anyway they want.” In reality, the majority of users (who often are a lot less technical than the designers) do not want to customize, they want it to magically have the perfect interface without having to spend a lot of time on anything not related to the actual business process. That presents a certain dilemma regarding the customization scheme. So customization would need to be extremely simple.⁵ Alternatively, one idea would be to employ a knowledge intermediary in a role I call the portal customization coach. This person would be an expert on customization and would go sit with every new (or role-changing) employee and assist in product customization. Just as we have ergonomics consultants help us set up desk, chair, and equipment to be optimal from an efficiency and health point of view, portal customization coaches would set up the information ergonomics. This is a great example of a role that the human resources function should look into creating.

One area where these limits are becoming more evident is in global companies, where the interaction from country to country is growing but information exchange is kept within boundaries, either geographic or divisional.

I am by no means a legal expert, so I will not go into great detail on the issues. In general, I would emphasize that those driving knowledge flow management need to be in regular contact with their legal department and involve them in strategy building. Integrating legal processes can cut into some of the desired freedom, but the consequences for the whole knowledge flow management program could be disastrous if legal limits are ignored. Some examples of where those limits might apply are:

Those are just some examples. The details of what is allowed and what is not can be complicated, and can also change over time, based on new regulations, laws, or bilateral agreements between countries.

But there are some general ideas on how you can tackle this barrier to at least some degree:

As we have seen, there are a number of barriers that can inhibit organizational knowledge flow. Reducing those barriers is one way to improve your flow. Motivated by some of the drivers, people often like to share their knowledge. The barriers could be holding them back. Therefore, managing the barriers is a good way to positively influence the flow.