Originally published on June 9, 2016
This is taken from the breakfast tutorial I gave at KMWorld 2015, which was captured on video:
KM Myth 1: Push it
The first myth is the desire to push. I worked at Deloitte where John Hagel is the head of Deloitte’s Center for the Edge. He’s written a book called The Power of Pull, but it’s not as if everybody always follows that religiously. We still have a lot of people who love to push things out — namely, the idea that if only we publicize it, advertise it, promote it, force it into someone’s mailbox, etc., that people will read it and do whatever it is that we’re trying to get them to do. Variations on this “push” approach include promoting banner ads on the Internet, sending out frequent emails or frequent reminders and then, telling your audience that they need to do this, reminding them to do that, or pleading with them to complete some profile or submit some document or use some tool.
The problem with push is that we’re so used to seeing this kind of thing that we just tune it out. If you receive an email and it isn’t one that you specifically were looking forward to getting, it’s not from someone that you consider to be important, it’s not on a subject that’s relevant to you, your general inclination is to ignore it, delete it, get rid of it, or automatically filter it into a junk folder. The idea that we can push something and that that will work is less and less valid.
Ironically, we’ll lament that we get too much email, but we’ll still rely on it. The same people that will say, “I get too much email, I don’t want any more email” are the ones who only use email to communicate. It’s a lot better to try to create pull, demand for what you have to offer, than if you try to force it on people. Figure out ways to get your message across in such a way that it’s not forced on anyone. If you can make it appealing, if you can make it at a place that people can choose to consume it, that’s a better way to get people to read it, understand it, and take whatever action you want than if you try to force it on them.
KM Myth 2: Someone Else Will Do It
This one starts with leaders who initiate a KM program and then will leave it to others and say, “Okay, you take it from here and I’ll do something else.” Or people who work in knowledge management, but who don’t lead by example. They want everyone in the organization to use a particular tool or to follow a particular process, but then they don’t do that themselves. They figure someone else will do that.
They might say that we should use an enterprise social network, but then they continue sending email or they say, “You should fill in your profile,” but then they have someone else fill in their own profile. You’ll run into this kind of thing when you’re encouraging a leader to interact in an enterprise social network or to do something using one of the tools and they’ll delegate that to someone else. They’ll say, “You fill in my profile or you post for me” or “you ghost write it for me,” and things of that sort.
We can all sense that when it’s happening. You can’t really get away with that without people realizing it. If you really want someone to do something, one of the very best ways to do is to do it yourself and then, not only will you learn about how it works and the pros and cons of it, but other people will also see you doing that and they’ll do it as well.
Another version of this is benchmarking competitors. We see that a lot. We’ve got to benchmark our competitors so we can do what they’re doing. It’s valid to find out what other organizations are doing. That’s the value of going to a conference like KMWorld. We hear from each other. We can learn and we can innovate on what we hear from other people, but if you only want to do exactly what other people are doing, then you’re really just leaving it to someone else. You’re not thinking about what’s good for your organization. You’re saying, “We’ll do just exactly what someone else does,” and that’s not really going to be very innovative or may not even be relevant to the problems that you face.
Another one is not wanting to get your hands dirty by learning by doing. Sometimes, when a new tool comes along, the people who are trying to promote it have to be the first ones to jump in and try it. That can be messy and it may not work right. It might be hard. The point is, if you don’t do that and then you’re turning around and talking about it, that’s not a good thing.
We see this a lot when it comes to getting people to use knowledge management tools by asking them to post in an enterprise social network or contribute documents or anything that requires them to sort of take a risk, but we think someone else will do it. We’re all familiar with the general rule of thumb that says about 90% of any community will tend to read or be more passive in a community and there’s 10% that’s more active. If the 90% never post anything at all, if they never contribute anything at all, then obviously, our knowledge sharing programs aren’t going to work.
It’s like if we do a search and we don’t find what we’re searching for, we can blame the search engine, but more often than not, it may be that the thing you’re searching for isn’t there. And why is that? Someone didn’t contribute it. Somehow things will magically get done so we can take advantage of them. We can have supply without anyone creating it. We’ll just search and find it or someone else will ask the question that I was thinking of asking, but I’m afraid to ask and then I’ll benefit from that. But if that doesn’t happen, then no one ever learns. We’ve got to be willing to do it ourselves as opposed to expecting someone else to do it.
Consider the concept of demand without supply, that you should just be able to get whatever you want. I regularly receive requests where people are asking for some very, very specific thing. Recently I received one from a person who wanted all kinds of very specific information about best practices for KM, ROI data and so forth. This person seemed to think that everything is just out there somewhere and that we will just magically find it. But if someone hasn’t supplied it, it’s going to be hard to find.
Can you lead a KM program without having deep knowledge of the field? I don’t think so.
KM Myth 3: KM is Dead
Here’s one we all have heard and recently came back to life again: the assertion that KM is dead, it’s on life support, or it’s irrelevant. We’ve been hearing this for the last 20 years. Not only was KM sort of born in 1995, but a year later, people were asking if it was dead. Along the way, so was everything else that we used. We’ll hear that email is dead, but doesn’t seem like it is. We still seem to get lots of it. Social business is dead. Whatever it is, saying that it’s dead just seems like a way to generate interest in a point of view or sell a product or sell a service. You can make a claim like that and it’ll be provocative and people will tend to pay attention to you, but that doesn’t mean it’s accurate.
Recently, there was article that Tom Davenport published about this where he was claiming that knowledge management has become irrelevant. That generated a lot of comments. I wrote an article in response to that called “Is Knowledge Management on Life Support?” I tried to take an objective view, acknowledging that there are some negative indicators that have occurred over the years. It’s not like everything is 100% perfect, but I think there are more positive indicators than negative indicators. The fact that we continue to hold KMWorld and we all come to it, the number of people that sign up to attend the workshops and participate in the sessions, the number of different people every year that are presenting, that’s one sign. The number of times that I get asked about knowledge management doesn’t seem to go down.
Something is going on that continues to sustain it. It may not be rapidly growing in size, but I think it’s clear that knowledge management is not dead. I don’t think the need for knowledge management will ever go away, whether we continue to call it knowledge management or start calling it something else. Will we continue to need to share and innovate and reuse and collaborate and learn? I think we always will. That’s why I don’t think the idea that we won’t need knowledge management anymore is an accurate view.
What I think is dead are some of the older notions that we started out with. When we started out 20 years ago, we focused more on collection and getting document repositories created and measuring things like website visits. Some of us are worrying about that same thing, but I think that’s the thing that’s on the way out.
One of the other reasons people say KM is dead has to do with the name for knowledge management. There are always people saying that we shouldn’t call it knowledge management, that we should call it something else. In one of the slides that I present in my workshop, I show 50 different names that people have suggested for it. They all have some validity. There’s nothing wrong with any of them, but we’re still calling it knowledge management. That’s the label that stuck. Spending a lot of time talking about what we should call it probably isn’t as helpful as worrying about how to do it better.
KM Myth 4: Incentives Don’t Work
We also hear from people that incentives don’t work. I’ve heard this as long as I’ve been in the field. My own view is different. I think incentives do work and I’ve developed incentive systems that have worked quite well and have been adopted by other companies, but the belief is that people will game the system.
We had a point system that I developed when I was at Hewlett-Packard that awarded points for knowledge-sharing behaviors and, theoretically, it could have been gamed. It would have been easy to game because you got a point for every time you posted in the threaded discussion board. We had one person who would tend to post in the discussion board with some trivial comment like “great, thanks,” just to run up the score, and eventually, I approached that person about that. After that, he was never seen in the forums again. It’s self-correcting. If people do this in the open, in enterprise social networks, everyone else is going to see that and they’re not going to appreciate it and you’ll hear back. In my experience, people gaming the system hasn’t proven a problem.
Another part of the incentive issue is that people aren’t really motivated. Intrinsic motivation is more important than extrinsic motivation; rewards wear out. There’s probably some truth to that. There was actually great response to when we added an incentive component to our point system. I think it’s not only because participants could earn some money, which everyone likes to do, but it also signaled the importance of the effort. When they saw that the chief executive was backing up this program financially they said, “This must be important. Therefore, I probably should be doing it.”
To me, knowledge management incentive programs have worked. If you want to see some examples of them working today, you can look at IBM and Accenture, both based on the KM Stars Program I developed at HP.
KM Myth 5: Roll it Out and Drive Adoption
We hear a lot of talk about rolling out a tool or driving adoption. I always cringe when I hear that. Rolling out a tool implies that we have a tool that’s in search of a solution. We don’t know why we’re rolling it out; we just are. In the early days of SharePoint, for example, they’d say, “We want to roll out SharePoint.” They wouldn’t explain why or what it was going to be used for. It just existed for its own sake.
Today, we hear about that with enterprise social networks. We want everyone to start using our enterprise social network and they’ll use some sort of vague terminology like, “We want everyone to start collaborating globally. We want everyone to make connections. We want everybody to interact.” If you don’t get more specific than that, that’s not a very appealing use case. If you say, “Will you please start collaborating globally?” it doesn’t mean anything to me.
If you say that you want them to share, ask, find, answer, recognize, inform, and suggest and then you go into a little more detail about each one of those use cases, people can relate better to that. You could have a conversation with them; ask them, “The last time you wanted to share something, what did you do? Did you share with an email? How did that work? Last time you had a question, what did you do? Did you ask the person sitting next to you? How did that work?”
You can interact on the specific use cases and then you can talk about how the tool that you’re wanting them to actually use does that better. If you just make it this vague thing — you’re rolling it out, we’re driving adoption — that doesn’t generally work too well.
Then there will be the one-time special events like when we rolled out our enterprise social network we had a big fanfare and we had a 24-hour rolling online jam and so forth, but that sort of thing wears out and people can be skeptical about that. We were just trying to drive a lot hoopla and hype over it, and when you do that people will tend to tune it out. I recommend not talking about driving adoption or rolling out tools. Instead, make it clear to people what the advantages of using the tools are.
KM Myth 6: Social Media is Frivolous
We’ve all heard the claim that social media is frivolous, social is not serious, or it’s a waste of time. That’s where we had discussion yesterday where one of the speakers said that you don’t want to call your enterprise social network “Facebook for the enterprise.” That’s probably a good suggestion, because a lot of people will conjure up something different from work if you talk about social in that sense. Some people even say to avoid the word “social” altogether. They’ll tend to give you the example, “I don’t care what you ate for breakfast.”
I don’t actually see a lot of posts about what people ate for breakfast. I don’t think that’s the primary use of social media, but that’s a common lament. Once again, you have to get back to your use case and say, “No, we’re not really talking about sharing what you ate for breakfast. We’re really talking about these other uses that are valid and which social tools do better than other previous tools.”
Then there’s the assumption of wasting time. I’ve even had cases where people have told me, “I was chastised for using the social network to post something and was told to stop doing that and go back to work.” We’ve got some work to do there if that’s what’s viewed as wasting of time. I think you can turn that around and say, “What were you supposed to do instead?” The time that people spend on social networks, if they’re truly sharing useful information for the rest of the organization, if they’re truly using it to ask and answer questions, we have to recognize them and celebrate that, and not make them think that somehow that’s a waste of time.
KM Myth 7: Don’t Control
In the community realm, we often get into a debate about whether we should try to control the creation of communities. There’s not agreement on this. I have one position. There are other people who have opposing views. My own view is that there’s actually value in trying to limit the number of communities that any organization has. There are a lot of reasons to do this, but the counter-argument is that we should let a thousand flowers bloom and use survival of the fittest. Let there be 100 different communities all focused on social media. One of them will emerge and that’s the way it should be.
My own experience is, if you have 100 communities for social media, they’ll all die. None of them will thrive. There won’t be the survival of the fittest. There will be the death of all of them. Why is that? It’s because when someone tries to figure that out, and they say, “I want to go and learn about social media,” they look to see the available communities and they’re shown this bewildering list of, say, 10 communities to choose from, they’ll just give up. They’re not going to go pick one. They’re going to give up, or if they do pick one, they’ll miss lots of other people who would have benefited from sharing information or who could have answered questions.
The thought that we should allow there to be an infinite number of these things, in my experience doesn’t work well. In this instance, limited control has value. Get groups to combine. Make your communities so that it’s easy for the user to figure out which one to join, and to have critical mass where all people interested in the same topic can be together. You should try to prevent redundant communities, but it’s not because you’re trying to make some kind of top-down authoritarian control. Rather, it’s to respect your users — to give them an easy-to-understand environment where they know which community to join, and all the people can reliably be expected to be in that community.
KM Myth 8: Eliminate Risks
Some companies are very sensitive to risks. I worked at one of them, and there are plenty of other ones. They’re concerned that we might somehow share information that we shouldn’t share, or that information would be leaked somehow. In some cases, I’ve seen where they try to control all access to the outside world. We’ve had some instances where countries would say, “All social tools are blocked.” Why was that? Because we’re going to control leaking information that we don’t want to leak.
If you had a social network and it was open, then you would be aware of it if such a thing was happening, because you would see it. It would be visible. If you don’t allow that, what happens? People do it some other way that you don’t see. You can’t prevent somebody from handing a piece of paper or sending an email or having a phone call or some other means. You can’t necessarily control that. Yet you’re saying, “If we block social media, that will be the answer.” It’s actually better to encourage things to be shared where you can see them, and if somebody does something inappropriate, you could then talk to them and make an intervention. Whereas if you drive it underground, it doesn’t work.
My own view is to trust people to do no harm. It doesn’t mean that people won’t do harm. They may do it intentionally or unintentionally, but if they do it in such a way that you can see it, then you can counsel them and you can intervene. If you don’t trust people, why did you hire them? People are working for a company. You hire them. You entrust them with the work that they’re doing. You should trust them to use good sense also when it comes to sharing information.
Here is a humorous, but relevant, example: New technology — the threat to our information
KM Myth 9: Be Like Google and Amazon
Have you ever been asked why your search isn’t more like Google? We all know the reasons why people ask that. The reason it isn’t has to do with scale and the difference between the millions of people on the Internet and the thousands or hundreds of people in your company. But they still ask the question. You’ll even have leaders who say, “Let’s make our search just like Google.”
The other one you’ll sometimes hear is, “Let’s have content ratings like Amazon.” That’s another one of those things that don’t work well when they’re not at scale. The number of people who actually rate things on Amazon isn’t a very large number, but because there are so many people, it’s large enough to matter.
Inside of a company, the percentage of people who might actually rate a document is tiny. Typically, what we see is there are only two types of people who would actually give a one-to-five-star rating on a document. The person who wrote it will give themselves five stars and someone else who had some axe to grind with them will give them one star. You won’t get a useful rating. Why is that?
My own experience is that if I’m asked to come up with a five-star rating, it’s hard. I have to struggle with, “Is this three or four or five?” I won’t do it. I think that’s the wrong approach. It’s better to ask simple questions such as, “Were you able to reuse this document?” That’s a yes or no question. That’s an easier one to answer. It’s like the Like button. If you click the Like button, you don’t have to think too hard about it. You either like it or you don’t. If you like it, you click Like. If you have to rate something one, two, three, four or five, you have to think about it. That’s a different dynamic.
I like this approach better: “Click here if you were able to reuse this document.” That’s a very objective statement. You either were able to reuse it or you weren’t. If one is clicked a lot like that, then you can say that’s probably a document that you’ll want to promote or have it appear higher in search results. Think about how these things actually work behind firewalls inside of companies and treat them differently than saying this should be just like Google or just like Amazon.
KM Myth 10: We Need Our Own
Often, the reason for doing something is the belief that we need our own. I’ll be asked, “Can I have a community for SAP?” I’ll reply, “We already have one. Why don’t you just use that community?” They reply, “I need my own.” They don’t articulate it well as to why, but it’s generally some variation of we need our own. It could be for what they think is a valid reason. It could be “We need one just for this country that we’re in. I need a knowledge management community just for Portugal.” I’ll say, “Is knowledge management that different in Portugal from how it is in some other country?”
If they wanted to have conversations in Portuguese, that might be a valid reason, but if they simply want an English-language community that’s just for people in Portugal, then there are two problems with that: A, there aren’t going to be that many people in it; and B, they’re going to miss out on all the other knowledge management people in the other knowledge management community. Tell them, “You don’t really need your own” and try to refocus their energy to start their own new community into helping lead the existing one. In that case, the best advice is to say, “I’m glad that you’re excited to lead this new community. Let’s have you be a co-leader of the existing one. We can really use your energy bringing in your colleagues from the organization you’re in.” The alternative is to try to get a new one off the ground, which isn’t likely to go well.
We also see the issue with internal versus external — the desire to have an internal community or an internal forum or an internal repository when in fact, most of the wisdom about the subject may be outside of the company. You’ll see that sort of thing in a community that’s formed where people ask some question that could easily be answered if you were part of an external community, but can’t be answered that easily inside.
I had an example of that where someone wanted to know what the job descriptions were for knowledge managers at competitors. That’s a hard question to answer inside a company because we are not our own competitor. If they asked that question in an external community like the SIKM Leaders Community, they will likely get some answers. The idea that we can only do this inside, and we don’t want to do it outside often isn’t going to be effective.
Then there’s the narrow niche. This is where they need an enterprise social network group for a specific module of SAP. They’ll localize it even further. It’s going to be for Europe and the FI module of SAP. We say, “I don’t think that’s going to achieve critical mass. You aren’t going to find that many people. I know you’re excited about it, but you may be the only one in your community.”
We have seen people form their group and then write an initial post where they say, “Hey, everyone. We’re going to talk about the FI Module!” And they’re the only member of the group. No one is actually seeing their excited post. We need to help them understand and educate them and guide them, but we also need to help them to see that when you don’t get critical mass in a community, you generally don’t have an active community.
My colleague, Lee Romero, studied what number of people you need to have for a community to be active. That number turned out to be 200. If you have 200 or more, there is more likelihood of an active community. If you have fewer than 200, it’s less active. It doesn’t mean that there aren’t counter-examples. It just means that on average, if you don’t get to that magic number, it’s not as likely.
Follow these 10 Tips for Leading Communities.
KM Myth 11: I Don’t Have Time
A typical lament you hear is, “I don’t have time for that,” meaning a variety of things. “I don’t have the time to do the thing you’re asking me to do. I don’t have time to participate in communities. I don’t have time to be on calls. I don’t have time to go to conferences.”
What that implies is they don’t think that learning is as important as mundane tasks. If you said, “Why didn’t you attend the community call this week?” they’d say, “I had other stuff to do.” What exactly is that other stuff? Often it’s attending some meeting or it’s doing some kind of mundane work.
If you back away from that and you say, “We’re in the field of knowledge management; we’re trying to get people to learn and get better at things. Won’t we do that ourselves? Won’t we make one hour a month to learn more about our field?”
Instead, we get consumed by the mundane. No one’s making you learn. No one’s making you attend the conference. When you do, you generally are going to get better at KM. The excuse that you don’t have time generally means that you don’t think it’s important, and you should probably step back and reevaluate that.
You will also encounter people who will want to plan and prepare endlessly rather than try things out. They will say, “Yeah, we should probably do that, but let’s develop a plan,” and there will be an endless planning cycle and “We’ll start up a task force.” We’re so busy with our mundane dreary work that we don’t realize that we could be doing something else. We could step back and figure out a better way that would actually end up saving us time. Instead of endless planning, we should Implement, Improve, and Iterate.
KM Myth 12: We Should Work Ourselves Out of a Job
Another thing I hear frequently is that we should work ourselves out of a job. Knowledge management is everyone’s job. Therefore, we don’t really need knowledge management as a department. We don’t really need to be full-time knowledge managers. Our goal should be to not even need knowledge managers anymore. When I hear that, I always say, “What about Finance, HR, and Operations? Is it their goal to work themselves out of a job? Are we going to get rid of the Finance department because finance is all of our jobs?”
I think this is a fundamental mistake. It’s all of our jobs to actually share and learn and do the things that knowledge management includes. For anything to actually get led in an effective way, there needs to be somebody leading it. To say that there will be no one leading knowledge management and everyone will just do it is naive. It’s not that you need a gigantic knowledge management team, but you always need at least one person who is worrying about this. You may need a few more.
When you say it’s everyone’s job, it’s everyone’s job to do it, but it’s not everyone’s job to be the advocate for it, to be the champion for it, to be shepherding all the people, processes, tools, and components that go into knowledge management work. I don’t think we’re trying to work ourselves out of a job. We’re trying to ingrain knowledge-sharing into the work of everyone else, but not necessarily to eliminate the people trying to lead the effort.
If you have an organization with a few people, with someone leading people and someone leading process and someone leading technology, and you have some extended virtual team members, that may be all that you need. You don’t necessarily have to have some monolithic giant structure, but I think you need something in order to shepherd knowledge management.
KM Myth 13: Bigger is Better
Some KM practitioners say, “The bigger team we have, the better. The more power I’ll have. The greater importance I’ll have in the organization. I’ll be measured by that.” So they’ll build up large teams. They’ll develop large offshore presences, and they’ll think this somehow signifies that they’re important or doing good work. But large doesn’t necessarily mean more effective. In fact, many times the larger you get, the less effective you get because you’re spending all of your time coordinating and communicating with many, many people, and if you get down to a smaller number, you have to spend less time doing that.
Large isn’t necessarily better in terms of teams, and large isn’t necessarily better in terms of anything else. The more websites you have isn’t necessarily the better. We’ve heard some instances where people said they had organizations with millions of web pages. I doubt that that’s a good thing — having dizzying websites with lots of crazy stuff on them, animation, widgets, and things.
Actually, as Google showed when it came on to the scene, simpler was better. The initial Google interface was just a box in the middle of the page. Meanwhile, the previous champion, AltaVista, had evolved to include all kinds of things. It had every kind of information known to mankind on the page, but that wasn’t what people wanted. They wanted something simpler. More is not necessarily better. Sometimes, we’ll tout the fact that we have more ESN groups. As I said before, that’s not necessarily good. That could be bad. More isn’t necessarily good.
Then you have the problem of citing numbers that don’t necessarily reflect reality — i.e., join-only members. People join a community and then they don’t pay any further attention. We can tout that we have thousands of members of our community, but how many of them are actually even paying attention to what’s going on?
Now the exception to this is the more members who are paying attention, the better. I’ve never found any reason why the size of a community needed to be limited. Sometimes people ask me, “Isn’t there an optimum size, or shouldn’t you try to keep it small?” My own experience and the research that Lee did suggests that if you have 1,000 members in a community and then member 1,001 joins, that’s not going to cause any harm. Member 1,001 may begin learning and benefiting from the other 1,000 members. They may be able to answer questions and share useful information. There isn’t any harm in it. In the case of community membership, more is better.
KM Myth 14: Make People Do It
The expectation that we can make people do things is naive. For example, we say we’ll make them maintain their expertise profiles. How many people have been able to successfully make someone maintain their expertise profile? It’s not something we tend to like to do, or to contribute all documents. In the early days of KM, we’d say, “Contribute all your documents and then we’ll put them in a repository, and then we can reuse all of them.” No one likes to do that. The idea that we can make somebody do something is not valid. If we make them do it and we enforce it, they’ll do it to the minimum extent possible.
Forced membership in communities isn’t a good idea. Participation in communities should be voluntary. Or the wish that everyone’s going to start from one home page. That’s naive. We think, “Here’s our intranet home page. We’re going to put a banner ad on there because everyone will go there.” But they won’t. They’re going to bookmark some other page and go there and you’re not going to be able to determine where they go. Don’t even try. Instead, back to the power of pull, try to pull them in. If you need to locate expertise, instead of making people fill in their expertise profile, let them join communities and let the expertise emerge in the community.
KM Myth 15: Everything is a Community
My work is primarily in communities and in collaboration, and I always hear community used in sometimes strange ways, as if everything is a community. Sometimes, I hear entire populations referred to as a community. My own definition of community is that it’s a voluntary group that you join because you want to get better at something, not something that defines the organization you’re in, or defines the ethnicity that you have, or whatever. There are all these uses of the word community.
To me, a community is something you choose to join because you want to meet up with other people who are interested in the same subject. A community is not a website. It’s not a wiki. It’s not a blog. It’s not an ESN. It’s not an organization. It’s not a project team. It’s just the people who choose to learn more about a subject by coming together. I’ve written more about that in The Communities Manifesto.
KM Myth 16: Our IP Will Be Stolen
The last of they 16 myths is that our intellectual property will be stolen. I remember many a discussion inside of companies that I’ve been at where they said, “We’ve got to lock down this content because some other part of our company will use it in the wrong way.”
Here’s an example of that. I was at a company in which we had a consulting division and a field service division. The field service division realized that they needed new sources of revenue because maintenance was a declining revenue stream for computers. They believed they needed to get into new services. The consulting business then became wary: “If we publish any of our materials that we use to deliver services, the field service business is going to steal it and they’ll go out and deliver those services and we’ll lose revenue. Let’s make sure that we make this accessible only for consulting people.”
Of course, that’s not very realistic, because a field service technician in possession of some project plan from a consultant is probably not likely to be able to go out and deliver that consulting service. What’s more likely is that they’ll come to the person who posted it and say, “I see that you posted this document. My customer wants to buy that. Can you help me deliver that?” The thinking that you need to lock it down and secure it so that other people can’t see it goes against the whole concept of knowledge management.
One of my articles, “Open the Gates and Tear Down the Walls,” looks at private groups or locked-down content, and contrasts that with what we’re all trying to do, which is get people to share and to be more open in that sharing. You have to step back and say, “Why are we doing that?” The answer may be, “We’re going to prevent competitors from getting it” or, “We’re going to prevent disgruntled employees from getting it.” There are legitimate reasons — you might be working in a project team which needs to limit access to the project team’s content. That’s fine, but that’s a little bit different than some broader community or broader knowledge repository.
If you’re encountering that view, ask, “Is there truly a risk that we’re dealing with here or is it imaginary?”
- Slides for this presentation
- Knowledge Management Sins, Pitfalls, Mistakes, and Causes of Failure
- Busted! Knowledge Management Myths Revisited
- Yet Another Myth: The DIKW Pyramid Scheme
- 5 Knowledge Management Myths Debunked by Caitlin Zucal
- Knowledge Flows: Mainstream or Myths? by David Skyrme
- 13 Myths of Knowledge Management by Steve Denning
- Top 10 Myths by Ed Rogers