The trouble with allocating Saturday as a work day in a city centre apartment hotel on floor four is that the noise and distraction level is high. That said I managed to get some writing done, along with the chance to reflect on my two earlier posts on babies, plug holdes and bathwater. In the latter of those posts I introduced the idea of coevolution as a both-and alternative to the either-or position suggested by Seddon. I summarised a method, social network stimulation, which can be used to increase the levels of interaction between technical staff and users, and between unarticulated/unknown needs and capabilities. That method works because it has been designed to follow three basic heuristics of working with complexity:
I am reinforcing here my basic tenant that its not enough to have good intent and experience, you have to have knowledge of theory, or why, if anything is to scale or be applied in a different context. This is about chefs, not recipe users simply repeating past success without real understanding. As promised I want to move on now to discuss narrative methods of requirements capture, and as critically project monitoring and related impact measurement.Now I should make it clear that this means I am going to be talking about SenseMaker® which is proprietary to Cognitive Edge and subject to a US patent I don’t often do this, but given my long term advocacy of certain principles it would be surprising if I had not incorporated those principles into the software. I can enjoy criticising the excesses of systems thinking as much as the next ape-descended life form, but what matters is putting things in place to do things differently that can be learnt and scaled by people on a day to day basis. This along with my previous post are a part of the course I am putting together on complexity for the Lean/Agile/Scrum communities by the way. I should also say that this is a new and emerging series of applications so don’t expect fully formed case studies, its a work in progress and ideas and questions are welcome.
Traditionally is systems users are interview by systems analysts or brought to gather in workshops to gain an understanding of what they need our of the proposed new system. This approach has at least seven problems (some of which KM people will be very familiar with.
I could add that in many cases requirements capture creates bureaucracy and therefore rewards those who are good at documentation and the non-creation of angst or worry with senior managers. Documenting needs falls foul of the tacit-explicit conversion heresy, i.e. it wrongly assumes that I can translate a need into a document. Just think how much of social computing is learnt by doing, not by reading if you want some proof of this.
Overall the function of a user requirement document is so that users can sign up to something they only partially understand at best, but which they can be held accountable for by the IT department later.
So how can we do things differently? That will be the subject of tomorrow’s post, or maybe the day after, depending on how flights workout
Serious posts will have to wait for tomorrow. I was up at 0400 today ...