… was so skinny and thin

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:

1. Finely grained objects: multiple small teams tacking different aspects of the problem in parallel at a very tangible level
2. Distributed cognition: not just any old self-organising team, but self organisation with constraints to force diversity of membership and increase scanning range
3. Disintermediation: visibility of results to senior decision makers without mediation or interpretation

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.

1. In general users don’t know what they want until they get it, then they want something different
2. This in part because the interview process can only really explore what they don’t like abut the current state of affairs, a sort of need defined by negation of the present
3. Systems analysts like any interviewer start to form subconscious hypothesis after a fairly small number of interviews and then only pay attention to things that match those hypotheses in subsequent interviews
4. Outliers, or odd demands are often ignored, while these may present some of the best opportunities of radical innovation and improvement
5. Most radical new uses of technology are discovered through use, not through request and more often than not accidentally (think facebook, twitter etc. etc)
6. people only know what they know when they need to know it, it requires a contextual trigger which cannot be achieved in an interview
7. Early stage problems in roll out are easily ignored, or more frequently not reported, as they seem minor but then they build and result in major setbacks.

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