Of Portals, Policies, and Poets

When we think about better ways of doing business at a university, the spur is often some new and compelling technology. Indeed, technology offers abundant scope for radical improvement to our processes. If we simply change our processes in response to evolving technology, though, we miss a valuable opportunity to reflect on the continuing relevance of the policies behind the processes and to review and reaffirm the institutional principles they serve. Introducing a campus portal is a terrific case in point for the effect that a technology project can have as a catalyst for institutional reflection and change.

Universities and Portals

Universities are drawn to portals as an effective way of organizing and delivering campus services and information. Looney and Lyman, for example, described a portal as an epicenter of the online experience.¹ In a university environment, where the desire for local autonomy and the impetus for centralization are in constant tension, a portal seems especially appealing because it allows local solutions through a shared medium. But the very fact that a portal cuts across many sectors of the campus, delivering services and information that transcend organizational boundaries, means that implementing a portal raises important questions about jurisdiction, responsibility, and authority.

Such questions cannot and should not be addressed by the technical team. As others have noted,² a successful portal project is as much a social exercise as a technical one, and it demands wide community engagement. A portal implementation is an opportunity to bring together service providers, system developers, and user groups who might not normally work together, providing incentives for them to collaborate and to reflect on common processes and shared principles. Both this collaboration and this reflection are unanticipated but enormously valuable byproducts of a technology project.

This article arose from our experience introducing a campus portal at the University of Saskatchewan, a publicly funded research-intensive university offering a range of undergraduate, graduate, and professional programs to some 20,000 students. As our project evolved, so too did our understanding of where we needed to direct our attention. We began by conceiving the portal implementation primarily as a technology project, soon broadened our perspective to emphasize content, and then came to see that an even broader view was called for—one that acknowledged the importance of technology but placed far greater emphasis on content, community engagement, and the range of policy implications that our project exposed.

A Technology Project …

By the spring of 2003, various constituencies around the University of Saskatchewan had been exploring the idea of a portal for several years. Considerable groundwork had been done to map out requirements and to identify potential service providers across campus, but the initiative had stalled, led as it was primarily by our IT division and other technical staff on campus. Parts of the university community were fishing for a portal implementation, but senior administration, leery of yet another costly IT project, wasn’t nibbling.

All that changed in late spring when the university purchased new student and finance systems and incidentally acquired a portal product. Including the portal in the overall purchase price was justified by the promise that the new portal would serve as a common gateway, not only to the newly acquired enterprise resource planning (ERP) systems but also to a host of existing systems (a mix of vendor and home-grown applications) covering areas such as human resources, library, student computing, advancement, alumni, and e-mail. As the vehicle for single-sign-on access to the institution’s various administrative systems, the portal could have been, and initially was, construed as a technical solution to the problem of providing more consistent access to multiple back-end systems.

It would take at least 18 months before our newly acquired student and finance systems could deliver services such as Web registration, electronic payment, and online access to accounts through the portal. The portal itself, though, had the capacity to provide some functionality (such as calendar and course management tools) right away, and other readily available services and sources of information—like campus news feeds and a Webcam—could easily be delivered through the portal’s channels. Some “throwaway” links to our legacy student information system, such as grade reporting and online examination schedules, could be developed quickly and then replaced once we were ready to deliver our new administrative systems. It seemed a shame to leave the portal on the shelf until the new ERP systems were ready to provide full functionality. Thus we boldly decided—having signed the contract for the software in June—to bring the portal up by September, when our students returned for fall classes. This gave us two months to implement the portal. We were determined and confident we could do this if we set achievable targets.

We knew we had to work effectively to put together our project team and our governance structure, train our team members, select and organize our content, and choose the portal’s name and look, all in the face of an aggressive schedule driven by the academic calendar. We had no time to secure the blessing of senior administration for this project or obtain funding for it. We knew we were taking some chances, but we had the opportunity, we had the technology, we had the desire, and we sensed a will on the part of our community. And thus,

It’s not easy to implement a portal in two months, but it can be done if you don’t try to do too much too fast. We began by focusing on services to students. Our initial plan involved delivering existing services with the new technology. When timelines are short, decisions must be made quickly, and so we created a nimble governance structure led by a four-person steering committee comprising the Associate Vice President for ICT (Bunt, also the project sponsor), the Director of Student Information Systems (Pennock at the time), the Director of IT Services, and the Manager of Student Computing (who was given the job of project manager).

As we began work that summer, it’s fair to say that we still saw the project primarily as a set of technical issues to resolve—such as implementing single-sign-on access and integrating with our existing middleware technology and communications tools³—and our initial focus was on assembling the right technical resources. We knew there would be other work involved (we needed content, after all), but we didn’t fully appreciate where this work would lead us. As it turned out, not until we got beyond thinking of the portal in technical terms did we realize what this project could do for us.

… But Also a Content Project

Our maturing sense of the scope and implications of launching a campus portal began with a nudge from our vendor consultants. Acting on their advice, we began to consider more carefully the broad impact that the project could have on campus. Workshops on content planning and organizational planning helped us see beyond the technical issues to the necessity for addressing things like roles, processes, layouts, and content life cycles. We began to see that implementing a portal is much more than deciding how to integrate the software with existing middleware and administrative systems. We quickly realized that just as our team needed a technical lead, it would also need a content lead—someone who would facilitate discussions about which content should be delivered in which channels, what roles should be assigned, and what the interface would look like.

In addition to our project manager, technical lead, and content lead, we pulled together a core project team consisting of a small group of technical staff, some designers and writers, a central Webmaster, and an administrative assistant. Meanwhile, we continued to nurture our communities of support through an advisory committee with broad campus representation, primarily staff members in our academic and administrative units who had functional responsibility for various services to students.

Since we had initially conceived this as a student portal, our first focus was on rolling out services to students.⁴ Serving students effectively with a centralized service in a distributed environment presupposes engaging many offices whose activities affect students. This means that these units are critically important clients as well as service providers. By engaging potential service providers early, we got them excited about the possibilities for using the portal.

Acting under budgetary and time constraints, we adopted a co-development model in which the project partnered with service providers to develop applications for our fledgling portal. In retrospect, this model paid off in unexpected ways, creating a sense of engagement and involvement that was a critical factor in campus acceptance. And we learned that to serve communities, we needed to build communities.

As Zazelenchuk and Boling pointed out, “Portal designers wrestle with presenting large quantities of information in a manner that is both organized and aesthetically appealing.”⁵ Our content lead helped us appreciate that the look and feel of the portal is not merely a cosmetic consideration but a fundamental means of gaining acceptance. We wanted a name and a look that would resonate with both users and service providers, so we took considerable care to do this right. We looked at other portals, polled segments of our community, and presented some designs for consideration. In the end we chose PAWS (Personalized Access to Web Services), a name and an image readily identified with our campus sports teams, the Huskies. The name tested well with students, and we were able to recast a well-established and readily identifiable institutional symbol.

We knew that engaging our faculty colleagues would be critical to our success, and we knew we had to work to make this happen. It was inevitable that many would resist adopting the new technology, but we counted on some keen early adopters to help us. We selected 10 faculty members to act as a pilot group for the first term. They agreed to take training in the course management toolset and to use the portal in their classes. We provided them all the support they needed, and in turn they gave us feedback on strengths and weaknesses of the technology.

Our faculty pilot added great value to the project. Not only did the participating faculty members test drive the portal for us, they also worked closely with our development team and gave us useful advice. They and their students became advocates for PAWS.

We decided early on that our September launch would be a quiet one. We didn’t want to make too many promises, and we wanted to keep user expectations in check. Better to under-promise and over-deliver than vice versa! Our first offerings would be quite limited, and we would add new services as they became available. As it turned out, this incremental approach was exactly right. Interested users found the portal, and its usage grew steadily as word spread and new services appeared. We were able to sustain this interest and build momentum before our official launch in spring 2004.

We were ready to go on September 4, 2003, in time for the start of classes. We went live with essentially out-of-the-box functionality primarily targeting students—including e-mail,⁶ a personal calendar, some collaboration tools, a few information channels, and access to online course materials—all presented through a single-sign-on, personalized, customizable interface. We had set up accounts for more than 30,000 potential users, linked the product’s course management subsystem to more than 3,000 fall term courses, and provided single-sign-on access to a variety of online library services (the library was an early and enthusiastic co-development partner).

Even though we launched with no fanfare, during our first week of operation more than 4,000 users found the link to PAWS on the university’s home page and logged in. Word started to spread, and an early fall article in the campus newspaper helped build awareness. Our focus on services to students paid off: we gave students some services they had sought, and they endorsed the new portal with enthusiastic comments and in the alacrity with which they signed on as new users. As one student wrote in an e-mail message, “[This] was my first experience with … PAWS and I was blown away…. I feel like I have more control and can manage my entire academic career from this one site.”

Content development was a major priority through the fall and winter, along with some technical upgrades. We introduced a range of information channels, from current events to sports team schedules to weather. Temporary links to our legacy student information system enabled new services such as personalized exam schedules, grades, income tax receipts, and transcript ordering to be delivered quickly. By spring 2004 we were ready for an official launch. More than 200 faculty and staff had taken PAWS training. We had 12,000 users, 4,000 courses, dozens of channels delivering both information and services, and 50 special-interest and administrative groups using the portal’s collaboration tools. The rapid pace of adoption made it clear we had sufficient content to tempt new users.

… and Even a Policy Project

The third stage of our awareness of the scope of this technology project came early, as the project began to expose questions and issues in the realm of institutional policy. Having conquered the technological challenges and made countless operational decisions around content, we found ourselves facing more abstract questions that hinged on the nature of the portal as an agent of social and cultural change. This was a “eureka!” moment for us. In about two months we had moved from focusing on technology to focusing on content to focusing on institutional policy.

We confronted issues more far-reaching than we could reasonably expect either a technical lead or a content lead to resolve for the institution. Suddenly we were into the murky areas of authority, responsibility, privacy, and stewardship. The issues we needed to address before we could proceed clearly exceeded the authority of our advisory group and would require the attention and participation of senior administrators—associate vice presidents, deans, and directors—to resolve. In some cases the solutions would require adjustment to institutional policies. We quickly moved to set up a portal policy management committee.

Perhaps the need for a senior policy body for the portal project should have been clear from the outset, but our experience tells us that a proposal for such a thing would have fallen on deaf ears as long as the portal was still understood as a technology project. The first response from our senior administrators to an invitation to sit on such a body would have been (indeed was) to delegate participation to their technical folk. Only after the concrete reality of an installed portal forced the policy issues to the surface was there sufficient clarity to compel the attention of the policy makers on campus. It wasn’t until we could come to our senior administrators with examples that the abstract considerations of portal policy became clear.

We are convinced that policy development and content development need to proceed synchronously. Without real-life examples of the issues, however, you can’t win the attention of those at senior levels who need to be engaged. Policy work becomes meaningful to them only when they see concrete issues to resolve. Our project provided us with a need and an opportunity to review existing policies and processes in a number of areas, to get senior administration involved, and, where necessary, to refer back to some core principles to find a solution.

Data Ownership

Among the first issues the project uncovered were questions related to ownership of data and other content—who is responsible for collection, storage, accuracy, distribution, updating, and removal of institutional data? A good example came in the wake of our deployment of tools for course management in the portal. These tools enable students and faculty to use functionality such as file sharing, instant messaging, e-mail distribution lists, and calendaring to manage their assignments and other interactions for the particular courses they are taking or teaching.

It was a pretty straightforward matter, technically, to create course pages for each of our courses and to populate the database with the students registered in them. That information was held centrally in our student information system. More problematic was the fact that we had no central database to keep track of who was teaching each section of each course. Without that information we couldn’t link faculty to their courses. The information we needed existed in electronic form, but it was maintained in many disparate local databases—in departmental offices, the exam office, the room scheduling office, the institutional planning office, and so forth. Not one of these databases was 100 percent accurate because the various sources collected their information at different times of the year, and some contained information that contradicted data held in the others.

Our need for access to this data exposed some process issues but also uncovered a policy gap. Who was the institutional authority for collecting and maintaining this information, and how was that authority translated into reliable data? Rather than simply create yet another process and yet another data source, we addressed this issue by going back to principles (data should be captured once, at the source) and policies (department heads are responsible for assigning faculty duties). We located the authority for the information we needed (the department heads) and set up a simple mechanism for them to provide the information via a Web form. Through this we created a single, accurate data source that could be used by the various applications requiring this information, including PAWS.

A specific need of the portal had uncovered a policy gap that led us to be more intentional about assigning responsibility for data stewardship. Our simple solution to the problem revealed (but not created) by the portal replaced a series of cumbersome practices with a new, improved process. The outcome is a single data authority, complete and consistent, that everyone can use.

Eligibility for Services

Another policy issue the portal exposed was eligibility for institutional services. As at other universities, our practices for providing services to students, faculty, and staff have often grown up in an ad hoc way. Providers of every kind of service—from library cards to counseling to athletic facilities to computer lab access—made their own decisions and assumptions about who should be entitled to use the university’s facilities, amenities, and offerings. The lack of consistency in this area came to the fore in the portal as we faced the need to assign each user a role and attendant services.

As we struggled to define roles and began to ask questions about eligibility for services, it became clear that, as an institution, we had vague and often contradictory definitions of student, faculty, and staff. When, we asked, does an individual become a student—on first application to the institution? On acceptance? On first registration? On first attendance? When does that relationship end—at the end of term? On graduation? During a suspension? What about students at federated or affiliated institutions? Students on internships or clinical placements? Non-credit students? And the apparently straightforward question, who are our faculty?, proved not easy to answer either. Do we include clinical supervisors? Faculty from other institutions involved in graduate supervision? Professors emeriti? Visiting scholars?

We discovered that the answers vary, depending on whom you ask. For the library, which carefully limits its patron list for reasons of adherence to licensing agreements around electronic journals, the definitions for students and faculty were very different from the ones put forward by the registrar, the faculty association, or the alumni office. Not only were the definitions inconsistent, there was no agreement on whose definition held authority. As a consequence, individuals from various groups got contradictory messages about their status as members of our community and about the amenities and services available to them.

Again, the portal did not create this confusion, but simply exposed it in a way that gave us the opportunity to go back to some first principles about who we defined as members of our community and the extent to which we as an institution wanted to ensure that they shared in our services and facilities. This led us to create a data use policy that allows us to deliver services in a more consistent way by identifying the institutional authority for data stewardship for students, faculty, staff, alumni, and retirees.

Compliance

Inconsistent local practices can also increase the institution’s exposure to risk. In the highly decentralized environment that characterizes most universities, issues like appropriate release of information and protection of personal information depend on the vagaries of local appreciation for the importance of such protection. Deans, department heads, and administrative offices each take on authority and responsibility for monitoring appropriate use of local communications vehicles (Web sites, newsletters, posters in the hall) and for assuring protection of electronic and paper files containing personal information about students and faculty. When you introduce a portal into such an environment, suddenly it becomes much clearer that the institution itself is a stakeholder in, and has ultimate responsibility for, ensuring appropriate protection of privacy.

Similarly, issues relating to freedom of speech and of association come to the fore. As soon as the portal was launched and our community began to recognize its potential as a vehicle for targeting communication, special-interest groups on campus began asking to set up member groups to use the new collaboration tools. Requests came from formal and informal campus clubs, from advocacy groups, and from employee bargaining units. These requests raised important questions about the university’s rights, responsibilities, and obligations to ensure that use of this technology is appropriate, consistent with our policies (if one applies), and compliant with federal and provincial law. What constitutes due diligence here, and whose responsibility is it to provide oversight and controls? To what extent is the university liable when unfortunate consequences arise from an individual’s or a group’s use of an institutional resource? And who can and should make all of these decisions?

The answer to the last of these questions, at least, was clear. Decisions around institutional risk must be addressed at the highest levels, not assumed by (or delegated to) “the computer people.” Our portal project brought these issues to the attention of those senior administrators who needed to address them and ensured that appropriate measures were put into place both for making decisions and for educating members of the campus community about their responsibilities.

Prompting Change

The cause of progress is not always best served by clarifying or declaring an institutional policy. Sometimes what’s needed is not a directive but an incentive. Champions of IT are painfully aware that despite the many compelling reasons to do so, it is always difficult for an institution to impose or enforce technology standards. Users develop powerful attachments to their personal e-mail systems or word processors and resolutely resist any attempt to move them to something else.

As we implemented our portal, we realized that for PAWS to be effective, users would need to accept change in some key areas. We needed to find the right enticement to persuade our users to adopt standard tools. As an example, we had no single, central practice for identification and authentication of users. We did have a campus-wide identifier, which all eligible users have, but it was not universally used. Various colleges and departments, and even some of our administrative units, run their own IT environments with their own local identifiers, using their own systems and processes for authentication. When we introduced the portal, we decided to accept only the campus-wide identifier as the login credential. Desire to access the functionality offered through PAWS was the incentive that the campus had lacked. While we had many calls from users who didn’t know what their campus-wide identifier was (since they had never used it), we got almost no opposition to the decision to use it. Quietly, and with little push back, we achieved a centralized authentication solution. It wasn’t necessary for us to write policy to force this to happen, and changing practices through use of the portal may smooth the way to the eventual introduction of new policy.

Reflecting on Policies

These examples illustrate some of the opportunities that implementing a portal can bring to a university. The project exposed a range of issues, a number of which caused us to examine core institutional principles and the policies that support them. In fact, our experience has inspired a comprehensive institutional review of policies and policy processes—a review that’s presently under way.

How the Campus Responded

It’s been more than two years since we rolled out the portal. Our community has responded positively, and PAWS quickly became a common word on campus, demonstrating that “if you build it, they will come.” Students have been enthusiastic supporters from the outset. In an interview for the student newspaper shortly after our launch, the incoming vice president of the undergraduate student society singled out PAWS as one of the best things the university was doing to help students.

PAWS has also helped us encourage faculty adoption of technology, a hitherto elusive goal. We have seen this not only in their use of the portal to access various institutional services but also in their increasing use of the course management tools, which have proven popular with students and faculty alike. As a faculty member in the history department told us,

In addition, surveys (conducted through the portal, of course) and focus groups provide valuable feedback about what users and prospective users like and don’t like. Not all the feedback is supported by the facts, however. For example, focus groups told us they considered “frivolous” channels such as “joke of the day” and “word of the day” to be unwelcome distractions, yet those are the two most popular channels in PAWS. This response might simply reflect the serious nature of people inclined to attend focus groups. Perhaps the most valuable lesson is the importance of letting users customize their own layouts.

In the meantime, PAWS continues to develop, and its usage continues to grow. We now have more than 20,000 users, approximately 13,000 daily. PAWS is widely accepted as a delivery platform, and we’re adding new functionality all the time as our co-development partners identify the portal as an ideal place to deliver new services. (Some recent examples include online surveys, elections, classified ads, and parking permits.)

The portal now has over 50 channels and more than 5,500 courses. Our group studio serves more than 250 groups with diverse interests, including the History Teaching Group, the Comedy Club, the Neuropsychiatry Research Units Discussion Group, the Volleyball Addicts, Students Against Global AIDS, the Campus Carpool, High-Performance Computing Researchers, the Drumming Circle, and the Medicine Class of 2008. As we bring these groups together, we are reminded of the richness and diversity of our campus community and of the fact that it takes all kinds—database administrators and graphic designers, librarians and poets—to build a portal that reflects the kind of university we aspire to be.

Concluding Remarks

Portals are a wonderful fit for universities. Like universities themselves, they participate in the tension between distributed and centralized approaches and processes, providing both a way to centralize services and a way to distribute them. A portal’s approach to service delivery respects local autonomy in the realm of processes and data, and simultaneously enables institutional coordination of look and feel, presentation and style. Furthermore a portal, like a university, is all about community—both the wider community and the smaller communities that compose the whole. PAWS has helped us serve communities of users and service providers while also building and tapping in to them. The portal’s tools for communication, group work, and collaboration enhance community and connect to principles of encouraging expression and dialogue and freedom of association, principles that lie at the heart of what a university is all about.

Our portal project has done a lot for our university. We expected to benefit from new functionality, and we have, but we have also benefited in ways we hadn’t anticipated. Implementing our portal forced us to come together to address gaps and contradictions in policy, in authority structures, and in responsibilities by exposing and giving urgency to issues that were always there but that nobody had stepped forward to resolve or even recognized as problems. The project demonstrated that service delivery work and policy work need to be done synchronously. It also showed us that policy work becomes more meaningful when there are concrete problems to solve. In a university environment—an environment notorious for resisting change and clinging to tradition—successful introduction of new policies or new processes requires continual reference back to enduring institutional principles.

We believe that we had a richer experience and a better project because we involved so many members of our community in thinking about how a portal could help our entire campus to achieve its collective and individual goals. This project reminded us once again of the wealth of resources available at a university. Tapping into these resources can make all the difference for a campus-wide project like this, which will be most successful when your poets work hand in hand with your programmers.

Postscript

Since the portal project’s tentacles touched so many different areas, many stakeholders came to the fore as it progressed. By the time of our official launch, we’d been at this for nine months, and more than 100 people had made direct and significant contributions. We wanted to thank them very publicly for making PAWS such a success, and so we threw a party at the university president’s house for them. This was an opportunity to congratulate the project team and celebrate a job well done, and also a chance to let the university know that something significant had happened. Testimonials came from the president, the provost, and the vendor’s vice president. Our thanks came in verse: