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.