Portland State University Functional Needs Assessment Report

January 31, 2001 John Savarese • Linda Fleit Edutech International Table of Contents Organization, management, and leadership Resources Web hosting infrastructure, servers, operational support Software People and skills Relationship of UUPP Project development to other campus Web initiatives Issues related to the continuation of the Project beyond the initial grant period Questions posed by this institution Organization, management, and leadership The Portfolio Project (PP) at Portland State University (PSU) has gotten off to a very collaborative start. Early on, the Office of Institutional Research and Planning (OIRP) established a very meaningful Faculty Advisory Committee, and involved its members deeply in deciding on the nature and content of the portfolio. This established a very good sense of partnership with the faculty and other elements of the campus and established a very positive attitude toward the PP. OIRP has done a good job of making the PP very conspicuous and well-known on campus. The PP has had a beneficial effect on OIRP itself. It has coincided with an effort by OIRP to transform itself into more complex service. Instead of merely being a collector or generator of data, OIRP is now taking a stronger role in two areas. The first is acting as a broker or coordinator, bringing together other groups on campus to help produce more useful information about the University, and the second is developing ways to communicate information effectively to various audiences. This effort by OIRP to extend its role has been stimulated and aided by the PP. The PP has strong administration-level support from the Provost and the PP has been firmly located in the OIRP. This success of the PP in getting itself firmly established, however, has bred its own problems. For one thing, the very success of the Project has made it an attractive vehicle to support additional purposes, such as planning and reaccreditation. While these can be valuable and appropriate roles for the PP, the immediate progress of the PP (and OIRP) is in danger of being slowed down by the burden of taking on multiple roles. Also, the collaborative nature of the original design process, while very appropriate in setting the general direction of the project, may be keeping the project focused on the stage of overall design, while the time has come to move on to implementation. The PSU PP was going through an overall redesign at the time of our visit, which was expected to be completed by the end of December, 2000. The project was on track to roll out a full version of the Portfolio to the campus by June 2001. The Portfolio will be aligned with PSU's major theme, "Great City: Great University." This seems a natural tie-in with the themes that have been selected for the Portfolio: Community Pathways, Teaching and Learning (assessment), Research and Scholarship, and Institutional Effectiveness (quantitative measures). Recommendation: It is appropriate at this point to make a deliberate move from the initial planning stage to the stages of implementation and completion. The nature and purpose of the Portfolio Project, at least Phase I, should be sharply defined and limited. Formal project management should be instituted for the project, with milestones and narrowly defined objectives. The role of collaborators and supporters now should be to help move the project forward to completion of its first phase. Additional functions for the Portfolio can be planned at this point and their later implementation positioned on the project schedule, but they should not interfere with getting the first phase of implementation completed. When the core concept of the PP has been implemented, the other purposes will fit naturally on top of that foundation. Resources Resources are required for the Portfolio Project in several categories. In this section we describe these resource types and discuss where they are coming from now and where they are likely to come from in the future. We also discuss whether the right quantity and quality of resources are available to complete the initial implementation of the project and then to sustain it after the grant period. Web hosting infrastructure, servers, operational support Web servers with sufficient processing power, hard disk space, and other resources to handle the content of the PP and the expected traffic Internet connectivity (bandwidth to internet service provided) Operational support to keep the infrastructure running on a daily basis The Portfolio Project has been the beneficiary of an especially good relationship with a supportive IT department. However, the IT department is not currently set up or funded to provide very strong support to Web development and deployment in general across the campus. The deployment of the initial Portfolio prototype has been made possible because the IT department made space available on an existing Web server. The two Sun servers in IT currently support 400 Web sites. The Portfolio is sharing existing PSU Internet connectivity. The understanding on both sides seems to be that IT will provide a platform and connectivity as long as it can. Since the design of the Portfolio is still evolving, it is not known at this time how much resources it will ultimately require. At least one of the sections of content that is still being planned, the assessment section containing samples of student work and perhaps audio and even video statements by students, could put large demands on storage space, CPU power, and Internet connectivity. However, it is possible that the assessment project could establish its own resources as a "satellite" site to the Portfolio. Recommendations: Discuss with the IT department the possibility of establishing a more formal Service Level Agreement, to make the expectations on both sides more explicit. The SLA should spell out how much disk space IT can provide, how many hits it can service, and what kinds of media it can support, before it is necessary for the Portfolio project to provide its own server. Software Web server software; database and gateway software for dynamic content Access to a suitable campus-wide administrative information system, data warehouse, and tools for extracting analytic data, for static or dynamic inclusion in the portfolio Software tools for creating content and managing a complex site as it changes over time, including a way to manage evolving versions of content and to maintain navigation and links as the changes are made to the structure of the portfolio Software tools for end users to use to make routine updates to content PSU is using Zope as a development tool to build its prototype of the Portfolio. PSU is using an outside consultant with Zope expertise to assist with this. In fact, the adoption of Zope has largely been driven by this consultant's advice, and PSU is in the process of determining whether Zope is a good fit. This raises a number of issues: What problems does Zope solve for PSU? What effect does it have on resource requirements? Does it provide a sound foundation for moving forward with the Portfolio? Zope is many things rolled into one. It may well be the most comprehensive single product available for developing Web sites. It combines multiple functions that in other environments are usual performed by a collection of separate tools. (For example, it contains a Web server, a scripting language, and a database, among other features.) But even beyond that, it also automates some aspects of creating and maintaining a complex Website that must be done by hand in most other environments. It provides a security system which limits what each person can change and allows certain privileges to be delegated. Zope collects all the pages, images, and other items that make up a Website into a database of objects. It provides a mechanism that allows each page in a Website to automatically "acquire" (inherit) certain features that are common to the family it belongs to. So a navigation bar, a header, or a footer could be automatically included in a page, depending on which section of the site it belonged to. Significantly, these acquired features could be changed by altering the parent copy once, rather than requiring someone to find and change each page by hand. Besides its technical sophistication, there are some pragmatic aspects to using Zope that make it attractive. It is Open Source software, which means it is free, the source code is readily available, and it is maintained and enhanced by a community of loyal volunteer programmers, as well as being supported by a commercial firm. It is efficient and requires less computer horsepower than some commercial software (although everyone agrees that the more CPU power Zope has, the better it runs.) The cost of the software and hardware, however, is going to be a relatively minor issue in the long run for the Portfolio project. The cost of technical support and the time of functional staff will be more significant. Does Zope hold the promise of allowing non-technical users to maintain a complex Website and add to it? At some levels, yes. Users can be allowed to update the text on a certain page, for example, and not on others. Users would do this through a familiar Web browser interface. A powerful feature of Zope is that it helps manage versions as they change, and even allows a site administrator to roll back the Website to a previous version. Zope is designed to be a big help to a large group collaborating on a complex Website. At a more technical level, Zope also assists developers in creating and maintaining pages with advanced features, such as dynamic access to a backroom database. But advanced features such as that require the use of a scripting language that possesses all the power and complexity of a programming language (DTML). Proper use of the advanced features requires a full understanding of the underlying structure of the Zope system. Although it can be argued that Zope allows non-technical users to create effects that they would not be able to otherwise, the higher levels of Zope are really designed to assist the Web programmers who would otherwise be programming with tools and environments like CGI, Perl, Java, JSP, ASP, or PHP. Of course, non-technical users could develop and modify pages using WYSIWYG page editing tools such as Dreamweaver or Page Mill. But they would not get help from their WYSIWYG editors in dealing with the complexities of DTML source code. How would the adoption of Zope affect the need for personnel to support the Portfolio? The need for high-level technical expertise and programmer skills to design, manage, and enhance the Website would remain high. This high-level technical support would have to come from people who know Zope. The Zope community is certainly enthusiastic and growing, but Zope is far from being the dominant environment in the industry , and perhaps it has not yet even acquired mainstream status. At PSU there are some outposts of Zope development, but it is not the prevalent standard. The PSU IT department has a receptive attitude toward Zope, but has not yet adopted it as a standard with guaranteed support, taking a wait-and-see attitude. Asking functional users throughout the University to maintain pages in the Zope system would generate the need to train and support them. Most of these users would not already be using Zope in their other Web duties. The Portfolio Project would somehow have to provide this training and support, probably indefinitely into the future. Zope's browser interface and editor may be easy to learn, but experience shows that almost anything requires support, at least until it becomes so pervasive that a user can get casual help from the person at the next desk. Recommendations: Proceed with the exploration of Zope, carefully weighing its advantages against its costs. In particular, it is important to determine whether the final design of the Portfolio will be complex enough to require this kind of Web development environment. Test the hypothesis that functional users, in OIRP and elsewhere, can learn DTML and use it effectively. Assess whether the effort required fits in with their other duties. Determine how much outside technical and user support these functional users will require. This assessment should be done in a realistic way by actually implementing a prototype Zope project. People and skills System administrator for servers and other platforms, Web server administrator, operational support DBA (database administrator)/programmer for dynamic content Support for administrative information system, data warehouse Support for report writing, query writing, to get info from administrative information system and other sources Web design and layout (look and feel, navigation) Media content producers (e.g., video, audio, animation) Overall architect Distributed people for supplying and updating content Leadership and management of the project, to bring together the efforts of many people across campus and to keep the project in line with the goals of the University In the section on Web Hosting, we discussed the supportive role that the IT department has played in getting the PP under way. IT is providing the basic technical support, but there are clear limits to what IT can provide with its current staffing. IT's "Web Master" role is currently filled by the allocation of 0.1 FTE of a staff member who has responsibility for maintain labs and classrooms. Clearly, IT can only support campus Web development activities in a minimal way at this point. There is a proposal to fund and staff a central Web Team within the next two years, but this is not yet a commitment. Since OIRP has clearly been given the lead responsibility for guiding and developing the Portfolio, it will have to develop both internal and contract resources. As to the generation of content, and in particular assessment materials, PSU has mounted a substantial effort, including a faculty member in residence. This will provide much of the support and effort that will be needed to provide assessment materials for the Portfolio. OIRP's current plan, to make the assessment Web page a "satellite site" of the main Portfolio, seems like a good way to delegate control and achieve collaboration. Recommendations Again, as with basic hosting services, an explicit discussion of a Service Level Agreement with IT would help OIRP know better what resources it will have to seek through contract or by growing or reallocating its own staff. The technical development of the prototype has relied heavily on contract services. This is a good strategy, but the need is likely to continue for some time, so it will be important to provide some measure of continuity. That means putting the funding for this kind of service into the ongoing budget, and also making sure there is someone within OIRP with enough Web development expertise to be able to effectively manage the outside services and ensure consistency over time. There is little support available on campus for producing multimedia content and other specialized materials for the Portfolio, if the University decides it wants to include such material (for example, in support of the section on student work). The PP will have to look to contract help from outside, or rely on other units (such as assessment) to create material that can be repurposed. For delivering multimedia content, the University might consider the possibility of using outside hosts. This is expensive, but it may be the only feasible method. Since the PSU PP is still very dynamic, and since it seems likely that major additions and modifications will be made over the coming years, OIRP should be increased by a full position. This person should already have a full range of experience and skill in both high-level Website design and a fairly technical level of implementation. It also seems reasonable to expect that the demand on the time of the Director of OIRP and the Institutional Research PP representative will continue long after the rollout of the initial version of the Portfolio. The Director in particular will have a major role on campus in bringing together the groups and individuals who will contribute content and in coordinating the decisions about the overall design and message of the Portfolio, how much of it will be publicly available, etc. Relationship of UUPP Project development to other campus Web initiatives The previous section discussed the relationship between the Portfolio and the assessment Website that is under development. This would be a good time to discuss the relationship among the many major Web presences that are developing at PSU: the main University site (www.pdx.edu), the Alumni site (Alumni is considering using a commercial Website), the site that the School of Engineering is planning for accreditation, the University planning site, in addition to the assessment site and others. There should be a formal mechanism for continually tuning the relationship among these sites, how they link to each other, what content they share, what audiences they address, and other policy questions. The Director of OIRP, as the person responsible for the Portfolio, would be an appropriate person to do this, but the charge should be made formal. It would be very difficult to have that responsibility without an official mantle. Whoever has this responsibility would be helped immensely by a formal, high-level, authoritative Web policy committee. Issues related to the continuation of the Project beyond the initial grant period The will to continue the Portfolio Project beyond the end of the initial grant period is strong at PSU. OIRP as a department has been regenerated around the Portfolio concept. The Provost and the Deans see it as a powerful tool and have given it their backing. The faculty see it as an expression of their values. The question is, will the necessary funds be available in the face of the budget cuts that are being asked of all areas of campus? If not, the existing resources will not be enough to carry out the ambitious ideas that have been generated. The Portfolio Project would then only be able to go forward in a very limited way. Questions posed by this institution: How can the work of updating and maintaining be divided efficiently across functional units on campus, while retaining management of the portfolio within the Office of Institutional Research? From the level of the University administration, charge the Director of OIRP with responsibility for coordinating the core, University-wide sites, including the Portfolio. Establish a committee of top-level people in each area that has a stake in this to set Web policy under the leadership of the Director of OIRP. Make the PP an umbrella to coordinate the message that the University is sharing. Are the technology tools we are using or proposing to use sufficient to sustain the portfolio over time, and can they be shared across campuses? See the discussion in the Software section.