A project by definition has a beginning and an end. An initiative—the way I define it—could be short or long term, but in general I see it as an ongoing activity that does not necessarily have a predefined end. As long as an initiative provides value, it could go on year after year, potentially with a modified focus and slightly changing objectives.

Certain subactivities under the umbrella of the initiative could be run as projects, though. If you create and install a technical system to support certain parts of your knowledge flow, this is an example of a project within the initiative. But it is only a small piece of the complete initiative, and without the other components, the project by itself provides limited value. So I see a project as an activity with a defined beginning and end that would be run within an initiative. One element projects and initiatives have in common is that they need funding and measures to see whether activities are on track to reach predefined goals.

Ongoing efforts will ensure that the result of a project fits the overall strategy and changing conditions within the initiative. Those efforts and support activities include not only the technical support for the system but, even more important, all those actions to sustain or grow ongoing effective participation. This includes marketing efforts, such as evangelizing to parts of the organization that could benefit but might not even be aware of any potential.

If you talk only about a project, the word brings with it the danger that key stakeholders might feel they can finish one specific knowledge management project, then be done with knowledge flow management and take the resources off and use them somewhere else. While talking about a project might work for creating and rolling out a technical system by itself, it is a sure recipe for failure when you want to get ongoing value from what you created. One of the key success factors for a successful knowledge flow management initiative is the availability of longer-term passionate resources that will guide it.

Knowledge flow management is largely about driving human behavior, which often takes considerably more time than a pure information technology (IT) project. It might take years rather than months to get an initiative not only launched but also embedded into the organization to the point where it is part of normal business processes. I refer to this phase as the bootstrap phase. Being patient enough to surpass the bootstrap phase can be well worth it, though, as the return on highly leveraged knowledge can be considerable if not a prerequisite for organizational survival.¹

Having a consistent strategy during the bootstrap phase is a key requirement for success. That does not mean that there should not be any fluctuation in your support team. In fact, it can help to get some fresh ideas, but because the key ideas have to be consistent, a core team should be there longer term. Apart from consistency, you should focus on a manageable number of initiatives to which you can devote full attention for an extended time in order to move from the bootstrap phase to the point where participation in the initiative becomes a standard business process. And even if participation has become a natural element of business operations, the need for support will not diminish completely.

One more reason for closely guiding these initiatives is the potential for innovation. When it comes to the supporting technology, there is a difference between operational systems, such as a typical finance or personnel system, and technology used to support knowledge flow. Operational systems are usually created with extensive phases of requirements gathering, larger phases of development, and rather infrequent update release points. Technical systems created to support knowledge flow management initiatives need to be extremely flexible and agile. For operational systems, it is easier to prescribe standard procedures. You can just demand that everyone in human resources (HR) use the new HR system. In some cases legal compliance rules might mandate usage. When it comes to knowledge sharing—and specifically if you want the most valuable knowledge to flow—you cannot just prescribe participation. It is the knowledge in people’s heads that needs to be shared. So it is essential that you make participation in the initiative as attractive as possible and remove any potential barriers. Some of those barriers are discussed in Chapter 6. If you want that behavior to become part of the standard processes, it is important to ensure that the support system and the processes fit together.

In my experiences with ToolPool and other initiatives, this fit can be achieved only via ongoing monitoring of participant behavior. The behavior will likely change over time, and it is important to be aware of that. It is essential to modify systems and processes very quickly should there be any conflict, even if the conflict is based only on some type of fear. People might be afraid to lose some of the value to the organization because they shared their knowledge, for example.

When I talk about a quick reaction, I am thinking of a response within days, not months or years. In the case of ToolPool, we reached out to our users daily—especially during the bootstrap phase—and if we heard that certain things were not working well or not fitting the process, we reacted and adapted the process or system sometimes that same day. If you start with a small user group, you can afford that type of flexibility. With a launch to 10,000 employees, it is a lot more risky.

By starting iteratively, early participants will be more likely to form a positive attitude toward your initiative as they see that it adapts to their wishes almost instantly. It makes them realize how much they are part of the initiative. They can influence how it works, and by the time your initiative grows and reaches additional audiences, you will have fixed some of the major issues and won some additional regional evangelizers.

It is actually easier to accept a slow start than to work with a standard operational system. If only a portion of your organizational knowledge flows more effectively, you are still better off than if you had no flow at all. Another advantage of the staged approach is the potential to collect some specific success stories that can be used to build further support from additional participants and key stakeholders. An example might be a use of some shared knowledge that immediately results in high return.

But the staged approach does not work without a connecting strategy and some passionate support people who can adapt the strategy to changing business requirements. I refer to those passionate support people as drivers because they drive the initiatives forward. I also talk about drivership as the collective activities of drivers to move a knowledge flow management initiative along.

Make sure to view your knowledge flow management activities longer term and open-ended—not as a fixed-time project. Also ensure that they have that persistent ongoing drivership without too much turnover of your key strategists.

It is important that the key team members have the capabilities and powers to reach outside of the organization in which they are located. In some organizational cultures, this is possible even if the team members sit in one of those mentioned suborganizations. In other cultures, it will be possible only when they are located outside of any of those organizations in a separate entity reporting to the chief executive officer or chief operating officer. The reach across different functions is important, as most initiatives will have a combination of human, technical, and business process elements, and the knowledge flow management team will have to reach out to stakeholders in all of those areas.

A useful structural element is the existence of champions throughout the organization who will drive knowledge flow management initiatives at the local level. In our case, we called them knowledge coordinators. They are organized in a global community of practice, but their main focus is the local organization they report into. They are knowledge intermediaries,² mediating knowledge flow management processes where necessary. I discuss roles further in Chapter 3.

There are, however, some general components that you should cover in your strategy. The framework outlined in Exhibit 2.1 provides some of the main elements that are needed.

Your efforts will be based on the culture of the organization you are dealing with. Your strategy will have a technology foundation that some of the support systems you might build are based on. There will be a set of processes guiding how things get done. Some of those processes might be embedded in systems; others are laid out in documents that are either followed or not. There will also be some processes that are just understood by those following them without being documented. Very often, however, they will represent the way things get done.

At the core of your knowledge flow management activities are some initiatives with a longer-term focus. Within the different initiatives you might run certain projects to implement infrastructure, create and run marketing campaigns, or drive processes forward.

The activities are framed on one side by the business organizations, the parts of your organization that participate in the initiatives for the sake of better business results. The support organization drives the initiatives, ensures participation, and guides changes to the underlying platforms (processes, technology, and culture).

The initiatives themselves can actually be viewed as separate entities, but it is important to connect them intelligently. Doing so could include connecting subcomponents, such as technical subsystems. As an example we enhanced our global online staff directory by showing a list of contributions and usage data.

When you develop or refine components for your own organizational strategy to support the knowledge flow, there are a number of factors that you should keep in mind. It is easy to jump to an action plan to implement or enhance certain subcomponents.

I recommend putting any proposal through the following acid test of questions (see Exhibit 2.2)³ to see if you are really ready to start. These questions are based on experience with a range of initiatives and projects, some successful and a few unsuccessful ones. You can use them for a self-check or to get a better understanding of your key stakeholders motivations and vision. The questions can also be used to uncover areas where the organization is not ready to go forward with their knowledge flow management initiative.

Add up your score and see where you fit:

This questionnaire does not replace a proper complete assessment, of course, but it can highlight some possible danger points early on.

If you do not have a lot of established successful initiatives running, Scenario 2 is the one that is more likely to succeed. This is especially true when it comes to those initiatives that will include social media and social networking components.

Apart from starting small with one initiative, I also recommend starting with focused topics. If there are systems involved, keep them focused on certain topics and audiences to start with. There are a number of advantages to this approach:

One of the dangers might be that you are taking the feedback from the small starting group and assuming that it will equally apply to a wider audience. This is the reason why you need to be very flexible and adapt with growth.

Within a large initiative that often has a large system component, ownership is usually shared so widely that an individual cannot really see the effect she might be having. Consequently, she will not take the same level of ownership and responsibility. In many cases, ownership is one of the key ingredients in creating the passion that is needed constantly. If there is more focus, supporters will see it as their key responsibility to serve their specific audience as well as possible.

Here are the main advantages of approaching knowledge flow issues with smaller and more focused initiatives:

There are of course a couple of downsides to having separate initiatives and specifically separate technical systems:

In my experience, the best way to deal with these issues is through the creation of intelligently networked systems. What I mean by that term is that each module that has a relationship to another module is linked at a touch point, which could be common categorization, for example. These touch points include simple sets of categories (e.g., countries, products, etc.) or more complex taxonomies.

Let us take a simple example from ToolPool: the tools, tips, and tricks sharing initiative. Within the system supporting ToolPool, there is a simple search interface that lets you find entries by keywords. But ToolPool is not the only source of technical content at SAS. Another important resource is the customer problem tracking application. Customer support staff can mark certain problem tracks as tips and tricks instead of software problems. As our partners and customers build and use more complex applications, our customer support not only deals with software problems and errors but also often provides guidance and consulting on how to solve specific challenges. Those customer interactions are tracked but usually will not result in any request for a fix to the software.

The customer tracking process and ToolPool are supported by separate systems, but they are intelligently linked. That means if users do not find the right solution in ToolPool, they will get an easy, one-click way of forwarding their search to the customer tracking center tips and tricks area. However, customer support agents have an easy way to search not only their tracking system but ToolPool as well.

While the systems used are part of different knowledge flow initiatives, a link enables the user to travel from one to the other. At the same time, it is possible to upgrade the tracking system or make changes to ToolPool independently as long as the cross-search linkage stays intact.

It is often an advantage to start with a focused search first and then work into adjacent areas depending on your needs. In this case, we found the concept of modular intelligently networked systems is often a lot more appealing. Actually what we created in the late 1990s is very similar to the approach of using mashup applications in the Web 2.0 world today. An example for a mashup would be the possibility to link from a real-estate Web site to a map application. The linkage is via address or coordinates. As a starting point, you might see a listing of properties with pictures. Only if you are more interested in a specific property would you move to the actual map application to show the exact location, satellite picture, street views, and more of a property.

Approaching problems of this kind using smaller steps is a common theme, especially in the Web application landscape.⁴

The big picture is an application framework with enough flexibility to plug in a range of smaller components and that obeys a common standard—in programming terms called an API (Application Programming Interface)—that leaves it open as to what type of component somebody might want to build and integrate. The key is that all those small components can be connected intelligently to some degree.

So far in this section I have mainly given examples that have a strong technical component. But you can ask how wide or focused you should be in beginning any components of your knowledge flow management efforts.

In the next example, sharing of knowledge happens person to person mostly through side-by-side engagements. The example initiative discussed involves sharing experts throughout the organization in a market model. The basic idea is that those in need of specific subject matter expertise will submit a request for a suitable expert. A brokering service identifies candidates and presents them to the requestor, who then selects a favorite candidate and negotiates details with that person’s manager. As a result, the expert will travel to the area of the organization where she is needed. Part of that type of engagement is the involvement of local staff to build up local knowledge for the future.

The initiative is called resource sharing, and over the years it has grown from exchanging experts on a regional level to doing so on a global level. As with the ToolPool initiative, it started quite small. The process actually preceded any type of sophisticated system, and only a few resources per month were shared. This allowed us to refine and rework the involved processes and iteratively create the right support infrastructure and systems, before we rolled it out on a global scale to share resources among all SAS offices worldwide.

To emphasize again, the key to this highly successful initiative that gives SAS a lot of flexibility is the underlying process, not the system that supported that process. If it were not for scaling, we might have been able to run without any technical system (other than e-mail and phone) for a while.

Some modular intelligently connected systems (a skills database to identify candidates on a global scale as well as an application for processing so-called resource requests) were introduced and allowed for higher scaling, finally extending the process to thousands of engagements every year.

What makes this initiative highly successful is the degree of passionate leadership and support behind it, which allowed us to scale it into becoming fully integrated into standard processes. It provides value to several groups at SAS:

The last point shows that any knowledge flow management process needs to be viewed as just another business process and represents a great candidate for measurement and analyzing. Chapter 8 covers this topic in more depth.