The Art of Managing Knowledge Management Programs

I recently gave a presentation on adaptive knowledge architectures (slides and audio). The presentation was more a case study than anything else. I ended with two slides of lessons learned -- what I would do differently in hindsight to avoid the difficulties we encountered.

The original slides (and afterthought) are more conceptual than practical. For example, my primary insight was "beware of success". What I meant by that was that, if you succeed, others will not only want to jump on the bandwagon, they will try to take control and alter both the goals and practices to match their needs rather than the original principles.

There were two things I left out of my slides. One I intentionally left out because it is a more generalized issue about strategy, KM or otherwise. The other I simply forgot until people started asking me questions. They are both practical considerations when managing knowledge management programs.

The general rule is: communicate continually and repeatedly.

I must have presented the original architecture (the 3-tier model) 50-60 times when we started. And my boss at the time did as well. It even appeared in a case study written by Microsoft.

I would then include the 3-tier architecture diagram at the beginning of every KM presentation I gave -- explaining how the new features or changes fit into the architecture. Inevitably someone would ask about the diagram as if they had never seen it. Even people I know I had presented it to within the previous year.

Richard Saul Wurman makes the point in one of his books that you only learn what you are ready to learn. This is particularly true of strategies and architectures. You have to repeat it over and over again -- until you are bored with it! Because there will be people who haven't absorbed it yet.

I think this applies particularly when you move into Enterprise 2.0 and web 2.0 where there is a seismic shift of intent and responsibilities. Managers just don't get it. They say they do, but they don't. They are hearing part of it (the rapid adoption part) but not the self-managed part. They think they can pick and choose the attributes without damaging the system. Sorry, it doesn't work that way. In the case study I used for my adaptive architecture presentation, that is exactly what they did to our communities.

Which brings me to my second point (the one I had forgotten). The reason they took over our communities was not so much that we had succeeded at KM, but that we had succeeded at content management. At the beginning of my presentation I mentioned that the 3-tier diagram includes the top tier (the intranet) so I could dismiss it and say it is not part of the KM environment.

What I didn't count on was the fact that we built an infrastructure (based on SharePoint) that was so much easier to use and and manage than what was being used for the intranet, management would want it for their "portals".

Essentially, they were responsible for the last branch of the intranet hierarchy and it took weeks (and several employees) to get content posted. Ironically, I had worked with the organization's IT team trying to sell them on using SharePoint to manage their intranet sites (separate from our KM infrastructure), but it was rejected. (I won't go into that here, but that was an entertaining episode in its own right.)

But what happened was management saw that our "communities" had all the attributes of their portals but little of the pain. So they jumped on it.

So what would I do differently? I wouldn't ignore the top layer. I would set aside part of the infrastructure just for them. Even though it isn't really KM, I would do it to create a manageable buffer zone between their activities and our KM processes.

How does this apply to Enterprise 2.0? I think the same thing will happen to people trying to implement web 2.0 internally. Part of the attraction of social software is its ease of use. And if the technology catches on, people will jump on it for purposes not intended by the software vendors or the sponsors. And once they do, they will try to apply their traditional "management" thinking to it.

Two small examples I saw at a large corporation:

• The internal corporate "wikipedia" included pages describing, among other things, each of the organizations: what they did, who ran them, their relationships. Someone discovered this and complained that the entries did not match the description on the managed intranet pages. It was not a suggestion or a demand. It was simply stated as what they saw as a fact; that the wiki pages should be made to match the intranet pages. In other words, selected content should be controlled.
  
• On our social networking site we got management to promote the site to our organization. It was then pointed out that the managers themselves should create profiles. Several did. But upper management insisted that their executive assistants draft the content and that we should have a way to post these "ghosted" profiles (completely in opposition to the basic model and implementation of the application). We did change the software to permit this, but as innocuous as this sounds it does create a philosophical schism in the application: who gets to have "ghosted" profiles? How can people tell real from edited profiles? etc.

These may seem trivial, but our apps were still in birth mode, without widespread adoption. So these were just the first signs of the problem.

The question is: what would I do about it? Like I said in the presentation, I don't think there is a generic answer. It depends on the corporate culture and, I'm afraid, the individuals involved. You can try to second guess the culture. So, for example, in hindsight I would have created spaces for the HQ intranet sites to try to alleviate the pressure on the communities. Would that have worked? Possibly. But it is just as likely that they would then argue that the communities are unnecessary since their portals provide all the information consultants need. (Which, in fact they did when they argued that we should dissolve all of the communities that they didn't control. But we managed to stop that effort...)

In the case of Enterprise 2.0, I would have suggested creating one or more executive wikis, secured for use by managers of the individual organizations. This may have satisfied their need for secrecy, ease of use, and taught them a little bit about the operating principles of web 2.0. Would that have sufficiently distracted them from messing with the employee wiki (which was the real goal)? Perhaps, perhaps not. But it would be worth a try.

Another recommendation would be to have a very clear business objective for E2.0. For example, internal development blogs for each project/product. You can allow other uses of blogs, but by having a clear, measurable, but not ROI-based, objective and repeatedly stating it (i.e. constant communication as stated above) you may be able to deflect people trying to commandeer the program.

I could go on, but I better stop before I end up writing War & Peace...

[Many thanks to Steve Ardire for inspiring this post and Stan Garfield for teaching me much of what I know about managing KM programs.]