‘Why’ is usually more important than the how. As knowledge managers do not usually have any say in ‘why collaborate’, they are stuck with the how. And then there is the constant tradeoff between why a business does something versus why for an altruistic purpose. Again, knowledge managers are comfortable with the altruistic purpose of a community, of innovation, of knowledge sharing, of wisdom in crowds or similar such purposes. That leads me to think the why part of the equation is a red sea muddled with points and counter points, but the how part of collaboration is open for intervention.
Collaborate with its original meaning, “to work with” has to be delineated further. “Work” today is non-linear than what it used to be (even 5 years back) and “with” is very disjointed as well.
Continuity typically is on a work item (e.g. system requirement or issue). To achieve continuity within groups there has to be an overlap of function (e.g. development), identity, effort (e.g. of coding), space (a physical space, a code base). Work in Progress items are more suited for continuity, e.g. developers working together on a release (10.3.4 or R14) or version, talk abstracted or abbreviated language among them that lends continuity. End-products are not given much prominence for example the specification itself or any of the process documentation created during the process.
Coordination is for actions done by individuals in a specific time and space (e.g. check *.ini before service start up, capture log immediately after error, build after check in from all developers is complete). Within groups most understand the rules or rituals and follow them, usually there is not much to intervene here. If the number of people that need to be coordinating increases then a linear sequence with fall backs and alternate paths are developed usually by managers. That flowchart is presented in review meetings with no relevance to actual developers. I find Paul Graham’s maker manager distinction very relevant here.
Communication is often a channel decision, and people choose channels that they are most comfortable.
As in managers email, developers list, clients chat or instant message, friends SMS, and family calls
Channel is a tough choice to make specifically because
· enterprise software are aged and fragmented,
· email inbox more and more looks like somebody else’s to do list,
· managers cannot control requirement change over chat messages,
· and documents never are updated
Rule of thumb that has worked for me is take work to a channel where all the parties are already present. If there is no channel, create one and allow free access.
Metrics around velocity or work, closeness of drop dead date, progress on work items, my items (both in and out), are all derivable from most systems. This I feel one of the basic reasons why basecamp succeeds.
Coherence
· is meaning derived from the work,
· is making sense of where we are, and knowing where the effort is going,
· is relating to the bigger picture
This never comes from status meetings with a formatted ppt, most developers consider that meeting as a break and try to speak as less as possible and take back no action forget about coordinated actions. A concept map on the other hand provides a better way to look at things zoomed out or zoomed in, more clearly with relationships and dependencies.
Knowledge manager’s job gets interesting if more than one of these dimensions is handled. Just saying
