The World's Smallest Instruction Manual

3.5 X 4.25 inches
Single sheet of paper, printed on one side.
(Instructions for a pocket calculator.)

The Work We Do

I recently changed jobs. As a consequence I am no longer "doing" Knowledge Management. I am reminded of this fact by friends who ask me how much KM is involved in my new job. The simple answer is none. But to be honest, that's not entirely true.

My new role brings me back to my roots in Technical Writing, Information Architecture, and what is currently known as "Content Strategy". (Although "Content Strategy" appears to be having the same sort of identity crisis KM and IA go through on a regular basis.)

Which may also explain why my new role doesn't feel so different. In my previous profession, people would ask me how Information Architecture relates to Knowledge Management. My pat answer was that KM is the architectural design of potential -- rather than existing -- information.

My response was flippant, but also quite accurate. Whether you are defining the structure of a website for well-understood content or designing an interface for some as-yet-undefined content that will be chosen by people in the future... the tools, the methods, and the experience you use are much the same.

Ditto technical writing, which is very much like information architecture except on a much smaller scale. (What goes in this document vs. another? Where do we put the introductory information so the user can't help tripping over it? etc.)

Now, I know there are technical writers that do nothing but write and are affronted if you suggest they "design" things. Just as there are Information Architects that design taxonomies and not much else. But the fields themselves are much bigger than that. Which is where the confusion and bickering comes in.

I seem to be constantly in the middle of one battle or another no matter which of my various "professions" I am practicing. The reason for that is because the boundaries are very fuzzy. And ambiguity makes people uncomfortable.

So they try to delineate their roles. On the one hand, practitioners try to define the field by how they currently practice it: the tools they use or the methodology they have adopted. While others with a more philosophical bent try to expand the scope, often treading on the toes of their neighboring professions.

Currently, information architects are arguing whether IA even exists or if it (and several other forms of design) are all just different flavors of a new profession, user experience design. Or is it interaction design? Or is it...

Similarly, KM practitioners (and pundits from other fields) are trying to decide if there is a battle going on between KM and social media. Excuse me? There is no battle unless you assume KM as a field of study has to be practiced in a specific way or within a predefined, limited field of vision.

I feel like channeling a famous ex-wrestler and shouting "It doesn't matter what your profession is!"

The names we make up for our jobs help avoid conflicts when working with others by divvying up the territory. They also give us a ready answer to social situations when someone asks "what is it you do?"

Unfortunately, these names also create unnecessary barriers to getting work done. If you define your role by specific tools or tasks, you are also defining the boundaries for the solutions you can provide. You doom yourself to repeating the same work over and over... even when the environment around you changes, as it inevitably will.

The fact is that all of my professions are variations on addressing the traditional dilemma of communications theory. Whether it is communication between management and employees, among the employees themselves, between the company and customers, or among the current and potential customers the company seeks, the professions I travel with are all trying to resolve the problem of getting information into the right hands at the right time.

In knowledge management it is creating channels for the ambient knowledge within whatever community you support. In this case, your audience is often both content providers and consumers at different times. You don't control the content, you try to maximize the channel.

In information architecture it is sorting, defining, and providing a clear logical structure to at least that part of the information space you have control over (whether that be a web site, marketing, promotion, community facilitation, or whatever). You manage the content, somewhat like an orchestra conductor. But you are not the composer.

In user experience and usability design it is tuning the communication channel to be as effective as possible. You don't control the content or the structure, but you control how the audience interacts with it. (Of course, this is untrue in actuality because the interface becomes part of the message. Wasn't it McLuhan who said the medium is the message? But this is just another example of how the professions overlap...)

And in technical writing it is creating the perfect communication, including content and structure, but within the limited scope of the channel you have available to you (whether that be books, online help, training modules, or a web site). You have complete control over the content, but less over the channel and still less over the audience.

They all address the issue of communication from different angles. And taken together, provide an endless array of solutions and approaches when faced with any problem related to information.

That's why I like it.

And that's what I do.

Approaches to Sustainability: Design to Zero

[Continued from Approaches to Sustainable KM: Embedded KM]

Another approach to sustainable KM is "design to zero".

It's impossible to start a business initiative with no resources. Even if it is only your own time and attention, there is some expenditure required. And usually there is a lot more than just that.

Any new project requires a "bump" to get it started. This might include training, hardware and software expenditures, project management, etc. Any number of capital or resource costs are needed to get things going.

The problem is that budget planning often only accounts for the short term (2, 3 or perhaps 5 years at most). For projects with a defined endpoint, this is OK. However, almost all KM projects are intended to run indefinitely. (It doesn't make sense to stop sharing knowledge after 3 years, does it?)

This means that, although it may not show up on the plan of record, the KM program must account for the ongoing maintenance of long-term projects. If you load up your KM program with management of ongoing initiatives, there are two negative consequences:

• If budgets and headcount are cut (or worse, eliminated), you have no choice but to abandon one or more of the initiatives, usually bringing the program to a screeching halt. Without the expected leadership and constant "push", non-sustainable programs fail when the budget stops.
• Even if budgets stay the same, after a while, you have no spare resources to start new programs. Even if a good idea comes along (such as Enterprise 2.0) your KM team is fully booked and you do not have sufficient resources to start anything new without impacting existing programs.
  

How do you avoid this dilemma? The key is to design each project -- from the beginning -- to reach zero cost.

That doesn't mean management goes to zero or that residual effort goes to zero, but that the program is designed to become self-supporting at a set point in time.

So rather than planning for the the first year "bump" and letting maintenance trail on indefinitely, plan from the beginning that management of the program and responsibility for its ongoing success will be transferred to the appropriate people within the organization. Sometimes this means the project may need a bigger expense up front (as soon in the graph below). But the benefit is that the project then becomes self-sustaining and the KM team can move on to tackle other tasks.

Going back to our example of embedded KM, it is not sufficient to have the idea to invite architects from other disciplines to the project reviews. You need to make sure that the organization running the reviews understands that their success depends on this outside participation and, therefore, they are responsible for making sure it continues once the program is off the ground.

As with any sustainability practice, not all projects are suited for design to zero. But far more projects are than you might expect. The trick is to look for the part of the organization (usually lines of business) that will benefit most from the effort. Engage them early in the planning, so they feel responsible for its success. Then get them to commit to ongoing management as part of their regular business cycle.

[To be continued]

What I'm Playing: Professor Layton and the Curious Village

Last night I finished Professor Layton and the Curious Village, the puzzle/mystery game for the Nintendo DS. I know I'm a little late -- the game's been out for more than a year now and there is a new Professor Layton game that's already been released. But I will not be playing the second game.

Why not? Because the Curious Village is surprisingly boring. You'd think it was right up my alley. It has puzzles (I like puzzles). It has a mystery (I like mysteries). You can save at any time (I have limited free time so being able to play in short bursts -- which this game is ideally suited for -- is essential for me). And when I saw the original trailer, I loved the art style and the animation.

But I didn't enjoy it. To start with... Hey! Where'd the animation go? Except for the opening cinematics (and the final scene) there is almost no animation. The story -- what there is of one -- is told in a slide show of static images and printed text. And there aren't very many of these either, since the village is pretty small. Get ready to see the same places over and over again.

Then there is the mystery, which is really no mystery at all. About a quarter of the way through the game, the primary "mystery" of the village becomes self-evident. At that point, the game becomes an exercise in slogging through the puzzles and waiting for new areas to open up.

Which brings us to the puzzles. I like puzzles, I really do. But the worst problem with Professor Layton is I don't find its puzzles satisfying. These puzzles are not mental exercises, they are more what I would call "trick" puzzles, similar to the "move two match sticks to form a different picture" variety. (In fact, that specific type of puzzle shows up several times.)

Now you might say that these types of puzzles teach out-of-the-box thinking, where you need to look at the question in a new way to recognize the answer. However, in many cases, you either see the trick of your don't. If you don't, then the puzzle is simply a frustration. If you do, you quickly answer it and move on, without learning much or feeling any great sense of achievement. This is especially true the third or fourth time you have to answer the same type of puzzle.

Quite frankly I find the puzzles in the "educational" titles Brain Age and Big Brain Academy far more animated, enlightening, and ultimately more fun than dealing with the professor and his mysterious village.

So why, you might ask, did I finish it? Well, to tell the truth, I wanted to prove that my guess as to the answer to mystery was true (which it was). And, in fact, the last few puzzles in the game really ramped up the difficulty and required some serious brain power to solve -- and they were subsequently more satisfying to master.

But it was far too little too late to make up for the general tedium of the game. It's a shame. I really like puzzle games and was hoping this one would live up to the hype. But I guess I'll have to keep looking...

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