Thursday, May 27, 2004

Natural knowledge capture

Most knowledge management efforts fail because they are an add-on process -- yet another thing to do for the best and brightest in your organization. But what if you took a different approach, and made knowledge capture part of the natural flow of work?

How? By leveraging blogs, notification, and search. If people post to blogs, knowledge that would be buried in email threads is available for everyone to mine via search. And this knowledge gets retained, rather than tossed by an email retention process. Notification lets interested folks -- and only interested folks -- know when new content is available.

Topical blogs with dense cross linking facilitate search (think Google) and the happy accidents that lead to innovation.

Blogs that accept email posts can provide a familiar interface that eases the transition.

What's not to love?

overstated: Weblogs and authority

A good take on the differences between blogroll links (to the top level of a site) and permalinks (to deeper content). There are a lot of insightful comments, so be sure to read them, too.

Tuesday, May 25, 2004

Blogging behind the firewall

Chad Dickerson discusses InfoWorld's use of blogs internally. Good stuff.

But, I have to ask, what really is internal or external? How do off-site contractors, for instance, access the internal blog? What about employees working from home? Probably via a VPN. Which makes them internal, and makes their machines internal too. And once they are "inside," do they just have access to what they need, or do they have access to all kinds of things because they are an insider?

There is no perimeter. There's only varying degrees of trust, which are constantly being renegotiated. And since Guy confesses to being an idea vampire, I'm freely riffing on his theme.

Availability awareness

While we are on the subject of stupid names, let's talk about presence. Who thought up that one? It in no way captures the essence of the technology. It's about making others aware of your availability, so why don't we call it availability awareness?

And while we're at it, why don't we make it granular so I can control which folks can figure out how to contact me at different times and in different settings?

Monday, May 24, 2004

ECM includes collaboration and BPM?

This article says that it does. Hmmm... I have some issues with that. Collaboration once again is used rather vaguely. Team workspaces, yes. Collaboration, no. How does ECM include virtual meetings?

Business Process Modeling is another interesting choice. Typically, we tend to think of BPM with Vitria's BusinessWare, our integration bus. While it might make sense for document-centric processes, whatever the ECM vendors offer better tie into what Vitria and its competitors bring to the table.

Saturday, May 22, 2004

iRoom collaborative environment

A group at Stanford has been doing lots of work on interactive rooms. This is way cool. It's a completely different approach than we have taken. Their focus is on designing conferences rooms with electronic enhancements for those in the room, facilitating interaction and information sharing. The design approach they've taken strikes me as being very sound.

Other than using mimio, we've pretty much ignored this approach. And, most of our attention on mimio as been sharing the whiteboard with remote users via NetMeeting and not on its use for capturing brainstorming sessions.

I think we need to leave a placeholder in the strategy for this kind of stuff, even though it isn't a current focus.

Of great interest in the Future Directions section is this tidbit:
we have so far focused on co-located collaboration. Allowing project teams in remotely located interacted workspaces to work with one another is both interesting and useful. The main issues here are how to facilitate coordination between desired applications while insuring that workspace-specific events remain only in the appropriate location. For example, sending an event to turn on all lights should probably remain only in the environment where it was generated. As we extend the work to multiple linked rooms and remote
participants, we will use observations of the work to determine how much additional structure needs to be added. We are driven not by what is technically possible, but what is humanly appropriate.

RSS Feeding Your Consumption Habits

I'm starting to notice this type of thing popping up all over.

Is there anything the 21st century prizes more than "free time"?

Markets love this efficiency. People want to delegate their drudge work to 'bots.

So why is the US - a country which literally creates the future for themselves and the world - obsessed with the artifacts of its past?

I think what gives rise to both questions is the fact that our cultures are rapidly evolving. Collaboration (scientific, artistic, ludic ...) makes the engines go fast and - more often than not - moves in us the right directions.

Friday, May 21, 2004

Microsoft recognizes the value of RSS and blogs

Gates also talked about the possibilities of using Web logging techniques and RSS feeds in combination with E-mail as a way of giving users new ways of communicating. "E-mail is not without its problems," he said.

Thursday, May 20, 2004

Unified notification

It's not push or pull. Control of the channel is a key element, but it doesn't capture the essence of what we are talking about. It's notification.

We want to be notified when things happen, whether it is new content on a blog or "standard" web site, or a stock hits it a target price, or our package is nearing it's destination, or if a storm has a high probability of causing a major power outage, or whatever. We need to have control over what notifications we receive. We want to be able to get all of our notifications in one spot.

The RSS/Atom infrastructure should provide that place. But what a mouthful! And what a hassle to explain. RSS? Atom? Feeds? Feed readers? News readers? The names mean nothing to the average Joe. So why don't we call it notification? The feed --in whatever flavor -- is the Notifier. The client is the Recipient. Simple. To the point. Anyone can instantly get it.

As for the interface, how about a nice, single click button that says, "Notify Me!" and automatically adds the Notifier to your Recipient, regardless of whether your recipient runs on a desktop or a web server?

Controlling the channel

Control of the channel is an important thing. Why else would we wrestle over the remote when watching TV? This control is equally important from a net perspective. As Jon Udell says:
What matters is who controls the channel of communication, not how we construe the direction of flow.

That's your basic problem with an email thread that you've been copied on that goes on for ever and ever and ever. It's not that they are "pushing" it to you. It's that you can't turn it off. You don't control the channel. An equally vexing, although less talked about problem, is when you are left off a thread that you would be very interested in. This gets less traction because it is a sin of omission. You get irked when you are aware that it happens, but how often does it happen without your knowledge?

Jon also discusses personalized RSS feeds for things like bank notifications that might otherwise get lost in the email stream. This is clearly different from the filtering a stream on the client side -- you can't be allowed to see other people's notices. And again, it is about channel control. What if you'd really prefer to be informed via RSS?

I really wonder about the mechanics of making this work. How do you keep people from subscribing to other folks' feeds?

Penn State bans servers in dorms

This bonehead move gets cited here because of this bit:
Computer science students often learn best through hands-on experimentation and tinkering with technology, and as Jamie Boyle noted in his plenary talk, unplanned experimentation often bears the biggest educational fruit. To paraphrase: "How many times do we learn more from the book next to the book we originally went to find on the shelf, or from the article after the article we looked up in the journal?"

This ties right into the concept of casual interaction being the source of innovation. It's not much of a leap from the cocktail party chatter that provided the impetus for the Black-Scholes option pricing model to mistakes that worked like penicillin and chocolate chip cookies.

Wednesday, May 19, 2004

Get a Room

Call it retrograde if you will, but I think Chatzilla is gr8.

Lightweight and secure, DCC will be around awhile.


Another way around attachment issues

In Put down the attachment and walk away slowly..., the LiB points us to two unique web sites that get around some attachment issues. You simply stash your file in a dropbox at Dropload or YouSendIt. They will then notify the recipient(s) via email that the file is available for downloading for the next two or seven days, respectively. Since the file itself is never sent, size limits never enter the equation whether you are sending or receiving.

For the paranoid among us, YouSendIt offers a version you can host yourself. I think other alternatives, such as a secure team workspace, would make more sense than that.

Collaboration and innovation

I don't think we've talked enough about this linkage. As Malcolm Gladwell says, innovation is
fundamentally social. Ideas arise as much out of casual conversations as they do out of formal meetings. More precisely, as one study after another has demonstrated, the best ideas in any workplace arise out of casual contacts among different groups within the same company.

How do we promote these casual contacts? One way, as Gladwell discusses, is through intelligent office design. But that only helps those that are actually located in the same building. And in buildings as large as APC HQ and GPC HQ, intelligent office design only goes so far.

This is the gap that social software of all sorts addresses. We've treaded carefully here so far, focusing on more concrete payoffs in other collaborative spaces. However, social software may be the glue that holds all of the other collaborative stuff together. We ignore it at our peril.

Many-to-Many is a must read site

Many-to-Many is a group blog about social software. There are too many good things on here to cite individually, although I may highlight some later for further comment. For now though, I encourage you to read through this blog. They provide a different and helpful perspective and focus that complements our own well.

Monday, May 17, 2004

Moblogging with Blogger

I'm posting wandering around the halls. Blogger's use of a supersekret email address enables this mobile action, potentially making my Blackberry that much more valuable. We will see if I ever use it beyond this post.

[Later] I've edited this to fix hard return issues and clear off the auto signature from my Blackberry. I don't think there's anything to do about the hard returns, but if you place a #end when you finishing typing, Blogger will ignore the rest of the stream.

The Virtues of Chitchat - "Plogging" Away

In The Virtues of Chitchat - Making I.T. Work - CIO Magazine May 15,2004, Michael Schrage coins the term "plog" for project log. This is an interesting concept that we've hinted at as we've talked about the fit between team workspaces and project management.

An interesting blog-like project management tool is Basecamp. A very well designed application, it is intended for web design types, but it seems applicable to any project to me.

But, what Schrage is getting at is more informal -- using blogging tools as a project resource. He cites several examples, and discusses some of the potential risks.

None of this should be any news to us, because CollabuTech is really a plog. It's about collaborative technology in general, but the focus, not surprisingly, is on our strategy project. And as we move into pilot and rollout, this site will document those happenings.

One of the potential benefits that Schrage fails to mention is the opportunity for outside input. Maybe no one outside our group will ever find this site or comment on it, but maybe they will. And the insight that they provide may be just what moves us along to a better answer to our own problems.

Microsoft Office and Presence

Have we looked at Microsoft's Live Communications Server 2005 and its integrated presence information with Office (or other such integrations from other companies)? Why not look at the tools that will provide us with additional collaboration features (presence) using an already familiar interface such as Outlook.

We speak of the asynch vs. synch argument but I wonder if pretty soon we may not be able to make such a distinction within applications if the tool(s) are integrated to the point that it doesn't matter.

Tuesday, May 11, 2004

So what's the difference?

I'm trying out a new aggregator - Blog Navigator. It has Blog Groups and Article Baskets. What's the difference? It seems to assume I should know the difference.

Classifying collaborative technologies, part 2

Part 1 outlines where we stand in our efforts so far, and some areas where the model falls short.

An alternate, or perhaps supplemental, approach would be to talk about how collaborative technologies fill the holes in our current suite of tools. Some of the confusion around team workspaces and document management comes from the fact that they are both enterprise content management tools, albeit with very different purposes. It is reminiscent of the people thinking that we could rollout Sharepoint Team Services instead of TeamSite. Not a chance. Different tools with different purposes.

Similarly, maybe SIP (Session Initiation Protocol) is really just extending our network to support collaboration -- the network of the future.


Collaborating with outside parties

Jon Udell has succinctly summarized the benefits of collaborating with outside parties who just may be your competitors, too:

If you're working on a problem, odds are that someone else is working on the same or a similar problem. That person might work in your department, elsewhere in your company, or in a department like yours in another company halfway around the world. Vital collaboration can happen within any of these scopes. A public discussion space for users of your company's products or services is an excellent way to build a brain trust. Corporate and Usenet newsgroups and email lists can also gather valuable brain trusts.

There are, of course, limits to what you can say in public forums. Nobody should give up a competitive advantage by sharing the wrong kind of information. Nevertheless, collaboration among competitors is not a bizarre or unrealistic idea. Clearly you don't want to divulge company secrets, but not all information is competitively advantageous. You and I might both be working on proprietary applications that exploit certain features of HTTP basic authentication. We needn't reveal details about our respective projects in order to clarify our mutual understanding of how authentication works.

Nor need we collaborate altruistically. As in the case of open-source software, the guiding principle can be enlightened self-interest. The benefit of sharing information, measured in terms of the value of information received in turn, can outweigh the cost of sharing, measured in terms of the effort of collaboration and any competitive exposure that it entails.

We've been saying all of this stuff, but not as elegantly.

I'd seen Jon's book before, but I wasn't sure that there would be much useful in it since it was five years old. And from a technology standpoint, it is fairly out-of-date. But, there is a lot of good stuff in there beyond the technology-specific information that is quite useful today.

Blogroll and Atom link

If anyone is wondering where these went, template modifications are lost when you change templates. I copied the old template to a text file, and will add those modifications back when I get a chance. But for now, I'm focusing on posting my ideas around the collaboration strategy.

Until I modify the template, this will have to suffice: Atom feed.

You can read about translating Atom to RSS if you don't have an Atom-capable reader.

Classifying collaborative technologies

As we work on our collaboration strategy, the biggest hurdle is how to communicate what exactly collaborative technologies are. In short, any tool that enables people to work together more effectively or in wholly new ways regardless of distance or affiliation is a collaborative tool. While accurate, this definition is so broad that some folks have difficulty getting their arms around it. "So, when are you going to roll out collaboration?" is not a meaningful question, and not one that you want to hear.

So, after discussion and consultation with others, we decided that there are two distinguishing characteristics of collaborative tools -- synchronous v. asynchronous and ad hoc v. formalized. In general, tools in a given quadrant have similar characteristics and address similar needs. Of course, there are tools that bleed over these neat boundaries, but it gives us a starting point.

On reason these tools bleed over is that many of them are really collections of multiple functions. Team workspaces such as eRoom or Sharepoint Services are examples of this. Another reason is that the physical space analogue of the tool may cover multiple dimensions. For example, there are many different types of meetings. While all are synchronous, they fill the spectrum between ad hoc and formalized. Virtual meeting tools may support some types of meetings well, and not support other types of meetings at all.

Another limitation of this model is that it doesn't show how collaborative technologies relate to other technologies. This was a common question asked as I used this model to gather input on business priorities and pain points. There was confusion around the relationship between team workspaces and document management, for instance.

So, maybe this approach, while somewhat helpful, isn't really the right approach.

Monday, May 10, 2004

New look and feel

Blogger has completely revamped their look and feel, adding comments, post-per-page, and tons of new templates, among other things. I selected this template because it has a floating right margin that will expand to page width, which is really handy when you are full screen at 1280x1024. There are a lot of other choices, though. Let me know what you think.

Tuesday, May 04, 2004

Groove v3 synopsis

Jon Udell provides a synopsis of Groove. It looks like many of the issues that cropped up in our cursory review are still there. There still is no integrated search, but you can script it. Hmmm....This could be okay, if you just had to write one script that provided a hook into your enterprise search engine, but somehow I don't think it works that way.

Speak with a single voice?

Guy highlights some good stuff about reputation and the Net which is equally applicable from a corporate or individual standpoint. What is a corporation, after all, but a (legal) fictitious individual?

Worthy of more examination is the unhighlighted tenet "Speak with a single voice." To be a credible poster, you must have a reasonably consistent style and tone. It seems logical that this applies to corporations also. However, this ends up being one of the arguments against public employee blogs. Is the company speaking with more than one voice. As an employee of the company, are you speaking for the company? Is a disclaimer good enough? Do the different voices make the corporation more human and less Borg-like? Are perhaps common corporate values more important than one voice? I don't know. Thoughts?

Sunday, May 02, 2004

Immutable Laws

I am enjoying this book a lot, especially the highlit chapters:

PART ONE: Establishing a Good Reputation

1. Maximize Your Most Powerful Asset

2. Know Thyself -- Measure Your Reputation

3. Learn to Play to Many Audiences

4. Live Your Values and Ethics

5. Be a Model Citizen

6. Convey a Compelling Corporate Vision

7. Create Emotional Appeal

PART TWO: Keeping That Good Reputation

8. Recognize Your Shortcomings

9. Stay Vigilant to Ever-Present Perils

10. Make Your Employees Your Reputation Champions

11. Control the Internet Before It Controls You

12. Speak with a Single Voice

13. Beware the Dangers of Reputation Rub-off

PART THREE: Repairing a Damaged Reputation

14. Manage Crises with Finesse

15. Fix It Right the First Time

16. Never Underestimate the Public's Cynicism

17. Remember -- Being Defensive Is Offensive

18. If All Else Fails, Change Your Name

Are there only 18? Probably not.

Are some meant to be broken or bent, on occasion?

Here's a surprise ... or is it? Alsop addresses reputation from the perspective of corporate entities, yet bringing it back to the individual - myself specifically - I find their observations work equally well at both levels. Isn't that interesting?

I imagine similar truths adhere when applying this analysis to variably sized teams.