Slides are online here. Go here for more information and other presentations by professor Herrmann.
Notes from Thomas Herrman's talk on Technical Systems for Collaboration, Feb 6, 2007 at a MOCHI meeting, U of M campus, Ann Arbor, MI.
- Start with work procedures, not knowledge map
- Remember, Processes have a history and a future: change needs to be taken into account, including commitments and dependencies between roles.
- Iteratively build and diagram a model of work
- Diagram symbology, mousehole indicates incompleteness and a limit to what you can/will find out. (had two types of mousehole symbols, one for incompleteness below this level, one for incomplete representation of higher levels of abstraction/organization). Notes how showing fewer things at a time - and controlling that, in the modeling technology, going back and forth - can improve understanding.
Overexplicit diagrams (specification of control structures) do not work well for communication: choose level of incompleteness to use to communicate about any one thing.
- Can hide higher abstraction/parent detail as well as finer/child detail
- Ask workers questions about the model, e.g.
-- does this activity mirror your work?
-- what kind of information do you need, here?
- Express intentional freedom of decision-making
- Rationality of processes is not observed but constructed - watch out!
- Allow Varying perspectives/views
e.g. task oriented vs. Knowledge Management
- Continuous documentation - Immediate capture, on the wall, whiteboard, etc, so group can see (his research group makes free software that can be used for diagramming, but might still use white board for capture)
Benefits of technology not just seen in comments on interface/technology - benefits are in the process of people and technology working together, in people working together through technology.
contrasting this STWT technique with a cognitive workthrough:
- Cognitive Walkthrough
- one expert
- repeated questions for different parts of the system
Social-Technical Walk-Through (STWT)
- Series of Workshops
- group of stakeholders
- prepared set of questions
- use diagrams as method for re-focusing workshop
- capture problems
- construct solution requirements
- After workshop (between workshops), rework aesthetic appearance of diagram (don't change content)
Note: a comprehensible story about the diagram (to explain the meaning) will be subtly different from the process of building the diagram.
People in workshops will have different rhythms - breaks to document things (on the wall) may let some people catch up.
Note that diagramming and facilitation takes two different people - it's too much for one person to try to do at one time.
Someone asked for a sense of how many workshops you might do as part of the process. For their Drivers/dispatchers study, where they looked at the use of cell phones and other technology to communicate and track things, they did 5 to 7 2-3-hour workshops, over the course of 2 weeks.
"Don't automate, obliterate" - Michael Hammer
(re: reengineering work processes)
Either get Consensus
Or Clear Dissent
See also Gerhart Fisher on Design Process/abstract models, moveable objects for model construction.
"A maximum of explicitness leads to a minimum of understandability"
- Stay flexible in representing incompletely specified relationships
(for communication - later for control specifications everything should be explicit)