• Collaboration Ware

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

I consider this a special case of Group Ware, 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.

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 Xana Du: 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 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 WikiWikiWeb:GoldOwner and the WikiWikiWeb:GoalDonor. Whether/how to expose them to the CollaborationWare 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 P2 P necessary?) for this, but not yet...

Needs

• bottom: teamMembers - getting work done
  • see (somehow-prioritized) list of open tasks assigned to me; write log notes of progress 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 notes regarding all of the above. This generates a Web Log with Con Text. Should such a log be read within the collaborationware, or via RSS? Either way, I'll call it an App Log.

  • 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 Port Folio 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.

<hr>

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.

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 (Lee Way), 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 Proto Type 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 Experi Ment, without the constraints of a more formal Commit Ment to their positions and ideas. This atmosphere is as much a product of the necessary mutual Res Pect, Toler Ance, and trust between collaborators as it is a product of the shared space itself.

<hr>