(Silence)

Ah! Silence, a blessing... or a curse?

I realize Incredibly Dull has been quiescent for the last two months. No, I was not hit by a bus, run over by a train, nor did I run out of things to say. What did happen was I started a new job which has been occupying my time and attention (in a good way).

However, now that I am in the groove, I expect to get back to posting blog entries, particularly on sustainable knowledge management, games, and poetry & the other arts. You can consider that a promise (or a threat, depending upon your point of view). But for now, back to our regularly scheduled program...

Approaches to Sustainability: Embedded KM

[Continued from Sustainable KM: Principles & Approaches]

The first approach to sustainable KM is fairly obvious: embedded KM. This is where you embed knowledge management practices into the existing business processes. Some of the benefits to embedded KM are:

• Rapid adoption
• Tied to business metrics

An added advantage is that -- if done properly -- there is little or no need for training since there is little or no change to behavior. If you place the knowledge management procedures in the existing operational processes, they will be completed by people as they perform their day-to-day work.

This is best explained by example:

• Say your business process already includes reviews at key milestones. It is likely that certain documents are required for the review: project overview, costs, schedule, etc. There may already be a template for these documents.
• If one of your KM goals is to make employees more aware of other projects to increase shared resources and reduce overlap, an easy way to do this would be to simply collect the project overviews from each review to create a project catalog.
  

First, let's look at an embedded KM solution with little or no change to the process. Since the documents are already being created and the review is an existing milestone in the process, the only work needed to implement the KM catalog is creating the repository (a one-time event) and influencing the review managers to post the appropriate documents in it. Working with the managers responsible for the reviews, it should not be a major hurdle to get this slight modification to the standard process in place.

However, collecting information is only part of the solution. To have any impact at all, the information has to be used. And, quite frankly, a directory full of unsorted documents is neither particularly useful nor appealing to anyone. So to complete the circle there are at least two additional steps:

• Adding steps to the project lifecycle to remind team members to use the repository. (Again, this is best done by tweeking existing process steps or milestones, such as the steps for starting the requirements gathering, design, and/or implementation stages.)
• Making the repository easy to use.

The latter step sounds deceptively simple, but is really the crux of where KM projects go astray from a sustainability perspective. For the repository to be useful, it needs to be searchable/sortable in some meaningful way. The primary way to do this is to provide metadata about the documents; classifications such as industry, country, client name, etc.

Rarely is the interesting information clearly or consistently labeled in business documents. So the only way to effectively add the metadata is to:

• Require those contributing to the repository to fill out the metadata for each item
• Modify the templates used to include specific fields for the metadata (and get the authors to use them correctly)

Suddenly our simple update to an existing process has become far more complex. Getting people to fill out input forms including metadata is extremely hard; they are either put off by the form and so resist contributing or they fill out the form with incomplete or misleading information. The same problem occurs when templates contain embedded fields. Making sure everyone uses the new templates and uses them correctly is a significant training and communication task, besides the effort required to maintain and periodically update the templates. Finally, the only way to make sure the forms or templates are being filled out correctly is to monitor the submissions to make sure they are complete and meaningful.

As you can see, a simple "improvement" to the system quickly burgeons into extended activities required to maintain and support the process. Conceptually, you can view a "capture & reuse" program such as described as being positioned somewhere on a curve from no modification to optimized for reuse.

When there is little or no modification to the content, very little management needs to be applied and the process is highly sustainable. Unfortunately, this also leaves the work of providing relevance up to the users of the content, which is often too much to make the effort worthwhile. (In other words, the system may go unused and have little value.)

To make the information usable, it needs to be modified to provide relevance. However, doing this requires changes to the process by which it is captured, adding new challenges in communicating the new process, training the users, and encouraging submissions. The content becomes more usable, but significant, ongoing effort is required to enforce and monitor the submissions, since the effort is now put on the contributors rather than the end users. In other words, an unsustainable process.

The trick is to find the middle ground (indicated by the blue box in the following diagram), where the content is usable enough and the contribution process simple enough that people can and will manage their own use of the system. Experience teaches us that this "sweet spot" can be an extremely narrow segment of the curve and very hard to hit.

Now, I must confess. I cheated in my previous example. Creating a project catalog from existing documents is often the first instinct. But as I point out, processes managing this sort of explicit knowledge quickly evolve into complex, unsustainable programs from only minor "improvements".

So let's consider an alternative. Rather than trying to make all project knowledge available to anyone, what if we simply try to expand the current knowledge base incrementally over time? Rather than collecting the review documents, why not include at least one reviewer from an unrelated project to each review? This could be an architect, implementer, or project manager as long as that person can provide an objective, outside view of the project progress.

This approach has numerous benefits, but two in particular are related to our example:

• First, from a project management perspective, the outside reviewer helps to keep the project team "honest". It is easy for internal reviews to become formulaic rubber stamp events if those involved are all working on the project.They do not have enough distance to see hidden pitfalls and will resist calling foul on people they have to work with on a daily basis.
• Second, from a KM perspective, including outsiders gives at least one person a much more indepth and personal knowledge than could ever be gained by reading a set of historical documents with no one to explain them. Another value from a KM perspective is the opportunity the reviewer and the project team have to exchange knowledge, hints, and tips on the fly and in context of the discussion.

The outside reviewer will take this knowledge back to their own project where it may or may not be used immediately. But it will stick with that person for a long, long time due to their intimate interaction with the other team.

What is required to make this program work? Initiating the program may be difficult because it requires diplomacy. On the other hand, it involves only a limited number of people. What is needed is to convince management (either of the project teams or of the review process itself) of the efficacy of including outside reviewers. Although there are KM benefits, the real advantage is that the proposed process has management benefits, as described, and will make the reviews more meaningful.

Once you succeed at convincing them to make the modification to the review process, the program then becomes essentially self-managing from a KM perspective. The project management teams are responsible for ensuring outside reviewers are included and with each review, little by little, knowledge is shared across the organization.

Again, there are a number of details I have left out that will impact the efficacy of such a program. How outside reviewers are selected and/or rewarded for their efforts can significantly impact the extent to which knowledge spreads as well as the reviewers' willingness to participate. But all of these factors can be addressed either up front or at a periodic (annual?) review of the program, with little impact to the individuals who carry out the plan. The program will continue to expand the knowledge base over time with little or no input from the KM team. The KM team can move on to addressing other issues without being tied up in maintaining the review process, in the best sense of sustainable KM.

[Continued in Approaches to Sustainability: Design to Zero]

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.]

Bing Bang Boom

I've seen it. I've tried it. I'm bored.

OK. That's not entirely fair. All the hoopla around the emergence of Microsoft's new search engine Bing has made me testy.

Bing isn't all that bad as a search engine. There's nothing particularly new here (except the name) and lots of copy cat behavior. Overall it is an improvement over its predecessor, Live Search. But why all the ruckus?

Why? Because Microsoft is out to "win". All their business strategies focus on displacing the current industry leader and taking command of the market so they can then use that position to promote (or as they like to say "integrate") all their other products. Oh yes, there's the usual nod to improving the user experience and enhancing productivity. But the ultimate goal is market dominance.

And they are willing to spend the money to do it. Ten million dollars, purportedly. One might say "what's so wrong with that? This is a free market economy isn't it?" Yes it is. On the other hand, I don't know if Seth Godin was thinking about Microsoft as he was writing it, but his blog entry strikes me as very apropos when he says "you're boring." As Seth put it, the "half-price sale on attention is now over."

I'm not as sanguine as Seth. I think there is still a lot of attention that can be bought. And Microsoft has done it over and over again. Internet Explorer, Office, even Windows itself. Why do you think they redesign the logos of their products for every version? And the user interface? To make them look new. To give the consumer (particularly the corporate consumer) a reason for upgrading.

I am tired of Microsoft buying their way into the market with mediocre, me-too products. What's annoying is that their products aren't that bad. Windows has grown up into quite a reasonable OS. And Office has most of the features any normal human being could want. Unfortunately, it also has bucket loads of features that 90% of humanity will never need and that get in the way of finding the useful ones, simply as part of the one upmanship of product sequels.

And now we have Bing. What is really annoying about Bing is that it might be a good search engine. I'm not sure. A competitor to Google? Unlikely, but possible. But I am so sick of Microsoft's aggressive business practices (usually at the expense of the user), that I am soured to everything it does and Bing suffers for it.

But I did try Bing. And it's OK.

• The top horizontal function menu is borrowed wholesale from Google, as is the stripped down functional layout.
  
• The design does has a nice, clean visual feel.
  
• There's been a lot of touting of the popup excerpts for search results. But haven't we had abstracts since AltaVista 14 years ago?
  
• The Related Searches sidebar is nice. But not nice enough to make me replace my current favorite search engine.

And that is where Microsoft has a problem. They sell plenty of software in the corporate world. But internet search is a personal choice. And a fickle one at that. They will be able to buy a certain amount of attention with advertising, but ultimately they need a significant change in functionality to make people change their ways. And I don't see it in Bing.

So, failing to win technically, they now want to win by subterfuge. Bing touts itself as something new, a "decision engine". Excuse me? What decisions is it making? Even if I liked Bing enough to try it, this hyperbolic nonsense is enough to make me want it to fail simply to spite Microsoft's incessant marketing machine.

Which is a shame. Bing is a decent search engine. I feel sorry for the engineers who have put their time into it because, ultimately, its success or failure will have little to do with their efforts compared to the animosity and confusion Microsoft's business practices generate in the market.

I am Tired of Killing Things

I love playing video games. I like the technology, I like the imaginative environments, I like the gameplay, the challenges, the characters, and the music. I particularly enjoy the childish glee I get as I conquer some meaningless virtual hurdle, clear a level, earn a star, or whatnot. But I am getting tired of killing things.

This is not a polemic against violence in video games, per se. I enjoy fighting games as much as the next person. From the realistic (Call of Duty) to the cartoonish (Smash Brothers), from the horrifying (Resident Evil) to the hilarious (Ape Escape), from the fantastic (Star Wars) to the funny (Lego Star Wars). But at some point there have to be other modes of play.

What brought on this fit was hearing all the pre-show hype and rumor around this week's E3 exhibition. Oh, there will be plenty of non-violent news and entertainment (the usual passel of racing games and mini game collections aimed at "families") but the big bucks go to the third or fourth iteration of numerable kill-everything-and-save-the-world games. I'm talking about Nier, Assassin's Creed 2, God of War 3, Tekken 6, and Final Fantasy I've Lost Count. At some point I don't need the blood any more realistic or the hits any more spectacular. The game play is the same.

Now, I know half of the people reading this (the gamers) are going to dismiss it as the whining complaints of an ignorant old crank. The other half (non-gamers or ex-gamers) are likely to latch on to it as a global invective against fighting games. It is neither of those. It is simply an expression of frustration at the lack of innovation in game play at the highest levels.

Each fighting game has its nuance, its (hopefully) unique take on the genre. There are the stealth games, the strategy games, the collaborative games, the gruesome and the garish games. But there are ultimately only so many flavors of kill and games become boring when they are repetitive -- no matter how flashy or colorful the explosions.

But, of course, there is hope. And, no, it is not just adding motion detection or making me wear a telekinetic headset. It comes from invention. Titles like last year's Little Big Planet demonstrate that there is plenty of room left to create enthralling games without more killing. This year, Mini Ninjas, even while continuing the fighting model, seems to inject enough humor, story, and imaginative objects into the game to create a uniquely enjoyable experience.

At least from the trailers. And that's all we have to go on so far.

Sustainable KM: Principles & Approaches

[Continued from The Challenges, Part 4]

The Principles of Sustainable KM

So to summarize, the basic principles of sustainable KM are:

• Do not make KM extra work. Embed it in existing business processes.
• Avoid "Change Management". Let change will manage itself.
• Design for humans, not data.
• Pay attention to the people, not the policies.
  
• Eliminate the opposition.

The Approaches to Sustainable KM

Now that we have characterized some of the basic principles of sustainable KM, we can look at ways of achieving those goals. The following are four practical approaches to achieving sustainable KM. This is not an exhaustive list in any way, but is intended as a starting point. Each approach has its advantages and disadvantages, which I will go into when I describe each approach in detail.

The approaches to sustainable KM are:

• Embedded KM
• Design to Zero
• (Re)Use What Exists
  
• DYI KM

[Continued in Approaches to Sustainability: Embedded KM]

Sustainable KM: The Challenges (Part 4)

[Continued from Part 3]

There is one more principle of sustainable KM that I personally have struggled with, but ultimately been forced to accept. That principle is the need to eliminate the competition.

At first, it seems to contradict the second principle: let change manage itself. In fact, it does. It also goes against my own natural style and approach, which tends towards inclusiveness. But the fact is, within corporations, competition is not productive, it is divisive.

Knowledge management programs tend to be additive -- new systems and processes are added on top of the existing infrastructure. If distribution lists aren't working, add forums. If forums aren't working, add blogs and wikis.

On the internet, this isn't a problem; the audience is large enough to sustain all of these interactions, and people will over time migrate from one to another. But within corporations where the audience is much smaller and resources are limited, continually adding new processes and technology has several very negative impacts:

• You confuse the users. People are always asking which system are they supposed to use: the old ones or the new ones? Even if a strategic direction has been chosen and announced, the more systems there are, the more likely people will either A.) use the wrong one out of ignorance or B.) not even know the right one exists.
  
• You invite resistance. People don't like to change how they do things, even if the new method is better in the long run. If the old system exists, some percentage of the audience will insist on still using it, often bad-mouthing the new system as they do so.
• You more than double the expense. Within corporations, all programs cost money, even when they are not in use. Systems cost money for IT to maintain them. They cost money for the sponsoring organization to advertise and teach them. And it is not just twice the cost. Because there are two, there are additional expenses needed to explain when and why to use each and to migrate people and content from one to the other.
  

These rules are not specific to KM. They apply to any technology. But in the absence of overwhelming management support, KM tends to suffer them more than other line-of-business programs do.

Ultimately, unless you are implementing something totally new and so innovative it does not replace or overlap existing processes, there is going to be competition between the old and the new.

However, eliminating the competition right away can have an equally negative impact. If you change the process, people need to be made aware of the change. Unless your organization is preternaturally well organized, this is nearly impossible to achieve in one fell swoop. So there will be some crossover period. Even if you switch over technology "under the covers" leaving the interfaces and processes the same, there are likely to be glitches and unforeseen differences that will be noticed by the users.

So the key questions are when do you make the switch over and what do you do in the interim to mitigate the negative impact?

The answer to the first question is as soon as possible and plan it from the beginning. It is usually best, even if you must keep pre-existing processes and/or systems for some interim period, to schedule their removal from the beginning so everyone is aware they are going away. A swift changeover can be painful, but a long drawn out battle (with users) is worse.

What you do in the interim depends on the nature of the change and the influence you have. If you cannot shut off an existing process or system because you don't "own" it (a common problem in hierarchical organizations), the best approach is to integrate with the other process and make the new process demonstrably better.

By integrating, you do not penalize people who adopt the new system (they can still interoperate with others who have not). By being demonstrably better, you are able to sway the target audience and encourage adoption -- to the point where the old processes can be shut down. In other words, you win.

Even if you do control both the old and the new processes, it is important to provide a clear migration path: convert old data, map old processes to new, integrate with other processes, etc. Theses steps all help smooth the path for the users and reduce pain for both them and yourself.

[Continued in Sustainable KM: Principles & Approaches]