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]

Have We Missed the Boat?

I have been following with interest the enthusiasm with which practitioners are adopting and promoting web 2.0 as the next big thing for knowledge management. (Myself included.) It is not hard to see why. The explosive growth of social media and social networking sites such as FaceBook, MySpace, LinkedIn and Twitter is enough to make any old school KMer turn green with envy. Why can't we induce that sort of participation in our knowledge sharing programs?

However, even when corporations try implementing web 2.0 solutions inside the firewall, the results are often underwhelming. That is the Enterprise 2.0 dilemma.

People have offered a number of explanations for the difference: limited audience, cultural constraints, lack of incentives, generation gap, etc. All of these have an impact. But I am beginning to think we (i.e. corporations and those who are trying to move them forward) may be missing the bigger picture.

Why did social computing succeed in the first place? Granted, a significant portion of it was originally personal in nature, but it was very quickly adopted by engineers, white collar workers, and other professionals as a way to discuss both their private and their work life, including their professional experiences. Many professions have established formal and/or informal communities where they collaborate and share information through blogs, forums, twitter, etc. outside of the companies they work for.

Why is it that they are so willing to share information on the internet that is so hard to get out of them inside the firewall? We can nitpick the details of how and why, but at some point we have to face the fact that they do it because they get more satisfaction from sharing information outside than inside.

People share information on the internet because they feel a sense of connectedness to others with similar interests and tastes. They also feel that their ideas and opinions matter.

Even when web 2.0 technologies and methods are used inside a corporation, the sense of satisfaction is greatly diminished. The audience is smaller -- immeasurably smaller -- so finding like minds is far less likely. There may be others within the company with similar roles or professions, but having the same job doesn't automatically make you friends. If, on the other hand, you take all of the people with similar jobs from all companies around the world who may be on the internet... the chances of compatibility increases.

More importantly, people -- peers -- on the internet may not be able to act on your ideas, but they can admire them, praise them, and commiserate with your inability to get them implemented. Because of the smaller audience, contributions to an intranet often elicit fewer if any comment. That doesn't mean they are not seen. But at least subconsciously, the contributor often feels like their offerings are falling on deaf ears.

What's more, the corporation's specific business focus dramatically cuts down the scope of what is "appropriate" or "noteworthy" within the smaller environment. Even without explicit guidelines, there is an implicit constraint within the firewall that does not exist externally. And if web 2.0 is about anything, it is about the individual's freedom to contribute as they see fit.

So, yes, the smaller audience does play a role. But it is the individual's sense of actively participating, connecting, and freedom of expression that drives continued use of social software on the internet and not within the firewall. Are they really free? No. They are constrained by their own personal code of civility and moral appropriateness -- especially when dealing with information concerning their employment. But the sense of freedom is key to their willingness to participate.

What's worse is that by implementing web 2.0 technologies inside the firewall without any commensurate modifications or integration, knowledge management programs once again look like stodgy organizations that see a fad but doesn't quite "get it".

So, is all hope lost? No. But there are several lessons that can be learned here:

• Don't expect too much. No matter what you do, adoption of social software will not be as viral internally as it is externally for all the reasons described above.
  
• You may need to "feed the pump". Interaction is critical to the success of social software. (That's why it's called "social".) Since feedback is going to be diminished inside the firewall, you may want to solicit the assistance of a group of early adopters to amp up the initial set of responses to get the feedback loop going.
• If you can't beat them, join them. Before you even start planning new internal services, think whether you need them. Why compete with active, healthy services that already exist?
  

Perhaps it would be cheaper and far more successful to use those existing external services through the firewall as is, instead of setting up competing internal services. For example, rather than setting up blogs internally, think about the alternatives:

• Providing a list of the best internet blogs pertaining to your company's business (including those of your employees)
• Encouraging employees to blog externally and join external professional communities to both further their career and enhance their skills
  
• Aggregating internal news with feeds from external sources to provide more dynamic, objective information to your employees

Corporations are hesitant to "open up" the firewalls and blur the distinction between internal/proprietary and external/public information. But when you are talking about social computing, that blurring of distinctions is one of its key strengths and defining attributes. Why is Twitter popular? Not because I can talk about my private life; because I can talk about whatever parts of my life, private or professional, I choose to.

Smart companies will recognize that the floodgates between internal and external information were breached long ago, without their having any control over it. They also recognize that they can benefit more from encouraging their employees to use this new powerful medium effectively -- and appropriately -- than trying to constrain it within the artificial boundaries of the corporate firewall.

Social Architecture

Patti Anklam recently asked whether we need to define social architecture and if so, how should we do it? I never shy away from defining new terms, as long as:

• The term identifies some meaningful thing or quality
  
• The thing being defined is new and/or unlabeled (and therefore difficult to discuss without some shared terminology)
  
• The term is not completely ambiguous*

My gut feeling is that social architecture would be a good thing to define. That said, let's start with what it is we are defining.

The Definition

Social architecture is the conscious design of an environment that encourages certain social behavior leading towards some goal or set of goals.

By environment I mean a bounded set of physical or virtual structures, functions, or events where people interact.

I say "certain social behavior" because you are designing for specific interactions with the aim of achieving some goal. You are not designing a generic space where people congregate and interact in whatever way they please. (Unless, of course, that will achieve your goal.) You are designing towards some purpose, such as encouraging conservation (wiserEarth) or grassroots sharing of ideas and innovation (barcamps).

On the other hand, I am intentionally vague about what constitutes an "environment". If we are just speaking of digital spaces, then there is very little difference between "social architecture" and "information architecture" or "interaction design". Designers of social software might very well call themselves "social media architects". But that is not inclusive of everything that is needed to instigate and drive social behavior. Barcamp is an example that requires digital spaces to organize, but also a physical space and event logistics to pull off.

There is an ongoing debate within the Enterprise 2.0 community that E2.0 is not just social software inside the firewall. It is a change of culture. Well, that change of culture cannot occur without establishing the appropriate environment to foster it, including a coordinated set of capabilities, recommendations, influences, and incentives. The design of such an environment is social architecture.

Is a Definition Necessary?

Why even bother with a definition? Well, the argument within the Enterprise 2.0 community is a good example of why a new term is needed. I won't go into the details of why discussing changing culture is unproductive -- Venkatesh Rao has done a far better job explaining it than I could do -- suffice it to say that rather than complaining about a resistant culture, designing a system that utilizes inherent social behavior to recognize and reward a different approach is more likely to result in change.

Unfortunately, social media is being applied within corporations as if it were a large hammer, cutting a wide swath through traditional, stovepiped corporate approaches to knowledge. Even when the new applications are well received (which isn't always the case), one of the side effects of this approach is an "us vs. them" mentality. The old approaches are not removed; the new social applications are set up in opposition to them, creating an unnecessary barrier between the traditonalists and new agers. This friction is often amplified by a lack of integration of the social software into the existing corporate infrastructure.

What is needed is a more systematic approach to integrating social applications -- and the activities and interactions they incite -- into the corporate environment. From a technical perspective, this means integrating the content into intranet search and actively feeding social content streams into traditional environments, such as intranet web sites (e.g. the latest Yammer messages on the team site, the employee's blog and Twitter ID becoming part of the corporate whitepages, liveblogging status meetings, etc.) From a operational perspective, structuring the social interactions around meaningful topics and goals helps avoid competing approaches.

This type of coordination does not require extensive resources or a major overhaul of existing systems,. But it does require planning and often a complex set of small, coordinated adjustments to systems and processes. And the best way to describe this approach is social architecture.

As a side note, despite my examples, corporate environments are not the only possible target for social architecture. However, I mention them here because intranets are an area with perhaps the greatest potential use of coordinated architectural approaches because of the need to address deep rooted hierarchical processes.

Ambiguity

We also need to check to see if the new term we are defining is so ambiguous it will be misinterpreted or quickly misused. In other words, is there a better term?

I happen to like social architecture for several reasons:

• It fits well into the lingua franca of social computing, where terms such as social media and social software are already established.
• It is distinct from the existing terminology which tends to focus on either the technology or the content, but not the overall strategy.
• It is relatively intuitive as a term and does not require a significant amount of explanation.
  

On the negative side, there is ambiguity with previous uses of the term within the realm of physical architecture and sociology. (There is at least one reference as far back as 1876.) In physical architecture, the term social architecture tends to refer to the application of architecture towards humantarian aims. Housing for the poor, sustainable architecture practices, and designing for larger social goals all seem to fall within this category. The Wikipedia entry on social architecture is a stub referring to social structures, a sociological concept not too far from the environments and goals discussed in my definition.

Although there is ambiguity here, it does not seriously invalidate the use of the term in reference to web-based systems. More importantly, there is sufficient crossover between the definitions to to avoid direct conflict.

Existing Usage

Finally, I make no claim of originality in defining social architecture. Besides the use of the term in other fields, there are already a number of references to it as applied directly to social software and the internet:

• Stowe Boyd defined it in 2005. Although he appears to define it as an existant state ("the foundation of the blogosphere") rather than as a specific activity.
• Sam Huweatt describes it in his blog. His definition is very similar to what I outline above. He also makes a distinction between social architecture and social media architects.
• Christina Wodtke lists the elements of social architecture in her book Blueprints for the Web (summarized in A List Apart).
• In his slide presentation on Social Architecture: Modeling the Next Generation, Sean Madden makes the point that "social networks have limitless potential but we need to work towards designing them that way."
• Amy Jo Kim, in her bio, defines herself as designing "social games and social architecture[s]". Her book Community Building on the Web pre-dates much of what we now consider social software, but is still the pre-eminent text on designing for social interaction. She also calls her blog "Musings of a Social Architect".
  

I take these all as good signs that the term is both useful and sufficiently clear in its meaning. On the other hand, there are at least two other uses that do conflict.

There are a number of people (in particular, Ryan Turner) who use the alternate term "web information architecture" to define much the same thing as I defined as social architecture. My preference for the shorter term comes from the fact that "web", by this point in time, is pretty much redundant. Almost all information and interaction in modern life now involves the web to at least some extent. But at the same time, as I mentioned in the definition, not all activity involving social architecture is web based (for example meetups, Big Urban Games, and barcamps).

There is also at least one case where social architecture is equated to an existing term (Information Architecture = Social Architecture). Although this is well-intentioned, I believe it is inherently wrong. Not all information is social (in the social media sense) and at least some aspects of information architecture -- such as navigation and metadata definition -- that are determinative, not social. And not all social interaction design can be considered a part of information architecture. They are definitely related fields, but not identical.

*I'm sure others would go for more precision, such as "not ambiguous". But if that were the criteria we would define almost nothing.

Sustainable KM: The Challenges (Part 3)

[Continued from Part 2]

The same rules that apply to information apply to processes as well.

Knowledge management practices should be embedded in the work processes. And many KM initiatives attempt to do this. However, beware of designing KM programs around the officially defined processes of a corporation. Because, as many who has worked in business can tell you, the official policies and the actual practice can often vary -- dramatically.

To give a couple of examples from my own experience:

• When working on a project catalog, the project management office told me all projects had a project ID that could be used as a unique identifier. However, when talking to individual projects, it turned out that different IDs were used in each region, they weren't unique, and that most people working on the project did not know what the project ID was -- only the project manager did. So any process assuming a known, unique ID was bound to fail.
• The official process for creating project proposals was to use a web-based proposal generator that filled in all of the legal boilerplate materials etc. However, in actuality, most project leads used their last proposal to cut and paste or asked around for examples from similar projects.

Needless to say, if you design your KM programs around the officially documented processes rather than what people actually do, your program will be no more successful than the policies themselves. So, another principle of sustainable KM is: Pay attention to the people, not the policies.

As easy as it this is to say, achieving it can be far more difficult than one would expect. Official policies exist for a reason. Management wants the policies to be obeyed. In most cases the policies are intended to create consistency and reliability within the system. Unfortunately, the policies also often result in extra work with no perceived benefit to the individuals who are asked to comply. (Does this sound familiar? Oh yes! "Do not make [fill in the blank] extra work." The same rules that apply to sustainable KM apply to sustainable business processes as well...)

Unfortunately, business processes and policies tend to have far more management attention and leverage than KM programs. (This gets back to the age-old issue of perceived ROI for long-term vs. short-term objectives.) So in a battle between reality and official policy, strangely enough, reality usually loses out.

Going back to my second example above, the KM team was frequently asked by the consultants to provide a library of past proposals that they could borrow from when it came time to write a new proposal. Of course, as soon as the team responsible for the proposal generator caught wind of this, they objected. The consequence was that the proposal library project was canceled.

There is no generic answer to this problem. In the case I described, the outcome was that the several regions created and maintained their own libraries of proposals for reuse. This was not optimal but it was a pragmatic solution to the situation they found themselves in.

Another solution is to generalize the problem to avoid specific cases. For example, by creating a global project document library, it was possible for teams to share proposals (and other project documents) between regions. Because it was not specifically a proposal library, it successfully flew under the radar of those maintaining the official project proposal policies.

I am not recommending this approach. It depends on the specifics of each individual case as to how best to identify the true processes being used, encourage effective knowledge habits, and meet commitments to management. This is one of the many fine lines knowledge management professionals find themselves having to address.

[Continued in Part 4]

There Are Only Three Corporate Strategy Diagrams in the World

I have come to the conclusion that there are only three strategy diagrams in the entire world. Oh, the labels change and someone may use five or six boxes instead of four or five, but the basic diagrams are the same.

The Cloud

This is perhaps the oldest corporate strategy diagram around, dating back to at least the early 1980's. It depicts a set of known entities (usually shown on top as inputs), a whirling cloud of activity, and a set of one or more desired outputs. (Usually fewer outputs than inputs.)

This diagram is very good when trying to explain how to get from chaos to sanity. Strangely enough, the cloud is not the chaos, the plethora of unintegrated inputs at the top is the chaos. The cloud is the magic black box which boils the chaos down to a smaller, manageable set of outputs.

I have seen this diagram used to describe datatype conversions, programming interfaces, repurposing of content, and several other things.


As a side note, in the 1990's this diagram morphed sightly. As the multitude of disconnected systems diminished, the cloud was replaced with a solid object: a box, pipes, or a two-headed arrow. But the basic intent of communicating the integration of disparate systems into a manageable system remained.

The Pyramid

The pyramid is the preferred strategy diagram of non-management types. Non-techies use it in its 2-D form; techies prefer it in 3-D.

The pyramid represents a hierarchy of importance. Its origins as a diagram are as ancient as its inspiration, the pyramids of Egypt. We all know the recently dethroned food pyramid. Also Maslow's hierarchy of needs utilized this diagrammatic shape. However, its application in corporations is primarily to categorize – and prioritize – whatever the business is doing or producing.

As I mentioned, non-techies use the 2-D pyramid, usually accompanied with an arrow indicating the goal of moving from the lowest state of being to the most refined at the top. In KM, the pyramid is data -> information -> knowledge -> wisdom. (How you achieve this is never clearly defined.)

Engineers and other technical professions prefer the 3-D pyramid because it provides more surface to divvy up, classify, and subclassify into its component parts. The obvious problem with this is that no one but an engineer can understand or appreciate the level of detail provided, and the pyramid is lost for the trees (to mix a bad metaphor).

I actually had a software architect try to replace the pyramid with a cube – he wanted to show the products as the intersection of three different architectural perspectives, each suitably cut and divided into even further refinement. Once I explained that he could not show the back side of the cube on paper, he abandoned the plan (and, I might add, much of his respect for my abilities as a graphic artist. Oh well....)

The Arrow

Finally, there is the arrow -- the quickest, shortest path to any target. As a strategy diagram, the arrow is usually segmented to show the linear steps needed to reach the goal. Managers like the arrow because it not only identifies the necessary tasks but a sequence as well, making management (and the assignment of blame) much easier.

One important variant of the arrow is the circular arrow. The circular arrow is not as popular with management types since it does not have a clear start or end point. However, this variant is extremely popular with program teams

Intersecting Circles

Finally, there is a fourth diagram that is frequently seen in corporate presentations, but it is not a strategy diagram. This is the intersecting circles.

The circles can be labeled with anything you like: people , processes, technology... customers, managers, employees... music, video, telephony... etc.

This diagram is often mistaken for a strategy diagram because the center of the intersection is viewed as an end goal. However, the diagram is actually an illustration of the current state. Add an arrow and another stage where all three circles overlap and you might have a strategy diagram!