Collaboration Impact Zones

In my previous post Collaboration Chasm, I looked at the adoption of collaboration technology in the enterprise, drawing on Collaboration Framework published by the CISCO community earlier this year [Insights from the Collaboration Consortium Year One]. In this post, I'm going to explore the CISCO concept of Impact Zones.

CISCO starts from the idea that the greatest payoff from an investment in collaboration comes where people and content intersect - whether in real time, asynchronously, or both. CISCO looks at three aspects of collaboration: interaction, expertise and information. Interaction includes in-person meetings, phone conversations and project teams; expertise includes tacit or professional knowledge, such as an executive, knowledge worker, or specialist might have; and information includes that found in databases, working documents, and archives. “Collaboration impact zones” are those junctures where interactions and the exchange of expertise and information are frequent, urgent, and complex: these may be focused on either internal or external collaboration. CISCO believes that identifying these zones helps an organization focus on the right areas of collaboration to ensure that the financial return of collaboration is greater that the associated opportunity and collaboration costs.

The CISCO definition of collaboration impact zone uses the present tense, and so appears to refer to the AS-IS model of the enterprise. But if we take this too literally, it might lead an organization to invest in those areas where excessive collaboration is already taking place today, instead of those areas where collaboration is weak.

Here's an example. Many organizations have the most intense and angry exchanges with the customers after something has gone wrong: John Seddon calls this failure demand, and points out the stupidity of focusing on managing customer complaints more efficiently, when it would be far better to focus on preventing the things that the customers are complaining about.

However, the examples cited in the CISCO community document don't fit the literal definition of collaboration impact zones. Instead, the investment is apparently focused not on areas where the collaboration is already frequent, urgent and complex, but where collaboration is both insufficient (not enough interaction and expertise where it is needed) and expensive (even limited interaction and delayed expertise incurring significant travel costs). In these examples, the business benefits come from building a platform to support frequent, urgent, complex and affordable collaboration. "Both companies identified part of a business process in which a high concentration of interaction, expertise, and information is required to deliver the business process outputs ... the collaboration tools are adapted to the requirements of the collaboration impact zones." "An organization can begin the process of identifying its impact zones by developing hypotheses about what parts of the processes need performance improvements, then taking “deeper dives” to validate whether collaboration at those points can drive business value." Thus it is in the TO-BE model where we need to look for the collaboration impact zones, not in the AS-IS model. (Which of course raises the question where the TO-BE model comes from.)

But we should also note another possibility. AS-IS models can often be incomplete descriptions of reality, because they fail to document all the informal communication and coordination mechanisms that keep the business running. One way to discover these missing elements is to analyse the AS-IS models according to cybernetic or statistical principles, which may allow us to infer the existence of some coordination mechanism, even though we don't have any visible evidence of coordination taking place. This method is also used for detecting inappropriate collusion between systems that are supposed to be completely independent.

This in turn suggests another way of thinking about collaboration impact zones - they may be anywhere where there is something problematic about the collaboration that may or may not be taking place. For example, there may be some interactions that are not particularly frequent or urgent or complex, and are not expensive to transact, but need to be controlled for some reason - perhaps to eliminate risk or fraud, or to guarantee compliance with some critical requirement, or just to make them visible and available because managers like things that way. ("This call may be recorded for training purposes.") There will also be collaborations whose participants wish to avoid control and interference by management, for whatever reason. So the identification of these zones is going to raise a lot of issues.