Collaboration Cast

Collaboration,Collaboration News,Collaboration Podcast,Collaboration Research,

I would like to thank all of you for your support and interest in Collaboration Blogs. I have received many requests from you to expand my offering and provide more industry news and information. In response to your request, I have decided to launch a larger news service called Collaboration Cast (www.collaborationcast.com). The purpose of Collaboration Cast will be to continue covering collaboration technologies, but in addition to blogs we will offer additional broadcasting and information features such as: podcasts, an expert locator, product guide, highlighted research ,and a job board. The first release of Collaboration Cast is already available, and we will further integrate Collaboration Blogs in the next few weeks.   Let me know what you think and if you have any interesting news stories I could share. Also, I hope to post all your bios in our expert section.  Thanks again. 

While working at Novell, I led an initiative of trying to find a web conference vendor that would help us cut our web conference costs. I created my RFP (Request For Proposal) and sent it out to many web conference vendors. When the RFP came back, I was amazed to see how expensive it would be to purchase a web conferencing system for our 5000 person organization. Not only was the software expensive, but the consulting needed for implementation, training, and support was also very expensive. The lowest bargain I found was for $200,000, and the most expensive bid was for one million dollars. $200,000 was truly a remarkable deal compared to the rest of the vendors. Maintenance and upgrade protection was 15% of the cost: a significant price to pay yearly for the system.

Since leaving Novell, I have seen how easy it is to build a simple web conferencing tool that will meet the needs of 80% of a team’s requirements. Several people have built such tools on their own or with a team of two or three developers. Some examples of people who have built such tools include:

WebHuddle (www.webhuddle.com) - An open source web conference that was built by John McCaughey. John built the WebHuddle all by himself. WebHuddle was built in Java, is cross-platform, and does not require any downloads. WebHuddle is currently free and its source code is GPL.

Huddle (www.huddle.com) – A flash web conference system developed by an outsourcing company who works for Novell. A small number of developers, while I was at Novell, started building Huddle to meet some of Novell’s web conference needs. Huddle was first used for internal large group presentations and was slowly perfected. Unfortunately, at the time of the evaluation, the tool was still under development, but it has become a lot better and Huddle has successfully sold monthly subscriptions to small to medium businesses.

AV Chat (avchat.net) – A flash based web conferencing tool with Desktop sharing that was built in Romania. An unlimited license will cost you $299. AV Chat has desktop sharing: an impressive feature for a flash based system.
The most impressive of them is Openmeetings (http://code.google.com/p/openmeetings/): a web conference tool Sebastian Wagner built by himself in a few short months that already includes Video, Audio, Whiteboard, Document Importing, Invitations, and Public and Private conference rooms.

1VideoConference (www.1videoconference.com) - A peer-to-peer web conference system that is open source. They have integrated their product with Asterisk, an open source voice conferencing and PBX system. A team in India built 1videoconference. The open source project has 11 developers signup for the project.

These projects challenge the decision of paying $200,000 to half a million for a web conference system. It may be a very feasible strategy to use internal developers or outsource development to build a web conference system for your organization. Just the yearly maintenance cost alone could pay for a team who could manage and improve your own web conference system. Many of the above mentioned companies and individuals are willing to build such a system for your company.

My first article for Collaboration Loop back in January provided an overview of various Open Source collaboration tools that can provide enterprise or small business teams with a low-cost collaboration system.  Since then, I have discovered several Java-based Open Source collaboration tools that provide good portion of an enterprise’s collaboration requirements at a minimal cost.  Currently this suite is more of a vision — implementataion takes some development and integration effort. But as stand-alone products, these tools work well to support different business processes.The following list is not a comprehensive list of all of the Java-based Open Source collaboration tools, but provides some important components an enterprise or small to medium business may choose to implement in order to meet their collaborative requirements.

1. Liferay Portal. Liferay is a Java portal that has an AJAX interface that allows users to customize their user interface by dragging and dropping portlets.  Liferay has a good number of out-of-the-box portlets.  Specific collaboration portlets include a calendar, wiki, and blog functionality.  Liferay also has integrated with Alfresco, an open-source-content-management product.  When building a collaboration application, developers can use Liferay as their front end, which will allow the developer to take advantage of a granular-security module, skinable-user interface,  AJAX-interface framework, and portlet architecture.

2. Alfresco. Alfresco has created an Open Source, Java-based content-management system. Currently, Alfresco is best suited for document management, but the developers are working on a full suite of content- management functionality.  Users can create team workspaces, discussion forums, set up a simple workflow, and customize templates.  Alfresco supports object-level security access and the application has a skinable interface that developers can either build upon or modify. Stay tuned for future releases of Alfresco that will allow you to manage your content in a simple and easy to use manner.

3. uEngine.  Using Liferay, Twister (an Open Source workflow engine), a workflow designer, and a form designer, a Korean engineer put together an application that allows individuals to design their own workflow that can include custom forms, IM and email reminders, other application tie-ins, and a portal interface.  Companies who would like to create their own workflow process with minimal development that includes the use of different collaboration functionality, should consider using uEngine as a way to simplify collaborative-process automation.

4. Web Huddle.  Web Huddle is the leader and pioneer in Open Source web conferencing and collaboration tools.  Enterprises can leverage Web Huddle’s desktop and presentation-sharing functionality within a business process by integrating with other enterprise and collaboration applications. Additionally, Web Huddle fulfills many of the basic real-time collaboration requirements a user would expect from a web conference tool.

5. Collanos. A cross platform peer-to-peer competitor to Groove. Collanos provides a collaboration client that was built on Eclipse and uses different Open Source components.  Users can access team workspaces, start discussions, and have IM conversations. One can also store documents, messages, IM conversations, and discussions in their workspace.

6. Exadel.  Exadel provides a suite of development tools and a framework environment built on Eclipse.  Exadel’s mission is to help developers speed up their development process; it’s very similar to proprietary technologies such as Adobe Dreamweaver. The environment is also designed to help people exploit AJAX functionality and speed up AJAX development time.

Companies adopting these products could choose to use Collanos for their collaboration client and work-in-progress document management system.  With some integration, they could synchronize their files with Alfresco, which would be used as the central online data store for document and content management.  As Alfresco enhances their content management capabilities, users can use Alfresco and Liferay for their intranet, .com, and content management system.  Additionally, users can use Liferay’s wiki and blog functionality for online collaboration.  For real-time collaboration needs, users can use Web Huddle, and for more custom business process requirements, users can use uEngine which should be able to tie together systems such as Collanos, Web Huddle, and Alfresco.  Optimally, Exadel should save development time, ease integration efforts, and allow developers to take advantage of AJAX to deliver an improved user experience.

This scenario is not going to work “out of the box” — it would require custom development and assistance from vendors.  But the costs could be more manageable and significantly lower over time, especially if your organization can build expertise in these products.  Users will need to do the evaluation and weigh the cost and benefits of this approach.  For companies that want to invest less money up front but can invest the necessary development resources, this collaboration suite could be a good starting point.

In addition to the above technologies, you can also look into these products:

Email:

• Hula
• Zimbra
• Thunderbird
• Evolution

Instant Messaging:

• Jabber

Telephony:

• Asterix
• SipX

Browser:

• Firefox

Storage/Backup: 

• iFolder

Companies which cannot afford expensive collaboration tools but which have development resources should consider these kinds of alternatives.  Additionally, system integrators who would like to provide customers with a suite of lower-cost collaboration tools may choose to undertake the integration.  Open Source software providers may also benefit from doing a lot of the integration because  they will be able to increase their value and expand their opportunities with existing and potentially-new customers.
I am sure you will find additional solutions that I was not able to cover in this blog.  Please feel free to share your findings in the comment space below.  The Java-based Open Source collaboration tool market is taking off.  My bet is that this segment of tools will continue to improve and new products will be added.  The continued support of integrators such as Cignix, Enomaly, and Novacoast, as well as software companies such as Novell, Sun and IBM will help solidify the suite’s offering and integration between products in the suite.

Today, most team-based collaboration tools are browser-based.  This makes sense from a development perspective, because it saves the developer both money and resources.  Today there are few client-based solutions, and the ones that exist are not very advanced (with the exception of Groove).  I think Microsoft’s grip on the desktop has forced companies to take an alternate strategy and produce browser-based solutions.When talking to sales people from various collaboration vendors, they tell me that customers always request an offline client.  This begs the question, “Is a client-based collaboration tool preferred over a browser-based tool?”  Here is some history to the debate, my thoughts on what customers really want, and how vendors should evolve their products to meet their customer’s offline and online collaboration needs.
One of the most prevalent and commoditized collaboration software technologies today is email. People use email to communicate and collaboration daily with other users located in their same building and across the world.  My experience and interviews have validated that users still predominantly depend on a client such as Outlook, Lotus, or GroupWise as their primary platforms for collaboration.  Some new email products have emerged that are just browser-based, but most customers still prefer a client that allows them to store and access their emails offline or online.  Collaboration companies, such as Microsoft, have attempted to integrate their systems with their email client, but the task was not very easy.  Also, companies like IBM overwhelmed their users with functionality that users end up not using.  Some specific problems these companies encountered included:

• Technology design. The email client was designed around an individual and the emails were focused around individual communication — a very different paradigm than a system that is designed to fit the needs of a team.

• Challenging user experience. Building team capabilities into an user-centered messaging platform confuses the user and does not facilitate team collaboration.  Users felt they already had too much information and functionality to handle with the current email system, and having to spend more time going through extra steps to take advantage of the new team functionality was not optimal.

• Product architecture. Some email systems were not built to accommodate additional collaboration technology and adding new features would slow down the system and increase the complexity.

Consequently, vendors started to create new systems that focused only on collaboration.  The thinking was that users already had one client and would not want two clients, but would want to have their dominant mail client integrated with other collaboration systems through links, shared interface features, or portals.  Also, the prevalent thought was that users would participate in multiple collaborative environments, such as email, instant message, web conference, office application, and enterprise applications, and that an online system would best support this integration.

Today this is the prevailing view, and several vendors have started to tie into Microsoft Office (Interwoven), Open Office (O3Spaces), Exchange (Open Text and SharePoint), instant messaging clients (WebEx and AOL), and others. The amount of work required to tie into different systems became very costly to accomplish and standards never were created to facilitate integration and interoperability.  Although vendors continue to integrate their products, acquire new technologies and improve their online experience, customers still continue to ask, “Do you provide an offline client?”

After pondering this unfulfilled desire, I have come to believe that vendors should approach the problem in a different manner if they want to fulfill their customer’s needs.  Instead of continuing to support the idea of integrating multiple collaboration systems, vendors should focus on redesigning the messaging client that (1) focuses on a team member’s collaboration needs, (2) allows users to read their messages through a collaborative view, and (3) integrates with online collaboration systems and other systems that the user may require.

If vendors could provide users with a single client that would fulfill their collaboration and messaging needs, then the messaging clients would cease to exist and users would spend most of their time in the collaboration system — which would increase collaboration and knowledge sharing.  Maybe then users would be satisfied?  But to achieve this goal, a vendor needs to recreate the client.  This is a different philosophy then the one vendors are using today.  Many are trying to get away from the client, or copy the functionality of current clients within a browser.  This paradigm is a shift to the market’s current direction, but I believe that the first to market with this new product may gain an advantage and replace many mail systems.

To further illustrate, think of a collaboration client that would organize your environment by project and include a personal space for a user’s individual needs.  Emails sent to the client regarding a specific project would be automatically filed within the projects’s workspace, and subscription messages would be filed into a workspace specific to the type of content included in the message.  Filing emails into workspaces would allow users to view the emails in context, access additional content included in the workspace, contact a team member, view who is online, and immediately react to the email by creating a team task, appointment, or starting a real-time meeting.  Personal messages would be sent to the user’s personal workspace.  Order would be kept via workspace categorization.  A summary view could also be provided via RSS feeds to the personal workspace dashboard that would allow user to filter and prioritize received information and content changes.  An intelligent, well-organized, context-based, feature-rich, and knowledge-friendly system would be the result of this integrated and collaboration-focused client environment.

There are eight vendors today that could lead this client evolution:

1. Microsoft. Microsoft’s acquisition of Groove places them as a runner up, but it seems like Microsoft is investing little resources in this Groove transformation.  For now they are focused on their SharePoint and Live Office product releases.
2. IBM. IBM seems to be investing considerably in their Workplace Managed Client.  Email has already been integrated with their client.  IBM’s hope is that the new managed client will provide existing Lotus customers a superior option to IBM’s competitors, if the customer chooses to migrate off of Lotus.  Clients, especially IBM customers, should consider IBM’s Workplace Managed Client as an option.

3. Google.  Google’s desktop client, which primarily focuses on content and search, can be positioned for collaboration.  Especially since Google has a calendar, email, word processor and other tools and content that could come together within a new client.

4. EMC. EMC’s eRoom has several offline file capabilities and could be extended and modified to fit this offline client experience.  The question is whether EMC will make Documentum their priority, thereby squeezing resources and smothering innovation in their eRoom product.

5. Collanos. A new start-up, Collanos is building a heterogeneous collaboration client similar to Groove.  Collanos seems to have a good start, but their product team may not have sufficient collaboration experience to pull off this paradigm change.  Only time will tell, but at least I think they will be purchased by an existing collaboration vendor to develop their offline collaboration client.

6. Kubi Software. Having been around as long as Groove, Kubi Software offers a peer-to-peer client that is integrated with Outlook.  Kubi has found its niche in servicing the sales force.  Their dependence on Outlook and Windows has niched them to a market and to a platform that may limit their ability to lead the client revolution.

7. Foldera. As a well funded start-up, Foldera brings together smart email and collaboration features into one platform.  Currently their product is in a limited beta, but recent reviews seem to point to a successful product that will unify collaboration and email.  Their current plans seem to include browser access and a possible client could be in the works.

8. Virtual Global. Virtual Global has a thick client, but the platform is strongly tied to .Net and does not have peer-to-peer capabilities.  Virtual Global will probably stay focused on online-based collaboration.

It will be very interesting to see how the offline collaboration client will develop and whether we ever shed the enterprise email client.  My bet is that we will, and one of these eight vendors (or possibly a new vendor) will provide the solution. My belief is that the pendulum will swing again, and the days of the collaboration client will return.

A few months ago Money magazine published an article on how Bill Gates works.  Several people since then have written articles and blogs describing how they work.  I would like to add my two cents to the current stream of articles by not describing how I work, but how knowledge workers would like to work.   Most of my thoughts are based on over 80 interviews asking enterprise level employees how they would like to work.  My goal was to document requirements around collaboration and what the future state of collaboration should look like.  Here are some of my findings.

A Standardized Collaboration System

The number one requirement users have is that they want a single collaboration environment that they can use to collaborate with their team members, partners, and customers.  Two things upset users: (1) not having the proper tools to collaborate efficiently and (2) having too many tools that do the same thing.  A standardized system that could be used for team asynchronous and synchronous collaboration was the first step that would make knowledge workers satisfied.  The standard system should provide the following functionality: task management, calendars, document management, forums, membership management, access right management, web conference, and instant messaging.

Content Management Is Equally Important

In addition to having a standard collaboration workspace, users want content management functionality.  When teams are created, users also want to create different content pages to support their projects.  The majority of users tend to be visual and they would like to create content pages that include graphics.  Additionally, they would like to incorporate their collaboration functionality into content pages.

Super Users Want Full Control

Technologically advanced users and business-process owners have specific requirements regarding their desire to become less dependent on IT and developers.  Process owners want to be able to create workflows and forms that allow them to create, manage, and improve their department’s processes.  Having the ability to control a collaborative workflow, manipulate data capture, and integrate the collaboration system with enterprise systems from companies like Oracle/PeopleSoft and Siebel, with without requiring development, is a dream state for a process owner.

Expert Location and Content Delivery

After meeting their basic collaboration and content management requirements, the  next desire of both users is to extend the collaboration and content management system to locate experts and support advanced search features.  Users want one search engine that integrates with other enterprise systems and lets users search for experts based on the content they produce and association of user data from enterprise systems such as PeopleSoft, resume repositories, and so on.  Additionally, users want to be able to easily trace the content of their search.  For example, knowing where a file resides within the folder hierarchy can add context and lead to the discovery of additional resources.  Finally, users want content delivered to them as it is made available, such as through an RSS or Atom syndication feed.

Data Integration and Personalization

Once users can collaborate, post and manage their content, easily search for content and experts, and receive content updates, they would like to integrate the data stored in repositories with the rest of the collaboration and content management system.  Users ultimately want a dashboard that they can manage whose components can be manipulated in a portal environment.  Users want a portal dashboard that can be customized and can include the content, data, and collaboration tools they need to get their work done more efficiently and effectively.  Users want to drag, drop, and manipulate different gadgets on their portal page.

Simulating Face-to-Face Interactions and Efficiencies

Finally, users want to integrate presence throughout their collaboration and content management environments, so team members can stay in touch with their colleagues wherever they are in the workflow process.  While working on a document, one worker would like to track the online presence of other colleagues working on the same document.  This lets people send messages, get feedback on the document, ask questions, and so on. Simulating the physical presence lets users benefit from the conversations, interactions, and relationship building activities that face-to-face interaction provides.

How Knowledge Workers Would Like to Work

Now that I’ve laid the ground work for the ideal collaborative environment, I will attempt to summarize things: Users want a collaboration system that they can create and customize themselves; one that provides the right data, content, and tools that will make them most effective in a virtual environment, but will simulate a face-to-face team setting; and one that pushes interesting and pertinent content to the user rather than having to be located by the user.  Such an environment is a knowledge workers dream — and the future.

Several weeks ago I attended Gartner’s conference on portals, collaboration, and content management. There I had a chance to speak with over 50 different customers who were looking to solve problems that included collaboration. Many of them were just starting their efforts and were very happy to receive guidance from Gartner on how to start their enterprise projects. But several customers needed more assistance in understanding how to start a collaboration architecture project that would lead to a deployment roadmap. So I thought I would provide a step-by-step process you can follow to create your own collaboration architecture and deployment strategy.

1. Create an advisory board to help with the effort. Unless you have been in the company for a long time or have been exposed to all the business units in the business, I think it is a good idea to form an advisory board for the project. Call it a cross-functional advisory board and invite different business process owners to participate. Use the board to measure interest and to help navigate the organization to find groups in the company that are most needy and executives who would be willing to support the project.

2. Gather and document user requirements. With your board’s help, get in touch with different business process owners and participants so that you can gather the businesses requirements. I would suggest for you to focus on the core business processes in your company and interview a wide range of individuals within those processes. It is important that you interview the knowledge workers in the trenches and the executives. As you start your interview process, you will learn a lot about the business and start identifying which business units are in the most pain and have the most passion. Also, you will find out what executive is most willing to support your effort. I recommend recording these interviews and making them available to the whole company.

3. Create the business requirements document. After completing your interviews, it is wise to summarize the business requirements in the form of use cases, and then requirements. Compare the use cases to your company’s goals and objectives and categorize them in such a way that they align. This way you will be able to use your requirements to describe the return on value that a collaboration system would provide the company. Most importantly, you will start to understand and select priority processes where collaboration technologies could make the greatest visible impact.

Once you have your use cases documented, you will find that many of the use cases are similar in their process, but not their context. For example, you may have a business need for a resume repository in the consulting business unit and a request-for-proposal repository in the sales group. Both have different results but the core use case is similar. Take these similar use cases and aggregate them into a high-level set of business requirements. This will give you the basis for the next step: a deep dive into the technical requirements. Unfortunately, most people start documenting the technical requirements first and forget all about the business need.

4. Take your business requirements and transform them into technical requirements. This is where the true architecture work begins. Now that you have your business requirements, you should take those and start dividing them into two categories: What and How. “What” represents the business requirements we are trying to solve and the “How” represents the technical requirements we need to implement to solve the “What”. As you start doing this, you will quickly see that you mixed some business with technical requirements throughout your requirements gathering exercise. You will also fill in the technical requirements missing for all the business requirements. This exercise is time consuming, but it will help you come up with the architecture and understand what applications will need to be integrated to solve your business need. If you get really detailed, you will also understand how applications need to be integrated. Having this detailed understanding will save you a lot of time and money in the actual implementation.

5. Categorize the technology requirements. Once you have finished documenting all of your technology requirements, you will end up with a large list. Take that list and map the requirements to your standard IT architecture. An example would be the standard N-tier architecture. Using a standard architecture will allow you to map your requirements into categories that will prepare you for creating a logical architecture. You should also use this process to eliminate duplicate requirements and to consolidate similar requirements.

6. Draft architecture diagrams. Using the categorized requirements will allow you to create a logical architecture diagram. That diagram will include all the components needed to resolve your business requirements and fulfill your business use cases. The logical architecture will undoubtedly include the following components: portal, collaboration, content management, business process tools, and development tools. Several vendors have architectures that you can use to give you some ideas. Once you have created a high-level logical architecture, I recommend drilling down into each component, such as content management or document management, and create an architecture for each component. Once you have completed this exercise, you will know what solutions and products are required to solve your business needs. These architecture diagrams will be your most utilized tool. They will guide you throughout the rest of the project and allow other groups to understand the required components.

7. Conduct a gap analysis. By this stage in your project you will be very familiar with your business requirements. Also, from your different interviews and advisory board interaction, you will know what solutions your company already has in place and what tools various departments in your company have deployed. Now you can take your knowledge of what is available and compare it to your collaboration architecture. This will give you a gap analysis that will probably be very revealing. For example, you may find a large overlap of products solving a specific need such a team collaboration. These results will help you build a business case for consolidation or standardization.

8. Create your roadmap. With these seven steps completed, you will know the business needs of your organization. Your knowledge of what tools are in place, missing, redundant, and most important, will let you create a road map describing what should be implemented, and in what sequence. Knowing your resource availability will allow you to put together a proposed timeline for deployment. Your roadmap may take several years to achieve, but you will now have a direction. Your gap analysis and business use cases can be used as a business case for each project, and for the whole project.

9. Execute. The last step in the process is to use your roadmap to get executive sponsorship and resources. Then you execute. By this stage in the project, you will have a lot of information to backup your recommendations and you will have some detailed business cases for each of your proposals. Your effort will also reduce the risks for project failure while increasing the chances of immediate results. Good luck.

There are several costly mistakes a company can make when selecting and deploying a collaboration solution.  The primary mistake is a company’s poor understanding of its own requirements, causing it to select the wrong product – which can prove very costly.  Cost overruns can also be incurred during deployment, or after the system has been deployed and its use by employees increases.  Careful precautions taken early in the selection process can keep a project on budget.  Here are four key areas to evaluate during the vendor selection process.1.  Product scalability and performance. Ask each vendor for customer references who have deployed the solution.  When you talk to those customers, see how similar their environment was to your situation. Here are examples of high-gain questions you should ask them:
• What hardware, operating system (OS), and database did you use?
• How many people use the system?
• How many people can log in at the same time?
• How much data can be uploaded into the system by a given number of users?

If the vendor cannot provide you with access to customer that is at least as large as your company, then ask the vendor to provide you with results from their own performance and scalability tests.  There are several labs in North America and in Europe that will perform scalability and performance tests on systems and provide third-party non-biased results.  Without this data, and/or feeling uncomfortable with the test results, can lead to unexpected hardware and software expenses as the system grows to accommodate new users.

Additionally, software integration issues can cause deployment delays, and that in turn can hurt a system’s ability to scale and perform.   I have found that some vendors will tell you that their solution runs on a list of platforms (i.e., operating systems and databases) — yet that doesn’t necessarily imply that their systems will scale or perform equally well on each of those platforms.  When dealing with Open Source vendors, this may be one of the greatest problems you may encounter.

2.  Feature gaps and roadmap alignment. As you start your vendor evaluation you will find that every vendor has their own strength and weakness and none of the vendors have all the desired features.   Vendors will most likely attempt to convince you that their next release will solve your needs.  Understanding a vendor’s future release and roadmap is important, but carefully understanding the current product and its gaps, and aligning your choice with the vendor who can solve most of your needs, will reduce many possible costly risks.

Customers who select a vendor based on promised features incur the possible risk of delayed deployments, unhappy users, and expensive customizations if the vendor is not able to deliver on their promises.  On the other hand, those who select a vendor that fits best with their current needs, but whose roadmap does not align with the customer’s direction, can also incur possible risks, such as outdated and uncompetitive systems.

In order to insure proper alignment between your strategy and a vendor, it is important that requirements are properly documented, current solutions are thoroughly evaluated, and product feature gaps are identified.  Pilots are perfect mediums to conduct your analysis.  Once you understand the shortcomings of the system, make sure to engage the vendor’s product management and engineering teams to ensure roadmap alignment.  Knowing what is needed, what will be delivered, when, and by who will help minimize any potential costly risks from product and roadmap misalignment.  Also, the more informed you are, the more likely you will be able to set expectations with your own customers; consequently, making the project more successful.

3.  Installation, training and customization costs. Several collaboration vendors try to maximize their additional revenue by making their product expensive to customize and to use.  Their thinking seems to be that this will entice channel partners to push their product more, or that it will generate additional revenue down the line from consulting work.  You should keep this in mind as you evaluate different collaboration vendors.  The goal should be to find a vendor who can produce the functionality needed with minimal customization work, and one that has an existing community of users that freely shares enhancements and customizations with each other.

Make sure that installing the product is easy, and that learning how to set up the product and educating users isn’t too expensive.  Some of the knowledge management strategies and methodologies may require consulting, but good documentation can help minimize costs.  By not properly evaluating installation, training, and customization costs and available documentation, you will greatly underestimate potential costs that will come to later haunt you.

4.  Out-of-the-box experience. Some companies are not completely satisfied with a product, yet choose it anyway with the intention of customizing it to fit their needs – sometimes making elaborate changes.  The more elaborate the customization, the more challenging and expensive it will be for customers to upgrade to the newest version of the product.  Consequently, when selecting a vendor, make sure the “out-of-the-box experience” either meets your needs or can be minimally customized to do so.  If collaboration functionality can be easily added to a portal, then this may be the best medium for customizing the product to fulfill the customer’s requirements.    Ensuring that new versions of a product can be easily deployed into an environment can decrease additional development costs.

The more time invested up-front in defining a project and evaluating vendors, the more accurate ones budget and timelines will be.

In my last blog entry, I examined Open Source, asynchronous team-based collaboration systems. Several Open Source vendors were profiled and categorized in terms of their products’ functionality, scalability, integration, and support. Selecting proprietary (that is, non-Open Source) asynchronous team-based systems is a little more complicated, I’m afraid. There are many different vendors in this space, and their products often have similar features. Nevertheless, let’s look at some proprietary vendors and discuss how to narrow your choice.I am sure I will leave out several vendors as I try to categorize the market, but from my most recent analysis, conducted in December 2005, I found 16 prospective candidates. These vendors include: BEA, Collabnet, EMC, IBM, Interwoven, IsoSpace, Kubi Software, Microsoft, Net Documents, OpenText, Oracle, Project-Open, SiteScape, @task, Tomoye, Vignette, and Virtual Global Team Leader.

These vendors can be put into the following three categories:

1. Niche Collaboration Vendors
2. Generic Collaboration Vendors
3. Business Process Improvement Vendors

Niche Collaboration Vendors. Niche collaboration vendors target specific collaboration processes such as task management, sales effectiveness, software development, or outsourcing projects. Companies in this category either started as a consulting company that created an application for a specific customer’s need and then productized the solution, or a company that found a large enough market for their specific collaboration tool. The products are not deployed as enterprise collaboration systems, but more as process-specific systems. If a buyer has a specific collaboration need, limited budget, a self-contained user group, and does not need to worry about the rest of the company, then one of these vendors may be the right fit. Here’s a short description of some of the niche vendors:

• Collabnet. Focuses on collaboration software for software developers and for those contributing requirements to the project.
• Kubi Software. Built a sales effectiveness collaboration system that is integrated with Outlook and allows sales teams to work together on opportunities.
• Net Documents. Has a collaboration system for law firms that require asynchronous collaboration tools with rich document management capabilities.
• Project-Open. Specializes in the collaboration process that companies require for translating information into multiple languages.
• Tomoye. Prides itself on providing a rich collaborative environment for communities of practice.
  Virtual Global Team Leader. Focuses on the collaboration process for government organizations and software development.
• @task. Focuses on the project management process and tailors its collaboration environment to a project team’s needs.

Generic Collaboration Vendors. Generic collaboration vendors include BEA, EMC eRoom, IBM, Microsoft, and Oracle. These vendors specialize in providing collaboration solutions that can virally spread throughout the enterprise. Often these vendors provide a collaboration solution that is either free for a certain number of users or discounted as part of the purchase of another of their products.

The basic collaboration functionality provided by these vendors gives users a good start and experience with a asynchronous collaboration environment and provides teams with a good system, but as soon as several teams need to start sharing and collaborating with each other at a company-wide scale, or when a lot of customizations need to be made, these systems fall short or require the purchase of additional components. Also, these systems do not have the full collaboration functionality found in products sold by the business process improvement vendors (which I’ll cover momentarily). These vendors fall short when it comes to document management functionality (such as check in and out), product scalability, communities, search, and email integration.

The generic collaboration vendors have the most popular and widely deployed solutions and are continuously improving their solutions. As such, several of them might make the leap and become a business process improvement vendor — but my initial evaluation indicates that this hasn’t happened yet.

Business Process Improvements Vendors. Companies in this segment include Interwoven, OpenText, SiteScape, EMC Documentum and Vignette. These vendors are distinct from the generic collaboration vendors in that they provide customers with a rich set of collaboration functionality that can be customized to fit specific business processes that a department may require. These tools provide flexibility: one solution with many applications. The majority of the business process improvement vendors are most successful selling into specific groups within a company that have regulatory needs, content harvesting projects, knowledge management initiatives, and specific collaboration process demands. Customers who deploy this type of solution usually have experimented with several niche or generic collaboration vendors and now need a system that can consolidate these functions to fit an enterprise’s needs. Business process improvement solutions are more expensive than generic collaboration solutions, but can provide a better ROI and greater impact within a company. Some people in a company could be use a BPI product out-of-the-box, while others might construct a customized system that helps optimize a specific process. Yet in both cases, the same application and repository is used, and it’s supported by the same vendor.To help you understand which category best fits your needs, you should decide how much you want to spend, understand the business needs, how the business prioritizes collaboration, and how many users in the organization will use the system. You might start with several niche and general collaboration products within your company, and then consolidate them to a single business process improvement vendor. Or you may want to start with a business process improvement vendor. In my next blog entry, I’ll discuss how to avoid costly pitfalls during the vendor selection process.

It’s a privilege to join the team of bloggers here on Collaboration Loop. I consider myself a collaboration practitioner; I work for Novell as a Senior Knowledge Manager, responsible for the company’s collaboration architecture and infrastructure. For the last two years, I have led a project to help Novell understand its employees’ collaboration requirements and determine what infrastructure would best fulfill them, and to establish a collaboration infrastructure at the company — one that will give us a strategic advantage over our competitors. My work has included documenting requirements and processes, creating a collaboration architecture, conducting a gap analysis of our current collaboration systems, working to secure executive funding and commitment, getting internal organization’s commitment and alignment, conducting a request for information that was sent to thirty six collaboration vendors, conducting several pilots, and selecting a system. In this, and future blogs, I will share my experiences with you. In addition to my experience as a collaboration manager, I am working with Brigham Young University on several research papers on the topic of online communities. My most current paper is on the topic of how to motivate people to contribute to online communities. You can download the paper at http://e-business.fhbb.ch/eb/publications.nsf/id/390. Also, I am an enthusiast of, and contributor to, Open Source collaboration technologies. I will share my findings from this research as well.Let me begin by sharing what I learned from my research on asynchronous team-based collaboration solutions. My evaluation focused on enterprise requirements for these systems, and therefore my analysis is biased towards enterprise IT management. Some of the most popular vendors in this space include Akiva, Alfresco, Basecamp, Drupal, Mayflower, OpenACS, phpCollab, Ramius, and Xoops.

In order to better evaluate these products, I broke them down into three categories:

1. Community-built collaboration systems
2. Mixed-source hosted vendors
3. Enterprise collaboration vendors

Community-Built Collaboration Systems. This category includes Open Source projects like Drupal, Xoops, OpenACS and phpCollab. These tools are developed and supported by a large community of developers. The primary development language used by these projects is PHP. Several companies have adopted these Open Source technologies in their internal collaboration infrastructure. The downside is that they are challenging to integrate, do not include object-level security, and take additional resources to customize. Additionally, because companies must deal with the Open Source community that supports the product, a regular request for information (RFI) or request for proposal (RFP) can be challenging to execute. In the future, you may see these vendors making their way into the enterprise, but for now they specialize in large Internet content and collaboration deployments.

Mixed-source hosted systems. This category includes Open- and mixed-source vendors whose main focus is on hosted applications. These vendors, which include Ramius and Basecamp, have created low-cost alternative to traditional ASPs by leveraging Open Source components. These products are great for departmental collaboration, or for collaborating with external partners and customers. These vendors don’t provide a downloadable version of their product, hence development kits are not available and customization generally isn’t possible. My perspective is that as these vendors perfect their products, they will offer enterprise versions of them.

You have a better chance of getting these companies to reply to an RFI or RFP than with community-supported Open Source tools, but basically it’s “what you see is what you get” with these tools. You can submit requests and the vendors will add it to their development queue, but their core audience is the larger non-custom market.

Enterprise collaboration systems. This category includes vendors that provide solutions targeted at the enterprise customer. Vendors include Alfresco, Akiva and Mayflower. Less than a few years old, these companies provide a low-cost solution equivalent to that of the big enterprise collaboration vendors. Their business model differs from that of Open Source solutions since they employ developers to build their products, and rely on the community to test their products and provide the requirements. These companies are primarily Java based, abide by open standards and release the majority of their platform to Open Source. Trying to get an RFI or RFP reply from these vendors can be very challenging as well, unless you are seriously interested in purchasing many licenses of their technology.

In my next blog entry, I’ll cover non-open source asynchronous collaboration vendors and provide a similar categorization that can help potential buyers to better narrow their vendor analysis.