Just spend a moment pondering this scenario:
- There's a high probability that you'll be involved in a collaboration project within the next 12 months.
- Collaboration projects are high risk.
- Management is risk averse in the present economic circumstances.
- Job security at the present time is not great.
So being well prepared for a collaboration project makes good sense. Collaboration within a department (for example setting sales targets) does not have too much risk associated with it, although the same best practices still apply. It is when the collaboration project crosses functional boundaries, or even enterprise boundaries, (for example bid development for a major project) that the issues become substantial.
The key point is this: there are personal and business skills involved in collaboration; it is not just an issue of familiarity with the tools. So the most likely scenario is that an organisation will try a collaboration project and underestimate the skills issues involved. They may argue, it is easy, we'll soon pick it up; or they may request training just on the tools.
In either event there is a high probability of failure. Where the team participants are highly motivated towards the collaboration goal, and there is a sharing culture, the risk of failure will be reduced; but don't let that blind management on the next collaboration project.
The core issue with collaboration - especially across functional boundaries - is that it is barely compatible with our predominant management culture of top down responsibility and accountability.
In an enterprise with a strong collaboration culture, functional management's accountability and responsibility is reduced (especially when that management is not a direct participant in the collaboration) and there will always be an issue of where to place the blame if a collaborative project goes wrong.
Understanding collaboration
Collaboration tools have been with us for some time, but increasingly they are merging with content management tools and with portals, enterprise applications and enterprise social software. Increasingly, you will not license team collaboration tools on their own, but they will be something you acquire when you buy something else.
Each of these different areas that are now merging (collaboration, content management, enterprise applications, and social networking) will have their own specifics. Collaboration projects are more concerned with authoring, exchanging, debating and modifying content than on how to store it. In contrast, content management projects focus on the content in its final, or at least stable, state.
Enterprise applications focus on processes, and social networking projects focus more on mutual support, shared experiences and short-term interaction.
The functionality you should expect from such applications will include membership management, access controls, user profiles, shared workspaces, document sharing and discussion forums.
In the ideal world, it would also include calendar integration, task allocation, task tracking, workflow, basic project management, wikis, blogs, social tags, social bookmarks, social network analysis, social network visualisation, content feeds, people search (expertise location), team decision support (voting, sorting, ranking, scenario planning and categorising), content rating, reputation management and alerting.
The more complex your collaboration project, the more of these features you should expect to find - and the harder the task if they're not there. For example, developing a major new business initiative will require a far more robust collaboration environment than resolving the allocation of car park spaces.
The L&D role
In my experience, most IT departments feel that they own the collaboration strategy, and mainly feel that it's a done deal, except that people aren't using it very well. But it is increasingly recognised that its acceptance is a skills and culture issue, and that is where L&D come in.
Whilst it could be feasible to put the responsibility to an individual business unit, it really does need to be at a cross-functional level in order to send the right messages to the organisation. The best pay-off from collaboration is on cross-functional activities (that is where harnessing collective intelligence really creates value), and therefore responsibility for the collaboration process cannot be at functional level.
L&D almost certainly won't have any content expertise to contribute, but is role should be facilitation - to enable the group or community to work together effectively.
Community management
At the start of a collaborative process, participants must be brought on board; they must be invited to participate and must understand the reasons for their involvement, and the expectations of them. Once convinced (or mandated to participate), their initial connections must be tested, and there should be a governance system to update future connections.
One of the most critical aspects of team collaboration is getting the roles right, and here we can borrow many community management concepts from the knowledge management community.
One of the best established principles on roles was that people could be domain champions, contributors, and users. The domain champion was the ultimate arbiter on what was accepted within that domain and was clearly regarded as an expert by his or her peers.
Domain contributors were people who were able to contribute their knowledge and experience either in the form of documents (or other electronic collaterals), verbal content, or through IM, feeds etc. And the role of users is to access and use that intelligence.
Of course, within a project, there will be multiple domains, and so each individual would have a different mix of champion, contributor, and user roles as the project evolves. Whilst it may be advisable to have an overall leader, it is not essential, especially where there are sensitivities to the collaboration.
If there isn't an overall leader, the individual domain champions will exercise a joint leadership role or one person may take on a facilitator role if that is deemed to be the most effective approach.
Determining success
The other critical point at the start of a project is to determine the criteria for success. It is amazing how often I hear: 'We started a collaboration project but it just atrophied after a while.' When you dig behind it, you typically find that there was a short-term critical issue, and a number of people are brought together in a collaboration project to resolve it.
The participants are invariably the ones most affected by the issue and, once it is resolved, there is no longer a requirement for them to meet together. So, in fact, such a programme should be regarded as a success.
Six practices
Once you have the project underway, make sure that you follow the IITT’s six best practices for collaboration; they cover capturing the benefits, monitoring potential breakthroughs, collecting the outcomes, comparing the contributions, learning the lessons, and keeping management informed.
Capture the benefits
Make sure that a person or sub-group has been assigned to capture and document the outcomes. In the heat of the discussion and debate there can be such euphoria on reaching a conclusion that it is recorded in memory only - and that is notoriously inadequate. In addition, the L&D facilitator should be responsible for recording the social history of the group as that will be helpful in future assignments.
Breakthrough opportunities
Try to focus the participants on activities where collaboration is most likely to have a big effect. Look for individuals near the heart of your business and operations, and try to distinguish between positional authority (that is, people whose position allows them to drive and force through a conclusion) and team accomplishment. Set up good collaborators within the team as role models; this will encourage the participants to share ideas with others, and they pick up on new approaches more readily.
Collect the data
There are really two areas that you're looking for here - did collaboration help to achieve the outcome, and did the tools work? On the first one, consider if the collaboration programme didn't exist what would have happened, and, in addition, was teamworking as effective as it could be. On the tools, you should try to identify which approaches enhanced collaboration, innovation, and opportunity discovery, which ones were a pain, and did any of them have no effect?
Compare the contributions
As multiple collaboration projects develop you'll get some interesting comparisons. At first, there'll all be different, which means there'll be no common metrics. But over time you'll find common ground and be able to track it. That common ground is likely to be among the success criteria, common issues, approaches and profiles.
Learn quickly
It is critical that, as facilitator, you recognise mistakes quickly and turn them into opportunities for fast learning. Getting the personal skills of collaboration and the culture right won't happen immediately.
Communicate
You should expect that senior management may not always recognise the value of collaboration. Providing examples of the benefits of collaborative efforts is therefore critical to overcoming this scepticism. Obviously, you'll want to avoid setting unrealistic expectations, but most collaborative projects will offer excellent ways to demonstrate value through highly granular benefits.
So, collaboration projects may appear to be high risk at first, but in a situation in which innovative approaches are encouraged in order to create a more agile enterprise in the future, you certainly shouldn't try to avoid them.
