Consorting with Competitors

To thrive in a connected world, businesses need common standards. That’s why we’re seeing such a proliferation of industry consortia: groups of companies working together to develop technical terms and protocols that can serve as the basis for shared processes. Because consortia require competitors to collaborate closely, they can be difficult to set up—and even more difficult to keep on track. Indeed, the mixed results of consortia to date reveal how hard it is to make these complex new forms of business work. I’ve recently been involved in a technology industry effort to develop specifications for what we call Universal Description, Discovery, and Integration, or UDDI. In essence, UDDI makes it possible for companies—or units within companies—to transact complex business using a shared electronic directory to describe their products and services, find suitable partners or applications, and integrate them. When we established the UDDI project, we were cognizant of the many risks and challenges involved, so we carefully examined the experiences of other consortia, both successful and unsuccessful. Our painstaking approach paid off. The UDDI effort has succeeded beyond almost anyone’s expectations. Thousands of companies are already using the directory as a foundation for electronic business, and many large enterprises are using the same technology internally. Five practices had a lot to do with the consortium’s success: Stay focused. Most industry consortia set their sights too broadly. They try to anticipate every contingency and cover as much territory as possible, figuring that since they’ve gone to all the trouble of pulling the group together, they may as well solve all the industry’s problems. The goals quickly become lofty, and members get lost in airy, aimless discussions. With UDDI, we kept reminding ourselves that our goal was to solve the specific problem at hand in the simplest way possible. Anything more was too much. Most industry consortia set their sights too broadly. The goals quickly become lofty, and members get lost in airy, aimless discussions. Be inclusive. At the same time that we were narrowing the scope of the project, we were widening its membership. Again, that ran counter to common practice: Most consortia aim to assemble just enough expertise to come up with a good technical design. But that approach never gets the buy-in and shared understanding necessary for the recommendations to be implemented. So instead, we recruited broadly; we brought in executive-level representatives from every organization that would be important to the UDDI project’s ultimate success. This meant that relationships had to be established across companies that are fierce competitors. My first project briefing, for example, was at Oracle’s campus at Redwood Shores—most uncomfortable territory for a Microsoft manager—and our team has weekly, if not daily, discussions with our peers at Sun as well. But we’re now reaping the benefits of our inclusive approach, as companies throughout the industry embrace our specifications. Acknowledge competition. Cross-industry groups usually assume that their members will be suspicious of one another and disinclined to play nice. Some leaders try to sweep the entire issue under the rug, which often serves to heighten the tension. Others try to discourage any sense of competition, but that can also backfire: Members become so comfortable together that they compromise proprietary information. The UDDI group made a point of acknowledging that we represented competitors. Every member supported a clear statement on the issue: “We’re collaborating on the core specifications, and we’re competing on the implementation.” This kind of clarity about boundaries makes cooperation much easier. Look to the ultimate implementation. Industry consortia are usually formed because a standard needs to be set—and usually that task is seen as a question of spelling out specifications. More times than not, a group of people “goes underground” for a year or more and then emerges with an unwieldy, academic report. The UDDI team looked beyond the written specifications to the ultimate implementation. That meant that we explicitly dealt with practical issues like making sure our directory was compatible with a wide range of technologies. As a result, companies have been able to take our work and hit the ground running, regardless of which vendors they use. Don’t wait for perfection. Software marketers are big believers in a quick release cycle. They know it’s better to get a good-enough product into customers’ hands fast—and plan to upgrade it soon—than to wait to ship a product that has every last bell and whistle attached. It’s amazing, then, that even in the software industry, consortia take the opposite approach. Usually, they see themselves as standards bodies, not as product developers, and they try to cross every last “t” before revealing their work. The UDDI group, by contrast, drew up a tightly scheduled release road map, just like those its members use to plan products. It committed to three specific releases. When each deadline arrived, we “shipped” what we had completed, holding incomplete features until the next release. Without those hard deadlines, we would probably still be struggling to put together our first document. While UDDI was a tech industry initiative, its lessons are transferable to any group that crosses industry or company boundaries. They all reflect a hard-nosed, results-oriented assumption—that industry consortia are business projects that must produce practical solutions and deliver returns far in excess of investment.

Consorting with Competitors

Partner Center