After reflecting a while about Jamais’ idea about open source scenario planning and after reading Art Hutchinson’s comments about some difficulties I thought I should add some of my reflections about problems an open source approach could face.
After having teached scenario planning for several years, as well as being involved in several scenario projects on different levels I had problems accounting for the different levels of quality in the results. It is no secret that scenario planning is an art and not a method, which of course have something to do with it. What I see almost every day is that in overall young students have problems grasping and formulating driving forces, uncertainties and possible chains of events of some quality. What comes out are scattered sentences which doesn’t seem to connect to each other. The ability to reason on that level of abstraction, time-span or uncertainty doesn’t seem to be present.
After having delved into Elliott Jaques theories of time-span capacity and how people are able to manage uncertainty and levels of abstraction I have found a tool for analysing this (there are many, many references but the article “Are you big enough for your job? Is your job big enough for you?” by Judith McMorland is pretty new).
What I find is that people with a certain level of capacity (level IV and above) are in general capable of talking about abstract and uncertain chains of events in a intelligible way. At lower levels people in general can understand and appreciate the result of a scenario process, but are seldom able to construct them with any consistance or quality.
Why does this theory apply to this approach and not say open source software development? Probably because when constructing something “mechanical” you can test things and see if they work. Different individuals can provide the project with their own code, but the test comes if the code works or are being better than before. What we don’t see in open source processes is which individuals are being ignored or all the code that don’t match the quality level and thus is being replaced by others. The working code is a brutal fitness test which effectively filters out the crap.
In an open source scenario process such a filter is not possible and most of the crap will quickly hide all the goodies.