Much of the excitement around Web 2.0, Enterprise 2.0 and social networking as it penetrates corporations lies in the power of collaboration.   There a many great tools out there that enable collaboration – in its many different forms.  And there are many communities out there that want to collaborate.  And then there are IT organizations.  With their increasing need to work collaboratively.  Both among IT professionals, and with their clients and customers.

But, from my personal experience in looking at IT collaboration at my clients, I’m wondering if there aren’t some anomalies around the typical IT organization, or associated with the typical IT professional that impede collaboration?  I don’t think it should be taken for granted that because it makes sense to do certain kinds of work collaboratively, people will – even given the best tools in the world!  In the corporate setting, for certain kinds of work, for certain kinds of individuals, collaboration is an unnatural act.  Of course, I’m not the first to connect the “unnatural act” descriptor to collaboration.  And there’s a substantial body of research into collaboration, and when and why it works well, and when and why it falls short.

Kenneth Crow, back in 2002, wrote a nice piece – an easy quick read – on collaboration.  He points out several actions on multiple fronts necessary for successful collaboration to take place:

  1. Early involvement and the availability of resources to effectively collaborate
  2. A culture that encourages teamwork, cooperation and collaboration
  3. Effective teamwork and team member cooperation
  4. Defined team member responsibilities based on collaboration
  5. A defined product development process based on early sharing of information and collaboration
  6. Collocation or virtual collocation
  7. Collaboration technology

Let’s take these one at a time and apply them to the typical world of the IT professional.

1. Early involvement and the availability of resources to effectively collaborate. From my experience, everyone in the typical IT organization is more than fully loaded with assigned “project” activity.  Over and above that, there are the “special projects” – often several – that people are expected to contribute to, but for which no time is budgeted.  Then there’s the question of “early involvement.”  Most IT operating models are not particularly set up for this.  Again, they are lean and mean machines that tend to engage “as late as possible” rather than “as soon as feasible.”  So, on point 1, IT may be a little disadvantaged on the collaboration front.

2. A culture that encourages teamwork, cooperation and collaboration.  Here I see a mixed bag, but mostly I do find IT professionals, given condition 1. are collaborative by nature.  Often in my consulting work, I need to assign homework to sub-teams.  In most of my clients, I am continually pleasantly surprised and how effectively team members who do not typically work together do collaborate towards meeting the project’s goals – as long as they have some amount of time allocated to it, they believe the goal is worthy, and they believe that there will be some sort of recognition (even if only a pat on the back) for their efforts.

3. Effective teamwork and team member cooperation.  Again, I see a mixed bag, but mostly positive behavior here.  IT professionals are used to getting things achieved through the efforts of a team.  As such, they are usually effective team workers.  The one downside here is that they may not be so effective at managing the environment within which the team works.  For example, tacitly accepting deadlines that are arbitrary and unachievable; failing to confront absent sponsors; failing to confront lapses in team members commitment to deadlines, and so on.

4. Defined team member responsibilities based on collaboration.  Here things can get squirrelly.  With the major projects to which resources are formally allocated, accountability and roles are usually clear.  To smaller or slightly more casual projects, member roles and responsibilities are often not so well spelled out, and things can fall through the cracks.

5. A defined product development process based on early sharing of information and collaboration.  This is often where things start to really break down. It’s a good news/bad news thing.  The good news – there is a ‘product development process’ (SDLC or whatever.)  The bad news – the ‘product development process’ was not created with today’s level and scope of collaboration in mind.  In other words, most IT shops like formal processes, but most formal processes were designed and perfected in a less collaborative world. 

6. Collocation or virtual collocation.  Usually not a problem except when collaborators are in other parts of the world – other timezones, other languages, or other cultures.

7. Collaboration technology.  Usually the technology is available.  The typical shortcoming here is the assumption that people know how to use it, and don’t need training.  This is exacerbated by the IT professional’s ‘macho syndrome’ – “I don’t need no stinkin’ training!”  I have seen this become a real collaboration show stopper!  This mix of ‘macho syndrome’ together with a lack of free time to learn a new tool frequently gets in the way of collaboration in and around IT organizations.  Often the ‘shoemakers children’ we sell ourselves short when it comes to basic infrastructural things such as training, community facilitation and content management.  As a result of this, just when IT should be leading the way with the use of Web 2.0 tools in the corporation, instead IT is frequently timidly engaged in collaboration experiments that seem almost set up to fail.

Are you using Web 2.0 tools?  Are your collaboration experiments everything they could be?  Do you feel that the IT organization is blazing the trail, and setting a shining example of collaboration at its most productive?  Letters on a postcard, please.