Thursday 13 May 2010
Slides from Keynote at eKommune 2010 [Norwegian]
The slide deck from my eKommune 2010 keynote "Collaboration Strategies in Knowledge-Intensive Organizations" has been published on SlideShare [Norwegian language]:
Wednesday 14 April 2010
New Decision Support Tool for Improving Collaboration
Collaboration is complex stuff.
It's complex because it involves so many things; people, roles, processes, communication, interactions, negotiations, processes, shared understanding, operating principles, technology and workplaces. Plus a whole range of other things. Improving collaboration requires some knowledge about all of the above, and it is a process in its own right.
The problem with this complexity is that there are as many ways of approaching collaboration as there are things to think about. How to navigate all of this? I've been struggling with this myself for more than ten years. It's really hard!
In about two weeks a decision support tool is being introduced that allows you to navigate this stuff in a meaningful matter; KC Collaboration AnalyticsTM. It doesn't make collaboration simple, but it makes it a whole lot simpler.
It's complex because it involves so many things; people, roles, processes, communication, interactions, negotiations, processes, shared understanding, operating principles, technology and workplaces. Plus a whole range of other things. Improving collaboration requires some knowledge about all of the above, and it is a process in its own right.
The problem with this complexity is that there are as many ways of approaching collaboration as there are things to think about. How to navigate all of this? I've been struggling with this myself for more than ten years. It's really hard!
In about two weeks a decision support tool is being introduced that allows you to navigate this stuff in a meaningful matter; KC Collaboration AnalyticsTM. It doesn't make collaboration simple, but it makes it a whole lot simpler.
Wednesday 10 February 2010
Collaboration Requirements for Knowledge Workers
A deep understanding of requirements is the foundation of any good collaboration solution. Requirements are not separate from objectives; rather the opposite - requirements follow from precisely defined objectives. However, this translation is not always straightforward, and it requires some finesse and insight. Too often, requirements address symptoms and not the underlying issues. As I have mentioned before in this blog, Here is a very brief overview of the different requirement clusters identified in the ECOSPACE project (eProfessional Collaboration Space), where I recently participated in the final review (more from this review in a future blog post). ECOSPACE is an Integrated Project funded by the European Commission under the 6FP/IST Programme, Strategic Objective Collaborative Working Environments.
eProfessionals extends the traditional concept of professional in including any type of expert or knowledge worker that depend on ICT environments and tools in their work practices (see project description on AMI Communities or the ECOSPACE project website).
The following high-level requirement clusters (RCs) have been identified by the ECOSPACE project partners as generic requirements for eProfessionals:
RC 1: Activity space – Context-specific subset or representation of a work environment that includes resources, people and tools. Arranges everything that is needed to produce a typical piece of work in a team. This is where you go to produce outputs when objectives are clearly defined. Context-specific means adapted to the task at hand, e.g. smart use of desktop real estate – emphasizing relevant objects and hiding irrelevant ones using semantics or other approaches.
RC 2: Team setup – A simple way to connect people with the right individual competency profiles, help them develop a shared understanding, structure work, get them operational quickly, organize them in a group and link them together with all required connectivity options.
RC 3: Knowledge discovery – Identify available and relevant competencies and knowledge resources (documents, files, knowledge objects, ideas, concepts), create competence maps and establish proper links to particular project or community activities.
RC 4: Management overview on work – Management dashboard; gives project managers and innovation / community managers a quick overview of key issues and the status and progress towards objectives.
RC 5: Synchronous communication and collaboration – Seamless integration of synchronous and asynchronous collaboration into the work activities and support for synchronous collaboration processes.
RC 6: Personal work view – Support the self-organisation in the context of the collaborative activities; “myDashboard”, “iDashboard”, “iView” or similar. Highlights and structures relevant resources for each individual according to context and preferences. The key point is that knowledge and information requirements are dynamic and highly context-dependent, and this limits productivity because knowledge workers often have to spend mental capacity (that could otherwise be invested in value-adding activities) on configuring their own workspace to make it suitable for what they are doing. Each “shift” or “transition” between activities with different objectives and process inputs and resources hence forces the worker to focus on the technology and process setup rather than the objectives at hand. And as 1) relevant information in one context or work stream may be very different from what is needed in the next context, and 2) the number of such shifts or transitions can be substantial in any single day, the use of semantic principles and configuration technologies that could semi-automate or simplify the user interface not only in a single context, but across different contexts and work processes, could improve knowledge worker effectiveness and efficiency considerably.
In addition, change management was identified as a cross-cutting requirement:
RC X: Change management – How ICT can enable and support effective change management activities have been identified as a supportive requirement cluster. Some of the change requirements can probably be addressed from within the other clusters, but the point is to keep the required flexibility to stay agile and nimble under changing circumstances. The ICT systems in use should support the processes rather than restricting them.
An important research result from the ECOSPACE project is that although different industrial sectors appear to have similar collaboration requirements on an aggregated level, the manifestation of these requirements in actual collaboration concepts, systems and processes remain highly contextual. Therefore, the technologies developed to address identified collaboration requirements such as e.g. knowledge discovery or activity space, will necessarily have a different configuration or representation for different industrial sectors.
eProfessionals extends the traditional concept of professional in including any type of expert or knowledge worker that depend on ICT environments and tools in their work practices (see project description on AMI Communities or the ECOSPACE project website).
The following high-level requirement clusters (RCs) have been identified by the ECOSPACE project partners as generic requirements for eProfessionals:
RC 1: Activity space – Context-specific subset or representation of a work environment that includes resources, people and tools. Arranges everything that is needed to produce a typical piece of work in a team. This is where you go to produce outputs when objectives are clearly defined. Context-specific means adapted to the task at hand, e.g. smart use of desktop real estate – emphasizing relevant objects and hiding irrelevant ones using semantics or other approaches.
RC 2: Team setup – A simple way to connect people with the right individual competency profiles, help them develop a shared understanding, structure work, get them operational quickly, organize them in a group and link them together with all required connectivity options.
RC 3: Knowledge discovery – Identify available and relevant competencies and knowledge resources (documents, files, knowledge objects, ideas, concepts), create competence maps and establish proper links to particular project or community activities.
RC 4: Management overview on work – Management dashboard; gives project managers and innovation / community managers a quick overview of key issues and the status and progress towards objectives.
RC 5: Synchronous communication and collaboration – Seamless integration of synchronous and asynchronous collaboration into the work activities and support for synchronous collaboration processes.
RC 6: Personal work view – Support the self-organisation in the context of the collaborative activities; “myDashboard”, “iDashboard”, “iView” or similar. Highlights and structures relevant resources for each individual according to context and preferences. The key point is that knowledge and information requirements are dynamic and highly context-dependent, and this limits productivity because knowledge workers often have to spend mental capacity (that could otherwise be invested in value-adding activities) on configuring their own workspace to make it suitable for what they are doing. Each “shift” or “transition” between activities with different objectives and process inputs and resources hence forces the worker to focus on the technology and process setup rather than the objectives at hand. And as 1) relevant information in one context or work stream may be very different from what is needed in the next context, and 2) the number of such shifts or transitions can be substantial in any single day, the use of semantic principles and configuration technologies that could semi-automate or simplify the user interface not only in a single context, but across different contexts and work processes, could improve knowledge worker effectiveness and efficiency considerably.
In addition, change management was identified as a cross-cutting requirement:
RC X: Change management – How ICT can enable and support effective change management activities have been identified as a supportive requirement cluster. Some of the change requirements can probably be addressed from within the other clusters, but the point is to keep the required flexibility to stay agile and nimble under changing circumstances. The ICT systems in use should support the processes rather than restricting them.
An important research result from the ECOSPACE project is that although different industrial sectors appear to have similar collaboration requirements on an aggregated level, the manifestation of these requirements in actual collaboration concepts, systems and processes remain highly contextual. Therefore, the technologies developed to address identified collaboration requirements such as e.g. knowledge discovery or activity space, will necessarily have a different configuration or representation for different industrial sectors.
Tuesday 9 February 2010
Collaboration: Approach, Structure and Technology
As mentioned earlier in this blog, the realization of expected benefits from collaboration requires a clear collaborative strategy, and hands-on collaboration tactics. Lack of either (or a clear connection between the two) dramatically reduces the success rate.
In essence, what is needed is a connected and coherent, multi-level, multi-perspective approach that closes the gap between strategy and tactics and operationalizes collaborative strategies based on business objectives.
Excelling at collaboration is a complex undertaking that requires a broad approach. But the broad approach is not enough. The process of staging this (preferably broad) approach is also important, doing things in the appropriate sequence.
Therefore - begin with the end in mind – by establishing a set of good objectives that take into consideration the particular context of your company. “If you don’t know where you are going, any road will get you there” is an appropriate maxim in this context. Giving the process some attention is just good risk management.
Second - all too often solutions are prescribed without a proper understanding of the underlying problems. This is like playing ”Jeopardy” – you know the answer, and then go looking for problems that fit the solution. Needless to say, it should be the other way around, but reversing this common error does not happen by itself – this is largely due to the inherent structural imbalance (asymmetry) in power between a well-organized, streamlined supply side and a weak demand side. The supply side keeps delivering packaged solutions similar to previous projects, because this standardization minimizes their risk and maximizes their profits. This is their core business; they make a living doing this. Compared to the supply side, the demand side is less streamlined, and many representatives find themselves in unfamiliar territory, as being involved in such projects deviate much from their normal day to day activities. Systematically strengthening the user side and the user project could help addressing some of these problems.
A note on the role of technology: Technology alone should be viewed as a commodity – it can be purchased by your competitors, and offers little in terms of competitiveness in its own right. To use a sports metaphor – the sole act of buying a new collaboration technology gives you no more competitive edge than buying a new pair of boxing gloves if you are to fight Mike Tyson. Yes – technology may be necessary, but there is more to it. Technology alone rarely does the trick.
However, as a part of broader, contextualized concepts that also include processes, organization, competence and other elements, technology can, in combination with other elements, be a very powerful differentiator.
In essence, what is needed is a connected and coherent, multi-level, multi-perspective approach that closes the gap between strategy and tactics and operationalizes collaborative strategies based on business objectives.
Excelling at collaboration is a complex undertaking that requires a broad approach. But the broad approach is not enough. The process of staging this (preferably broad) approach is also important, doing things in the appropriate sequence.
Therefore - begin with the end in mind – by establishing a set of good objectives that take into consideration the particular context of your company. “If you don’t know where you are going, any road will get you there” is an appropriate maxim in this context. Giving the process some attention is just good risk management.
Second - all too often solutions are prescribed without a proper understanding of the underlying problems. This is like playing ”Jeopardy” – you know the answer, and then go looking for problems that fit the solution. Needless to say, it should be the other way around, but reversing this common error does not happen by itself – this is largely due to the inherent structural imbalance (asymmetry) in power between a well-organized, streamlined supply side and a weak demand side. The supply side keeps delivering packaged solutions similar to previous projects, because this standardization minimizes their risk and maximizes their profits. This is their core business; they make a living doing this. Compared to the supply side, the demand side is less streamlined, and many representatives find themselves in unfamiliar territory, as being involved in such projects deviate much from their normal day to day activities. Systematically strengthening the user side and the user project could help addressing some of these problems.
A note on the role of technology: Technology alone should be viewed as a commodity – it can be purchased by your competitors, and offers little in terms of competitiveness in its own right. To use a sports metaphor – the sole act of buying a new collaboration technology gives you no more competitive edge than buying a new pair of boxing gloves if you are to fight Mike Tyson. Yes – technology may be necessary, but there is more to it. Technology alone rarely does the trick.
However, as a part of broader, contextualized concepts that also include processes, organization, competence and other elements, technology can, in combination with other elements, be a very powerful differentiator.
Tuesday 26 January 2010
New journal article in the International Journal of e-Collaboration
Collaborative Performance: Addressing the ROI of Collaboration
Published in: International Journal of e-Collaboration, Vol. 6, Issue 1, pp. 53-69
Authors: Kjetil Kristensen (ESoCE-NET) & Björn Kijl (University of Twente)
Collaborative Performance: Addressing the ROI of Collaboration >>
The article is a part of the IJeC Special Issue on Collaboraborative Working Environments featuring several articles from the ECOSPACE Integrated Project [project wiki] funded as a part of the European Commission's Strategic Objective Collaborative Working Environments.
Published in: International Journal of e-Collaboration, Vol. 6, Issue 1, pp. 53-69
Authors: Kjetil Kristensen (ESoCE-NET) & Björn Kijl (University of Twente)
Most companies tend to address collaboration in a fragmented, ad hoc manner, despite the fact that many professionals today spend most of their time on collaborative activities. Significant productivity improvements can be realized from approaching collaboration more systematically. This article explains how businesses can benefit from a systematic, structured investment in tools and methods supporting collaboration. The article proposes a few governing principles and a list of specific action points for businesses that are interested in improving collaborative performance and collaborative Return on Investment (ROI).Read the abstract from the publisher IGI Global or access full text purchase options:
Collaborative Performance: Addressing the ROI of Collaboration >>
The article is a part of the IJeC Special Issue on Collaboraborative Working Environments featuring several articles from the ECOSPACE Integrated Project [project wiki] funded as a part of the European Commission's Strategic Objective Collaborative Working Environments.
Subscribe to:
Posts (Atom)