Information Technology Reference
In-Depth Information
other aspects may affect acceptance by the group
participating in the collaboration process, but such
specific considerations should be deliberated by
the collaboration engineer based on the thinkLet
description):
durations may be altered, and there should be an
option to automatically update the other times in
the process sequence.
For some thinkLets several aspects need to be
further specified. First of all, as mentioned earlier,
most thinkLets have variations named modifiers.
Modifiers can be selected, and they also alter the
results, patterns of collaboration and in some cases
the time and resources required for the step. Once
the modifiers are selected, some other aspects of
the thinkLets may need to be instantiated:
•
The timeframe.
•
The group size.
•
The scope of the task.
•
The complexity for the practitioner.
•
The complexity for the group.
•
The available technological resources, es-
pecially the availability of parallel input,
anonymity and data processing abilities as
offered in Group Support Systems.
•
Roles involved in the process can be
labeled.
Constraints to the data input or modifica-•
•
tions can be specified such as topics, cat-
egory names, and voting criteria.
Capabilities should be instantiated with re-
To further verify the choice of a thinkLet, the
CACE tool will compare information in the proj-
ect description with information in the thinkLet.
Furthermore, each of these factors affects the time
required for the thinkLet. While the collaboration
engineer should be free to specify the time frame
for the thinkLet differently, the system should
calculate a suggested time frame for each thinkLet
based on the earlier field experiences with the
particular thinkLet and these factors. When the
thinkLet time estimated based on these factors does
not fit the timeframe proposed by the collabora-
tion engineer, an alert should be given. Similar
intelligent design support will alert the facilitator
when the thinkLet does not fit the group size or
the complexity it can handle, when it does not fit
the breadth of the scope, when it does not work
without certain resources available or when it is
too complex for the practitioners involved.
Based on the above, not only the thinkLet
sequence which determines the process flow can
be created, but also the data flow should also
be specified and the decisions and transitions in
the process should be specified. Further, based
on the time frame of the meeting and the time
estimation of the individual activities in the col-
laboration process design, the starting time and
duration can be specified. Yet, starting times and
•
sources available.
Besides instantiation, the collaboration en-
gineer will want to alter some descriptions or
information in the thinkLet to further customize
the design. It should therefore also be possible to
edit the thinkLets in the project record without
changing the same thinkLet entries in the thin-
kLet library.
Validation
A number of thinkLets attributes can be used to
perform an overall assessment of the collaboration
process design, for example in terms of its com-
plexity, the amount of discussion, the amount of
input required from the participants, and the need
for consensus or agreement. These aspects give a
first indication of the acceptance of the process.
The choice verification system described above
will check for most of the 'resource fit' and alert
the collaboration engineer when the process does
not fit the resources available. The system can
render a list of skills required to run the process
to evaluate the fit to the practitioner. Furthermore,
for each thinkLet a list of challenges is specified
Search WWH ::
Custom Search