At UC Berkeley's Institute of Industrial Relations, (IIR, http://iir.berkeley.edu) the library is charged with monitoring networked information developments, and the staff was on the watch for a campus portal product selection. While a variety of departmental intranets had popped up at UC Berkeley, no single standard had emerged. The campus had plans for a major new portal, but the exact scope of the product was unclear. Rather than wait, the library staff partnered with IIR's desktop support staff to create an Institute-wide intranet. The challenge was to create an intranet that would work with the other products and services available in the campus system without duplicating them.
Three Gaps in Web-Based Services
At research universities like UC Berkeley, the information environment is rich, and user aptitude with the Web is high. Faculty, students, and staff rely on IP authentication to access large families of library databases, statistical and analytical computing, online courseware, e-commerce and Web-based calendaring. In essence, IP authentication transforms the open Web into an intranet.
The question arose as to whether a dedicated departmental intranet was required or not. Library staff, in touch with the literature and news from the corporate sector, thought there was. Informal surveying of the 200-person community revealed three definite areas where both campus-level goals and local desktop services left significant gaps: calendar management, Web-based file exchange, and secure database development. Many corporations address these tasks with intranets and firewalls, but at Berkeley, there was no standard or toolkit for all departments.
IIR users were unaware of the potential benefits of departmental intranets. They were familiar with computing from desktop and laptop perspectives; the Web was for surfing and reference, not necessarily for group work or shared projects. However, users were creating original research but did not perceive its lively, interactive potential—and online community-building opportunities were being lost. Worse yet, some original datasets lived haphazard lives, even disappearing as desktop systems were upgraded or key professors were recruited away to other universities. The environment was ideal for a low-cost intranet—if the case could be made to the leadership. This involved education, as many faculty and staff members did not know what were the many different benefits of an intranet. An assessment of campus and UC systemwide plans was needed to avoid duplication with unpublicized portals under design.
Three Zones of Knowledge Management
To develop a departmental strategy, the IIR created a map of the information landscape that identified the key players and charted the zones of knowledge management in the university. The users' needs were understood (see above), but a coordination strategy was needed with other knowledge managers. This was especially important because many computing groups on the campus had overlapping goals. Three areas where networked information management was rapidly evolving emerged: the UC system level, the UC Berkeley campus, and departmental intranets. With this knowledge, a complimentary information architecture was designed that avoided duplication with other initiatives.
The campus- and system-level planners had not articulated any blanket intranet solutions for units like IIR. Some large professional schools (like the business school) ran intranets, while other groups that had the funds did not. It remained possible that a campuswide (or systemwide) portal might appear within a few years. Indeed, the UC system and the campus were engaging in more and more group licensing, a possible future point of synergy.
Given all this, the IIR decided that an open source intranet solution was best for two reasons: First, the campus computing culture favored Unix and supported open source computing; second, open source networking would keep costs lower. One open source product, Zope (www.zope.org), held particular interest. Its object-oriented methodology eased the learning curve for the library's Web administrator and a desktop support engineer. A prototype intranet was created with Zope, and an implementation plan was developed to engage the staff.
The Organizational Strategy
In an independent environment like academe, a lot of good ideas go up in smoke, usually for lack of collegial alliances or failure to communicate with specialists who care mainly about a narrow band of knowledge. To avoid this, the library formed a cross-functional team of librarians, researchers, and programmers. The intranet was described in plain English. Since the concept of managing files and data via the Web was a new one, the planning group started a seminar series called "Tech Lunch"—offering free food to gain an audience (a tried-and-true local strategy). The library staff and programmers presented a visually appealing overview using PowerPoint software. Line staff were invited to join a steering committee tasked with guiding design priorities. May 2002 was set as the rollout target.
Users' Priorities: Keep it Simple
The campus had licensed and customized a calendar program for both individuals and departments, called CalAgenda. It did not work seamlessly with any of the popular personal digital assistants on the market. Many individuals and whole departments resisted adopting it. At IIR, individuals used personal digital assistants for their own calendars, but paper calendars were used for managing meeting space. When community members saw how easy it was to use the built-in calendaring module with the prototype, their excitement level "sold" the whole project and identified the top priority.
Web-based uploading and downloading of native files created a lot of excitement at the Tech Lunch demonstration. The campus utilizes a wide variety of file servers, ranging from Unix boxes to Window NT4. A browser-based system made immediate, visual sense to the community. Users were involved immediately by uploading IIR's administrative services manual. URLs comprised a large part of the print edition (with links for e-commerce, course syllabi, etc.), and the intranet obviated the need for a paper copy altogether.
Academic researchers were developing restricted access databases for special projects. While the projects varied in content, they were similar from security and access management viewpoints. The intranet, with built-in security, solved several problems for developers of original content. It enabled IIR at UC Berkeley to plan future extranet development with its key partners, IIR at UCLA and the statewide Institute for Labor and Employment (http://www.ucop .edu/ile). This was especially appealing because an extranet would enable multiple campuses and members of the community to have secure, remote access to restricted datasets.
Lessons Learned
By July 2002, the IIR Intranet was functional, hosting the administrative services manual, as well as calendars for the two lecture and meeting spaces within the building. Users began adding files for group editing and easy exchange over the Web, easing remote access when traveling. The services met near term requirements, but if a campuswide intranet solution ever does emerge as a replacement, IIR's investment to date has been very low.
The development team guessed correctly that the successful use of the intranet depended on gaining and keeping buy-in from both supervisors and line staff. The administrative staff did not immediately grasp that the intranet was really just a new platform for doing typical work processes, and this concept took time to sink in. It was necessary to get supervisors and staff together at the same time to create the right conditions for learning. Although this was time-consuming, it also brought dividends in community building.
The IIR library team avoided duplication of e-commerce and teaching applications, which were campuswide priorities, focusing instead on "quality of life" computing that eased some hassles and added some new functionality. This strategy was simple but effective: It addressed knowledge gaps in the campus information architecture while educating users in newer styles of computing. By emphasizing basic intranet capabilities, the development team helped users perceive the intranet as an extension of their desktops and themselves as publishers of online content.