Project Collaboration
Collaboration First, Then Knowledge Management
by Matthew Clapp
30-Jun-2004
You are probably being asked to join more and more global or
national working groups with your business peers in other locations, some of
whom you've never even met. What is the best way to work together to share
common knowledge and drive toward common goals? ECM vendors and knowledge
management (KM) specialists often give the same answer: collaboration
solutions. Yes, but towards what end?
Background to the Problem
For teams that are global or even national in nature, it's very expensive and time consuming to meet face-to-face. Sometimes it borders on impossible. Though many experts recommend at least a quarterly face-to-face meeting (as possible) for distributed project teams, this still means that the bulk of the meetings will be done via telephone or videoconferencing. These meetings are usually intended to review progress and discuss next steps -- the bulk of the work is done outside of these working groups. (In fact, the latest issue of the Harvard Business Review supports a suspicion I've had about remote teams: that they can actually be much more productive than groups that meet daily face-to-face.)
For those critical between-meeting times, teams rely frequently on e-mail and instant messaging, but these "discussions" are not usually archived in a meaningful way, cannot typically be threaded or organized properly for later group use, and -- at least in the case of e-mail -- can present severe version-control problems for the ubiquitous attached documents.
To streamline this process, business teams have been clamoring for a way to share files, comments, messages (with or without attachments) and discussions effectively, and then interact -- both with each other and that content. This presents a chance for technology to solve an actual business problem and perhaps even make some improvements to the current business process. Enter collaboration solutions.
There are two major goals of any collaboration initiative:
- Enable your employees around the world to easily collaborate; and
- Be able to share that output with the rest of the organization.
In my opinion, this order is significant. The goals of collaboration should first be to allow knowledge workers to labor together to complete projects and only then to collect that knowledge to be leveraged for the rest of the enterprise. Too many collaboration technology implementations are led by a knowledge management team that may have reversed the order of those two priorities. This can contribute to an over-engineered, failed project because the process for contributing and classifying content is so cumbersome that workers bypass the million dollar solution for another, simpler one that works.
Pilot First
The market is full of vendors eager to peddle their latest quick-fix collaboration solution (more about some of the larger ones below). Alhough some IT organizations are more than eager to throw a few hundred thousand dollars at the problem and hope that it goes away, I wouldn't recommend this approach.
Before you go and blow your entire budget on a solution that has the same likelihood of success as a manned mission to Mars in the same timeframe, consider piloting an open source solution with a small group that is in dire need and eager to get started. This will allow you time to build your business case, learn some hard lessons about usability, and also make essential improvements to business processes in anticipation of other groups. You will also quickly discover the sources of any network connectivity problems and have an opportunity to solve other persnickety (but potentially prohibitive) technical problems before rolling out a full-blown solution globally. A small sample of open source groupware tools available are: dotProject, eGroupWare, Moregroupware, phpCollab, PHProjekt.
Once you've piloted this process with a few teams, you will have received plenty of feedback to now make an informed decision about your organization's needs. This kind of feedback is invaluable to your business case for rolling out collaboration services across the enterprise.
One potential problem with this approach is that the initial pilot participants may rebel at converting to an enterprise standard package later. Maybe you shouldn't force them. But if you do meld them back into the borg, this is still better than implementing a full-blown collaboration system from the get-go (at a likely cost of high six-figures or more), only to discover that it wasn't the right tool. Your pilot team would need to switch either way. (I know of one large enterprise that had to jettison a well-known collaboration package after initial user training because it didn't support a belated but essential requirement for an offline client.)
Key Software Players
Perhaps your starting point for enterprise collaboration is enterprise content management (ECM). There are only a handful of commercial players in this space that enable serious integration to an enterprise content management system -- the most notable are Lotus Workplace, Documentum eRoom, Interwoven Worksite (formerly iManage), Vignette Business Workspaces (formerly Intraspect), and OpenText LiveLink.
You could also investigate the literally dozens of other collaboration solutions, most from small companies, but some from very large vendors, like Oracle's Collaboration Suite or even Microsoft Exchange. There are also a few desktop-based peer-to-peer applications, like Groove, that may win you some short-term tactical wins.
Most of these solutions grew out of very specific needs for managing projects and remote teams, and you can sense this in the particular backgrounds of individual tools. For example, some of ECM-based solutions tend to be very document-centric as opposed to project-centric. Or consider Exchange, a multidimensional product that is increasingly customizable, but still largely centered around e-mail. Nevertheless, these 800 pound gorillas fulfill a vital need and provide a particular path into your overall strategy.
Groove (developed by the creator of Lotus Notes, Ray Ozzie) has been around for a while and merits citing as another example. For some organizations this tool can offer quite a lot of functionality for a very low cost. Because Groove is pure peer-to-peer without a centralized server, the package is able to offer one feature that you can find in many document management systems, but much less so in collaboration products -- off-line access. This is of enormous value to those employees that are a part of the Groove space -- but to employees that are not invited (Groove's licensing is by user), those documents are just documents sitting on your hard drive -- unable to be seen by the rest of the organization. If your company has, or is planning, an enterprise content management strategy, this is one of the major drawbacks of Groove.
The Challenge
Whatever the limitations of Groove and similar systems, I believe the need for collaboration is more tactical than strategic. Your first challenge is to deliver on practical needs for collaboration, albeit without loosing sight of broader strategic goals.
Sure, working tactically has its drawbacks. Remember the days of wild-wild-west intranets? Every department had a website that some underpaid employee administered from their local machine via FrontPage. It's true that electronic collaboration in your organization could easily go the way of corporate intranets circa 1995. Maybe it already has. But this is one extreme.
The other extreme is, regrettably, just as prevalent. Let's say your company has a content management strategy. Now you may have to deal with a different problem -- that your ECM tool does not provide an adequate, or practical-enough solution for project-oriented collaboration. Departments may have access to the enterprise collaboration tool (sometimes a warmed-over DM system), but the process to insert a document to the repository is ridiculously daunting.
This problem often comes in the form of onerous metadata requirements, which are useful for the enterprise and zealously promoted by some KM gurus, but a big hassle for collaborative workgroups looking to complete a simple project. Tagging documents and storing them properly in a proprietary repository can be so time consuming that employees will just bypass the collaboration tools and go for what works. I've seen people collaborate via Yahoo! groups because of the time it takes to contribute a single document to the authorized collaborative space. Others get even cleverer and utilize another corporate tool, Microsoft NetMeeting, sending each other files via NetMeeting to bypass the low megabyte levels on their corporate email systems.
I've even seen editors get so frustrated with difficult-to-learn (and impossible-to-master) content- and document-management implementations that they resort to printing all documents and faxing changes back to the original author. Their argument: "It works and it doesn't take me an extra hour to do it." I feel their pain.
Can't we make both collaboration and contributing to the corporate knowledge base easy? Because of overcomplicated metadata requirements and document management tools still in their infancy, some enterprises are making it more difficult for people to contribute knowledge. The business process gets defined by the limitations of the software and over-ambitious categorization goals.
In my opinion, an important success factor for collaboration tools is having a seamless integration path with any content repository -- this could be something as sophisticated as a major ECM system or as simple as a shared drive. I'm not saying that KM specialists always push gargantuan collaboration solutions on the enterprise -- just that the focus, in my opinion, should be more on practical collaboration and less on building a definitive knowledge corpus.
Recommendations
OK, enough rant. Now some practical advice.
- Pilot a collaboration tool with a few groups that are motivated and eager to try something new -- ideally in a way that may help solve some larger problems for the corporation.
- In exchange for supporting their teams, pilot participants will offer to provide you with both positive and negative feedback about the process and the technology.
- Take this feedback and incorporate into your business case and subsequent requirements documentation if you go for an enterprise solution.
- Measure your success both in terms of the effectiveness by which people complete projects, as well as their ability to share and leverage knowledge.