Our collaboration project did not start out as a quest for ways to deploy fancy new Web 2.0 technologies like wikis and blogs.  It began as a set of management issues.  Our systems were growing in number and complexity and, mercifully, our technology team was also expanding.  We had more projects to do and more people to work on them.  As our workload and staff grew, however, our old methods of sharing knowledge — documents, spreadsheets and word-of-mouth — became increasingly inadequate.  We could not get quickly the information people needed to move forward on tasks.  We had to find new ways to collaborate.

As we examined the issues facing us, three stood out:

• Knowledge Sharing.  There were many times when an employee would encounter a problem and have some vague memory that "someone" knew "something" about the problem.  Unfortunately, they usually could not remember who knew it or what they knew.
• Collaboration.  We needed to find a tool to help us manage smaller technology projects.  Many of the projects on which we work are too small for full-blown project management tools.  We still, however, needed some centralized location where we could collaborate on them.
• Documentation.  We were struggling with documenting our systems.  We would put enormous effort into preparing Word documents.  Then, when we needed to reference them, we'd discover they were difficult to find and frequently out-of-date.

Once we defined these issues, we began to look at different collaboration tools.  For most law firms, document management systems (DMS) provide the basis for internal collaboration.  The process of creating documents and then "profiling" them with additional metadata provides a simple and highly organized means of collaboration that works quite well for work on legal documents.

Beginning with DMS
The DMS model, however, works much less well for the kind of collaboration required by our firm's technology team.  For years, we had been trying to develop system documentation by working within the confines of our DMS.  We created Word documents and tried in various ways to organize them by "clients" and "matters."  However, we found this methodology inflexible.  The information in the documents quickly became stale, and keeping them up to date was extremely difficult.  We also found that document-centric methods did not work very well for documenting complex systems.  Systems are, by their very nature, interlinked; servers run software and software runs on servers.  We needed a tool that would allow us to link easily from one document to others.

Next Step:  Wikis
As we started looking at new technologies, the flexibility and ease of use of wikis immediately caught our eye.  A wiki would provide the kind of flexibility we needed for our documentation and allow us to create pages that were easily interlinked.  Unfortunately, the pure wiki software we evaluated was, in many respects, too flexible.  We found that one can end up with a huge, flat Web of pages linked to other pages without enough internal organization.

The anarchic nature of a wiki made it very difficult to build the structure we required.  What we really needed was something in between a document management system, with its isolated and highly organized documents, and a wiki, with its ability to create and edit information easily in an ad hoc and unstructured manner.

The Solution:  An Enterprise Wiki
We found such a product in Confluence, which bills itself as "an enterprise wiki."  Published by Atlassian software (www.atlassian.com), Confluence is a reasonably priced application that provides, in our opinion, the best of both worlds. It gives us the flexibility of a wiki but, at the same time, allows us to organize our information to make it easier for users to find what they need.

Confluence is organized around the concept of a Space, which they define as "independently-managed wikis."  Each site can have multiple Spaces, which provide a level of organization and have their own home pages and security.  Each Space also has its own "News" section, which is essentially a blog.  Additionally, everything in Confluence is RSS enabled, which means each Space has its own RSS feed, and users can even create custom RSS feeds that bring together information from multiple locations.

At the center of Confluence is the dashboard.  The dashboard contains a list of all of the Confluence Spaces as well as a list of recently updated pages.  Just going to the main Confluence page, therefore, gives the user an immediate view of all of the site's recent activity.

Once users get into a Space, Confluence becomes more like a pure wiki.  Users can use wiki markup text to author text on a page and easily create new pages on the fly simply by enclosing the name of the page within brackets.  Authors can also attach files to pages and refer to them on the page either with a link to open the file or with a thumbnail of the file itself.

Addressing Our Management Issues
We used Confluence to address our main collaboration issues by first setting up three types of Spaces.  First, all members of the technology team have a personal Space, in which they can keep information they need and would like to share with the rest of the group.  The news section of each person's Space functions as his or her own blog, and team members are encouraged to blog daily.

Second, we have a number of project Spaces.  These Spaces are devoted to managing and documenting particular projects.  As people work on a project, they can enter notes in the Space's blog, create system documentation on the fly and attach Visio diagrams, PDF reference material or any other files related to the project.

Third, we have Spaces that are dedicated to system documentation and policies.  We have a server Space with a home page listing all of our servers.  This list has links to individual pages for each server.  With each server having its own wiki page, it is easy to record changes made to a server or notes about service calls, etc.  We have similar Spaces for the firm's software and for our disaster recovery guide.

Other documentation Spaces, like our Daily Check Space, record the regular checks our engineers perform on the system.  Each day a page is created that has checklists to be completed.  Our engineers complete the checklist items and enter comments on the page to indicate anything out of the ordinary.  When the daily check is complete, it appears in the IT director's RSS viewer, and he can see exactly what is going on with the network.

All in all, we have found Confluence to be an incredible tool for internal collaboration and knowledge sharing.  It provides a single place for team members to post information; it makes it easy to create and update system documentation as systems are developed; and it gives us a single place to go for all of our internal documentation and policies.

The technology itself, however, does not create collaboration.  It just makes it easier.  It is still necessary to foster a culture of knowledge sharing and communication so people are constantly thinking not only about doing their work, but also about documenting it.  Developing that collaborative culture requires what I call "wikEvangelists," people who post prolifically and encourage others to do so.  They have contributed to our successes with Confluence by always asking one question:  "Is it on the wiki?"

About our author . . .

Monroe Horn is the Chief Technology Officer for the Boston law firm of Bromberg & Sunstein LLP, where he manages the information technology and litigation support groups and works as a consultant in the firm's electronic discovery practice.  He has previously served as the New England Regional Vice-President for ILTA and has presented at the ILTA annual conference and on ILTA webinars.  Monroe earned his BA and MA in history from Harvard University and taught history at the collegiate level before entering the field of information technology.   He can be reached at mhorn@bromsun.com.