Shared Knowledge: Non-Cumulative Systems

Most of the communication occurring among members of a project team is aimed, or should be aimed, at making decisions and enforcing them. Managing a project through its entire lifecycle involves a bewildering number of critical decisions of all sorts, distributed along many dimensions: vision and strategy, technology choices, architecture and detail-level design, requirements from customers, derived from competitive analysis, constraints such as cost, timeline, and so on.

A lot of these decisions, provided that the project’s execution is to be successful, must be made in a tightly interwoven fashion: there are, for instance, complex implications between the availability of a given technology in the market at a given time, the level of expertise in the team for this technology, and the overall strategy and direction adopted by a software or hardware product. And these decisions should be based on the confrontation of as much relevant facts and cross-fact connections as available with the analytical ability of the team as a whole.

How, then, do the communication systems we use affect our ability to reach the right decisions, enforce them, revisit them? More precisely, how do they assist us in gathering, organizing, linking and analyzing the facts, the knowledge so essential to our decisions and ultimately our success? Just as critically, given the scarcity of solid knowledge during the early phases of a project, how do they help in iterating through the on-going process of integrating new facts, additional knowledge in order to confirm or refine those decisions?

Indeed, communication systems and their associated semantics, far from being neutral, transparent bearers of the information they convey, have a major impact on the structure of the exchanges taking place among the parties involved. Therefore, they affect the process of elaborating knowledge, and ultimately the richness, accuracy, and relevance of the facts we gather, categorize, and derive our decisions from.

Consequently, deconstructing team communication patterns is essential in understanding how structured knowledge is elaborated, and used to reach decisions. Such communication patterns are also important in understanding how such knowledge and decisions are then described and shared within and outside the team, as well as kept track of and evolved over the course of the project’s lifecycle.

Given its ubiquity in software development teams, let’s start by looking at the way email, as a communication medium, shapes the decision making and tracking process.

Email-based exchanges, that are message-oriented, carry “differential” semantics: like all conversational systems, they involve the exchange of messages among the parties involved that do not typically contain the entire knowledge shared among those parties. Instead, these entities communicating are responsible both for maintaining the mental image of the knowledge they are sharing, and for amending it continuously as they process the implications on this knowledge of the messages exchanged, containing only additions and changes proposed by one entity to the others.

The activity of constructing and maintaining the mental image of the shared knowledge is work-intensive. Worse, it is a risky task, in that the knowledge elaborated is not really shared directly, but instead maintained in mental images that are actually private to each party.

Therefore, I describe email as a non-cumulative knowledge building system. Not because each message that is exchanged only carries additions or changes to be made to that shared or pseudo-shared mental image, but because the work of processing the meaning of newly received messages is ultimately done by their human recipients.

How does the non-cumulative nature of a system impact the ability of the team to build knowledge?

A non-cumulative medium has many drawbacks, not the least of which is being prone to uncontrolled divergence between the private images of the shared set of facts and cross-fact connections held by the parties involved. Of course, the more parties are involved, the greater the risk of catastrophic divergence.

And the only way such divergences actually get noticed and possibly corrected in such a system is when one of the parties sends a message describing their contributions or additions to the shared knowledge and these additions suddenly fail to fit into the mental representation of the knowledge held by the receiving parties.

The sudden inconsistency prompts for clarifications, retransmissions, and not uncommonly, the rewinding of most of the conversation up to the point where all parties feel, again, confident enough that their private images are describing the same knowledge that they decide proceed forward again.

Such a phenomenon, obviously also found in verbal conversations, is the source of major inefficiencies in the communication, and it stems from the lack of a knowledge base that’s actually shared, and that all communicating parties are observing simultaneously as they evolve it.

Of course, cumulative systems, by contrast, rely on the existence and building of shared knowledge in the system itself, not in the minds of its users. Examples of cumulative systems are databases, shared file systems.

But what’s missing from a database of shared file system is the ability to exchange contributions and observations about the facts being shared, and thus augment, modify, refine the knowledge set of the group, within the boundaries of the system itself. Hence the appearance of out-of-band communications, typically taking the form of email exchanges, where additional knowledge is therefore appearing, outside of the shared system, at least until someone decides to feed their private cumulative image of the exchange back into the shared system. Quite a daunting effort!

The underlying challenge, thus, becomes: how can we integrate a cumulative shared system with a non-cumulative messaging system to support the on-going elaboration and refinement of structured knowledge, in a continuous, inline fashion, from a unified interface avoiding disruptions and rifts in the communication semantics?

Kubi Software’s Collaborative Email

I just checked out Kubi Software’s collaborative email product. They identified some of the inherent short-comings of email driven collaboration: all your messages are received there, unsorted, and even if you were to painfully move them around into organized folders, this would only benefit you. Client-side rules aimed at automating some of that are only addressing a fraction of the issue. So you end up spending your time sifting through relevant and not so relevant messages, expending vast amounts of energy just fighting the clutter. They propose a solution that plugs into the team members’ existing email clients (Outlook 2000, 2002 and Lotus Notes), and also leverages the servers already deployed.

Users of Kubi’s plug-in get to create Kubi spaces around projects or focus areas. The spaces are by-invitation only, and structured in the sense that they expose project-related tasks, contacts, documents, email discussions. Users publish documents, messages and track project events right from within their familiar email client interface. Removing the adoption critical mass barrier is thus one of the most immediately obvious qualities that Kubi brings its users.

One of the obvious features I still see as missing (at least from the demo): there is no sign of a workflow or generic event model that would allow users to subscribe to events on a particular project deliverable (say, a design specification document) and therefore get notified of changes automatically. Kubi does expose in its spaces a most recent activity pane, where I assume changes about document get automatically exposed based on the underlying shared document server, but there are no notifications that alert you it’s time to check out those updates.

Similarly, I didn’t see any mechanism to tie a particular document to a task and automate reminders, nor to enroll a set of users in reviewing documents at particular milestone points in the life-cycle of a deliverable. Finally, it doesn’t seem that Kubi spaces support sub-spaces, so you can’t create sub-projects to which a certain subset of your tasks gets delegated.

Incidentally, Kubi Software plans to launch their product next quarter, and VentureWire reports they will start raising a $10-million round of funding later this year.