For the moment, I will use the term Collaboration Ware to refer to an assembly of software and people/practices to assist a (Telic?) team (or network of teams) in accomplishing things (Team Work). What is Collaboration?

http://dilbert.com/strips/comic/2012-02-28/

see Collaboration Roadmap for some specific app variations

old notes: 2002

I consider this a broader/special case of GroupWare, which can include (a) narrow components like Group Calendaring, plus (b) Group Discussion systems. What I'm trying to focus on is (a) there has to be a targeted outcome (which doesn't have to be a software/web delivery, I'm trying to be more general), and (b) I want to design an approach that solves the core yet wide needs of such a team. The latter means I have to start by defining a minimal set of requirements/features, based on my belief as to an archetypal team's needs.

See My CollaborationWare History

Some try to use Wiki For Collaboration Ware, but it's probably a stretch.

At the other extreme is Douglas Engelbart's Open Hyperdocument System and Ted Nelson's Xanadu: exciting systems that may never see the light of day.

Environment/context (User Scenarios)

• I'm focusing on situations where there's lots of uncertainty: not just how to do something, but what to do. A "project" that amounts to "do something we've done 100 times for the 101st time", then I'm not terribly interested... These projects can rarely occur as paid work for a client, since it's difficult to decide who should bear the cost of surprises...
  • this triggers the big issue of how much Planning and controlling of a project plan and schedule are possible or appropriate.
    • my bias is to treat plans as fictions which usually are just a basis for pointless blame. I find that schedule/cost changes rarely result in decision changes (cancel project, change scope, put project on hold to bring up "better" project in the Development Queue, etc.). So then who cares?
    • on the other hand, the process of creating a semi-formal plan surfaces questions, assumptions, etc. which can be key to the basic definition of a given project. (e.g. I've seen a company start evaluating CMS systems without starting from a shared vision of what effects that system would have on the business - so what features would be key?)
    • having to recognize when the outcome of your plans have changed significantly (oops, we're going to be 6 months late) can force a revisiting of scope and process, whereas if you just keep sliding, it's easy to stick to a bad path.
• really no single focus: there are multiple people, teams, and organizations, performing multiple projects (Overlapping Scopes Of Collaboration). A micro-level view can probably focus on a single project (or a single person), but a macro-level view has to take into account the wider ecology.
• a person belongs to multiple teams, working on multiple projects. Hopefully, he focuses on a single project at a time (day? month?) to reduce context switching (since humans don't really multitask)
• many projects have Clients or Customers. These include the Wiki Wiki Web:GoldOwner and the Wiki Wiki Web:GoalDonor. Whether/how to expose them to the Collaboration Ware is a messy problem. If you have a structured issue-tracking system, you might like to have be able to enter new issues, or see resolution. On the other hand, this increases the need to sanitize comments, making them less useful (or at least easy-to-add) for the people actually getting things done (see Overlapping Scopes Of Collaboration). Of course, this is also true for Managers. And even for other team members. EMail and Instant Messaging are often used for sub-team communications for this reason (and others).
• many teams "belong" to a single owner organization, many projects include only team members employed by a single organization (esp when excluding Customers). In such situations upper organization managers typically feel a need to impose a top-down macro process, anticipating coming projects and associated needed resources, and tracking current projects' progress against plans.
• but this may be increasingly not true in the future, with more projects being performed by fuzzy teams crossing organizational boundaries (many members not being fully employed by any organization, being a Free Agent), or other loose Organization Models. And a person may certainly have personal or family projects where he'd like to have access to some of the same tools (if for no other reason than, e.g., to synch to a single PDA task-list). At some point I'll have to think about the delivery architecture (e.g. is P2P necessary?) for this, but not yet...

Needs

• bottom: teamMembers - getting work done
  • see (somehow-prioritized) list of open tasks assigned to me; write log Progress Note-s on tasks; create new tasks at various levels (for myself and others); flag completed tasks. Ask for guidance in prioritizing tasks (esp when across projects). Update expected complete date for open tasks (and have this info bubble up the calendar)
  • identify issues requiring discussion. Initiate discussion with appropriate parties. Continue discussion, bring to conclusion. Document results to avoid unnecessary future revisiting.
  • write/share documents (procedures, decisions, plans, work product) (Collaborative Writing). Perhaps allow others to change documents, maybe just let them post comments while you control actual changes.
  • Progress Note-s regarding all of the above. This generates a WebLog with Context. Should such a log be read within the collaborationware, or via RSS? Either way, I'll call it an AppLog.
  • interact with others about all of the above. Triggering an email thread from one of the above objects can create useful context.
• middle: projectManager, teamLeader, etc. - administration
  • define scope/boundaries of project. Refine scope based on crude discussion of cost/benefit, resource availability, etc.
  • coordinate creation of initial project plan (requirements, priorities, process, risks, unknowns, phases, etc.). Begin creating hierarchy of tasks, then laying out on calendar. Review significant changes to calendar triggered by changes made by people doing the work.
• top: people pretending to manage a Portfolio of projects
  • pick what projects to do vs not-do. Prioritize projects. Have a rough plan of project completion dates (esp if drives revenue).
• other
  • Knowledge Management?: copy a solution someone else already came up with to a similar problem. Find a person who's already solved a similar problem.

Ward Cunningham notes (via email Jul13, 2003): For a programming team, the most important communication is through readable code. The second most important is the shared experience of programming, the third most important is tested specifications (junit, fit), the forth is cooperative deliberation with the customer, the fifth is wiki or chat or email or something like that. By the time you get to the fifth priority it almost doesn't matter what medium you use. That is why largely broken systems like email work at all: we don't ask them to do things that they don't do well. If I were going to try to change team dynamics I'd work on the first or second priority. When they're broken, no about of email is going to fix it. Real Collaboration Challenges

Michael Schrage presentation notes - Key among the conditions necessary for true collaboration is the Shared Space where collaborators can have equal access and interaction. These shared spaces usually permit Real Time access by all collaborators ... serving as both a model and a road map (Shared Vision), and they are essential as a technique for managing conversational ambiguity (LeeWay), serving as a touchstone for the act of collaboration. A blackboard (White Board) with equations; a rehearsal room where actors, director, and crew gather; a rough ProtoType of an invention: all these serve as shared spaces. In effect, the shared spaces are the collaborative tools that people wield to make sure that the whole of the relationship is greater than the sum of the individuals' expertise... Within the shared space, collaborators must feel free to play at their activities (Game Playing), to explore and to Experiment, without the constraints of a more formal Commitment to their positions and ideas. This atmosphere is as much a product of the necessary mutual Res Pect, Tolerance, and trust between collaborators as it is a product of the shared space itself.

Nov'2011: (per a friend) *Some of the modalities / temporalities (making up a shared info space):

• synchronous (or near-synchronous) text chat (Live Chat)
• voice and video (though I could probably write a whole dissertation on video and whether it's a distraction or a necessity)
• synchronous collaborative text-editing (first SubEthaEdit, now Ether Pad (or less satisfactorily, GoogleDocs))
• Screen Sharing (ideally from collectively-owned desktops, not an individual's)
• daylogs (I use the SocialText "blog" feature for this, but it's not perfect)
• document / page store with linking, tagging, search (i.e., a "wiki")
• shared table/list editing (wiki or GoogleDocs)
• shared diagramming / White Board-ing
• ticket-based task management (Issue Tracker) system*
• (hmm, WikiProxy on top of each of these?)