Collaboration in a tool-rich environment
Collaboration can be defined as: (1) Working
together to produce a common outcome, (2) to work together, especially in a
joint intellectual process.
This definition can be broken down into a few core values for collaboration. The words "Working together" and "joint intellectual process" imply Communication, Sharing and Process. "To produce" implies Development and Publication.
The core values of collaboration are: Communication, Sharing, Development, Publication and Process.
This definition can be broken down into a few core values for collaboration. The words "Working together" and "joint intellectual process" imply Communication, Sharing and Process. "To produce" implies Development and Publication.
The core values of collaboration are: Communication, Sharing, Development, Publication and Process.
There are many tools that we could use to
facilitate collaboration - various word processors, web sites, web logs, the
telephone, email, project management software, PIMS, CASE tools and paper mail
to name a few. By assessing tools for how they best fill the core values you
can build a collaboration environment.
There are project demands that play into the toolset choice as well. If you are working to produce a sky scraper you will choose different tools than if you are working to produce a movie. The sky scraper project will need architectural drawings. The movie might need story boards.
One interesting outcome of looking at collaboration as a set of core values is that the real issues are at the interfaces of the values. For example, the interface between Communicate and Share. Communicate means telling someone about what is going on. Sharing means allowing them to interact. This shifts the choice from being one of a tool ("We will all use WordPerfect5.0) to one about the sharable item that is being communicated ("all documents will be in WordPerfect5.0 format). If you are comfortable editing WordPerfect5.0 documents in vi or emacs, go right ahead just save it so others can read it.
Analysis of "collaboration space" should be focused on the interface areas - not the tool areas. Analysis should look to define a small number of exchangeable artifacts. Examples of artifacts include: text documents with rich formating for printing, graphic documents for project timelines and plans, mixed text and graphics for UML documents. Once the needed artifacts are defined, then a set of actions for each artifact can be listed. For the Rich Text document, the actions might be: editable with versioning, tracking changes, sharable across the network. From the Artifacts and Actions, then a set of useful object types can be listed and select few chosen. Then you can set the collaboration format definitions: Rich Text will be in Word 6.0 or newer or PDF format.
Ideally, you can find solutions that are not "product dependent". It would be better, generally, to chose RTF over Word Perfect or Word though many 3rd party word processors can save in common formats. I am still searching for an open format for Project Planning documents (like Gantt and Pert charts). PNGs work well for drawing documents.
If you approach collaboration as a an analysis of the artifacts needed and the actions that are needed for each artifact, then you can build a collaboration space that is not (hopefully) bound by vendor products and closed document formats.
There are project demands that play into the toolset choice as well. If you are working to produce a sky scraper you will choose different tools than if you are working to produce a movie. The sky scraper project will need architectural drawings. The movie might need story boards.
One interesting outcome of looking at collaboration as a set of core values is that the real issues are at the interfaces of the values. For example, the interface between Communicate and Share. Communicate means telling someone about what is going on. Sharing means allowing them to interact. This shifts the choice from being one of a tool ("We will all use WordPerfect5.0) to one about the sharable item that is being communicated ("all documents will be in WordPerfect5.0 format). If you are comfortable editing WordPerfect5.0 documents in vi or emacs, go right ahead just save it so others can read it.
Analysis of "collaboration space" should be focused on the interface areas - not the tool areas. Analysis should look to define a small number of exchangeable artifacts. Examples of artifacts include: text documents with rich formating for printing, graphic documents for project timelines and plans, mixed text and graphics for UML documents. Once the needed artifacts are defined, then a set of actions for each artifact can be listed. For the Rich Text document, the actions might be: editable with versioning, tracking changes, sharable across the network. From the Artifacts and Actions, then a set of useful object types can be listed and select few chosen. Then you can set the collaboration format definitions: Rich Text will be in Word 6.0 or newer or PDF format.
Ideally, you can find solutions that are not "product dependent". It would be better, generally, to chose RTF over Word Perfect or Word though many 3rd party word processors can save in common formats. I am still searching for an open format for Project Planning documents (like Gantt and Pert charts). PNGs work well for drawing documents.
If you approach collaboration as a an analysis of the artifacts needed and the actions that are needed for each artifact, then you can build a collaboration space that is not (hopefully) bound by vendor products and closed document formats.
Posted: Mon - September 15, 2003 at 04:56 PM
