I am speaking at a conference tomorrow, looking at case studies of KM systems implementation. During my preparation, I was struck by how much I was concentrating on the things that went wrong. On reflection, I think this is correct.
Last week, Shawn Callahan asked why business writing tended not to use examples:
I suspect it takes more time to find an example and it’s much easier to espouse an opinion.
For example, I’m writing a client report at the moment and I’ve asked my client to send me a couple of examples illustratinh how their information system has been used to have a bottom-line and positive impact on the business. I also asked for examples of when the system had been misused or failed the organisation. My client could immediately think of examples of the latter and is still looking for our positive examples.
So maybe it’s harder to find the positive stories and business report writers have a tendency to want to show strength and a positive outlook, and this is more easily done, especially with time pressures, with opinions. The problem is, we are creating a false intellectual economy because without the examples your readers don’t know what you really mean and instantly forget the main ideas.
On Friday, Dave Snowden shared seven principles of knowledge management. One of them is “tolerated failure imprints learning better than success.” I think this is right, and it probably explains why examples of success do not stick in the mind.
Imagine: if we run a project and it is successful — a KM system is launched and people use it happily. How do we know why it is successful? What are the elements that generated that success? These systems are generally complex and so we can’t point to anything that is particularly responsible things going well. Was it the good relationship between KM and IT? Was it the user interface? Was it the underlying tehcnology? Was it the internal communications about the project? Was it good leadership? Was it good project teamwork? Was it actually a success? There is no way to be sure.
However, when things do not go quite right we can suspect immediately what the cause was. Is the system hard to use? That’s probably because the UI is a nightmare. Does everyone ignore it? That’ll be down to the fact that we are asking people to do something that doesn’t fit into their normal working pattern. Does it crash on a regular basis? Oops, we underspecified the hardware. And so on. We can learn from these things and try to avoid them in future projects.
I might go further than Dave: I am not sure that we learn anything from success at all. As Phil Rosenzweig explains in his book, The Halo Effect, successes are often dependent on a specific set of circumstances and are poorly understood by those who write about them. Rather than learning from success, Rosenzweig suggests that we are more often deluded by it.
So when we look at a success, all we can say reliably is that there is no guarantee that if you do what I did you will succeed in the same way. Contrariwise, in the case of failure, if you do the same as I did (by act or omission) you are likely to fail in the same way. In both situations, you may even fail in a different way.
Mark Gould... 