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.
|
