Karsten, H. et al. (2001) Crossing boundaries and conscripting participation: representing and integrating knowledge in a paper machinery project, European Journal of Information Systems, 10, pp.89-98
In this paper, the authors analyze how technical specification of a paper machine acted as a boundary object to help perspective taking. In addition, they analyse how the specification was used as a conscription device and how this enabled perspective making.The four concepts ‘boundary object’, ‘conscription device’, ‘perspective taking’ and ‘perspective making’ are theoretical lenses taken from previous literature. They help give insight on knowledge representation and integration. These insights can be used to list requirements for IT tools. Conscription devices not only facilitate sharing of information within a community, but they also provide means for participating in constructing information (compare to concept ‘epistemic objects’). The users of a consription device must engage in inputting its elements and revising them for it to serve its purpose. Perspective making is communication that strengthens the unique knowledge of a community. Perspective taking refers to estimating what the members of the community know and taking this into account. The process of perspective taking involves depicting and exchanging representations of a community’s understanding of an idea. To sum up, when knowledge is made available to others in a boundary object, it provides a basis for perspective taking, and when participants in a community of practice engage in creating and maintaining a conscription device, they engage in perspective taking. Paper compares boundary objects and conscription devices:
- Communicate information to facilitate cooperation
- Perspective taking between semantic communities
- Modified within one community, but brought to closure for crossing the boundary between communities
- Structure form a grammar for understanding in different communities
- Different interpretations in different semantic communities
- Enlist and contrain participation
- Perspective making within a semantic community
- Modified together in the community. Closure signifies agreement, not immutability
- Structure forms a grammar for constructing the object
- Converging interpretations within the semantic community
The results show that the technical specification worked as a boundary object but not as a conscription device. It is too complex to be updated thus is gradually left to the role of telling what was agreed in the beginning, with other documents taking over (e.g., design drawings). Paper lists also what was learned in knowledge integration and representation, and what this could mean in designing IT support:
- negotiating over a boundary object, channel for free communication connected to the negotiation. Make the boundary object durable but allow annotating
- punctuated and regulated process of participation, responsible author regulates who can see and access entries. The entries should be distinguishable from each other
- cascade of boundary objects: history of subsequent versions with rationale for changes, show earlier versions with rationale and circumstances for changes. Hide these when not needed.
- timing, information alignment with schedule.
- A system of boundary objects, conversions from other formats. If boundary object is changed, the sources should be informed
The authors also assert several reasons why the technical specifications did not work as a concription device
- perpective making took place with the specification only early in the delivery process
- creation of the specification was unidirectional, and it could only be changed via negotiations with the customer. Other documents replaced this and worked as conscription devices.
- Specifications were on too general level to be useful to the design team as such
- changes is the specifications were distributed by several means, thus keeping track was hard
Some tentative results about using conscription devices are presented in the paper: conscription device should be maintainable by all participants, it needs to be comprehensive (detailed), etc.