Re: [ba-ohs-talk] new version of graph model paper posted
Eugene's point below reminded me of an unpublished piece I wrote probably
4-5 years ago, which appears following Eugene's. (01)
"The term that I settled on was "hyperdocument." (Boy, that one was just
staring at me in the face. :-) I think the flaw with Groves and NODAL as
a candidate data model for the OHS is that they are too document-centric
-- NODAL less so than Groves. They express a data model for a document,
but depend on something external to relate data between documents. (02)
The point I try to get across in my paper is that there is no need for
such a distinction, and in fact, there is much to gain by not separating
the two. A hyperdocument, as I express it, expresses data and their
relationships with each other. Documents are simply two-dimensional views
of a hyperdocument." (03)
And mine: (04)
In the current business world, things move too fast and change too quickly
for document-centric methods of team communication. (05)
Project teams have to work and communicate on many levels. They have to
cope with changing requirements, situations, and demands, constantly
reconfiguring themselves and their activities and priorities in the face of
the changes. Communicating about and responding to these changes
constitutes much of the real work of project management and coordination.
There is a constant struggle between the need to maintain structure and the
need to respond in an ad hoc manner to ad hoc pressures. (06)
Teams (as a whole and as individual members) need to pull ideas together,
recombine them, grab things of relevance. It shouldn't matter whether the
ideas were voiced in a meeting, culled from a document, thrown out as
passing comments or sudden, ill-formed realizations, created as annotations
to something else, or sent as e-mail. (07)
Project teams have to pull skeins of meaning from this turbulent stew,
ready to replunge and reform their skeins on a daily basis, continually
asking and answering:
- What are we doing
- What's happening to us
- What's on the horizon
- What's going to matter next week, month, six months, in a year
- What should we change (08)
It's a constant Chinese-restaurant-ordering exercise in which team members
have to choose two actions from Column A and three from Column B, except
that the number of choices and the items in each column (as well as the
level of knowledge about each item and the consequences of making
particular sets of choices) are constantly changing. (09)
Documents are not ideas -- they are collections or structures of ideas,
assembled in certain ways for certain reasons at certain times. Teams
shouldn't be beholden to those arbitrary structures, shouldn't have to
painstakingly seperate ideas from them when they want to reuse them. (010)
Intranets and Notes-like setups that provide only documents, discussion
databases, and/or email, while all valuable on their own, are not enough.
Because they are all document-centric (whether the document is a posting,
email, spreadsheet, or memo), they imprison a team's thinking and ideas in
the midst of documents. (011)
What's needed is to get beyond, and below, and in between the idea of a
formally constructed document, to the ideas that make up the document. The
ideas need to be accessible as individual ideas as well as in document-type
structures. The facts, concepts, thoughts, and observations a team needs
should be available to them in whatever granularity then need at the time.
They should not have to read through documents to find the nuggets of
interest; they should have direct access to the nuggets themselves. (012)
Teams need databases that combine the structures of documents
with the free-form associativeness of human thinking and memory. These
"workbases" are more than repositories; they are mechanisms that support
the active retrieval, combination, and recombination of ideas into fresh
responses to the needs of the moment, without losing the originating
contexts of those ideas. The workbase needs to support both individual
and group work, both synchronous and asynchronous access, both
granular and combinatorial views of data. It needs to provide fast and
easy ways of entering data from multiple sources, including a method
of "harvesting" associatable ideas from existing documents. (013)
When teams have a resource that lets them respond to any question or
challenge with the full strength of their collective thinking and memory,
they will complete the circle that document-sharing began. (014)