Redundancy in KM
While reading one Nonaka's papers today, I came across the concept of redundancy, i.e. conscious overlapping of activities, information and responsibilities, which is very common in Japanese companies. It has negative connotations of waste, and it is easy to argue that it is not as efficient since there is duplication of effort. Still, it is not necessarily a bad thing if the duplication of effort is channeled in a collaborative way. Nonaka makes the point that building in redundancy like this increases the level of communication and dialogue about issues, since more people are involved. These extra connections can lead to breakthroughs in understanding or insight in my opinion, and I have three examples.
The first goes back to the KBAM in-module work. My group was struggling for ideas on what to do. We decided to write various aspects of what we working on, on the board for everyone to see. This led to numerous conversations about the links between each person's work. By doing this, redundancy was found - we were able to see where things crossed over and since everyone had different viewpoints, this led to creativity, and ideas for approaching WaveRiders asset management is a unified way.
The next is about the Lego task in OPP this past week (sorry to those of you who were not present, this might not mean much). We were working on dismantling and reassembling a model, using only our own memories and drawings. Guy mentioned that most teams did it by splitting the work, but that another approach was to have everybody do everything together, drawing or memorising every connection. He mentioned this was slow, but likely to result in success eventually. I guess you could call it complete redundancy or something. If you remember, then he drew a diagram on the board, of overlapping circles, signifying an approach where everyone has there own part, but their remit crosses with others. This is probably the ideal. I don't know about everyone else, but certainly a problem in my group was that everyone remembered their part, but struggled with how to connect their part back to the overall model. Had we extended the scope of 'our part' to the connection, and created some more redundancy, it would have been much easier to complete the task more quickly.
Ok, the last is not technically about knowledge, but I think it demonstrates the concept well. Remember, we talked about redundancy in PEUSS, as a safety mechanism to build in reliability or robustness into design. If one area fails, something else is there to cover for it and protect the system from failure. In the case of knowledge, if one person doesn't recognise something important, but other people are engaged, they may spot it, potentially leading to realisations that can be passed around the organisation, perhaps saving money or time.