About the Project

Collaboration

The success of this project has been based on collaboration between:

• project partners, WCET staff and consultants

• each project partner and his/her vision, design and development teams 

Some of the challenges to collaboration were:

• dissimilar missions, student bodies, budgets, student information systems, administrative and academic structures, and priorities placed on student services among the partners

• sharing information effectively

• generating sufficient commitment to the project by campus stakeholders

• getting the project work done in addition to all the other regularly scheduled and expected work, with limited resources

• agreeing on the meaning and uses of terminology

• agreeing on a common work plan and timeline

Key Lessons Learned

Develop Common Terminology/Glossary
Identify Motivating Forces
Build Cross-Functional Teams
Use Effective Strategies and Techniques
What We Would Have Done Differently
Collaboration PowerPoint slides

Develop Common Terminology/Glossary

Initially, each partner had a different idea about what the term "student services" meant and which services were within the administrative core. In order to proceed, the partners generated a list of student services for online learners, divided into five "suites of services" to provide a common basis for discussion within the project. These suites include:

• Administrative Core
  Admissions, registration, financial aid, student accounts, student records, and course/program catalog and schedule of classes

• Communications Suite
  Student to student, faculty to student, faculty and staff to faculty and staff, and institution to student

• Academic Suite
  Academic advising, academic counseling, assessment and testing (diagnostic, placement, and academic), bookstore, library, developmental education services, retention services, technical support, tutoring, and services for students with disabilities

• Personal Services Suite
  Personal counseling, career counseling and placement services, ethical and legal services, financial planning (budgeting, banking, loan and credit card management), wellness services, and orientation

• Student Communities Suite
  Student activities (recreation, leadership, academics, religion and spirituality) and student population segments (international, minority, veteran, and alumni). 

The partners found this graphic of a web of student services of the above described suites helpful to understand the connectedness of web-based student services.

In another example, although the grant proposal called for "creating services for online learners," the partners immediately realized that all their students wanted to access services online and that "creating online student services" was really a more accurate description of what was needed. They agreed to keep the official title of the project but to recognize that they had a broader mission than the words implied. 

Identify Motivating Forces

By agreeing to some of the motivating forces for newly designed student services, the partners pursued solutions that all can adopt: 

• Student-centered
  The Web's integrated nature makes it possible to design services that are more student-centered, rather than institution-centered.

• Self-service
  To the extent possible, services should be designed to allow students the choice to serve themselves anytime and anyplace, continuously or in discrete increments.

• Personalized and interactive
  The service should recognize the student and provide a personalized and interactive experience.

• Just-in-time
  Services should be delivered in user-friendly modules as needed on a just-in-time basis, rather than as large, one-time "data dumps."

• Push and pull
  Students should not only pull information from services, but services should also push information to the student, as appropriate, throughout institutions' relationship with the students. For example, the system should notify a student when a closed course of interest to them reopens by "pushing" this information to the student.

• Life-long
  Services should be available to students as long as they desire to be associated with the institution. These services may be offered at different levels and for different fees, but they should be available nevertheless.

Build Cross-Functional Teams

This sounds simple too, but it can be very complex when working on services beyond those in the administrative core. Services in these other suites such as academic advising may be partially decentralized, or wholly decentralized within the institution's structure. In addition, there may be two sets of services offered across the suites: one for on-campus students and one for off-campus students. To address this situation, each of the project's institutional partners created cross-functional vision teams from across campus. Participants included:

• deans of instruction

• academic support

• continuing education

• student services

• admissions officers

• chief information officers

• counselors

• program directors

• faculty representatives

• Web masters

• computer specialists

It is interesting to note that each of the campuses found it necessary to expand their original teams as they realized that their student audience was not just the distance learner — but campus-based students as well. The expanded teams assessed the status of their current student services, determined which services their campuses should offer via the Web, and then identified which services were their highest priority for development and, therefore, to be the focus of the project. The corporate partner determined its focus based on research among its client institutions.

Use Effective Strategies and Techniques

Because of the many differences among the partners, they decided to use a "picture language" for scenario building — Unified Modeling Language or UML — as the technique for identifying process requirements. 

User scenarios are theoretically similar to scenes in a literary play whereby a dialog simulates an exchange of information to accomplish some purpose. UML treats the human user of the as-yet-undefined system as an "actor" who interacts with the system in a series of scenarios, where each scenario accomplishes some single purpose. In fact, the UML picture symbol for the actor is a stick-person. 

This graphic shows in UML the concept of push-pull technology where students should have a choice of pulling information (or requesting services) from an institution as well as having the institution provide the convenience of pushing information (or supplying a service) to the students on a timely basis. This pushing choice, which is an obligation on the institution, serves to provide "just-in-time" information or services rather than forcing the burden to be upon the student to absorb lots of information at one time (in a mass-dump manner) or be responsible for requesting services when they are needed.

The project's Collaborative Workspace displays the partners' scenarios at the end of the design phase. To view the scenarios, go to each partner's page and click the Flow / Scenarios / Steps links. Note: this version of the workspace is not operational; you may not send email or link to the threaded discussion board.

Once the stakeholders at each campus were comfortable that the selected scenarios accurately describe what the new service should be like, these scenarios were handed over to the campus IT staff for review. The IT staff then recommended technology options for supporting the scenarios including using existing campus technology solutions, buying new solutions or outsourcing to a third-party provider, building new solutions, or partnering in the development of new technology solutions. 

Although each of the partners is developing scenarios for a different service, they plan to share these scenarios and adopt or adapt them to their campuses where possible. Each campus can then accelerate its effort in a broader area because it will not need to start from scratch or to specify technical details too early. Partners took this approach in the project because each campus had different priorities for its initial focus. In collaborations where there is an initial joint focus, the same scenario process can help partners come more quickly to a joint vision for the new service. One important observation: It takes time for campus professionals to learn to use the scenario process and UML, a different way of communicating. Thus, there should be an allowance for this built into the timeline. Involving a facilitator knowledgeable in this area can be very beneficial.

What We Would Have Done Differently 

The institutional partners were selected for the project because they represented different sectors of higher education and constituencies in order to develop solutions with broad application. If this had been taken a step further to select campuses with the same level of sophistication in their Web infrastructure for student services and one that was common to the corporate partner, it would have allowed the project to move faster. That would have been good for the project — what we are doing may be better for the field as it may be more typical since no two institutions are ever exactly alike.