Menu
Menu
You Think Tomaytoes, I Think Tomahtoes

You Think Tomaytoes, I Think Tomahtoes

Dale Mead looked over 23,000 pages of documents in the Bay Networks database.

There were product specs, price sheets, sales presentations, competitive intelligence reports, white papers, press releases, news stories and dozens of other kinds of information. And they were, in Mead's mind, a mess. For Mead, who in June 1997 had just accepted a job as a knowledge architect at Bay Networks, a computer networking hardware and software company based in Santa Clara, California, that was the good news. Mead liked a challenge, and he liked to organise things. He loved figuring out why different people thought of the same thing in different ways and how their relationships coloured their thinking.

At Bay Networks, Mead's challenge was twofold. First, he had to understand how some 7,000 employees thought about each particle in the ocean of information that was swelling the company's database. Then he had to decide how to package it, slicing and dicing and referencing and cross-referencing so that most people could find more stuff with less effort most of the time. Mead had been itching for such a project for years. A former reference librarian and researcher in Apple Computer Inc.'s advanced technology group, he relished the chance to pioneer a Web-based knowledge management system. "I'm a knowledge addict," Mead says. "As a kid, I used to read the encyclopedia cover to cover.

When I found out that [Bay] was thinking along the same lines and had secured funding, I said 'Yeah, let's go!'"At that time, just two years ago, Mead thought it unusual to find a company deeply committed to building a corporate intranet, and Bay Networks appeared to be very deeply committed. Today, when many companies are thinking about where to start, Bay, along with its new parent company Nortel Networks, has something called the Information Management and Delivery System (IMDS), a US $3 million effort that connects 7,000 users to 3.8G bytes of data, organises 23,000 documents housed on 2,800 separate home pages and promises to reduce product cycle times by 10 percent. Company officials estimate that each member of the sales staff will save a minimum of two minutes a day searching for documents-time that translates into US $10 million a year. IMDS helps engineers test products faster, and it helps a great many people at Bay Networks do their jobs more efficiently. Within the networking industry, the Bay Networks/Nortel intranet is seen as a model of knowledge management. Inside Nortel, it is seen as a monumental effort with a big payoff.

In the pre-IMDS days, Bay employees suffered from information overload.

Overflowing e-mail boxes, stuffed voice mail systems and the Web were stealing time from more productive efforts. "We were a mess," says Steve Larsen, senior manager of knowledge systems architecture and strategies for Nortel Networks Inc. Many people in marketing had their own home pages on which they posted such things as news articles about the competition. While users loved having such documents posted online, without a central search mechanism they had a devil of a time finding what they needed.

Lisa Guess, director of systems engineering, says she spent a couple of hours a week searching for documents such as price lists, technical briefs and sales pitches for products. So did many of her colleagues. In order to find a document, Guess had to know which department put it out. Sometimes, because departments are organised around product lines, it was next to impossible for Guess to find what she needed. A white paper that explained how data transmission can be prioritised on a network, for example, would be associated with several products and could be housed under any of several departments' sites. Once or twice a week, Guess would have to call someone in another department to find documents. Finding what she needed, Guess says, was like searching through random stacks of books to find a particular volume.

In early 1995 Larsen proposed to upper management that the company try to clean up the mess by linking the many islands of information together under one system. At the time, the likely way to do that was with Lotus Notes or other groupware systems, a prospect that didn't thrill the people at Bay Networks because systems like those restricted the way documents were linked. "We didn't want the application to dictate how people work," explains Bay Networks CIO Jorge Taborga. The company hoped to encourage people to continue posting useful information on their own departments' home pages, something impossible with groupware that required everyone to place information on the groupware itself.

New groupware would also require extensive training, something no one was up for. So Larsen's proposal went on the back burner.

Just over a year later, in spring 1996, Larsen was back with a new plan, one that won the support of Michael Fox, vice president of knowledge systems.

Instead of relying on groupware, Larsen wanted to use a new technology, dynamic HTML, that promised to allow a Web browser to compile documents on the fly.

With dynamic HTML, programmers simply create templates that automate how information is presented online. When a user searches for, say, white papers for the Accelar family of data switches, the system would compile the list from components. Programmers would not have to create a page that lists all the white papers, a convenience that could save untold hours of grunt work. The technology looked promising. But the knowledge management architecture would not be so easily procured. It would have to be built from the inside out. Mead joined the project in June and wasted no time before digging into how information was used at Bay. He studied reference books such as the Predicast Revised Event Code & Event Name List, a reader's guide to the business press, for insight into how people look for information. He found that the directory indexed articles by three categories: product, industry and activity. An article on a WAN implementation, for instance, would be indexed under computer networking, high technology and information systems. Mead decided that Predicast was a good model for IMDS because Bay's documents would also fall in multiple categories.

Mead also learned that most business indexes classify business by function: manufacturing, marketing, sales, finance and so forth. But that traditional way of organising information alone wouldn't be suitable for Bay. The company's product development was split in two groups: one for businesses, the other for the telecommunications industry. IMDS would have to accommodate both lines of business.

Mead spent a year getting inside the heads of Bay users to find out how they wanted information presented. The first step was to use something called cluster analysis, a technique brought to Web navigation by Jakob Nielsen, Sun Microsystems' Web usability guru (see "Jakob Nielsen on Dinosaurs" an interview with Nielsen in CIO Section 2, Feb. 1, 1999). Mead enlisted about 25 volunteers representing all departments of the company. Each volunteer sat in Mead's office in front of a stack of 70 cards that listed a type of Web page that would go into IMDS. Each card contained a word designating a category of information, such as product lines, brands, product announcements, authors and approval processes.

The volunteers were told to place the cards in piles representing the way they would like to organise the intranet. Mead hoped to find out how users wanted to arrange and categorise documents. For example, did most users prefer to have press releases for Centillion ATM switches listed under "Centillion," "press releases" or "ATM"?Mead was surprised by what he learned. People seemed to have two entirely different ways of categorising information depending on whether they wanted to post information or look for it. When they posted information, most people wanted to organise it by department. For instance, engineers lumped all engineering documents under engineering. That tendency, Mead learned, was a holdover from the grassroots intranets that had been created mostly for their own departments.

When asked to wear their information consumer hats, however, most people organised cards differently, placing them under product groups. But even then, they wanted to look at the information in different ways, and those ways had more to do with what they wanted to do with the information than the information per se. For example, some marketing personnel wanted to jump from a product announcement to competitors' product announcements; others wanted to jump from the product announcement to a list of customers that would provide references. Users also wanted to be able to link to a company directory from the name of the author of a document.

Thinking back to his reference librarian days, Mead realised that he was in one sense creating online bookshelves. He had to make finding information on the intranet like finding books in a library. In a library, people used to walk from a card catalogue to a shelf in search of a particular book only to find another book a few feet away that serves their needs better. On a computer screen, that doesn't happen, so Mead had to present several ways to find things. He and his fellow knowledge architects would have to create aliases under multiple categories so that multiple links would lead to the same document: Users looking for Centillion press releases would be able to find them under "Centillion," "press releases" and "ATM products." On average, Mead learned, each document would link to four other documents, although some training documents linked to as many as 100 pages because they included references to multiple products, industry-specific sales tips and technical strategies.

Mead also had to figure out how information moved through the company. In fall 1997, Mead began a three-month program to study information flow. He sat down with about 70 people representing every area of the company for one-on-one interviews. Mead asked the volunteers to describe from whom they received documents and to whom they sent them. What he found wasn't encouraging.

In one case he learned that the people who wrote sales copy had little contact with salespeople who could give them valuable feedback. Mead figured that a feedback button for salespeople to offer critiques online would help close that disconnect. The IMDS team also had to make sure related documents, say, a product spec sheet and a report outlining competing products, were linked.

Sometimes, he found, a product would be improved, but the company's official competitive analysis report wouldn't reflect that improvement. Mead was determined that with IMDS, when a product's specification changed, it should be easy to find all the related documents that need updating. "A lot of processes got bogged down by poor information flow," Mead says.

Mead identified a troubling bottleneck between engineering and marketing, particularly during the development of new products when people in different departments needed to sign off on marketing collateral and engineering documents. During that process, he found, a document would occasionally stall at a desktop for a day or two while someone tried to figure out who needed it next. To keep things moving, Bay used Documentum Inc. workflow software, which can provide a road map for document routing.

Mead was less than pleased when the information flow research led from logistic analyses to a political quagmire. The problem was access: Who gets to see what and when. To keep competitors guessing about its strategy, Bay, like most companies, likes to keep a tight rein on new technical developments.

Mead learned that most projects follow a pattern in which the earliest stages are the most secretive. Products such as the Accelar family of data switches begin with an early conception and development phase primarily driven by operations and engineering executives. Next, product engineers start design. As a project moves forward, finance, marketing, public relations and sales get involved. After each project milestone, more people see specifications.

To make the matter more confusing and perhaps more galling, access privileges were assigned by role, not by title. A project manager has access to everything she needs for her own project but is shut out from information about other projects. She can call up the competitive analysis document that compares her product with the same technology Cisco Systems Inc. and other competitors have on the market, but she won't be able to see the comparable document for other products. In the latter stages of a project, it often gets harder to keep a lid on information. Key customers test new products, and Bay's salespeople occasionally hear about new product release dates from customers before they hear about them through official internal channels. "When the person in the next cube gets inside information before you, people get irked," says Fox.

The company's solution to all this was the formation of something called the New Product Introduction Council. Comprising representatives from engineering and marketing, this 20-person committee was charged with making the tough decisions on information access. With the power of the committee behind access issues, Bay found, workers complained less about being kept in the dark. It was Mead's job to take the committee's decisions and build them into IMDS. To do that, the project team created a Lightweight Directory Access Protocol, a central password clearinghouse that automates security access privileges.

Because IMDS delivers information on the fly in dynamic HTML, users see documents only for which they are allowed access.

After studying user preferences, workflow and security access, the IMDS team was ready to design the system. For inspiration, they looked to other Web sites. First, they looked at their competitors' sites, studying their navigation schemes. Then they checked out Yahoo, Amazon.com and other popular sites, borrowing ideas liberally and figuring that copying the most popular Web sites would result in an interface that was familiar to most users.

Consequently, IMDS mimics Yahoo's strategy of presenting categories before drilling down to documents. Because Mead and his team had learned that users wanted several ways to find documents, they built multiple indexes. Users can now look for documents alphabetically and chronologically. They can also look at a group of documents by type-all the white papers for ATM products, for example.

Mead's research revealed that users had strong opinions about how the system should look and feel. "They said, 'We don't have enough bandwidth in a hotel room to look at spinning wheels and fancy graphics,'" Taborga recalls. So the IMDS team strove for simplicity and used graphically sparse, low-bandwidth forms and templates.

In January 1998 the project team had a prototype ready to go, and Mead sought its first critique from a user. Jill Silva, Bay's external Web manager, did the honours. Because of her constant need for new information as well as her experience providing information to a boatload of users, Silva was a natural for the test. She, along with several others, poked and prodded the system for three months. She was on call to the team, talking in person or by phone to IS and knowledge systems people five times a day. And the two parties didn't always agree. Silva remembers a debate over a template to enter document attributes-key words, a brief description and where to route it-that forced her to scroll down three screens. That slowed performance. At her suggestion, the project team agreed to scrap that template and replaced it with three separate ones.

Ten users test-drove the system after Silva. Mead had them search for 10 documents that they would need in their day-to-day activities. The test didn't go well. Most users couldn't find what they were looking for. The main problem was that most information had been grouped by either product category or department, yet a lot of important documents didn't fit those categories. For example, Bay has product presentations and sales tip sheets to sell products to the banking industry. The IMDS team had to create new categories, like "financial services" and "ISP market," to suit industry-specific documents. It then had to link them to related products. When a sales presentation on the banking industry referenced the Optivity Network Management software suite, the presentation would have to link to the Optivity product line.

The confusion took 40 days to fix. When Mead was done, the prototype that had resembled a single decision tree had evolved into something that he describes as a group of trees that allowed cross-pollination. Because knowledge architects added more than a thousand links among documents, users could get to the same information via many more paths than in the prototype version.

When a group of 15 users tested the revamped system, they were able to find all 10 items. In May 1998 the intranet was officially rolled out to 7,000 Bay users, and yet another problem became immediately apparent: Users weren't aware of the various indexes-alphabetical, chronological, departmental-that were available. So the IMDS team added a button that linked to all the indexes.

Since then, things have run more smoothly, and most Bay Networks users have high praise for the system. Tyson Kostan, systems engineering manager, recently used IMDS to calm the Y2K fears of a key customer. By clicking on Y2K in the index, Kostan found a list of Bay's Y2K-compliant products, a list of software products the company feels needs remediation and a presentation that a colleague gave on Y2K.

"To get that information in the old days, I would have had to shoot out e-mails to several people in product marketing and the legal department," Kostan says.

"It would have taken days to get it." Guess, who used to spend hours looking for documents, says she can now find anything she needs in less than 15 minutes.

As for Mead, he got the news last September, when he learned that Nortel Networks, the US $18 billion telecommunications giant, was buying Bay Networks.

Suddenly Mead had to integrate his system, which had 23,000 documents and 7,000 employees, with one that had 466,000 documents and 75,000 employees. For most people, a scale up of that magnitude would seem like a nightmare. For Mead, whose hankering for a challenge had not diminished, it was a dream come true.

(Senior Writer Peter Fabris can be reached at pfabris@cio.com.)

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!

Error: Please check your email address.

More about Amazon.comApple ComputerBay NetworksCiscoDocumentumMimicsNielsenNortel NetworksSun MicrosystemsYahoo

Show Comments

Market Place

Computerworld
ARN
Techworld
CMO