For the Good of the Groupware, Quest for Better Will Go On
In presentations these days, Netscape Communications co-founder Marc Andreessen often gives a fast-paced rap extolling groupware as the first real “killer app” for internal company networks.
It’s a speech laden with enough buzzwords and stale hype to make even the greenest reporters and analysts blanch. But it has a ring of truth. If the purpose of corporate “intranets” is to tie together groups of co-workers, surely groupware--software that makes it easier for people to coordinate projects and work together--would be an enormous boon.
Yet today, even as the groupware strategies of the big players such as Netscape, Microsoft and Lotus come into focus, and customers begin to deploy their first groupware efforts, the line between hype and truth remains murky.
For one thing, once you strip away the marketing-speak, the technology that Netscape and Microsoft are billing as groupware is shockingly primitive. Netscape’s product, for example, is based on a 13-year-old protocol called NNTP (network news transfer protocol) that has long been used by savvy Internet users to form discussion groups. Netscape has extended the protocol in a few small ways and added a much nicer interface, but under the hood, it’s the same old technology.
Similarly, Microsoft’s groupware solution could just as accurately be described as “enhanced e-mail.” Sure, Microsoft Exchange helps people work together by facilitating communication. But so do fax machines. For something to deserve the title “groupware,” shouldn’t it take advantage of the power of computers and provide “intelligent” assistance?
When I brought up this shortcoming with Nathan Mhyrvold, Microsoft’s chief technology officer, he agreed.
“Yeah, it makes sense that software should be able to provide more intelligent support for cooperative work,” he acknowledged. “But no one has done that good a job of it, and I don’t have a good explanation for why.”
I’m not going to suggest that I know something that the adept and eclectic Mhyrvold doesn’t. But I think anyone who has ever tried to use first-generation groupware probably has a good sense of what the shortcomings are. If we focus on those, we might be able to figure out how to build groupware that works.
My first experience with groupware was when I was an editor at Wired, the monthly magazine about culture and technology. In an attempt to speed up the highly collaborative process of creating an issue, we decided to adapt the Quark Publishing System (QPS).
This complex and expensive program promised to act as a sort of orchestra conductor, ensuring that articles flowed smoothly from edit to design to production. No longer would articles sit on a designer’s desk while copy editors sat idle, wondering where the piece had gone to.
The program largely met its promise. And after two months, it was junked.
The problem was that we valued the ability to capriciously make changes at any stage too much to sacrifice it for gains in efficiency. We were willing to tolerate articles being delayed in the hope that it might result in more inspired design. The program might have made sense for a daily newspaper, where efficiency is critical, but for a monthly magazine, it was simply too structured.
Lucy Suchman, an anthropologist at Xerox’s Palo Alto Research Center, has seen that problem repeatedly.
“The more you automate a process, the less negotiation between participants you end up permitting,” she said. “And that negotiation is often critical.”
When I related the story of QPS to Mhyrvold, he echoed Suchman’s sentiments.
“If you work as a claims adjuster at an insurance company, then you’d want a structured tool,” Mhyrvold said. “But if you apply a structured tool to an unstructured problem, then people will subvert it. And unfortunately, computers are best at very structured problems.”
Just as problematic is when the logical structure differs from the structure of the organization.
Suchman tells of a groupware project at a law firm that ran into this quandary. The law firm had a very set pay and status structure that sharply distinguished between lawyers and legal clerks. This structure made sense in light of the firms’ view that legal document coding was essentially unskilled labor.
But as Suchman’s group investigated how work was actually done at the firm and tried to encode that structure into the technology, the conflict between what made sense for the firm and what seemed rational to an outside observer quickly became apparent.
“We found ourselves in the middle of a contest over professional identities and practices within the firm--a contest between one characterization of work, made possible by distance, and another held by those who did the work” and confirmed by her group’s observations of what it entailed, she later wrote.
Anyone who has ever battled with his or her organization’s information systems department over who has access to what files knows how much power technology can wield.
So where does groupware go from here?
Most experts still hold out hope that as we better understand how people work together, we’ll find ways to intelligently apply computers to the task.
“What we need to find are the ‘sheep dog problems’ for groupware,” Mhyrvold eventually concluded.
“If you want to herd sheep, a sheep dog is a great thing. It can respond to physical commands, it can bark and it loves to herd sheep. But you wouldn’t ask a sheep dog to help you with running the farm. Computers are not quite as smart as sheep dogs, but they are similar in that they have a few things they are very good at. We need to understand what those are.”
