The Power of Jointness
How Collaboration Works in Real Life
"Collaboration" is one of the big knowledge management-mantra words—this is a list that also includes "sharing," "capturing" and even "delivering" knowledge. When industry gurus talk about KM, you can bet "collaboration" isn't far behind. So how come it's so hard to write about?
We know what we mean when we hear it. We know intuitively that "collaborating" is something that takes place every day in our work lives. Every e-mail you write, every contract you weigh-in on, every patient record you update is a collaboration of sorts.
And sometimes in our private lives, too. I have been in a rock-and-roll band of one kind or another since I was in high school. They're usually four- or five-piece outfits that get together a couple times a week to make a lot of noise, and maybe once in a while achieve something approaching listenable music.
To call these groups "collaborative" is both correct and incorrect. We collaborate, sure. We jam on songs, and sometimes we'll agree to change this verse or that ending. But one thing I have learned: democracies do NOT work in small numbers. It is much better to assign someone to be the leader. Otherwise, if one of us is unhappy, that's a 25% dissatisfaction rate. That's huge.
The Pentagon calls this "jointness"—the services combine their strengths rather than work separately. It's part of an ambitious effort to save money by streamlining support services across the armed forces. All I know is that it makes sense and I'm thinking of calling my next band "Jointness."
Here's a succinct list of "lessons learned" from the MITRE Group, a not-for-profit organization chartered to work in the public interest. MITRE manages three federally funded research and development centers (known to some as FFRDCs, because all public-sector groups go by an acronym): one for the Department of Defense, one for the Federal Aviation Administration and one for the Internal Revenue Service. I thought this list of "lessons learned" about collaborative efforts would shed some light on the following essays. So says MITRE: "Conventional wisdom would have one believe that successful technology insertion must follow six hypothetical guidelines:
• The organization's culture must naturally support collaboration.
• Exhaustive requirements analysis is needed to ensure success.
• You need broad high-level management support.
• The information technology (IT) infrastructure must be accommodating.
• Build it and they will come.
• You need a lot of money to deploy collaboration technologies."
But here's the kicker: "None of these guidelines proved entirely true in our experience."
A Short List of Lessons Learned
Guideline 1: The organization's culture must naturally support collaboration. Intelligence analysts (not dissimilar to business executives) have been trained to produce world-class technical intelligence products in a culture that rewards closely held ownership of information. Downsizing has led to the loss of senior analysts and managers. There is a growing awareness that working smarter, not harder, means working together.
Lesson learned: All large organizations are feeling "market pressures" to react to a rapidly changing world. In such cultures, the need to change is a powerful ally in addressing substantive cultural barriers to collaboration, but you have to highlight the compelling business arguments supporting that change.
Guideline 2: Exhaustive requirements analysis is needed to ensure success.
Lesson learned: It's not the technology, or the process, but rather its application that is the key to success.
Guideline 3: You need broad high-level management support. It's good when you can get it, says MITRE, but the nature of collaboration systems as a disruptive technology means that broad management support is probably unattainable early on. Be prepared for broad opposition.
Lesson learned: The root of most management opposition is fear. You have to overcome fear with documented test results, overwhelming customer demand, persistence and a generous supply of "get out of jail free" cards from at least one senior manager.
Guideline 4: The IT infrastructure must be accommodating. This is the one guideline MITRE agrees with. A well prepared enterprise architecture for wide deployment of a collaboration application is key.
Lesson learned: The critical aspects of any collaboration system lie in its supporting network communications technologies. If you want to fit the system into your enterprise structure, get a good network engineer on your team from the beginning, and make your initiative fit the infrastructure.
Guideline 5: Build it and they will come. Try to imagine what MITRE thinks about this one. "This argues that standing up the capability is all one need do, and that once in service, it will draw users in. This couldn't be further from the truth," MITRE firmly states.
"We had to build compelling business cases and publicize them to the workforce through their peers in order to win over skeptics. This is organizational change in action, and it's painful. No organization changes on its own accord without a compelling reason to do so."
Lesson learned: Go where you are needed. Wider is not better, at least in the early stages. Reaching critical mass can be slow, but is the only sure way to demonstrate a compelling business case.
Guideline 6: You need a lot of money to deploy collaboration technologies. Nope, says MITRE. "We wish we had deep pockets. When we began this effort, we had no server, no virtual network, no client distribution facility, no headsets, microphones, video cards or any other hardware supportive of desktop collaboration systems. We had to ‘liberate' the equipment."
Lesson learned: Sometimes you have to appropriate the needed resources in nontraditional ways.
This is a short list of collaboration truths. As you read the following essays, see how much of MITRE's work rings true for your organization.
Andy Moore is a 25-year publishing professional, editor and writer who concentrates on business process improvement through document and content management. As a publication editor, Moore most recently was editor-in-chief and co-publisher of KMWorld Magazine. He is now publisher of KMWorld Magazine and its related online publications.
Moore acts as chair for the "KMWorld Best Practices White Papers", overseeing editorial content, conducting market research and writing the opening essays for each of the white papers in the series.
He has been fortunate enough to cover emerging areas of applied technology for much of his career, ranging from telecom and networking through to information management. In this role, he has been pleased to witness first-hand the decade's most significant business and organizational revolution: the drive to leverage organizational knowledge assets (documents, records, information and object repositories) to improve performance and improve lives.
Moore is based in Camden, Maine, and can be reached at andy_moore@verizon.net