“I never thought it would be so political” noted one CIO of a client company we worked with to develop a new collaboration strategy. CIO’s are in a tough position these days in terms of collaboration. They are also often responsible for security and a variety of policies (e-mail, IM, wikis, blogs) to deal with new Web 2.0 social software that is creeping into the enterprise whether they like it or not! The choice of collaboration tools is not simply a technical decision, and something you can throw over the wall and expect people to use successfully, but often it ends up as a political decision that goes straight up to the CEO and even ends up in boardroom discussions for large multi-nationals.

[More:]

So why are collaboration tools so political? In my opinion, one reason is that when you start to change the way people communicate with each other (inside the company) and how they can share content, you begin to change the organizational structure. People are very picky about what, how and with what they do these behaviors with (after all collaboration is a human behavior not a technology).

Web 2.0

Web 2.0 in a way has made things both better and worse. It has made things worse in that many of those coming into the job market from college expect to be able to use many of the same toolset they had available to them in college. Things like Facebook and Twitter and Meebo, which although they are consumer oriented, they did give their users a lot of great collaborative functionality, or were able to aggregate a variety of data sources into one easily accessed platform (e.g. Meebo allows you to IM across almost any of the consumer IM clouds (MSN, Yahoo Messenger, AIM, Gtalk, etc.).

These new workers when faced with the restricted and archaic collaboration and e-mail tools, which unlike Web 2.0 tools, require days and weeks of training, often rebel or are very disappointed in the corporate infrastructure and fall back on the collaboration tools they know (even if they are not sanctioned by the enterprise) to get their work done.

The Ostrich Strategy for Mash-ups

I have been intrigued on how the enterprise is adopting some of these Web 2.0 collaboration tools, and in interviews with a variety of CIOs over the last few months have asked them about their strategy for mash-ups. Given that Gartner came out a few months ago with a prediction that 70% of enterprise data would be through mash-ups by 2010, I thought this a reasonable question in 2008. However, I got no answers. None of the CIOs I talked with had any mash-up policies. I am not sure they were intentionally ignoring it, but they seemed to have other more pressing problems currently that were attracting their attention. My guess is that when they discover that people in their company are doing mash-ups and without IT knowledge, they will start to develop a policy, and maybe even select some mash-up tools to try to deal with this.

Are Wiki Policies an Oxymoron?

Wikis are also part of the Web 2.0 revolution, and there are several tools that are focused on the enterprise like: SocialText and Atlassian's Confluence. Mostly we see wikis sprouting up in the research and development areas, or IT organizations in our client companies, usually for engineers to share complex knowledge (or even code) with others they work with who are at distributed locations). Often the engineers just pick what works for them, not what might work for the enterprise.

Depending on which tools you pick (and some engineering-oriented companies have already been through this) it is good to have a policy that is not too confining. A good example of this is Sun Microsystems. When people there originally started doing Wikis (especially ones that were public facing), the lawyers went ballistic and insisted that they vett everything before it was posted. OK, so that lasted for about a week, before the lawyers gave up after being deluged with posts and created a wiki policy, which is posted on Sun’s site at: http://www.sun.com/aboutsun/media/wiki/policy.html.
The policy is in plain English (not legalese), it is not too long, and basically says, use common sense before you post something and if it has pricing information in it or other sensitive data, check with your management before you post it. Sun has been very successful with this policy with only 1-2 documents that the authors of those documents thought (after posting) that they should not have been posted.

Wiki’s like online communities and social networks, inherently need to police themselves and end up being stifled and die if draconian security policies are imposed by IT. There needs to be a dynamic tension here between innovation and creativity and the need for the organization to protect itself (security). Where your company comes out on that continuum most likely depends not on the collaboration tool, but your corporate culture.

To Blog or Not to Blog?

I had an interesting phone call a few months ago. An associated company brought me into a conference call with a financial services firm who had heard about Web 2.0 and wanted to employ some of those technologies. In the course of the conversation I found out that they had heard about blogs, wikis, and that Web 2.0 companies were cool and also transparent. So that is what the call was about, how they could employ these Web 2.0 tools and be cool and transparent. I first asked what kind of content they intended to exploit with these tools and they wanted to get more information out about their various loan programs. I first suggested a wiki, but when they found out that anyone could contribute to the wiki (although you can lock some wiki tools blocking these contributions) they decided that it was not the best tool for what they wanted to do. So we moved on to blogs. They liked the fact that when they posted something that no one else could change it, but I pointed out that people could comment on each of the blogs. Again, they did not like that because they could not control it (the comments). What we finally got to, was they wanted to do another web page with information about their new loans and would leave it at that.

Although this was a ridiculous conversation, it does point out that this company really did not want to be transparent, but that they were interested in using these new Web 2.0 tools in cool ways, but still wanted to maintain the control of the content they had in Web 0.0 and Web 1.0. The point here is that the tools are an extension of our mindset, and our mindset (and assumptions) have to change before we will be able to use the tools effectively. Unfortunately, changing mindset and behavior is much harder (and probably more expensive) than changing a line of code or a configuration setting in a collaboration tool.

The CIOs Dilemma

So where does this leave today’s CIO? In a pickle! They need to upgrade an aging collaboration infrastructure, they are besieged by large vendors and Microsoft to either keep with Notes or Exchange messaging infrastructure or to switch (which is difficult and expensive and I am not really sure what it gets you) to the other vendor’s tools. Of course you could choose another vendor of collaboration tools (Oracle, Adobe and Cisco) or you could look at the burgeoning open source tools market?

Former open source content management tools like: Drupal, Plone and Joomla have all added a variety of collaborative modules. In looking at these tools for a non-profit I was doing some pro bono work for, I determined that Drupal not only had the most collaboration modules, but the largest ecosystem of developers. However, I still had some problems: Where to host it? Who would support it? What if I needed something specific built? How good were the collaboration modules that were available? Although this was a small non-profit, and not a large enterprise, I was asking many of the same questions.

I recently met with some executives from a Boston area start-up aimed at answering many of those questions. Acquia wants to be to Drupal what RedHat was to Linux. They will provide hosting, and will vett both developers and modules, and even provide support (help desk). I believe this will help the Drupal ecosystem explode, and many more people in the open source community will not only be building new modules for Drupal, but small and mid-sized organizations will start to adopt some of these open source solutions once they are more stable, the quality is known and they are supported.

What does this mean for the CIO? Probably that within the next 3-5 years they will need to consider an open source option for their collaboration infrastructure. Another issue is SaaS (software as a service). SaaS tools are already being used by the enterprise, both Salesforce.com and WebEx are offered as a SaaS. But are CIOs willing to give up some of their control (by having the messaging and collaboration software behind the firewall and on their servers) by adopting SaaS tools for something as fundamental as e-mail and IM? Where does that leave IT and its’ budget if these services are outsourced as a SaaS?

Since the majority of collaboration tools I have been briefed on over the last year have been offered as a SaaS, and even pre-Internet collaboration tools like Notes and Exchange can now be had as a SaaS (from third party service vendors) the CIO needs to look at their core assumptions for collaboration, and what they need to control, the cost and where the value of the IT organization is shifting to?

The Disgruntled Collaborator

I interviewed a purchasing person for a major retailer about 18 months ago. They had a problem in communicating with clothing manufacturers in Asia and went to the IT department for a solution. IT said they were evaluating Microsoft SharePoint and that it was a 2 year evaluation and would get back to them at the end of the evaluation.

Frustrated, the purchasing person went off and within 20 minutes found a wiki-based SaaS tool on the web which they could set up for $20/mo. After an hour they had customized (from drop down menus) and configured the tool (GroveSite), and invited the Asian manufacturers to use it for communicating about specifics on the clothing and orders. It was a great success, the vendors felt that they had more say in the process, the retailer was getting better product, delivery and prices, and the purchasing person was much less frustrated. She told others at the firm about her experience and today there are over 5000 people using this wiki-based tool and IT is still evaluating SharePoint.

The point here is that, unlike in the past, when users came to IT with a request, and IT did not have an immediate solution, and so the user had to go away and wait for IT to get to them, today the user has a wide variety of choices (mostly SaaS-based tools). Many of them follow Web 2.0 principles and are easy to use and configure, cheap, and lie outside the firewall so you can invite those in your value network into easy collaborations. These tools help meet user needs at a fraction of the cost, with no input from IT, and can be set up in minutes.

Since they are usually subscription based, there is no line item for them on a corporate budget, and most subscription costs are below the sign off level for most any employee, with many of these SaaS-based collaborative tools being free, or following the Freemium model (you pay for premium services, but basic services are free). This again puts IT at risk, and often finding out about these tools after the fact and after the business units are already using them successfully.

More to come

I believe these questions about IT and collaboration are both difficult and critical questions. I will be blogging more on this topic as we lead up to the Enterprise 2.0 show in Boston in June. However, it is also a topic I have been thinking about for quite a while (as we have many clients in this situation) and is a topic I ponder at great length in my new book “Collaboration 2.0.”