Tool/process inertia

In my earlier post on Project conversations, I spoke about a new project and our desire to experiment some more with different communication mediums:

I've been adopting an approach of trialling different communication/collaboration/information sharing tools and channels, in the hope that at least some of them will prove effective and useful. I'm not exactly sure which of these is going to be the most helpful - maybe it will be the group email, maybe the project weblog, maybe the shared file storage. Guess we'll just have to suck them all and see!

As part of the first phase of the project, it's essential for us to record a number of important design decisions as they are made, so that everyone has a record of what we've agreed. Some of this ends up documented in the requirements specification ultimately. But not necessarily all of it.

The design decisions themselves arise from either conversations we have face to face, or through encountering issues while specifying the requirements. The project team is fragmented across three organisations, without shared file space. So how did we end up communicating and recording these?

Basically, as often happens, we defaulted to email (with a common subject prefix - DD) for non-face to face interactions, which are then collated in a spreadsheet to track the conversations around each decision. Face to face conversations relating to the design decisions are written up and emailed around. Periodically, the current spreadsheet is emailed to everyone, to provide a record of all the updates.

The obvious alternative, a project weblog with a specific category for design decisions, together with commenting mechanisms, was not adopted.

I've been thinking about why.

Martin Röll's recent excellent article about Distributed KM makes a number of interesting points about the ubiquity of an email client.

Today, the email client arguably has become the most intensively used knowledge work tool.  ... The reason for this is email's embeddedness in communicative processes.

Martin makes the following summary:

In my view, email has two characteristics that are its success factors for becoming a "serial killer app":

1. It embedds managing information with communication
2. It is personal (it belongs to the user), private (no one else can access it if it is not shared) and personalisable (it can be configured to ones personal needs and work style).

Or, to put it differently: Email is successful because it is personal and social at the same time.

He then goes on to examine weblogs (and weblog readers/publishing tools) and how they can contribute to the kinds of knowledge processes we've been carrying out.

Note that we do have a project weblog. And we do use it. Our failure decision not to use the weblog for this particular circumstance (which bears the hallmarks of all of the Information Snowflake set of activities) arises for a number of reasons I believe:

1. Everyone has an email client as part of their work environment. Synop people all have Sauce Reader, but our customer team would have to use a web-based interface (or get changes made to their SOE), and this is not ingrained into people's work habits.
2. The Blogger-hosted weblog does not support categories, to allow easy discrimination between posts to the project weblog on design decisions versus other information. (Yes, other weblog publishing engines support categories, but they are harder to set up in 5 minutes which are then instantly accessible to the distributed team, without more expert knowledge.)
3. Some of the design decisions go to a slightly wider audience than others. This is easy to express within email - as per Jon Udell's analysis of ridiculously easy group forming (and dissolving). This is hard to do still with weblogs. (Not that the information is necessarily private, but it's unnecessary to be distributed to a wider audience all the time.)

The email solution is by no means perfect, and in fact materially suffers in many ways in comparison to a weblog/weblog tools approach:

1. The current definitive set of design decisions is expressed in an ad hoc medium (email conversations), and only periodically are these summarised and available in one place from the spreadsheet.
2. There is no cross-linking available (e.g. this design decision is made because this <link to>earlier design decision</link to> has these consequences). Thus there is no easy mechanism for people to explore the background of decisions.
3. It is more difficult to track how the conversation around an individual design decision unfolded. An email client's view on conversations denies the richness available in a threaded (or even serialised) sequence of comments would provide. As much as anything, this is just a straight interface issue because the primary information (timestamps, people) is all identical to both mediums.
4. Design decision communication intermingles with lots of other communication that arrives by email, adding to the filtering lag. 
5. Both one of the customer's team and ourselves have multiple email addresses - which one is the one which should be sent to today? Send to all?

What will it take for weblog tools to become the medium of choice for such issues? I believe the critical features are:

1. A ridiculously easy interface - for managing the intended audience for weblog posts.
2. Tool ubiquity - everyone has to have one, and they have to be part of the daily set of tools in use.
3. An easy ability to express the importance of being alerted to new material - it's got to be simple to say that new design decisions are important to me and I want to know straight away (or within a short period of time).
4. An easy ability to add downloadable attachments - some of the design decisions come with affiliated information that should be preserved in its native format, not converted to an HTML presentation.

Guess those of us involved in building PKM tools better just keep working to make them simpler still! Until then, the "good enough" syndrome of email technologies (basically a tool/process inertia) will prevail over the adoption of more effective technologies.