SSP Updates

Below are selected articles from SSP Updates from the project's inception in December 2004 through its completion in December 2009.




April 2005

Request for Proposal Process Moves Forward

There are several steps in selecting the best student information system for U.Va. and the best implementation partner. The first step has been taken in securing clearance from the Virginia Information Technology Agency (VITA) to issue a Request for Proposals (RFP). The second step is underway: completing the RFP and submitting it to the Integrated System Executive Committee and VITA for final approval. Once an RFP is issued, the steps that follow include:

“This is a long process,” reports Charlie Grisham, SSP Director, “but it is essential that it be done right. Many people from around Grounds will be invited to participate, particularly to attend vendor demonstrations. We will be soliciting broad input to ensure that we are selecting vendor(s) who best meet the vision and requirements of the University community.”


June 2005

Student Puzzle Pieces Being Assembled in Workshops

The University of Virginia exists to educate students. At the very base level, students are recruited, apply, enroll, attend class, take exams, and graduate. The infrastructure that allows all that and more to happen for 19,643 students in 154 different fields, on schedule, year after year, is extensive and is about to be examined and reconfigured through the Student System Project (SSP).

“To the outsider, or to the student, for that matter, there are three primary functions that must occur to usher students through their University education,” says Charles Grisham, Director of the SSP. “Student Financial Services, Registration and Records, and Admissions. What are less obvious are all the processes that comprise those functions.”

A first sampling of the high level processes that constitute the student puzzle includes:


Student Financial Services

Registration and Records

“Each of these global processes is comprised of hundreds of smaller processes,” says Grisham. “But right now we are focused on the global level so we can identify common and distinct requirements across schools and departments, and identify strategies, policy issues, and shadow systems related to each global process.”

The format for this evaluation is a series of approximately 20 workshops (one for each global process noted above), held throughout the summer months, and attended by people who represent these activities in the schools, departments, and central offices. “We are having tremendous participation and enthusiasm,” says Grisham. “Many people are giving many hours to help us understand current processes and where there might be opportunities for improvement.”

Following the workshops in the areas of admissions, registration and records, and student financial services, SSP will begin to address other critical student-related processes in University services such as housing, parking, bookstore, IDs, etc.

Other summer activities on the SSP docket include visits to universities that have implemented student systems and further refinement of the requirements for a new system, adding puzzle pieces systematically until the complete picture emerges.

Web Software Allows Many to Weigh In on New Student System

There are over 2,000 potential requirements for a university student information system – functions that the University needs or would like a system to do. When selecting a new system, each requirement has to be prioritized, and vendors must be evaluated on how many requirements they meet and how well they meet them. Getting stakeholder input on both requirement definition and vendor evaluation is essential. It is also a daunting task.

To assist and manage that task, SSP will be using DecisionDirector, a web-hosted stakeholder-engagement platform from Advantiv.

“DecisionDirector starts us off with a comprehensive inventory of student system requirements,” says Charles Grisham, Director of the Student System Project. “It then hosts a web site where we can solicit input from central office, departmental and school stakeholders, thus allowing us to ‘brainstorm’ and validate system requirements on line. All the information goes into a database, from which we receive summaries and reports.”

Advantiv facilitates the web forum, offers instructions on how to use it, and provides reports that present prioritized listings of business processes and systems that presently support those processes. If stakeholders propose additional requirements, those are provided to SSP, evaluated, and, if approved as a requirement, added to the requirements database.

“Once requirements are defined, they are designated as ‘key’ or ‘to be included,’” explains Grisham. “We can also indicate whether they should be included in a vendor demonstration (demo) by prospective vendors. As such, DecisionDirector can then be used in demo preparation, and in demo and vendor evaluation. Demo attendees can be given a checklist to take notes and provide their ratings on line. Advantiv then provides detailed and summary vendor comparison reports based on the ratings. Vendors will also be evaluated using University-specific criteria.

“This tool will expedite the pre-implementation process, ensure a comprehensive evaluation of requirements, and enable people across the University to weigh in on the selection of a new student system,” Grisham concludes. “We are optimistic that, at the end of this process, we will be in the best position to select and implement the best system for the University because we will have heard from the future users of the system.”


September 2005

U.Va. Student Processes Dissected, Future Envisioned

The Student System Project (SSP) has reached its first milestone: completing 17 student process validation workshops that have teased out current practices, pain points, requirements for the future system, and issues. They also have generated a vision for a future where student administrative processes are largely automated, where students don’t have to provide the same information over and over to different (or the same!) offices, and where a student system provides sufficient flexibility to meet the diverse needs of diverse programs serving diverse students, i.e., today’s university.

George Stovall, Director of Institutional Assessment and Studies, is one of 175 University staff who attended one or more workshops (in Stovall’s case, 13). He shares the opinion of many participants that one of the greatest benefits to the workshops was gaining an understanding of how much is involved in managing student administrative and academic processes and how different schools and departments accomplish that work.

“I have a much greater appreciation of what people do across the University,” Stovall says. “I think the workshops contributed to a sense of team, a camaraderie that will carry us into the implementation of a new system.”

Rachel Most, who attended six workshops, is a professor and assistant dean in the College of Arts and Sciences. She came away viewing the need to implement a new student system as, at the same time, a burden and an “incredible opportunity.”

“Each school and administrative office has the chance to review how they perform all processes relating to a student and rethink them from the ground up,” says Most. “While it's likely some processes will remain the same, I am also hopeful that we can streamline much of what we do and make it appear seamless to our prospective and enrolled students, as well as our alumni.”

The format of the workshops facilitated a sharing of views and information across units that probably has never occurred before, according to Charlie Grisham, SSP Director. “Everyone was interested in learning from others, as well as explaining their own needs,” he reports. “I would characterize the consensus as hoping for, and being willing to work toward, a cohesive academic environment for students across the University that takes into consideration the diverse needs of the various schools and departments.”

We Want It All

The American Heritage College Dictionary defines “requirement” as: 1. “Something that is required; a necessity. 2. Something obligatory; a prerequisite.” That is not exactly how the University is using the term “requirement” when listing what it expects to find in a new student information system.

“ Decision Director (the web-hosted platform SSP is using to prioritize system requirements) contains over 2,000 ‘requirements’ for a student system,” says Charlie Grisham, SSP Director. “These have been supplemented by the requirements that were identified in the process validation workshops. Rather than ‘a necessity,’ these are features a system should have to meet fully the functionality sought by the University. It is unlikely that any system will provide all of these features, and that is why we must review and prioritize them to determine which are truly ‘requirements.’”

The SSP Project Team has organized the “requirements” in Decision Director to make it easier to tackle the task of reviewing so many potential features of a student system. The 55 members of the Student System Advisory Committee (SSAC), who represent all the schools and departments throughout the University, and their designees, have been asked to prioritize the need for detailed functionality in the following areas:

• Recruitment
• Admission
• Student Records, including course management and registration
• Degree Audit
• Financial Aid
• Student Accounts
• Student Services, such as health, housing, and career services
• Self Service, including applying, advising, and maintaining personal information
• Miscellaneous, including demographic and biographical data, special needs, self-service functions, and state residency

Requirements will be ranked according to whether they are critical, important, desired, or no need. “We will use the responses recorded for each requirement in Decision Director to rank the functionality that most users across the University hope will be included in the software we select,” says Grisham. “Our vendor choice will depend, in part, on the match between our functional needs and the functionality that is built into the software.”

(Another component that will influence the choice of vendor is site visits to and discussions, to be completed by mid-November, with other universities that have implemented or are implementing student systems.)

“Obviously, we would like to have it all,” says Grisham. “But we don’t have forever to replace our current system, and we would have to wait even longer than that to find a package that would provide it all.”


January 2006

University Community Sets SSP Agenda

It is not a simple task to achieve the mission set forth by the University for the Student System Project: “To provide the University community with an efficient and effective student information system that supports the University's mission, integrates with existing systems, and adapts to growth and change.”

“It takes a village” characterizes how the SSP has been able to take the first steps in achieving that mission.

What are the University’s requirements?
Who can better determine the requirements for a new student system than members of the University community who best know the current system? To tap this expertise, the SSP convened 17 Process Validation Workshops throughout the summer where administrators, faculty, and staff from across the University clarified current practices and defined requirements for a future system.

“Even more important than generating a list of requirements,” says Charles Grisham, SSP Director, “the workshops generated among participants and the project team an appreciation for and understanding of what people do across the University, revealing similarities and differences, and common and distinct pain points and issues. The real outcome of these workshops is that the University community set the agenda for the Student System Project and created a momentum that propelled the project forward.

“When workshop participants and others were offered the opportunity to prioritize over 2,500 system requirements using DecisionDirector, there was remarkable consensus among voters.”

Once requirements had been articulated (click here for requirements prioritized as “critical”), vendors were invited to rate their ability to meet those requirements. The next step was gathering information from peer institutions who had implemented different systems.

What do other institutions have to say?
“ We spoke to over 35 schools representing the four integrated student system software packages on the market,” reports Susan Barr, SSP Associate Director. “SSP team members and members of our core advisory group (CASS) visited five of those schools. It was an enlightening experience to hear not only about the features of different systems, but to take away lessons learned from others’ implementations.” (For Key Take-aways, click here.)

And the conclusion is?
After synthesizing input from the University community and from peer institutions, there are only two viable vendors for U.Va., according to Grisham. “Banner or PeopleSoft could potentially meet our needs,” he says. “Both are well represented at peer institutions. We are now in the process of determining which of those can best help us achieve the project’s mission.”

Advisors Keep Agenda Front and Center

Implementing a new student system is a challenge. It is a challenge the University can meet with the involvement of key stakeholders across Grounds.

The SSP has benefited from tremendous stakeholder involvement already and will ensure continued involvement through a governance structure that incorporates people who will be most affected by the future system at all levels of the University.

“Some elements of the governance structure are in place, while others are just being formed,” reports Charles Grisham, SSP Director. “Each will help guide the project through its strategic planning and decision making in a timely, inclusive manner.”

The advisory groups include:
• Integrated System Executive Committee
• Student System Policy Review Group
• Core Advisors to the Student System (CASS)
• Faculty Advisors to the Student System (FASS)
• Student System Advisory Committee (SSAC)
• Technical Advisors to the Student System (TASS)
• Student Advisors to the Student System (SASS)

For the mission of each group and a list of members (where complete), click here.

“Just as the University community has set the agenda for the Student System Project,” notes Grisham, “so will members of that community keep the project focused on that agenda through their personal involvement and their knowledge of University culture. We cannot be successful without their help.”


March 2006

PeopleSoft Software Selected for University's New Student Information System

From Top News Daily, March 14, 2006

Following an intensive, year-long analysis, the University of Virginia has chosen PeopleSoft as its new student information system, which includes admissions, financial aid, registration, transcripts, billing and other student administrative functions, such as housing and dining, that now exchange information with the current system for all schools and offices at the University.

Charles Grisham, professor of chemistry and Student System Project director, announced the decision today. “We are confident that PeopleSoft is the best match for the University’s requirements,” said Grisham, who led the search for a replacement for the University's 16-year-old Integrated Student Information System (ISIS) with a modern, enterprise-level administrative system.

In particular, Grisham emphasized that PeopleSoft, which has been successfully implemented at numerous universities of comparable size and complexity to U.Va., offers flexibility that will accommodate both current and future University requirements.

PeopleSoft was acquired by Oracle in January 2005, and the University’s finance and human resources systems are both Oracle. That situation presents potential for integration of systems in the future, and Grisham noted that PeopleSoft continues to evolve since its acquisition by Oracle.

With the software decision made, Grisham will begin establishing a timeline for implementation. He said that, typically, other universities have required up to four years to fully implement a new student system. The next steps will be to continue refining the parameters of the project and build an implementation team.

“This is the beginning of a new, evolutionary approach to addressing the administrative needs of students,” Grisham said. “The project mission is to provide the University community with an efficient and effective student information system that supports the University’s mission, integrates with existing systems, and adapts to growth and change.”

Key stakeholders in the student system were involved and informed throughout the process and will continue to be part of the implementation. Advisory groups involved in the project include: Integrated System Executive Committee, Student System Policy Review Group, Core Advisers to the Student System (CASS), Faculty Advisers to the Student System (FASS), Student System Advisory Committee (SSAC), Technical Advisers to the Student System (TASS) and Student Advisers to the Student System (SASS).

Users participated in 17 workshops focused on current student business process and systems during the summer of 2005. An online brainstorming session was valuable in developing the mission and vision of the project. More than 2,600 different student system requirements were identified and prioritized as the process unfolded.

Grisham said that there was remarkable consensus among those who participated in the exercise to prioritize the requirements.

In addition to assessing the software available from a variety of potential vendors, Grisham and others not only contacted nearly three dozen institutions but made site visits to five schools — Georgia Tech, Stanford, Minnesota, the University of Mississippi, and James Madison — to examine the systems under consideration.

After synthesizing input from the University community and from peer institutions, there were only two viable vendors for the project, and “PeopleSoft was clearly the best alternative for our specific needs,” Grisham said.


July 2006

SSP Moves from Software to Consulting Vendor Selection

Now that PeopleSoft has been selected as the software vendor for the new student information system, the Student System Project is concentrating on selecting a consulting firm that can provide experience and expertise on PeopleSoft implementations in universities of comparable size and complexity.

“An RFP (Request for Proposals) has been issued by Procurement Services,” reports Charles Grisham, Director of the SSP. “The closing date for receiving proposals is July 13. Review, presentations, and negotiations will follow, taking us probably until mid October before we have a signed contract.”

In the meantime, SSP team members have begun training on the PeopleSoft applications. “It’s a steep learning curve,” says Susan Barr, Associate Director of the SSP. “Initial training will give us an introduction to the language and conventions of PeopleSoft at a basic level. Future training will delve into how the applications are set up and function.”

More information and progress reports will be posted to the SSP website as the project continues to pick up speed.

Take a First Look at PeopleSoft Terminology

A new terminology will emerge from the PeopleSoft student system implementation. Here is a starting primer from the PeopleSoft website for future reference:

Campus Community

Campus Community provides a common source of campus data, coordinating all forms of communication to help you manage your administrative services. It captures all prospect, applicant, student, alumni, and organizational data, then secures it, tracks it, and delivers what you need upon request. With Campus Community, you can:
Establish rules or events to trigger automatic assignment of sets of communication-oriented records throughout Student Administration
Track all incoming and outgoing communication
Create checklists to automate activities
Create event templates, identify staffing needs, track attendance, and review results
Define committees, identify members, and maintain history
Define reciprocal relationships and manage joint communications
Maintain multiple names and addresses with effective dates, email addresses, and URLs
Manage other demographic data—residency, medical and emergency contacts, and extracurricular activities
Enable constituents to maintain their own data via the web

Recruiting and Admissions

Recruiting and Admissions helps you plan, manage, and track recruitment and admissions activities. This recruiting software solution provides comprehensive and flexible data collection, processing, and control to enhance your institution's academic service and meet your goals. With Recruiting and Admissions, you can
Plan and coordinate independent recruitment programs targeted to specific student populations
Match recruiters to prospective students based on region or special interest and monitor your progress toward enrollment targets
Load transcripts, tests, and applications from external agencies and central application services
Capture and analyze student recruiting information from multiple sources, including test loads
Tailor your admissions system according to your institution's varied requirements and evaluation practices
Enable students to apply, track application status, accept or decline admission, and pay deposit fees—all online
Set and monitor enrollment targets, track progress toward recruiting efforts, and analyze admissions decisions and patterns


Financial Aid

Financial Aid automates federal and institutional financial aid processing to ensure more efficient operations. Department of Education regulations are built into the software, so your institution remains in compliance. With Financial Aid processing software, you can
Tailor financial aid management to your business rules and practices
Track applications, control Institutional Student Information Record (ISIR) loads, and maintain an ISIR audit trail
Design a cost-of-attendance assessment, create student budgets, and calculate needs analysis
Automatically generate aid awards and packages
Ensure that an award complies with eligibility, then disburse it to the student's account
Process and track federal, state, university, and alternative loans

Student Financials

Student Financials is an essential tool for managing student and external organization accounts. You can manage and calculate all student financial information, including tuition, fees, receivables, billing, payment plans, and refunds. With Student Financials, you can
Open new accounts easily
Monitor and update student and third-party accounts
Calculate tuition and fees on an individual or group level
Check account balances and post transactions
Generate unique bills for students and third-party sponsors—by department, cycle, and "account past-due" messages
Automate receivables management
Tailor payment plans
Monitor delinquent accounts

Student Records

Student Records helps you manage all aspects of enrollment, including catalog and class schedule maintenance, transfer credits, requisite restrictions, class start and end dates, wait lists, academic programs, transcripts, and analysis. With Student Records, you can
Expedite enrollment by processing all permission, deadline, and other course requirements online
Administer enrollment by creating and assigning enrollment appointments to customized student populations
Build dynamic academic calendars for self-paced classes to calculate significant dates, such as drop and withdrawal deadlines
Evaluate course credit transfers and make adjustments to present the best-case scenario
Calculate academic statistics and report results
Customize transcript production and process multiple requests
Establish customized grading guidelines

Improve record maintenance and organization

Maintain course catalog, enrollment, and grading information in a single database


December 2006

Corporate Modeling Software Facilitates Mapping of Business Processes

The SSP is using CaseWise Corporate Modeller to map student-related University business processes in anticipation of implementing the new PeopleSoft system. Most processes in the areas of admission, registration and records, student finance, and University services have been mapped and validated by the schools and departments. These diagrams will help the team track essential functionality as the University makes the transition to the new system. For an example of mapping via Corporate Modeller for Course Management, click here. Click on the + signs in the diagrams to go to the next level of detail. The Object Key explains what each object represents.

March 2007

Previews Set the Stage

“Campus Community.” “Academic Structure.” These terms can conjure up a number of images. In the world of PeopleSoft Campus Solutions, they encompass some of the new concepts and opportunities that will characterize the University’s new student information system.

Learning what these, and other, PeopleSoft terms mean and the concepts and system modules they represent is the first step to making decisions about how the system will work for U.Va. This learning is taking place through a series of “Previews,” facilitated by consultants from CedarCrestone, Inc.

Nearly 200 people from across Grounds will be involved in 39 Preview sessions scheduled to continue through the end of March. Sessions began with Campus Community (the biographic and demographic core of the system) and Academic Structure (how U.Va. is represented in the PeopleSoft system), and will include topics pertaining to Admission, Financial Aid/Student Finance, Student Records, and University Services.

“The Previews are providing stakeholders with an opportunity to see how PeopleSoft looks and works, while also sharing our business and system requirements with the SSP team and consultants in the context of the new system,” explains Charlie Grisham, SSP Director. “This exchange will help all of us make important system setup decisions in the very near future.”

Phyllis Palmore and Sheilah Sprouse, representatives from the Curry School of Education, have found the sessions to be “very informative” if also a bit overwhelming. Palmore, who works with admissions, would like to attend more of the sessions, “but it is our busy season,” she says. “I get something out of each session. We all report back after we attend a session, and the response to what the system can do for us has been very positive.”

Sprouse finds the sessions make for very long days, but has been pleased with what the system will be able to offer. “It has been interesting to see the differences and commonalities between schools,” she says.

Palmore, who looks forward to bidding adieu to the green and black screens of ISIS, also notes the fact that the SSP team’s effort to understand and document the Schools’ processes seems to be paying off. “I am confident that the team knows what we are doing and has built in that information. They are helping make things work for us.”


June 2007

SSP Receives BOV Approval

The University of Virginia Board of Visitors approved the Student System Project budget and timeline at the June 7 meeting of the Finance Committee. This allows the SSP to continue on schedule to complete the implementation of PeopleSoft Campus Solutions version 9.0 by the end of 2009. To view a high level timeline for the project, click here.

Campus Community and Academic Structure Decisions Come First

Whereas the Preview sessions set the stage for the PeopleSoft Campus Solutions student system, the Interactive Design and Prototyping (IDP) sessions provide a forum for key stakeholders to make decisions on how the system will be configured. Just as Campus Community and Academic Structure were previewed first, to provide an overview of the foundation of the system, so Campus Community and Academic Structure are the first IDPs to make decisions that affect the setup and configuration of that foundation.

The Campus Community IDPs were held throughout May, co-facilitated by Admission Team Lead Tracy Pettit and CedarCrestone Admission consultant Kevin Gele; Academic Structure IDPs ran from June 4 through June 13, co-facilitated by Registration & Records Team Lead Robert LeHeup and CedarCrestone Registration & Records consultant Nancy Soletti. Both sets of IDP sessions involve between 10 and 15 representatives from schools and central offices.

Campus Community provides a common source of biographic-demographic (bio-demo) data for prospects, applicants, and students, as well as organizational data. It then secures the data, tracks it, and delivers it upon request.

“Setting up Campus Community is not glamorous,” says Astrid Henriksen, development analyst for the Office of University Development, who participated in the Campus Community IDP sessions. “We are anticipating all the data fields we may want or need—this is our opportunity to include in the system of record data we have been tracking in shadow systems. It is a tedious, but essential exercise.”

"These decisions cannot be made in a vacuum," notes Richard Tanson, foreign student advisor in the International Studies Office, who also attended the sessions. “We have to consider the effect of these decisions downstream in the system. How will they affect what we see later in Admission or Financial Aid?”

Thus, over the course of the month, decisions were made regarding name types, address types, honors and awards, and relationship data. Codes and naming conventions were established, so there will be consistency throughout the system, regardless of the department entering the information.

“Some decisions were put on hold, awaiting policy discussions,” reports Pettit, “but completion of the Campus Community IDPs represents the beginning of our system set-up.”

Academic Structure Follows Suit
Academic Structure helps define how the University organizes its schools, academic departments, majors, and concentrations. It defines what degrees are offered, how academic terms are established, what calendar is used, etc.

The Academic Structure IDPs put the basic structural elements, such as locations, subject areas, and departmental structure, in place, according to LeHeup. There are two areas that offer greater challenge.

“PeopleSoft terminology is different than ISIS terminology,” notes LeHeup. “We have to keep clarifying for ourselves what we mean by terms, such as 'cancelled,' that we use in specific situations in ISIS, but which have different meanings and uses in PeopleSoft. As IDP participants increasingly understand the concepts behind the PeopleSoft terms, the ramifications of proposed decisions become more apparent–this leads to further discussion and evaluation.”

“Second, as we explore ways to set up the system, we start by reflecting on current practices,” says LeHeup. “This often raises the question of whether or not there is, or should be, a University policy regarding those practices, and how much variety there should be across schools. For example, each school has rules on how they handle students repeating a course, but we’re finding that some of those practices have evolved over time and aren’t always clearly delineated as official policy.”

As with the Campus Community IDPs, the devil is in the details. Some decisions will carry over beyond the end of the sessions, where policy decisions will inform system setup, but the issues raised and decisions that are made in these IDP sessions will allow the project to move forward in configuring the new system.

Functional IDPs Run through End of Year
Now that Campus Community and Academic Structure IDPs both are completed, the decisions that will inform the setup of the specific functional modules can be made. Admission, Student Accounts, Financial Aid, and Student Records IDPs all will begin on July 9th and continue through the end of the year.


September 2007

Functional IDPs: One Down, Three to Go

The functional Interactive Design and Prototyping (IDP) sessions began in July, and the Admissions sessions already are complete. “Which is a good thing!” says Marianne Kosiewicz, Associate Dean of Admissions, who is on loan to SSP to assist with the Admissions implementation.

“Part of the Admissions module will be live as early as March 2008,” says Kosiewicz. “The participants in the IDP sessions shared our sense of urgency. They were knowledgeable, focused, and conscientious, which helped us move quickly through the decisions that had to be made.”

The Admissions team has moved on to begin constructing a system design document, while the Student Records, Student Financials, and Financial Aid teams continue their IDP sessions.

Student Records participants are “exploring how decisions made in set-up will be reflected in day-to-day business processes,” according to Robert LeHeup, Student Records Team Lead. “So far, we have addressed set-up issues related to the course catalog, majors (called ‘Plans’ in PeopleSoft), add/drop, and grading. We schedule hands-on time into the sessions so the participants have a better understanding of how things are related.”

The Financial Aid IDPs follow the order of the actual financial aid business process over the course of a year. “This facilitates the discussion and decision-making,” says Student Finance Team Lead Wendy West, “as each session leads logically to the next.”

West is appreciative of the strong and consistent representation she has had from units. “This process is requiring considerable time from participants in addition to the 14 hours a week spent in the IDP sessions,” she says. “Each session generates the need for more information that participants must bring to a subsequent session.”

Homework is required of all the groups. Student Financials Functional Analyst Stephanie Bickers gives an example from her group: “We have made decisions on the ranges and processing of charges and credits,” she says. “Now participants have to provide all the charges and credits they want to fall within those ranges.”

Bickers notes that the Student Financials group has worked together to create a consensus-oriented, productive environment that is facilitating decision-making.

SSP’s CedarCrestone Project Manager Paul Martin is impressed by the commitment of time and effort to the Project on the part of so many members of the University community. “U.Va. is a model of stakeholder participation,” he says. “This will have a profound effect on the success of the Project and the ultimate acceptance of the system.”


What Happens to those Parking Lot Issues?

While many decisions are made in the IDPs, others, which may require discussion or revision of University policies, are identified and deferred. Those decisions are put in the “parking lot” for further consideration. Some people would characterize the SSP list of pending decisions as a parking garage. But there is, in fact, a process for making these decisions, and many issues are working their way through that process. There also is a process for communicating decisions once they are made.

For a full description of the SSP issue management process, see pages 47-52 of the Project Charter.

In summary:
In general, two types of issues end up in the parking lot: questions of policy and requests to change the way PeopleSoft is set up to do things.

Policy issues are academic, financial, or other issues that carry implications that may require policy level considerations and/or change management activity in order for the Project to proceed with clear direction.

In the case of requests for changes to the system, a primary goal for the SSP is to rely on the best practices as contained in the delivered application, says Susan Barr, SSP Director. “Keeping the application as ‘vanilla’ as possible alleviates difficulties when revisions and upgrades are implemented,” she explains. “It also helps keep the implementation on time and on budget, since changes entail extra time and cost to design, develop, test, and maintain.”

Factors that will be considered in recommending a change will be:

Both policy issues and change requests go through the same decision-making process. What differs is which SSP governance group considers the issue.

The process is:

“With so many stakeholders involved, it is essential that decision deadlines are adhered to,” says Barr. “Fortunately, everyone understands what is at stake and is dedicating many hours in and outside of meetings to consider and resolve these issues as they arise. And we are committed to looping that information back to stakeholders so there are no surprises (that we can control!) as we move forward.”


SSP Solicits Students’ Perspectives

Students aren’t the only users of a student information system, but they are the largest group of users, and meeting their needs and expectations was the primary motivator behind the Student System Project.

Recognizing this, SSP plans to engage students early and often as the project progresses. The first such engagement took place in July as a student focus group helped construct a survey that will be sent to a random sample of 1,500 students in mid-October.

“This survey will provide a baseline measure of student perception of ISIS,” says Chris Doran, University Services Team Functional Analyst. “The same survey will be used to measure the change in student perception once the new PeopleSoft student system is implemented.”  

In the course of site visits to peer universities during the early stages of the project, the SSP team learned that none of those schools had included an early student involvement strategy in the overall project plan, according to University Services Team Lead Denise Hubbard. “Virtually all of these schools said they would involve students if they could do it over again,” she says. “We took that lesson to heart, and it already is bearing fruit in the feedback we got from the students involved in the focus group.”

Hubbard cites other opportunities for student involvement that are being planned:

“It is our intent to solicit students’ ideas and opinions as the project unfolds” says Hubbard. “It only makes sense to engage these users along with others in the system’s design.”


December 2007

Maelstrom of Meetings to Hit Decision Deadlines

Calendars across Grounds are solid with meetings to resolve policy issues that will inform and maximize the benefits of the University’s new student system. Driven by a system that seeks commonalities while allowing variation, representatives from the offices of the vice presidents and deans, and from the central offices of Admission, Student Financial Services, University Registrar, ITC, ISDS, and the Student System Project are meeting frequently and talking even more often to identify those commonalities and codify them in policy, while recognizing and accommodating areas of essential variation.

Issues being vetted range from determining policies surrounding academic transcripts to deciding whether and how to configure the system according to academic policies across schools within the University, for example, how to structure add/drop across the schools.

"In our University’s decentralized structure, some school policies have been set over the years without consideration for what other schools are doing or whether there might be some advantage to consistency across the schools," says Paxton Marshall, Associate Dean for the School of Engineering and Applied Sciences and member of the SSP Deans’ Designee governance group. "The SSP is giving us the opportunity to talk to each other and see where it makes sense and makes students’ lives easier to re-evaluate policies across schools."

"All the people engaged in these policy-making meetings understand the urgency of moving quickly," says Susan Barr, SSP Director. "Each decision is built into the project timeline so we have the answer at the point when it is required to configure the system. And we are meeting those deadlines thanks to the time, effort, and collaborative focus of these individuals."

150 Stakeholders Attend Student Records Prototype Demonstrations

The SSP Student Records team held eight sessions to share with stakeholders the proposed functionality that was developed based on the IDP sessions. Two demonstrations on each of four topics were presented:

-- Course Catalog and Schedule of Classes
-- Program/Plan, Enrollment, Grading, Graduation
-- Student Self Service
-- Instructor Self Service, Advisor Self Service, Academic Advisement

These sessions provided the opportunity for stakeholders to ask questions and provide feedback as the team continues to configure the application to meet the needs of the University.

"The response was constructive and positive," reports Robert LeHeup, Student Records Team Lead. "It was good to know that we are on the right track, but it also was valuable to learn more about a couple issues that surfaced in the IDPs. The demos confirmed we are in a good position to push ahead to work out the details of how these elements of the new student system will work."


March 2008

Recruitment/Campus Community Roll-Out a Success

The first roll-out of the new student information system occurred at 8:00 a.m., March 3. The deployment of Recruitment/Prospective Students module establishes the foundation for all subsequent elements of the student system. The inaugural roll-out was smooth - prospective student records are being created in Campus Solutions.

“Staff from the Admission Office, Athletics, School for Continuing and Professional Studies, and the School of Nursing have been tremendous in helping SSP navigate this first roll-out,” says Susan Barr, SSP Director. “They have helped us identify and work out our processes so others will benefit.”

“First line support is available from people in these offices who have been involved in testing the system,” says Tracy Pettit, Admission Team Lead. “SSP has had to field very few calls that these folks haven’t been able to handle.”

The next roll-out will be in early July with undergraduate admission processes.

When Will It Be My Turn???

The new student information system will be rolled-out in phases (see UVA Today article), which means that different people will be affected at different times. SSP calls these phases “waves,” and the magnitude of these waves will build through spring 2009 before they subside to the last few ripples in late fall 2009.

The next wave - Undergraduate Admission processes - is scheduled for early July and will affect primarily the Undergraduate Admission Office, the Bachelor of Interdisciplinary Studies office, School of Nursing, and the Athletics Department. Waves to follow include:



Wave Riders

Course Catalog and Schedule of Classes

August 2008

Office of University Registrar (UREG), school registrars

Financial Aid eUFAA processing

November 2008

Student Financial Services, School of Law and School of Medicine Financial Aid offices

Financial Aid ISIR reject processing

January 2009

Student Financial Services, School of Law and School of Medicine Financial Aid offices


February 2009

International Studies Office


March 2009

All faculty advisors, new students, school registrars, UREG

Financial Aid reading of applications and awarding

March 2009

Student Financial Services, School of Law and School of Medicine Financial Aid offices

Student Accounts Billing, Cashiering, and other processes

March 2009

Student Financial Services, Comptroller

Student Accounts Deposits and Self Service

April 2009

Student Financial Services, Comptroller

Financial Aid Loan processing for summer header recipients

June 2009

Student Financial Services

Financial Aid Loan and Pell Grant processing for fall recipients

July 2009

Student Financial Services, School of Law and School of Medicine Financial Aid offices

Grading and Graduation

December 2009

Faculty, UREG, school registrars

Applicants will begin using self service in July 2008, and all students will be using self service by fall 2009. Faculty will begin using self service in March 2009.

“Stakeholder involvement, communication, and training are factored into our work plan all the way through,” says Susan Barr, SSP Director. “Our governance groups, people on our teams who are on loan from departments, and key stakeholders throughout the University are advising us not only on system set up, but on the best times and methods to communicate with and train the diverse groups of people who will be using the new system.”


May 2008

University Prepares for Two More Rollouts

If “waves” are the metaphor for the roll-out of features of the new student system, some folks will be riding two new waves this summer.

Applicants First to Use Self Service
U.Va. undergraduate applicants for the fall 2009 term will be the first to use the student system self service student center during the summer. Admissions staff will process these applicants in the new system and manage the checklist that will show up in an applicant’s personalized view of the student center.

“The checklist is designed to let applicants know what is left for them to submit to the University for their application process to be complete,” says Tracy Pettit, Admissions team lead. “For example, it will show if they have yet to submit the application supplement, their high school mid-year grades, transcripts, and financial guarantee form for international students, if applicable.”

Applicants for the fall 2009 term will be applying using the Common Application, an on-line (or print) application new for the University that students may also use to apply to any number of nearly 300 participating colleges, of which U.Va. is now one.  The SSP team has been working with Common App to ensure a smooth electronic interface for information to flow between the application and the new system.

Course Catalog to be Tied to Class Schedule
In August, the Course Catalog will be available in the system so that class schedules for the fall 2009 term can be entered and associated with a course beginning in October. This will be the first wave of Student Records functionality.

“A course must exist in the new system’s catalog before a class section can be scheduled,” says Robert LeHeup, Student Records team lead. “The building of the course catalog is the foundation for all enrollment information in the system. It allows classes to be scheduled so students can enroll, advisors can retrieve degree audit information, grades can be entered, and transcripts can be produced.”

“Unfortunately, ISIS does not have a catalog as such, so we’ve had to build one from the ground up by extracting from ISIS all the individual class sections that have ever been offered,” explains LeHeup.

Two people are responsible for the fact that we now have 37,326 courses loaded into the new catalog, some dating as far back as 1921. Jill Card, Student Records functional analyst, helped extract the ISIS data and sorted through duplicates. Debbie Hoffman, special projects coordinator for the Office of the University Registrar, who is on loan to the Student System Project, reviewed every course for consistency, verifying credits, adding the grading basis, and identifying those courses that met specific area requirements. In addition, Card and Hoffman reviewed and edited all the course titles, converting them from all capital letters in ISIS to mixed case in the new system.

Beyond this herculean effort, for the courses that currently are being offered, every school had to renumber its courses from three to four numbers (e.g., PSYCH 101 became 1010) in order to allow for future expansion of the catalog as new courses are created and to add some logic to the numbering scheme. In addition to new numbers, all current courses also will have descriptions loaded to the new system, making the complete course information available to students and faculty in self service. This effort was coordinated by Jonathan Helm, the associate University registrar, who is himself on loan to the project. In addition to the renumbering, the schools and departments undertook the task of reviewing their offerings to ensure their accuracy in the new system.

As with the Recruitment roll-out, Applicants and Course Catalog will involve relatively few University staff and offices, but they are the foundation upon which all future features depend and upon which future functionality relies.


Degree Audit: The Devil is in the Details

When students check requirements for their degrees; when faculty advise them on which courses might best satisfy a requirement; when students and schools determine whether or not all degree requirements have been met for graduation – the source of information for all these questions regarding degree requirements, courses that meet those requirements, and progress toward degree, is the degree audit.

Implementing a new student system is an opportunity to review all of that information before it is codified anew, and the University is making the most of that opportunity. SSP team members Ann Reinicke and Cheryl Graves are partnering with CedarCrestone consultant Agatha Onwunli and with departmental experts Rebecca Garver, DARS administrator and ISIS trainer with the University Registrar’s office (UREG), Judy Updike, College of Arts & Sciences registrar, and Sharon Marsh, assistant College registrar, to do the heavy lifting for setting up the Academic Advisement module of the new system.

Having overseen development and maintenance of the University’s current degree audit system built using the DARS software, Garver lends the project her expertise on U.Va.’s degree requirements and how to encode them. She and Reinicke are wrapping up a first round of visits to the various undergraduate schools and departments to verify and validate their respective degree and major requirements. Later in the year, Reinicke and Garver will be visiting all those departments again for a final review of the degree audits before they are used by students and faculty for the first time in the spring of 2009.

Identifying the requirements is just the first step. For each of the hundreds of requirements, course lists must be built defining which courses will satisfy those requirements. Updike and Marsh, who bring to the project their extensive knowledge of the College’s degree requirements and familiarity with the current VISTAA degree audits, are working with Graves and the rest of the team to build these course lists and combine them into a degree audit for each major.

“As an integral part of the new system, the encoding of Academic Advisement is dependent upon the set-up of academic structure and student records,” explains Robert LeHeup, Student Records team lead. “The class lists, for example, are built using the new course catalog, and the various majors are identified by ‘plan codes,’ the development of which was based, in part, on the level of detail needed for the degree audits. Academic Advisement reports initially will be available for all undergraduate degrees—almost 125 different majors in all, and that’s not even counting minors and concentrations within majors.”


September 2008

This is HUGE!!!

Two and ½ years ago, Susan Barr, director of the Student System Project, could be heard around Grounds forewarning that, “This project is HUGE!!” Some may have doubted her then, but no longer!

Let’s start with the sheer order of magnitude:

Now let’s consider the people who have been consulted in the set up of the new system and in deliberating on policy issues related to the implementation.

“Yes, this is HUGE,” says Barr. “But we have generous, smart, industrious, committed people working with us on the team, in all the schools and departments, in the central offices, and throughout the administration to make this huge project a success.”

System Users Assigned Roles for the SSP Rollout

Who can do what in the new student system is determined by roles assigned to each user, based on security requirements. Roles determine not only what part of the system users may see, but also what they can do once they get there. The teams, in consultation with stakeholders, have created a structure for the roles within each area of system functionality.

Student or Faculty Center (self service) Access versus Administrative Access
Most faculty and students will have access to the student system through a portal, based on their roles. They will enter the Faculty Center or the Student Center using their NetBadge login and have no required training.

People who have administrative access to functionality of the system will log on using an iKey and require either instructor-led or online training specific to their assigned role(s).

Seeing versus doing
At a high level, the administrative roles are:

These roles are further refined within each functional area. For example, in the area of student records:

“A single individual can hold roles in different modules,” explains Robert LeHeup, Student Records team lead. “A person can have a local admin role in student records, a local admin role in admissions, and a viewer role in financial aid; or any such combination.”

“In assigning people roles in the student records module, we start with a report listing all ISIS users and what they can do in ISIS,” explains LeHeup. “We then take those names to departmental supervisors to confirm that the right people have the right access to the system to do their work. At that point we are able to determine who needs what training and notify them when it is time to register.”

“Current ISIS users can anticipate that they will be assigned roles that will allow them to accomplish their responsibilities in the new system,” assures Susan Barr, SSP director. “While their work will not be done the same way, they will have training and support for the transition.”


November 2008

Where are we now?

SIS users from SSP, central offices, and schools are working full throttle in two worlds at this point in the project—in production and in development. With five rollouts accomplished across Admission, Student Records, and Financial Aid modules, approximately 150 users are working in production while others develop upcoming functionality.

Those immersed in the world of development are preparing for enrollment, advising, and financial services rollouts in March 2009. Team members and stakeholders are testing, preparing training materials, setting up security, developing required functionality, and doing all the technical work that underpins the system.

“We are in the steep part of the project curve,” says Teresa Wimmer, SSP Project Manager and Technical Director. “We have our climbing shoes on and are measuring our progress to be sure we hit the summit on time, while making sure there is no avalanche where we already have climbed.”

Tackling Points of Contact

You might be surprised by the far-reaching implications of a student changing his or her name. It is a sleuthing job to tie the new name to the old name. Under which name is a transcript produced? Is this graduate school applicant the same person who was previously employed at the University?

Name changing is an example of a process that ripples through an integrated system such as the Student Information System (SIS). The new SIS is configured by modules: Admission, Student Records, Financial Aid, and Student Accounts. But as an integrated system, there are points of contact between these modules, often facilitated by a module called Campus Community. In the Campus Community module reside all prospect/applicant/student bio-demo data such as names and addresses, residency, and emergency contacts that are shared by the other modules.

Policies and processes that have implications across modules are among the most complex to map, according to Susan Barr, SSP Director. To address those points of contact and ensure that nothing is overlooked, SSP team members and key stakeholders regularly gather at “Student Lifecycle” meetings to follow a student’s path from application through graduation and beyond, identifying these cross-module processes and their outcomes.

Meetings involve stakeholders from key areas across the University, including Student Financial Services, Office of the University Registrar, School of Continuing and Professional Studies, the Graduate School of Arts & Sciences, Athletics, and the Comptroller’s Office. Each views the student from a slightly different vantage point, bringing a wide perspective to the discussion.  The group serves to prepare process documentation which is then shared with the Deans’ Designees and Core Advisors to the Student System.

In response to the concern about the validity of a person’s name(s) in the system, the participants in the Student Lifecycle meetings worked with SSP to develop a business process regarding who and by what process a primary name can be changed, when to use which name, and how to track multiple names in the system.

Another area with cross-module implications is the assignment of service indicators, commonly known as holds, which restrict a student’s ability to perform a process, such as enroll in classes, until the service indicator is resolved.

"There are over 50 types of service indicators, primarily for academic, financial, or honor purposes," says Barr. "In the new SIS, each type of service indicator can have multiple reasons associated with it, and each reason has a message assigned that students will see in their Student Center view, explaining what they must do to resolve the hold."

The construction of a table to identify the service indicators, reasons, and messages was initiated through the Student Lifecycle meetings and then vetted with SSP governance groups.

“It is the goal of the Student System Project to leave no stone unturned in analyzing and addressing all the elements of a student’s life at the University of Virginia as they relate to the student information system," says Barr. "We are fortunate to have the full participation and advice of our stakeholders in order for our processes to be as completely identified and mapped as possible.”


February 2009

The Countdown Begins

Beginning the week of March 16, everything will be in place for fall 2009 enrollment through the new Student Information System (the SIS). This is what the University has been driving toward for three years: getting applicants, students, courses, classes, and the financial infrastructure required to process financial aid and tuition deposits in place for students to enroll and faculty to advise.

Getting Students and Faculty Ready for the SIS
In anticipation, the Student System Project has published an online SIS Student Center demo and a Faculty Center demo, viewable from the SSP website. The Student Center demo provides an overview of how students will enroll in classes, apply for financial aid, pay bills on line, and more. The Faculty Center demo provides an overview of how faculty will view class lists, submit grades, and view information about advisees.

Also in the works are a Student Center Guide and a Faculty Center Guide that will be available through the SIS portal (the Faculty Guide also will be distributed in print) and just-in-time demos of specific self service functionality. The guides and demos will include information about class wait list and permission list as well as step-by-step processes associated with this functionality.

There will be a transition period from spring through summer 2009, when students and faculty will do some things in ISIS and some in the SIS. To help navigate this transition, the ISIS link from the University of Virginia homepage will be renamed ISIS/SIS and will open to an interim webpage that will provide a road map to “what occurs where” during this transition period. The page will become available the week of March 16, when students and faculty can access the SIS.

“SSP governance groups and student focus groups that have seen the Student Center and Faculty Center have given the SIS very positive reviews,” reports Chris Doran, User Services Team Lead. “The consensus is that web-wise students and faculty will be able to find their way around easily, especially with the self-help options that will be available."

Getting Administrative Users Ready for the SIS
Administrative users of ISIS are in the throes of being trained to use the SIS. Over 100 people are receiving instructor-led training in the various Student Records roles. A subset of users also is being trained on how to run reports on Student Records information. An additional 400 will complete Student Records Viewer training online.

“I feel well trained and ready to go,” says Mark DeNoble, registrar for the School of Nursing. “The materials were thorough, the instruction was very good, and it was helpful to be able to do the processes as we went along.”

A “sandbox” environment has been created for administrative users to practice in after training and before the rollout. In addition, training materials are being posted to the SIS website.

Getting the SIS Ready for Users
The SSP team and key stakeholders are heavily engaged in testing and training to ensure that the system is ready for users and the users are ready to use the system. Final touches are being applied to features the team has developed to meet particular University requirements that did not come built in.

“We will do enrollment and advising for the first time in the SIS this spring, and though the decisions and resulting system setup have occurred well within the project’s schedule, there is much to do in the final weeks prior to this rollout,” says Susan Barr, SSP Director. “Our goal is for the system to work well right away, but just as importantly, we are putting processes in place - as are our stakeholders in the schools and departments - to deal quickly and effectively with issues that may arise.  The benefit to the University of having these functions roll out this spring is that we and our stakeholders have had the time to focus on communications with students, faculty, and administrative users around the new functionality, and on creating various structures for users to receive help or learn about the SIS.”


March 2009

Students Enroll in the SIS

When Enrollment and Advisement rolled out for the SIS on March 16, it took only three days for thousands of students and faculty to check it out. Advisors began lifting holds and students explored fall course offerings and put them into their Enrollment Requests, awaiting their enrollment times.

Beginning April 6, undergraduates began enrolling for fall 2009 classes using their SIS Student Center. By April 8, 2,285 students had enrolled in 27,826 credits, for an average of about 12 credits per student. Enrollment appointments continue through April 17.

Admission offers are on line and students are accepting their offer and paying their deposits on line. Admitted applicants are able to see their financial aid packages online as well as set up payment plans.

The SSP team, Student Financial Services, and UREG continue to monitor performance and respond to questions in order to ease transition to the new system.


July 2009

Focus on Finance

Students can now see their account balances in their SIS Student Center and can link to Nelnet to make payments and set up payment plans.

Student Finance functionality rolled out the week of July 6th, just in time for disbursement of aid for summer term and processing of refunds, both of which will be reflected in the Student Center.

The conversion of account balances from ISIS to the SIS was completed June 28. The SIS is now the system of record for student account information, and no further financial information will be entered into ISIS.

“The conversion of student accounts from ISIS to the SIS has been particularly complex,” says Susan Barr, SSP director. “It touches not only ISIS, but the Integrated System as well. It has required extraordinary coordination between SSP, Student Financial Services, Accounting Services, Procurement Services, Office of Sponsored Programs, the auxiliaries, and Integrated System Deployment & Support (ISDS). We appreciate the cooperative spirit and willingness to help of everyone involved to meet this milestone of the SSP.”

SIS Stats:

Bottom line: it’s working, and getting better!

Were there issues?  “Yes,” says Susan Barr, SSP Director. “The SIS works, it is different than ISIS, and issues have been identified by students, faculty, and administrative users, as was expected.  By rolling the system out to enrolled students, we have been able to respond to users’ issues by providing FAQs, adding help messages to the SIS portal, adjusting the functionality in the context of the project’s guiding principles, and tweaking the technical systems.” 

Some functionality has been enhanced since rollout based upon the urgency of the need, while other more complex issues continue to be evaluated.

"For example, an early and frequent request was for administrative users to be able to view unofficial transcripts, as faculty and students were able to do," according to Robert LeHeup, Student Records team lead. "This turned out to be a relatively easy change for our technical team, and we will be announcing the expanded availability of unofficial transcripts shortly."

Requests for enhancements to the system have been logged and are being reviewed and prioritized for when resources are available to implement them until the project ends in December 2009, says Barr.  “As long as we have deadlines to meet for additional rollouts, those are our first priority,” she explains. “However, within those constraints, the easier the enhancement and the greater its impact, the sooner we will might turn our attention to it.”

In the meantime, SSP, with support from undergraduate admission, graduate admission offices, UREG, and SFS, continues to respond to any questions from students, faculty, and staff as they adapt to the new system.


September 2009

The SIS Academic Circle Closes and Begins Anew

When graduation functionality is rolled out this fall, the first academic circle for the first class of students in the new Student Information System (SIS) will be completed.  And yet, a new circle already has begun for a second crop of prospective students expressing an interest in U.Va. via the SIS Portal; a second round of applicants preparing to submit applications  to U.Va. through the Common Application; and currently enrolled students who soon will prepare to course enroll for spring term.

A retrospective review of the SIS rollout and SIS activities over the past few months reveals that:

A number of enhancements have been implemented in response to SIS user requests (an enhancements list will be maintained on the SIS Help Center website):

The Student System Project team continues to review issues reported to the Help Desk and to work with undergraduate and graduate admission offices and schools, the University Registrar, Student Financial Services, and other SIS users to address issues that arise. For example, unanticipated issues arose from the initial setup of the add/drop calendar and course waitlist functionality. While a manual workaround was developed for this semester, the schools have met to discuss changes that will prevent these issues in the future.

The first academic cycle for add/drop using the SIS in fall 2009 reflects a new system up and running; the second cycle will reflect improvements to system set up and business process in response to the learning curve of the first cycle.