A project can be visualized as a opportunity for interfusion of multiple different identities of people. These identities stem from role performed in the project, technology specialization/association of the project team member, affiliation with customer through proximity on location/role/relations, among many other identities.
A general agreement to collaborate across these different roles is realized as a need in most cases and there are contractual tie ups (could be a real agreement, or defined by role and individual responsibilities) between several pairs of parties, customer-service provider, manager-resource, practice-resource, onsite-offshore. Real progress on work usually involves actions by project team members across different identities.
When identities fuse across, there is a need for objects that are “Common Point of Reference that can have different meanings attached to it, while can act as a means for coordination, alignment and translation, while catering to different concerns simultaneously”
That was a definition of Boundary Object, all emphasis indicate the key characteristics.
Within Knowledge Management there are real good examples of boundary objects, below are some
- wiki page on wikipedia
- Knowledge Map of a project/community
- a story/anecdote
If you are on a project it is likely that your deliverable, usually an artifact is also being used as a boundary object. But no one thought about it that way yet…and you compromised, some symptoms below
- Have you ever noticed the indifference with which core process groups fill out or create templates, while the end users of the templates find it hard to use it for any real purpose
- Even when you send a status report that goes through the hierarchy will the “head” be able to make sense of the original concern that you wanted to be acted on or was it all lost in translation
- Dev team seems to be at ease with the seemingly random project wiki, while the business team finds it real hard to get anything out or the other way around, is the wiki really that pliable
- The tester does not seem to be all concerned with the reds in the project plan, while the PM is unable to catch the significance of a red flag in a key test case
Mark Weiser spent the best part of his life working on Ubiquitous computing. He has another noted work as well in which he indicates all social and knowledge work is all about reducing the problem to reach an agreement , where he explains reality distortion with the classic archetype the Dilbert. And there are measures that you can use, to reduce Reality Distortion and for those academically oriented there are complex equation to represent them, but I like the cartoons better.
The real issue I think is, can we design boundary objects and reduce the reality distortion differences over a period of time?