Design Principles / Foundational Thinking / Learning From Others / Social UX / User Centered

Wanted/Needed: UX Design for Collaboration 2.0

Posted by

No current software supports the full process of collaboration.

That’s a bold claim, and I hope that someone can prove me wrong.

This article is more of a “Working Towards …” position paper than the final word; written in the hope that the ensuing discussion will either bring to light some software of which I’m not aware, or motivate the right people to develop what’s needed.

There is plenty of hype about “Collaboration 2.0” at the moment, but the bugle is being blown too loudly, too soon. Take, for instance, the Enterprise Collaboration Panel at last year’s Office 2.0 Conference. Most of the discussion was really about communication rather than collaboration, with only a hint that beyond forming a social network (“putting the water cooler inside the computer”) there was still a lack of software that actually helped groups of people get the work done. What’s missing from the discussion is any formulation of what the process of collaboration entails; there’s no model from which collaborative applications could arise. If we can figure out a model then we in the UX community should be able to make a significant contribution to it.

I want to start this discussion by proposing a model for collaboration1 that links the various elements of collaboration, comment on the so-called “collaboration software” currently available, and make some tentative suggestions about IA and UX requirements for a real collaboration platform.

A proposed model

Definition

Collaboration is a co-ordinated sequence of actions performed by members of a team in order to achieve a shared goal.

The main concepts in this definition are:

  1. Collaboration is action-oriented. People must do something to collaborate. They may exchange ideas, arrange an event, write a report, lay bricks, or design some software. To collaborate is to act together and it is the combined set of actions that constitutes collaboration.
  2. Collaboration is goal-oriented. The reason for working together is to achieve something. There is some purpose behind the actions: to create a web site, to build an office block, to support each other through grief, or some other human goal. The collaborators may have varying motivations, but the collaboration per se focuses on a goal that is shared.
  3. Collaboration involves a team. No-one can collaborate alone. Collaboration requires a group of people working together. The team may be any size, may be geographically co-located or dispersed, membership may be voluntary or imposed, but there is at least some essence of being part of the team.
  4. Collaboration is co-ordinated. That is, the team is working together in some sense. The co-ordination may follow some formal methodology, but can equally well be implicit and informal. There needs to be some sense at least that there are a number of things to be done, some sequences of actions, some allocation of tasks within the group, and some way to combine the contributions of different team members.

Components of collaboration

Any collaboration process involves interactions between six elements, as shown in the following diagram:

The basic components of collaboration.

Figure 1. The basic components of collaboration

Artifacts

The Artifacts are the tangible objects relating to the collaboration. They include the outcomes of the process – the office block that progressively gets built, the web site that finally gets commissioned – as well as a variety of objects that were used along the way to promote, direct and record collaboration – such as design documents, project schedules, and meeting agendas.

Team

The Team element includes the collaborators and the interactions between them: Team membership and authorization, inter-personal dynamics, personal identity, decision making processes, and communication.

Tasks

The Tasks element includes the list of things to be done in order to reach the goal, along with all the processes necessary to manage that list. How do tasks get formulated? How is their status recorded and tracked over time? How is the list prioritized and scheduled? How are tasks assigned to team members and how are personal ‘To Do’ lists presented?

Calendar

Most collaboration is extended across time, and consequently requires some degree of time-management: setting deadlines, milestones and task completion dates; scheduling team meetings; and keeping an historical record of events.

Actions

Team members perform Actions based on the Tasks assigned to them. The Actions might just involve searching or viewing the Artifacts, but more typically mean modifying the Artifacts in some way. There might also be some meta-Actions such as maintaining the Artifact repository, keeping a log of Actions and commenting on the Artifacts.

Resources

Resources enable the Team members to perform the Actions. They include physical equipment, money, external advice, and all manner of software (project management, Wiki, spreadsheet, and content management systems, among others).

The current state of collaborative software

There are three primary ways in which humans interact: conversations, transactions, and collaborations. There is plenty of software that enables conversation–email, VOIP, chat, IM, forums–and plenty of software for transactions–eBay, PayPal, internet banking, shopping carts. But what is available for collaboration?

There are many software applications that seek to enable collaboration2. But let’s see what happens when they are evaluated under these three categories:

  • The extent to which the software provides the required functional components (i.e. the boxes in Figure 1)
  • The extent to which the software supports the interaction between those components (i.e. the lines in Figure 1)
  • The usual criteria that apply to all software , such as ease of interaction, security, integration with other applications, and so on.

It is true that there are software packages for most of the individual components of collaboration:

  1. Artifacts: we have software for maintaining and accessing a repository of digital Artifacts (e.g. any number of CMS applications–well-established ones like Documentum or Stellent, more recent one’s like Joomla! or any of the 925 others listed at The CMS Matrix), and we can easily construct databases for tracking the status of non-digital Artifacts.
  2. Team: software for maintaining team membership, facilitating group-based decision support, and managing remote meetings (e.g. WebEx) and video conferencing. There is even some possibility that virtual worlds like Second Life may provide an effective environment for team interaction. In Growing Pains: Can Web 2.0 Evolve Into An Enterprise Technology?, Andy Dornan quotes a business manager as saying that “Second Life allows more user engagement than traditional video or phone conferencing.” I know of one company whose preliminary experiments with Second Life found that there was a more relaxed and open interaction via avatars than when a team interacted face-to-face.
  3. Tasks: software for maintaining task lists (e.g. Jira, ScrumWorks); task dependencies and scheduling, Gantt Charts (Microsoft Project, @task); brainstorming; workflow and process modeling; and others.
  4. Calendar: Microsoft Outlook (along with Microsoft Exchange Server so that the calendar is shared), Google Calendar, among other similar software.
  5. Resources and Actions: Many software applications act as Resources for implementing diverse Actions. For instance, Wikis enable editing of shared documents, and there are any number of calculators, electronic dictionaries, encyclopedias, search engines, web design tools – software that team members might use as they do their work.

These ‘point’ solutions may address their targeted functions effectively and even showcase the core ideals of Web 2.0 – user-generated content and taxonomies, broad-based participation, software-as-a-service (SaaS), and rich user-interfaces within a web browser. But they can’t just be lumped together and called “Collaboration” (with or without the 2.0 suffix). If you buy into the definition and model described above, it should be clear that true collaboration software must go beyond a set of disconnected point solutions and reach for the broader goal of enabling the whole collaboration process.

A key shortcoming of current so-called “collaborative software” is that there is no compelling metaphor or unifying vocabulary. We have many of the necessary pieces, but they do not interact at either the backend or user interface levels.

Some major contenders

Computer-Supported Co-operative Work (CSCW) and Computer-Supported Collaboration (CSC)

CSCW and CSC both promised such systems, but where are the practical results? While these research areas from previous decades generated many novel and hopeful ideas, there seems to have been an overly academic orientation rather than much focus on software design. Although the theory made useful distinctions, such as the categorization of collaboration by time and space, the software that resulted from these efforts dealt more with communication and co-ordination than with real collaboration.

Google

Google offers an assortment of products that promote collaboration: Google Calendar, Google Apps, and more are promised. I was hoping that their acquisition of JotSpot in 2006 might result in a broader Wiki-based collaboration platform that unified those other offerings. But to date JotSpot has been silent. At this stage, Google’s offering is still an “assortment” rather than a clearly-conceived package.

Zoho

The Zoho suite encapsulates virtually all the point-solutions mentioned above. It includes the standard office tools (word processing, spreadsheet, presentations, email), remote conferencing, chat, meeting organizer, calendar, project management and a Wiki. All of that and more is delivered via a SaaS model through your web browser. Zoho is way ahead of any competition because of its unified user interface. However, there are still important aspects lacking in Zoho: not primarily additional modules but some key IA and UX characteristics that I outline below.

Microsoft

Perhaps the closest we have today is from Microsoft. Combine SharePoint, Outlook and the Office suite and this provides remarkably effective functionality for team management, scheduling meetings, communication and shared workspaces. Our organization makes heavy use of this combination, and it pushes teamwork and information sharing a long way ahead of where we once were. On the down-side, the Task management in that environment is quite simplistic, with little support for maintaining a complex task list, or prioritization, or comprehensive status reports. The Wiki facility shipped with SharePoint is very primitive3. Microsoft has implemented a “Collaboration 1.0” approach rather than “Collaboration 2.0”, by which I mean it requires a large degree of centralized control rather than drawing on the power of social networking. Of course, the content of email, announcements, uploaded documents, and so on is completely open to freedom of expression, but the constrained environment and heavy IT infrastructure make the system as a whole feels complex and unwieldy.

Multi-user editing

Perhaps something specific needs to be said about one type of so-called collaborative software – the type that enables multi-user editing of electronic documents. Most of these applications are primarily interested in version control: they maintain a repository of documents and control access to that repository. Authorized people can view documents and a subset of those can edit the documents. The software provides some process for giving each editor a copy of the document and when the changes have been made, the software merges the changes back into the master copy, while keeping some form of historical change log. Examples are clearspace and the various text-based code-management tools such as Subversion.

While revision control has an important role, it is a meager offering in terms of the extent of collaboration that it enables. In most cases, such applications assume that individuals work independently of each other. One user edits this part of the document and, as a quite separate task, another user may edit another part of the same document. Two people editing the same part of the document is treated as a problem, and typically the last person to submit changes trumps any previous changes.

A more significant level of collaboration requires the assumption that multiple people will be working together to edit the document simultaneously. That requires a single shared document rather than separate copies of a master document for each editor. See Wikipedia article for a list of such real-time collaborative editors.

XMPP (the Extensible Messaging and Presence Protocol) has extensions for both multi-user text editing and multi-user whiteboarding, so there is at least discussions about how such interaction can be standardized. But tools that use that protocol are few and far between.

The Challenge for IA and UX

There are many human and business activities mediated by computer systems where IA and UX practitioners have provided design guidance to make the interaction more effective. Given that collaboration is fundamentally about interacting effective to jointly achieve some goal, IA and UX can play an even more substantial role than usual.

So, what principles would you apply to collaboration software? Here are my suggestions:

1.      Build the user interface around a consistent, unifying metaphor.

  • The metaphor should be goal-oriented. That is, a stated goal should take center-stage, with the Team, Tasks, Calendar, Resources, and Artifacts being other players in the drama.
  • The user interface needs to enable and encourage interactions between collaborators. Perhaps the metaphor of a sport team would be effective.
  •  A “portal”/dashboard pattern allows simple movement between team management, task list, calendar, documentation management and the like. That approach can collate the answers to core concerns like: What collaboration projects am I part of? What’s the current status of each? What’s on my To Do list?

2.      Build an open, extensible, modular framework: a collaboration platform rather than a single application.

  • The scope of collaboration is too extensive to expect that a single vendor will be able to provide all the pieces. It is important to allow modules to be gathered from multiple sources and plugged into a shared framework.
  • For instance, Jira might be the first choice for the maintaining the Task list, but the framework should allow that to be substituted with alternatives. Similarly, in a basic system there may be a limited reporting feature (e.g. to view the change history for the Artifact), but it should be possible to plug in a more substantial reporting application later on.
  • Most importantly, it will be important to provide a standard API to the Artifact repository, so that any number of applications can view, add and modify Artifacts.

3.      Include at least the following functions “out of the box:”

  • Team management: functions to define and authorize team members, and for individuals to update their personal profiles
  • Task management: functions to add and prioritize tasks, allocate responsibilities to team members, and maintain current status
  • Calendar management: all team members can add events to a single shared calendar
  • Communication: integration with email, IM, and other technologies
  • Meetings: ability to schedule a meeting and invite specific team members, publish an agenda, record notes and decisions from the meeting.

4.      The platform itself should maintain a collaboration history rather than leave that function to the plug-in components. All meetings, decisions, changes to Artifacts, Task status changes and other events are recorded in that history. The history should be displayed as a journal along a time-line as well as being exposed as a life-stream via RSS/Atom.

5.      Connect to other enterprise applications and data stores. A collaboration application will gain significant value if it can interact with existing databases, content management systems, security mechanisms, and if it can exchange data with other applications via some standard like Web Services.

6.      Implement all this as a Rich Internet Application. The complexity of interactions between team members who are potentially geographically scattered indicates the platform needs to be web-based. The complexity of interactions between users and the system indicates that the user interface needs to be very dynamic, with near-real-time synchronization between all concurrent users and a shared Artifact repository.

Conclusion

Maybe all I’ve done here is scratch an itch. But I hope that the itch is contagious.

Collaboration is an essential part of human endeavor and information technology is at a stage where it should be able to add value to collaboration in more ways that just connecting people in a social network. We have many web-based applications that address parts of the process, but who’s going to create the framework to bring it all together?

Footnotes

1 This model was first presented at BarCamp Sydney in August 2007.

2 Capterra’s Web Collaboration Software Directory lists “174 Solutions”. See also the Wikipedia article on collaborative software.

3 Lawrence Liu comments that the SharePoint Wiki is not intended to be best-of-breed, just something that “is sufficient for a very large percentage of our customer base”. Even that is wishful thinking, but fortunately, the guys at Atlassian have made a SharePoint Connector for Confluence that can easily replace the default SharePoint Wiki.

27 comments

  1. Terrific article. I buy in!
    As to real Web2.0 PM & Collaboration tools are concern, I would agree that very few solutions have today either the breadth and depth we need, or the right integrated architecture. Lot of solutions are still addressing one issue (usually very well), but are far to be this comprehensive, secure SaaS based virtual office that should enable result oriented collaboration across the street or across the world.
    The success factors are first a very advanced architecture (service hypercube allowing to seamlessly move from one service to the other and link everything with everything), second a high level of Transparency and finally a high degree of Accountability. One tool does that, really. It is not on your radar screen yet. You should take a look at http://www.Qtask.com.

  3. One problem with SharePoint is the vendor lock-in and technical portfolio requirement. Forget it. You lose creative input right there from what would otherwise be a larger pool of of developers and UX people. Whatever happens it needs to be open. I agree with the module-based framework approach; seems like the right way to go.

    Just read that article Susan Chopra linked to. Very interesting. The collaborative web browsing is, in my opinion, a perfect example of the missing collaboration capabilities implied here. Certainly one artifact to covet.

    One thing I don’t quite get is your suggestion for synchronous collaboration (simultaneous merging?) on a document. For example, you pointed out diffing and subversion, etc, and seem to say that the most recent version save — trumping the previous — is less than perfect. Do you mean the process is too clunky (e.g., having to pick through a diffing page), or there should be a more esoteric merging of text, like mixing blue and yellow to get green?

  4. Interesting article, I liked reading your take on collaboration and it’s directions. I’d love to see your model expanded with your sports-team metaphor applied as a way of providing an example. Another piece of software that you might consider taking a look at is Microsoft’s Office Groove: (http://office.microsoft.com/en-us/groove/HA101656331033.aspx). I haven’t used it, but I know that it’s goal is to provide a single shared collaborative workspace.

    There are a couple things I’d like to see added to your description of ideal collaboration software. The first regards the role of the team leader. A leader has to be able to keep tabs on his or her team members and ensure progress, I think any good collaboration software should include this. My designed some communication software for search and rescue teams a few years back and teams really appreciated the ability for the team leader to be able to keep tabs on all his people from a single source.

    The second focuses on training. In my personal experience some of the most collaborative teams include football teams, hostage negotiation teams, and military units from companies down to fire teams. One thing that all of these teams have in common is that they train together regularly. As a result, they really understand their team members, their habits and their capabilities very well. I would like to see some kind of training feature in a which the team can work together to accomplish some kind of mini-task on some kind of regular or semi-regular basis. I feel like the biggest hurdle to effective collaboration is behavioral, it can be hard to get people that are not accustomed to collaborating to do it regularly and well. I’d love to see collaboration software address the behavioral piece.

  5. Although it is more focused on collaborative development, also check out IBM’s Jazz.net and Rational Team Concert.

  6. On Susan’s pointer to IBM: The idea of synchronised web browsing is novel, but with more general purpose tools for remote screen sharing (GoToMeeting, WebEx etc), why would you want just that limited facility?

    I like Blue Spruce — “to allow several users to huddle over Web pages and interact in real time as participants mark up the page”. That’s what I referred to in the article as multi-user editing and would be wonderful to see. This may help Destry Wion understand what I was referring to. The idea is not necessarily to merge multiple people’s changes in separate colours, but for all participants to see a single object that they can all manipulate. Of course, there would be a need to indicate who is making what changes, and that may be reflected in colour coding, or by floating avatars or something else.

    –Matt.

  7. Gabriel: thanks for the comments. I had not previously seen qtask and as I stated in the article, part of my intention was to find out about software I hadn’t considered. On first glance qtask looks quite neat. One question I have is about how open the architecture is — could different customers plug in alternative modules (e.g. could they incorporate Jira if that was what they were already using for task tracking?

    –Matt.

  8. Matthew: I see what you mean now, thanks. I thought you were referring to a physical melding of contributions (the resulting artifact), whereas you are talking more about the collaboration leading to the artifact’s final state. Seems trivial at first look, but there is a difference. My reference to color was misleading, as I was using it as an analogy of melding process and the illogical outcome if applied to text communication. 🙂

  9. Demetrius: On leadership, I deliberately left that out of the model because it plays such a different role in different teams. in fact some collaborative methodologies avoid any single leader, preferring to emphasise equal responsibility. Nevertheless, many (probably most) contexts would value the type of functionality that you suggest: namely, the ability for a designated person to see/control what others in the team are doing.

  10. Demetrius: there are some good things about Groove. I like how a workspace is both local and shared. That is, you can work on your copy of an artefact while disconnected from the network, and then it is auto-synced (auto-sunc?)when you reconnect. The product still suffers from the vendor lock-in that was noted by Destry about SharePoint.

  11. Demetrius: Excellent point about “collaboration software address[ing] the behavioral piece”. That not only applies to training. It would be very useful for the collaboration platform to have some embedded understanding of team dynamics, such as Bruce Tuckman’s Forming, Storming, Norming, Performing model.

  12. Matthew: Good point on the leadership aspect, for this application I was thinking about the role of the project manager and how they can get overloaded quickly. Collaboration definitely requires coordination and transparency would be very useful in that regard. I have a lot of interest in this topic, I recently saw Kim Goodwin from Cooper describing their team model during a talk and it was very compelling, it might be interesting to see what she would look for in a piece of software. Understanding the work of your teammates is a major hurdle also, I recently proposed an article on this site intended to help people understand research (my specialty) in the interest of better collaboration.

  13. You should check out the Omnium software (disclaimer: I’ve been involved with the project for some time). It’s mainly used for online collaborative teaching projects, often worldwide, but has a pretty good set of features. For this particular use it would need some expanding, but it’s open source so if anyone with the skills out there wants to get stuck in, they would be welcome. I teach (design and interaction design) students with it to Australia from here in Germany and really like it. http://www.omnium.net.au/software

  14. *kudos*
    After a period of intense and productive activity on my collaborative decision-making systems I just took a moment to kick back and ponder. What came to mind was “I wonder what folk at B&A are up to.”

    And I find this thread at the top of the homepage.
    How fine is that?!

  15. p.s. my methodology hinges on a slight refinement of your “Collaboration is action-oriented”. Point being this, playing on the distinguishing between “data” and information i.e. when I’m confronted with a decision point (existentially) salience makes itself felt. I mean at a gut level. This has everything to do with cognitive schema (“pop-out” and “priming”, yes?). Data that isn’t salient is, if not noise, distraction. (We daren’t throw it away … since events are actually fractal there’s no telling with certainty what will come into play.) Without denigrating other issues as trivial, the required action (i.e. decision point) imposes a set of priorities … and that should/must be empowered, that has to translate into a set of operational filters: these datum are salient, these are key, and all of those are secondary / peripheral.

  16. Ben: it all sounds confusingly metaphysical to me, but I think you are correct to point out that a lot of data is thrown into the collaboration process, and not all that data is information. That certainly necessitates a filtering and prioritisation process. If collaboration is to reach some goal then the “actions” need to be “directed actions”. Am I understanding you correctly?

  17. How left brain is this?

    Colloboration is a label not an action.
    Passing documents back and forth or engaging in conversation is just that.
    Chipmunks don’t collaborate with themselves by leaving nuts in the ground, they store and retrieve nuts.

    If you want software to make it go faster then give up now or force everybody to adopt the same interaction processes.
    After all, software is just the manifestation of process, simple as that.

    Cheers,
    Nick
    http://www.scenario2.com

  18. @Matthew – Less “metaphysical” and more “operational”; imagine being able to filter documents / information / data by salience. What I find myself suggesting is that once we reduce the information overload we then have space and time to address what matters to the individuals involved, to get into the players’ subjective narrative. And the whole thing turning on the single point: does this directly affect the point at hand / the matter at issue.

    @Nick – I’m sure you’d allow that lots of times action is pretty pointless … make-work … thrash … lots of heat but no light. In a collaborative setting (IMNSHO) there’s a real likelihood that activity is goal-oriented, so long as the agenda is observed.

  19. This is a great article and a vital conversation. We’ve got a section on collaboration in the social design patterns wiki, and I’d welcome feedback, suggestions, corrections, etc:

    Most of the relevant patterns are under Collaboration (but a few, such as those related to calendaring, are under geo/location).

  21. Random musings.

    I wonder if there is not something Holy Grail-ish about the idea of a single monolithic out-of-the-box piece of software that can elegantly answer all of process collaborations actual forms. It may be like enlightenment or perfection; something we are always moving toward but will never absolutely reach.

    There is so much that is unique to the way that 1) different kinds of projects are structured, 2) to how different types of teams work, 3) how different teams are configured re: whether responsibilities and skill-sets are combined or fragmented among more or less people, 4) how individuals actually use tools (for purposes intended, un-itentended, or using one tool for a task for which another tool is designed), 5) how custom meta-associations could iterate on the needs of even a well thought our modularity … etc. Achieving an infinite range of custom flexibility in a modular suite is one challenge; then what about flexibility within a project configuration that accommodates the individual team member while still being operable in a common world of exchangeability with others on the team.

    There are so many directions of flexibility to accommodate every last possible variation in such a totalistic system. It seems like we would need to inventory every last feature of all collaboration software, break them into a zillion modular components, and use a host of wizards, maps, and other planning tools to help users configure the work-space of their dreams. Big learning/effort curve here for sure. Many prefer simple out-of-the-box tools because they don’t want to roll their own. Perhaps an answer to this is to have a community of configurations, rather than (or in addition to) a free form community of modular developers. Imagine a case where I am a large scale multi-media theater director and I have created a set of modules and meta-associations that work great for me. Well my configuration should be findable by someone doing a particular project. Is the big problem always that software does not have what we need, or that we just don’t know how to make it do what we need it to do? Well a browseable library of project-type configurations could help someone through the weeds of a monolithic collaboration tool like this.

    I think open source development would have to be heavily curated. It seems like there would need to be a dominant controller who would need to keep up with everything going on in the community of development. Imagine a case of managing “Enterprise Modularity”. How do you keep people from developing redundant tools? It could end up like at RecipeZaar.com where you have the option to select between 1,229 recipes for “chocolate chip cookies”. Where do you start?

  22. Interesting read and certainly caught my attention. I normally don’t comment/advertise with software that I’m associated with, but you asked for it!

    ConcourseConnect is a new collaboration and community application that has many of the features mentioned, and in the spirit of collaboration it is available with an Open Source license. There’s a lot of breadth, and in some areas not enough depth, but hopefully if you are inclined and would like to share your opinion, whether you are a business user, designer or developer, there’s room for participation and feedback. There are web conferencing capabilities in development, but other than that, you will find wikis, blogs, reviews, ratings, commenting, planning and more.

    Concursive ConcourseConnect
    http://www.concursive.com

  23. Interesting article. Trends covered in my book are geared toward creative solutions that require a bit more abstraction and fluidity in the collaboration engineering components. The ones listed in the article here might be used as rules of thumb for certain cases. Collaboration seems to be moving toward deeper activity rather than portable apps (“out of the box” instead of out of the box) :]

    *Disclaimer – author’s book*
    http://www.igi-pub.com/reference/details.asp?id=34633

  24. An off the wall approach comes from SERENA Software. SERENA Software sells an expensive, but comprehensive web based integrated tool set that:
     Support collaborative development team process with IA integration
     Visually capture requirements as wireframes and extend them into high-fidelity prototypes that simulate the final application
     Supports Agile, lean business management and other common methodologies
     Manage the product requirements, business process, development life cycle, defects, software configuration & releases
     Uses a Project and portfolio tool to track project plans, tasks, resources, time tables and schedules

  25. In the article I lament the fact that Google’s acquisition of JotSpot didn’t seem to have produced anything good. But the URL “https://www.google.com/accounts/ServiceLogin?continue=http%3A%2F%2Fsites.google.com%2Fsite%2F&service=jotspot&ul=1” suggests that Google Sites is derived from JotSpot. Anyoen able to confirm that heritage?

    –Matt

  26. I used JotSpot before Google bought it and think Google ruined what worked well and Googleized it into something less.

    You might look at Microsoft’s Communication Server software. It creates a framework around tools a team typically uses rather than forcing a team to learn new tools in order to work together.

Comments are closed.